[STM32F103] velocidade max. GPIO?

[tcpipchip]

Tem cache de código no stm32f429 ?

[Fervolt]

Rodrigo_P_A,

Vou fazer o teste hoje, ontem não consegui mexer.

Mas, cheguei a conclusão que pra fazer isso que eu preciso do jeito que eu imaginei, não vou conseguir com processamento em série, precisa ser muito rápido e alguns sinais precisam ser gerados simultaneamente. Estive lendo, o que daria conta do recado seria FPGA, não tenho neurônios suficientes pra isso...kk

Vou pensar numa outra forma de fazer, com ci´s discretos mesmo.

Obrigado!

[Fervolt]

Rodrigo_P_A,

Fiz o teste, interessante mesmo, não tinha feito isso antes.

Com 10 linhas daquele comando, deu 17.3MHz.

Eu também não sabia do cache interno desse uC.

Valeu!

[Rodrigo_P_A]

Tem cache de código no stm32f429 ?

Num sei hehe, por isso pedi para ele testar... eu ainda to nos NXP LPC.

Fiz muitas brincadeiras assim, outra dica é, use variáveis " int " ( de 32 bits ) pois ele processa mais rápido do que outros tipos.

[RobL]

Cache?
Não sei quantos ciclos têm um desvio incondicional no ARM CM3 ou CM4 e quantos ciclos têm um XOR. Para não procurar no manual vou usar outro micro.

Um exemplo no AVR fica simples de entender pois cada clock executa um ciclo de instrução.

Sei de cabeça que para um AVR, um xor 1 ciclo e um desvio incondicional “true” 2 ciclos.
Lembro que após o XOR executará um desvio incondicional e novamente o XOR ...
Portanto, para um clock de 20Mhz o primeiro código (com um só XOR) vai mudar o estado da saída a cada 3 ciclos ( 1XOR+2 Incondicional) . O período terá 6 ciclos e portanto F= 20Mhz/6ciclos = 3,3Mhz, na porta.

Para o código com dez XOR, haverá 1 ciclo para cada mudança na porta e só no final do loop um desvio incondicional de 2 ciclos. Se medido por um osciloscópio, com preço para os mortais, ele vai mostrar graficamente no display a assimetria(corretamente) no momento do desvio incondicional, mas o cálculo apresentado da frequência no display será de F= 20Mhz/2ciclos= 10Mhz !!!
Isto por que no momento do desvio incondicional, o scope inicia um novo cálculo devido a variação (aumento) do tempo para 1+2 ciclos (1 do xor e 2 do desvio) e ao final desse ciclo o scope percebe nova assimetria, caindo novamente para 1 ciclo (dos xor) . Aguarda alguns ciclos simétricos para recalcular a frequência. O resultado será novamente 10Mhz.

Concluímos que com um só XOR e um desvio incondicional torna a operação simétrica. Com a sequência de dez XOR aumentará a frequência, neste trecho, mas ao gerar o desvio incondicional gera uma assimetria.
O aumento da frequência se deu devido aos dez XOR com 1 ciclo, comparado ao primeiro código onde cada transição leva 3 ciclos.
No ARM Cortex3 ou 4 acontecerá da mesma forma, o desvio incondicional poderá ter 1 ciclo ou 1+P ciclos.
Suponho não ter nada de cache influenciando esse aumento da frequência.

Minha consulta no site ARM para tirar essa dúvida:
ARM M0 a M4 não tem cache são para propósitos gerais. Exemplo com cache: ARM940 ou SARM946E-S o número 4 na sequencia numérica significa cache.

[Rodrigo_P_A]

Cache?
Não sei quantos ciclos têm um desvio incondicional no ARM CM3 ou CM4 e quantos ciclos têm um XOR. Para não procurar no manual vou usar outro micro.

Um exemplo no AVR fica simples de entender pois cada clock executa um ciclo de instrução.

Sei de cabeça que para um AVR, um xor 1 ciclo e um desvio incondicional “true” 2 ciclos.
Lembro que após o XOR executará um desvio incondicional e novamente o XOR ...
Portanto, para um clock de 20Mhz o primeiro código (com um só XOR) vai mudar o estado da saída a cada 3 ciclos ( 1XOR+2 Incondicional) . O período terá 6 ciclos e portanto F= 20Mhz/6ciclos = 3,3Mhz, na porta.

Para o código com dez XOR, haverá 1 ciclo para cada mudança na porta e só no final do loop um desvio incondicional de 2 ciclos. Se medido por um osciloscópio, com preço para os mortais, ele vai mostrar graficamente no display a assimetria(corretamente) no momento do desvio incondicional, mas o cálculo apresentado da frequência no display será de F= 20Mhz/2ciclos= 10Mhz !!!
Isto por que no momento do desvio incondicional, o scope inicia um novo cálculo devido a variação (aumento) do tempo para 1+2 ciclos (1 do xor e 2 do desvio) e ao final desse ciclo o scope percebe nova assimetria, caindo novamente para 1 ciclo (dos xor) . Aguarda alguns ciclos simétricos para recalcular a frequência. O resultado será novamente 10Mhz.

Concluímos que com um só XOR e um desvio incondicional torna a operação simétrica. Com a sequência de dez XOR aumentará a frequência, neste trecho, mas ao gerar o desvio incondicional gera uma assimetria.
O aumento da frequência se deu devido aos dez XOR com 1 ciclo, comparado ao primeiro código onde cada transição leva 3 ciclos.
No ARM Cortex3 ou 4 acontecerá da mesma forma, o desvio incondicional poderá ter 1 ciclo ou 1+P ciclos.
Suponho não ter nada de cache influenciando esse aumento da frequência.

Minha consulta no site ARM para tirar essa dúvida:
ARM M0 a M4 não tem cache são para propósitos gerais. Exemplo com cache: ARM940 ou SARM946E-S o número 4 na sequencia numérica significa cache.

Estou considerando como cache o tamanho do pipeline, a quantidade de dados que ele lê à frente do código que está sendo executado, ele tem uma área de memória RAM que trabalha na velocidade do CLOCK do processador para compensar a lentidão da flash, você habilita ou desabilita tal função via registradores, eu deduzi que os ST tenham algo parecido.
Nos LPC (ARM7, CM3) funciona como um "CACHE", tanto é, que quando desativamos tal função percebe-se a diminuição da velocidade no processamento.
Não conheco os ST.

Complementando, faça o teste declarando outros tipos de variáveis, e vai perceber que ele é mais lento para trabalhar com palavras com menos de 32 bits.

[RobL]

Outros tipos de dados pode gerar penalidades com determinadas instruções. O que seria feito em 1 ciclo pode levar mais de um. Isto vai impactar no resultado final da velocidade.
Entendi quanto ao "cache" que se refere.

[mastk]

Estou com os mesmo problema com um KL25Z40 da NXP e é de cair o *u da cara ter que pensar em cache e pipeline para acionar um GPIO, vai se hidratar pelo outro extremo do sistema digestivo.
Genitaria masculina...

[msamsoniuk]

essas discussoes sobre performance de GPIO sao divertidas, mas profundamente improdutivas. depois de anos e anos acompanhando esse tipo de coisa, a unica conclusao logica que eu observo eh "nunca tente fazer em software o que vc DEVE fazer em hardware". primeiro que eh um grande desperdicio de recursos computacionais: bem lembro de um computador cujo refresh de video era feita por software e isso consumia 75% da performance do processador, sobrando livre apenas os 25% referentes ao retraco vertical. era algo aceitavel na epoca, em que as pessoas usavam o computador como um brinquedo e se maravilhavam com qualquer porcaria e nao davam muito valor para o dinheiro, mas hoje em dia seria tao inaceitavel quanto encontrar uma promocao do mercado "pague 4 e leve 1". segundo que a medida que os processadores ficam mais complexos, eles ficam menos deterministicos. entao calcular tempo via software comeca a ficar complicado: vc pode ateh usar um timer ou sinal de trigger para calibrar o tempo, mas fatidicamente vai ter um certo jitter para responder. terceiro e ultimo eh que querer fazer tudo por software em pleno seculo XXI eh, no minimo, personificar um senhor da inquisicao. lah na decada de 70 ateh seria justificavel, visto que o hardware era todo discreto e complexo, mas hoje em dia nao parece existir justificativa: todo fabricante embute uma boa quantidade de hardware integrado, variando de timers a canais de DMA, de modo que o software fique restrito a tarefas de controle e gerenciamento. em tempo, fazer as coisas por software nao eh pecado, mas fazer vista grossa para o hardware que esta disponivel certamente beira a burrice!

solucao simples para o problema de performance de GPIO: DMA + FIFO. via DMA vc transfere dados com mais performance do que usando o processador, inclusive deixando o processador livre para outras tarefas de controle. embora a banda de memoria seja dividida, as transferencias via DMA possuem menos overhead. literalmente, o controlador de DMA eh um memcpy() codificado em hardware, onde toda a parte "chata" de incrementar ponteiros, decrementar contador, testar, etc eh feita pelo hardware, em paralelo e sem intervencao do processador. o problema eh que o DMA eh um canhao: para otimizar os acessos, eh interessante fazer as transferencias em burst (blocos). e como ele divide espaco com o processador, esta sujeito a um certo jitter referente a esse compartilhamento. entao uma FIFO resolve os dois problemas: recebe as transferencias em burst e ajusta para a velocidade nominal que vc quer ter no GPIO. ao mesmo tempo, limpa o jitter que o compartilhamento de barramento injeta nas transferencias. o resultado eh seu GPIO transferindo dados continuamente, de forma brutalmente veloz e precisa. sobre a FIFO, tem que considerar o periferico: alguns jah possuem FIFOs integradas. entao ao inves de despejar tudo em um GPIO, eventualmente, pode optar por um componente externo mais especializado que jah possui FIFO. por exemplo, ao inves de conectar um ADC diretamente no GPIO e puxar o DMA diretamente, um ADC com FIFO e bus pode ser uma opcao melhor, pq essa FIFO integrada jah absorve os problemas de jitter que o DMA vai ter. e se o bus for mais largo que os dados efetivos (bus de 32 bits para um ADC de 8 bits, por exemplo), vc multiplica a performance (no exemplo, 4x).

[Rodrigo_P_A]

essas discussoes sobre performance de GPIO sao divertidas, mas profundamente improdutivas. depois de anos e anos acompanhando esse tipo de coisa, a unica conclusao logica que eu observo eh "nunca tente fazer em software o que vc DEVE fazer em hardware". primeiro que eh um grande desperdicio de recursos computacionais: bem lembro de um computador cujo refresh de video era feita por software e isso consumia 75% da performance do processador, sobrando livre apenas os 25% referentes ao retraco vertical. era algo aceitavel na epoca, em que as pessoas usavam o computador como um brinquedo e se maravilhavam com qualquer porcaria e nao davam muito valor para o dinheiro, mas hoje em dia seria tao inaceitavel quanto encontrar uma promocao do mercado "pague 4 e leve 1". segundo que a medida que os processadores ficam mais complexos, eles ficam menos deterministicos. entao calcular tempo via software comeca a ficar complicado: vc pode ateh usar um timer ou sinal de trigger para calibrar o tempo, mas fatidicamente vai ter um certo jitter para responder. terceiro e ultimo eh que querer fazer tudo por software em pleno seculo XXI eh, no minimo, personificar um senhor da inquisicao. lah na decada de 70 ateh seria justificavel, visto que o hardware era todo discreto e complexo, mas hoje em dia nao parece existir justificativa: todo fabricante embute uma boa quantidade de hardware integrado, variando de timers a canais de DMA, de modo que o software fique restrito a tarefas de controle e gerenciamento. em tempo, fazer as coisas por software nao eh pecado, mas fazer vista grossa para o hardware que esta disponivel certamente beira a burrice!

solucao simples para o problema de performance de GPIO: DMA + FIFO. via DMA vc transfere dados com mais performance do que usando o processador, inclusive deixando o processador livre para outras tarefas de controle. embora a banda de memoria seja dividida, as transferencias via DMA possuem menos overhead. literalmente, o controlador de DMA eh um memcpy() codificado em hardware, onde toda a parte "chata" de incrementar ponteiros, decrementar contador, testar, etc eh feita pelo hardware, em paralelo e sem intervencao do processador. o problema eh que o DMA eh um canhao: para otimizar os acessos, eh interessante fazer as transferencias em burst (blocos). e como ele divide espaco com o processador, esta sujeito a um certo jitter referente a esse compartilhamento. entao uma FIFO resolve os dois problemas: recebe as transferencias em burst e ajusta para a velocidade nominal que vc quer ter no GPIO. ao mesmo tempo, limpa o jitter que o compartilhamento de barramento injeta nas transferencias. o resultado eh seu GPIO transferindo dados continuamente, de forma brutalmente veloz e precisa. sobre a FIFO, tem que considerar o periferico: alguns jah possuem FIFOs integradas. entao ao inves de despejar tudo em um GPIO, eventualmente, pode optar por um componente externo mais especializado que jah possui FIFO. por exemplo, ao inves de conectar um ADC diretamente no GPIO e puxar o DMA diretamente, um ADC com FIFO e bus pode ser uma opcao melhor, pq essa FIFO integrada jah absorve os problemas de jitter que o DMA vai ter. e se o bus for mais largo que os dados efetivos (bus de 32 bits para um ADC de 8 bits, por exemplo), vc multiplica a performance (no exemplo, 4x).

Concordo que num se deve fazer o que deve ser feito por HW em SW.
Mas quis mostrar para os colegas do fórum uma coisa que a maioria num se atenta sobre o pipeline , cache e diferença quando se usa determinados tipos de dados no ARM.

[Fervolt]

Caro msamsoniuk, concordo com o que você escreveu exceto um ponto, de que essas discussões são "profundamente improdutivas'. Acredito que todos querem fazer seus projetos da melhor forma e o mais eficiente possível.
Eu postei essa dúvida, pois fiquei meio desapontado com os resultados de um simples teste, porque um microcontrolador que tem seu núcleo rodando a 72MHz entrega só 3,2MHz num pino? claro que não pensei que saísse algo próximo do clock, mas achei que é muito pouco.
Esse tópico me agregou informações interessantes, como o caso do "cache", que eu desconhecia até então.
Essa questão de programar microcontroladores eu tenho como hobby, apesar de conseguir fazer algumas coisas aqui, não tenho vivência.
Agradeço a todos que responderam.
De fato, o que eu consegui fazer até agora está de acordo com o que você recomendou, estou terminando um gerador de vídeo para testes de monitores de máquinas e estou usando timers com interrupção para gerar os sinais de sincronismo horizontal e vertical e o sinal de vídeo é gerado usando DMA + SPI. A performance é excelente não consome quase nada de processamento, esse meu projeto tem como base o do link https://www.artekit.eu/vga-output-using-a-36-pin-stm32/ sendo que o que coloquei a mais foi a possibilidade de poder ajustar as frequências de varredura através de um LCD 320x240 e um encoder rotativo.
A conversão dos sinais de vídeo resolvi deixar quieto por enquanto.

Valeu!

[msamsoniuk]

ufa! ainda bem que vc usou a cabeca!

Caro msamsoniuk, concordo com o que você escreveu exceto um ponto, de que essas discussões são "profundamente improdutivas'. Acredito que todos querem fazer seus projetos da melhor forma e o mais eficiente possível.
Eu postei essa dúvida, pois fiquei meio desapontado com os resultados de um simples teste, porque um microcontrolador que tem seu núcleo rodando a 72MHz entrega só 3,2MHz num pino? claro que não pensei que saísse algo próximo do clock, mas achei que é muito pouco.
Esse tópico me agregou informações interessantes, como o caso do "cache", que eu desconhecia até então.
Essa questão de programar microcontroladores eu tenho como hobby, apesar de conseguir fazer algumas coisas aqui, não tenho vivência.
Agradeço a todos que responderam.
De fato, o que eu consegui fazer até agora está de acordo com o que você recomendou, estou terminando um gerador de vídeo para testes de monitores de máquinas e estou usando timers com interrupção para gerar os sinais de sincronismo horizontal e vertical e o sinal de vídeo é gerado usando DMA + SPI. A performance é excelente não consome quase nada de processamento, esse meu projeto tem como base o do link https://www.artekit.eu/vga-output-using-a-36-pin-stm32/ sendo que o que coloquei a mais foi a possibilidade de poder ajustar as frequências de varredura através de um LCD 320x240 e um encoder rotativo.
A conversão dos sinais de vídeo resolvi deixar quieto por enquanto.

Valeu!

[pamv]

Eu só fiquei com uma dúvida

O título do post é

[STM32F103] velocidade max. GPIO?

e o "context switch" sobre cache começou após a pergunta:

Tem cache de código no stm32f429 ?

no final, o que estava em discussão stm32f1 ou stm32f4 ?