O que é HAL_

[eletroinf]

Usa um timer para gerar os delays.

Eu uso o SysTick

Aproveita pra fazer variáveis para cada timer, de forma a não bloquear o processador na rotina de tempo.

[KrafT]

Caramba, me deu um nó na cabeça...me ajudem.

Como eu calculo o tempo de processamento? O meu clock é de 72mhz no stm32f103, como eu faço a conta para saber exatamente o tempo de cada ciclo, para poder gerar meus delays com maior precisão.
Affi...deu branco

Bom, com os ARM não são mais válidos os mesmos paradigmas da programação "assembly para PIC".

Tens que mudar teu "mindeset" se não ti não vai sair do lugar.

Vc diz que não gosta de software feito por terceiros, mas já pensou em reescrever um simples stack TCP? Ou USB?

Rotina de delay contando ciclos de máquina? Tais doido? Tu mesmo "desrecomendou" esse método em um post anterior.

No máximo algum "nop()" avulso para acertar coisas críticas.

[eletroinf]

Eu faço tipo assim (ajusta o intervalo de interrupção de acordo com a necessidade)

Código: Selecionar todos

// Ajusto o Systick, fonte de clock = 72 MHz/8 = 9 MHz.
   SysTick -> LOAD = 900;      // Reload value. Para base de tempo de 100 us
   SysTick -> CTRL = BIT_1 + BIT_0;   // Liga o SysTick e habilita int. Linha 2873 do my_stm32f10x.h

E daí na interrupção eu decremento as variáveis de timers:

Código: Selecionar todos

/*******************************************************************
 Interrupção do SysTick, ocorre a cada 100 us
- base de tempo;
- Timers
********************************************************************/
void SysTick_Handler(void)
{
   static unsigned short int cnt = 500;
   static unsigned char cnt_10 = 9;

   if(cnt)   cnt--;
   else
   {
      cnt = 500;
   }

   if(cnt_10)   cnt_10--;
   else
   {
      cnt_10 = 9;
      if(delay_ms_0)      delay_ms_0--;      // Timer.
      if(delay_ms_disp)   delay_ms_disp--;   // Timer das funções do display.
      if(delay_ms_hw)      delay_ms_hw--;      // Timer do arquivo hw.c
   }

}

Quer maior barbada que isso?

[cfreund]

Tem mais algumas implicações ao se optar por não usar HAL do fabricante e, uma delas é bem importante: updates ou correções de bug do componente.

Por padrão, deve-se utilizar HAL.

Somente em alguns casos como otimizações ou no primeiro contato com a arquitetura faz bem abrir mão.

Sem CMSIS, acho que ARM não estaria tão difundido e funcionando relativamente bem como hoje em dia.

[Guri]

Eu faço tipo assim (ajusta o intervalo de interrupção de acordo com a necessidade)

Código: Selecionar todos

// Ajusto o Systick, fonte de clock = 72 MHz/8 = 9 MHz.
   SysTick -> LOAD = 900;      // Reload value. Para base de tempo de 100 us
   SysTick -> CTRL = BIT_1 + BIT_0;   // Liga o SysTick e habilita int. Linha 2873 do my_stm32f10x.h

E daí na interrupção eu decremento as variáveis de timers:

Código: Selecionar todos

/*******************************************************************
 Interrupção do SysTick, ocorre a cada 100 us
- base de tempo;
- Timers
********************************************************************/
void SysTick_Handler(void)
{
   static unsigned short int cnt = 500;
   static unsigned char cnt_10 = 9;

   if(cnt)   cnt--;
   else
   {
      cnt = 500;
   }

   if(cnt_10)   cnt_10--;
   else
   {
      cnt_10 = 9;
      if(delay_ms_0)      delay_ms_0--;      // Timer.
      if(delay_ms_disp)   delay_ms_disp--;   // Timer das funções do display.
      if(delay_ms_hw)      delay_ms_hw--;      // Timer do arquivo hw.c
   }

}

Quer maior barbada que isso?

Caro, você fez delay de uma forma muito inteligente e bonita, parabéns.
Usar um TMR para gerar uma base única na interrupção e setar por flags, muito bom.
Assim fica mais intuitivo gerar delays, apenas ajustando a base principal

[Guri]

Caramba, me deu um nó na cabeça...me ajudem.

Como eu calculo o tempo de processamento? O meu clock é de 72mhz no stm32f103, como eu faço a conta para saber exatamente o tempo de cada ciclo, para poder gerar meus delays com maior precisão.
Affi...deu branco

Bom, com os ARM não são mais válidos os mesmos paradigmas da programação "assembly para PIC".

Tens que mudar teu "mindeset" se não ti não vai sair do lugar.

Vc diz que não gosta de software feito por terceiros, mas já pensou em reescrever um simples stack TCP? Ou USB?

Rotina de delay contando ciclos de máquina? Tais doido? Tu mesmo "desrecomendou" esse método em um post anterior.

No máximo algum "nop()" avulso para acertar coisas críticas.

Meu amigo, eu não gosto mesmo de utilizar coisas prontas, prefiro perdem tempo e neurônios e criar libs é mais seguro. Já me lasquei no inicio, cheguei a utilizar rotinas prontas em C e tomei na jaca...Mas cada um tem seus gostos e não vou discutir, não tô fora

Até confesso que gosto de provocar um pouco os caros amigos os quais tenho grande carinho e sou muito grato a todos sem excessões pela enorme contribuição ao forum.
As vezes vejo esse forum quietinho e gosto de dar umas cutucadas, perdoem o véio vonilmam.

[Guri]

Tem mais algumas implicações ao se optar por não usar HAL do fabricante e, uma delas é bem importante: updates ou correções de bug do componente.

Por padrão, deve-se utilizar HAL.

Somente em alguns casos como otimizações ou no primeiro contato com a arquitetura faz bem abrir mão.

Sem CMSIS, acho que ARM não estaria tão difundido e funcionando relativamente bem como hoje em dia.

Vendo por esse lado, suas informações são muito coerentes e devem ser levadas em consideração.
No inicio eu também concordo que utilizar um plano digamos mais visível da arquitetura como um todo é muito mais confortável.

Andei vendo os comandos em HAL_ na apostila da ST e são complexas no inicio, mas é como você disse, ao ponto que se vai amadurecendo a mente a programação automáticamente vai pedir para olhar para o HAL_, e sem dúvida, se fizeram uma plataforma CMSIS foi justamente para fazer o ARM rodar melhor com os periféricos pedurados neles e ninguém melhor que o fabricante do chip para oferecer isso.

Obrigado

[Guri]

Eu achei o trustudio muito legal, principalmente pelo elegante gerador inicializador de periféricos o CUBE.
Vou estudar as HAL_ com mais carinho e vou tentar arranhar alguma coisas no intuito de entender e aprender sobre elas.

Obrigado a todos,

[KrafT]

Grande Guri, lembra que eu disse acima, que eu bagunço os HAL e CMSIS e depois só me ferro. Não quero que o amigo caia na mesma armadilha.

Mas verás que depois dessa fase de conhecer a arquitetura , tanto software como hardware, é muito mais produtivo usar as bibliotecas existentes do que escrever as próprias, sempre que possível. Ainda mais num projeto feito em time. Teus funcionários podem usar bibliotecas já testadas e validadas, sem ter que esperar por ti.

Claro que tudo tem exceções, mas estamos falando do 80, não do 20.

[dreher]

O HAL teoricamente era para ter a compatibilidade entre qualquer fabricante que licenciasse o nucleo certo? O fabricante disponibiliza as bibliotecas no padrão HAL e tu só faz a regra do negocio. Eu tambem não curti muito mas estou me obrigando agora a trabalhar com eles, até porque ferramentas como o STM32Cube geram toda a inicialização com o HAL e facilitam muito a vida. O problema é a preguiça sempre de mudar de plataforma. Usei o Coocox muito tempo, agora mudar para o STM, mudar de baremetal para RTOS, mudar de EAGLE para o Kicad, mudar de office para openoffice, windows para linux, e assim vai...

[Guri]

O HAL teoricamente era para ter a compatibilidade entre qualquer fabricante que licenciasse o nucleo certo? O fabricante disponibiliza as bibliotecas no padrão HAL e tu só faz a regra do negocio. Eu tambem não curti muito mas estou me obrigando agora a trabalhar com eles, até porque ferramentas como o STM32Cube geram toda a inicialização com o HAL e facilitam muito a vida. O problema é a preguiça sempre de mudar de plataforma. Usei o Coocox muito tempo, agora mudar para o STM, mudar de baremetal para RTOS, mudar de EAGLE para o Kicad, mudar de office para openoffice, windows para linux, e assim vai...

Realmente mudanças no nosso ramo de trabalho é um Óh...só

[Guri]

Grande Guri, lembra que eu disse acima, que eu bagunço os HAL e CMSIS e depois só me ferro. Não quero que o amigo caia na mesma armadilha.

Mas verás que depois dessa fase de conhecer a arquitetura , tanto software como hardware, é muito mais produtivo usar as bibliotecas existentes do que escrever as próprias, sempre que possível. Ainda mais num projeto feito em time. Teus funcionários podem usar bibliotecas já testadas e validadas, sem ter que esperar por ti.

Claro que tudo tem exceções, mas estamos falando do 80, não do 20.

Sabias e bem colocadas palavras, amigo Kraft. Pelo que entendi a libs criadas no HAL_ foram feitas pelo próprio fabricante, isso dá maior confiabilidade de uso, sem dúvidas.
Aprendi muito aqui com vocês todos e quero agradecer muito a todos.

[Guri]

A ideia do eletroinf é muito elegante e bem sacada...parabéns, meu amigo.

[Guri]

Alguém ai sabe onde conseguir o FW do stlink-v2?
Esse FW é disponibilizado pela ST...pelo menos o código compilado!

[sync]

Alguém ai sabe onde conseguir o FW do stlink-v2?
Esse FW é disponibilizado pela ST...pelo menos o código compilado!

Amigo:
Não sei se entendi
É só clicar no aplicativo que ele atualiza o firmware do stlink