Entrar    Registrar

[STM32F103] velocidade max. GPIO?

Software e Hardware para linha ARM

Moderadores: guest2003, 51, Renie, gpenga

  • Autor
    Mensagem

Re: [STM32F103] velocidade max. GPIO?

Mensagempor tcpipchip » 10 Fev 2017 08:04

Tem cache de código no stm32f429 ?
------------------------------------------
http://www.youtube.com/tcpipchip
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 5610
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Re: [STM32F103] velocidade max. GPIO?

Mensagempor Fervolt » 10 Fev 2017 08:48

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
Bit
 
Mensagens: 17
Registrado em: 18 Abr 2014 11:40

Re: [STM32F103] velocidade max. GPIO?

Mensagempor Fervolt » 11 Fev 2017 16:17

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!
Fervolt
Bit
 
Mensagens: 17
Registrado em: 18 Abr 2014 11:40

Re: [STM32F103] velocidade max. GPIO?

Mensagempor Rodrigo_P_A » 13 Fev 2017 06:58

tcpipchip escreveu: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.
---
Avatar do usuário
Rodrigo_P_A
Dword
 
Mensagens: 1924
Registrado em: 12 Out 2006 18:27
Localização: Osasco - S.P - Brasil

Re: [STM32F103] velocidade max. GPIO?

Mensagempor RobL » 18 Mar 2017 17:05

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.
RobL
Dword
 
Mensagens: 1546
Registrado em: 20 Fev 2007 17:56

Re: [STM32F103] velocidade max. GPIO?

Mensagempor Rodrigo_P_A » 19 Mar 2017 09:51

RobL escreveu: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.
---
Avatar do usuário
Rodrigo_P_A
Dword
 
Mensagens: 1924
Registrado em: 12 Out 2006 18:27
Localização: Osasco - S.P - Brasil

Re: [STM32F103] velocidade max. GPIO?

Mensagempor RobL » 19 Mar 2017 12:08

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.
RobL
Dword
 
Mensagens: 1546
Registrado em: 20 Fev 2007 17:56

Re: [STM32F103] velocidade max. GPIO?

Mensagempor mastk » 21 Mar 2017 16:43

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...
Sim, mesmo se alguém conquistar apenas uma alma, uma única alma em todo o mundo. Mas aquele que não foi capaz disso, que fique chorando sozinho!

http://mastk.wordpress.com/

http://www.youtube.com/user/Mastk2008
Avatar do usuário
mastk
Dword
 
Mensagens: 4335
Registrado em: 14 Out 2006 20:43

Re: [STM32F103] velocidade max. GPIO?

Mensagempor msamsoniuk » 21 Mar 2017 18:44

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).
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2882
Registrado em: 13 Out 2006 18:04

Re: [STM32F103] velocidade max. GPIO?

Mensagempor Rodrigo_P_A » 22 Mar 2017 10:45

msamsoniuk escreveu: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.
---
Avatar do usuário
Rodrigo_P_A
Dword
 
Mensagens: 1924
Registrado em: 12 Out 2006 18:27
Localização: Osasco - S.P - Brasil

Re: [STM32F103] velocidade max. GPIO?

Mensagempor Fervolt » 22 Mar 2017 22:10

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!
Fervolt
Bit
 
Mensagens: 17
Registrado em: 18 Abr 2014 11:40

Re: [STM32F103] velocidade max. GPIO?

Mensagempor msamsoniuk » 23 Mar 2017 00:17

ufa! ainda bem que vc usou a cabeca! :)

Fervolt escreveu: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!
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2882
Registrado em: 13 Out 2006 18:04

Re: [STM32F103] velocidade max. GPIO?

Mensagempor pamv » 24 Mar 2017 01:33

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 ?
pamv
Byte
 
Mensagens: 464
Registrado em: 20 Jun 2016 21:47

Anterior

Voltar para ARM

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 4 visitantes

cron