ASM51

Olá,

Alguém pode me ajudar?
Estive esses dias mexendo aqui com um placa ARM (STM32F103VCT6) e estava tentando saber qual a velocidade máxima que conseguiria num pino como saída.
Fiz um programa bem simples onde coloquei uma linha só dentro do "loop infinito", como abaixo:

Código: Selecionar todos

while(1){
       GPIOC->ODR ^= GPIO_Pin_3;
      //asm("nop");
    }

Como podem ver, somente para ficar alernando o estado de PC3.

Configurei o clock para o máximo, com crital de 8MHz, PLL com multiplicador x9 onde, SYSCLK e APB2 seriam 72MHz. Fiz isso pelo STM32CubeMX e depois converti para usar no CooCox (1.7..

Para minha surpresa, no pino em questão só consegui 1.8MHz com CooCox e 3.2Mhz com um programa igual que fiz no Keil uVision 5.

Minha dúvida é: seria só isso mesmo? Ou tem algo que fiz de errado ou deixei de fazer para conseguir uma frequência mais alta nessa saída?

Obrigado.

Eu não cheguei a ler tudo, mas nesse tópico é discutido o assunto:

http://electronics.stackexchange.com/qu ... s-possible

Parece que tem a ver com a otimização do código.

.

eletroinf, fico grato por responder.

Realmente, pelo que entendi, a "culpa" é dos compiladores! Depois vou debugar os dois programas novamente o do CooCox e do Keil e comparar pra saber porque o do Keil roda mais rápido. O do CooCox, pelo que me lembro foi traduzido em 4 linhas de assembly a instrução em C:

Código: Selecionar todos

GPIOC->ODR ^= GPIO_Pin_3;

e não tinha nenhuma chamada ou "jumps".

Enfim, agora preciso saber como programar STM32 em assembly, numa pesquisa rápida não achei quase nada sobre isso, achei somente um exemplo de "led_blink" com um assembler (compilador) que roda em linux. Não achei o set de instruçoes.

Alguém já usou STM32 com assembly?

Obrigado.

Será que não precisa habilitar alguma otimização no compilador ???

O set de instruções você pode conseguir no documento PM0056 Programing Manual

Segue o link

www.st.com/resource/en/programming_manual/cd00228163.pdf

Estou com meu kit engavetado para quando sobrar um tempinho começar a estudar ... mas tá difícil !

Espero que ajude ...

Valeu Jairo15!

Depois vou dar uma lida melhor no manual, não parece ser fácil, mas vou tentar escrever alguma coisa pra testar.

Pelo que li, não tem um assembler próprio da ST, somente de terceiros.

Muito Obrigado!

O ARM permitem que você configure a velocidade do pino para evitar EMI e diminuir consumo, depende de como configurou o pino.....

Eu ainda não cheguei nos MCUs de 32 bits, mas acho que tem que configurar o clock da GPIO. Não sei se é padrão mas tem um parâmetro GPIO_InitStructure.GPIO_Speed num texto que eu vi. Outra coisa que pode afetar, acredito eu, é o tipo de saída: pull-up, pull-down, push-pull. Eu uso push-pull (ou toten) quando uma saída precisa de velocidade.

[url=http://]http://www.st.com/content/ccc/resource/technical/document/reference_manual/51/f7/f3/06/cd/b6/46/ec/CD00225773.pdf/files/CD00225773.pdf/jcr:content/translations/en.CD00225773.pdf[/url]

Na pagina 138

Fast toggle capable of changing every two clock cycles

Sobre a configuração do pino, está assim:

Código: Selecionar todos

 void GPIO_Configuration(void){

   GPIO_InitTypeDef GPIO_InitStructure;

   RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);

   GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
   GPIO_InitStructure.GPIO_Mode  = GPIO_Mode_Out_PP;
   GPIO_InitStructure.GPIO_Pin   = GPIO_Pin_3;
   GPIO_Init(GPIOC, &GPIO_InitStructure);
}

Para o STM32F103 os valores para GPIO_Speed são 2MHz, 10MHz ou 50MHz.

Ontem mexi na otimização de código no CooCox que por padrão é -O1, mudei para -O2 e a frequência subiu para 3.2MHz como no Keil. Mudei para -O3 e permaneceu 3.2MHz

Tcpipchip, vou olhar o link depois.

Valeu!

Sent from my SM-G925I using Tapatalk

tcpipchip,

Olhei o manual de referência, mas esse manual se aplica aos STM32F2xx, o meu é STM32F103.

Baixei o manual do STMF103 e não é citado o recurso de "fast toggle", pelo menos eu não encontrei.

link do manual:

www.st.com/content/ccc/resource/technical/document/reference_manual/59/b9/ba/7f/11/af/43/d5/CD00171190.pdf/files/CD00171190.pdf/jcr:content/translations/en.CD00171190.pdf

Hoje vou ligar uma placa discovery que tenho lá, com STM32F429, salvo engano roda até 172MHz, vou fazer esse teste e ver qual a frequência que chega com esse mesmo programa.

Valeu!

Que mal pergunte, qual a necessidade de velocidade tão alta?
Creio que seja possível usar um timer comutando o pino também.

Estou iniciando um projeto, um conversor de sinal de vídeo.

Preciso converter um sinal de vídeo de uma máquina CNC (antiga) para adaptar uma tela LCD.

Da forma que pensei em fazer, preciso de um micro suficientemente rápido, pois preciso armazenar o sinal de vídeo que vem da máquina para depois montar um sinal VGA.

Valeu!

Fervolt

Como você criou o projeto com o STM32CubeMX, sugiro que de uma olhada neste site www.openstm32.org/HomePage.

Não tenho nenhum stm32f103 que possa fazer um teste, porem usei uma STM32F4DISCOVERY configurada com clock de 168Mhz, sem otimização 'O0' consegui ~8Mhz, com otimização 'O3' ~12Mhz.

Espero que as informações te ajude.

Ivan Braga,

Exatamente! Fiz o mesmo teste ontem a noite, tenho uma discovery com stm32f429. Montei o projeto pelo Cube e gerei o código pro uVision 5 com otimização -O3 (tentei a -OFast também), configurado para 180MHz, saiu no pino 12.8MHz aprox. Mas nem sai retangular, sai meio triangular, meio senóide...kkk

Deve haver alguma outra forma de fazer isso que eu preciso, estou pensando em usar o frame que vem no sinal de vídeo da máquina, sem mexer nele, assim os sinais de sincronismo horizontal e vertical são mais tranquilos na questão tempo.

Valeu!

Nunca mexi com este micro, mas fica uma dica, faça o seguinte teste:

for (;;)
{
GPIOC->ODR ^= GPIO_Pin_3;
}

Meça o sinal, depois , faça:

for (;;)
{
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
GPIOC->ODR ^= GPIO_Pin_3;
}

E meça! Você vai ver uma coisa interessante.... por causa do cache interno