HAL stm32f4

14 views
Skip to first unread message

Miguel Moreto

unread,
Dec 4, 2014, 3:01:29 PM12/4/14
to br...@googlegroups.com
Olá Gustavo,

eu poderia enviar essa dúvida diretamente para ti, mas achei melhor escrever aqui pois talvez possa interessar outros usuários do BRTOS.

Pois bem, vi no repositório SVN que tem duas versões de HAL para o STM32F4:

1) CoIDE_gcc_STM32F4x_nesting_int
2) CoIDE_gcc_STM32F4x

Qual a diferença entre eles? quando usar um ou outro? No meu caso quero utilizar no STM32F401RE

Saudações!

Moreto

Gustavo Denardin

unread,
Dec 5, 2014, 5:44:13 PM12/5/14
to br...@googlegroups.com
Olá Miguel, tudo bem?

Desculpe a demora na resposta. Quando estava fazendo o port para os processadores ARM Cortex-Mx fiz dois possíveis ports. No entanto, o oficial é o que ficou com o final "nesting_int".

A partir da tua dúvida resolvi fazer uma alteração. O port para qualquer ARM Cortex-M3/M4 de qualquer fabricante está agora na pasta GCC_CORTEX-M4, incluindo o microcontrolador da ST que você está utilizando.

Qualquer dúvida estou a disposição.

Abraço,
Gustavo

Gustavo Weber Denardin
 Universidade Tecnológica Federal do Paraná (UTFPR)
 Campus Pato Branco - Departamento de Eng. Elétrica (DAELE)
 Via do Conhecimento, Km 1 -     Pato Branco - PR -   CEP: 85503-390
 Fone / Fax: (46) 3220-2570
 Home Page: http://pessoal.utfpr.edu.br/gustavo/

--
Você recebeu essa mensagem porque está inscrito no grupo "BRTOS" dos Grupos do Google.
Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para brtos+un...@googlegroups.com.
Para postar nesse grupo, envie um e-mail para br...@googlegroups.com.
Acesse esse grupo em http://groups.google.com/group/brtos.
Para mais opções, acesse https://groups.google.com/d/optout.

Miguel Moreto

unread,
Dec 7, 2014, 6:35:45 AM12/7/14
to br...@googlegroups.com
Obrigado Denardin,

consegui fazer funcionar o brtos aqui na Nucleo F401 com microcontrolador STM32F401RE.

No entanto, não foi "direto" e tive que fazer aquelas modificações no arquivo startup_stm32f4xx.c

Vi que no novo HAL.h já tem as definições dos interrupt handlers usados pelo BRTOS:

extern void TickTimer(void);
extern __attribute__((naked)) void SwitchContext(void);
extern __attribute__((naked)) void SwitchContextToFirstTask(void);

#define SVC_Handler SwitchContextToFirstTask
#define PendSV_Handler SwitchContext
#define SysTick_Handler TickTimer

Porém verifiquei que essas definições não estão sendo usadas e eu tive que implementar esse "mapeamento" dos vetores de interrupção diretamente lá no aquivo startup_stm32f4xx.c, como era feito usualmente.

Eu até comentei essas linhas acima do arquivo HAL.h e o programa compilou e rodou normalmente, ou seja, não estão sendo usadas pelo compilador. É isso mesmo ou estou esquecendo de algo para que essas definições funcionem?

Pelo que entendi, a ideia dessas definições no HAL.h é não ser mais necessário ficar mexendo no arquivo startup default né? Achei legal isso e seria bom se funcionasse.

Estou fazendo um projetinho demo no Coide com o brtos e essa NucleoF401. Em breve vou atualizar no github.

Saudações!

Moreto

Gustavo Denardin

unread,
Dec 7, 2014, 7:17:04 AM12/7/14
to br...@googlegroups.com
Olá Miguel,

Realmente, testei essa configuração para não ter que mudar o arquivo de startup. No entanto, o compilador e linker não reconhecem aquela definição diretamente. Pelo menos ficou mais fácil, basicamente é só adicionar o include do HAL.h no arquivo de startup que as interrupções serão reconhecidas.

Assim que terminar o demo nos avise, pois podemos divulgar no blog

Abraço,
Gustavo Weber Denardin
 Universidade Tecnológica Federal do Paraná (UTFPR)
 Campus Pato Branco - Departamento de Eng. Elétrica (DAELE)
 Via do Conhecimento, Km 1 -     Pato Branco - PR -   CEP: 85503-390
 Fone / Fax: (46) 3220-2570
 Home Page: http://pessoal.utfpr.edu.br/gustavo/

Miguel Moreto

unread,
Dec 7, 2014, 9:12:42 AM12/7/14
to br...@googlegroups.com
Olá Denardin,

Fiz um demo bem simples do BRTOS na plaquinha Nucleo F401.

Postei o projeto no github:


E também fiz um post no meu blog:


Espero ter usado corretamente a mutex.

Abraços,

Moreto

Carlos Henrique Barriquello

unread,
Dec 7, 2014, 9:45:58 AM12/7/14
to br...@googlegroups.com
Miguel,

muito legal o demo com o BRTOS.

Gustavo,

será que não vale a pena criar um repositorio do BRTOS no github ? Muita gente tá utilizando o Git, assim como o Miguel, e que poderia trazer várias contribuições para o projeto através de "pull requests"... aí facilitaria a integração das contribuições diretamente no repositório do BRTOS.

O que vc acha? Daria para deixar o respositorio no Google Code, mas deixar no Github o oficial...

Abraço

Gustavo Denardin

unread,
Dec 7, 2014, 11:20:12 AM12/7/14
to br...@googlegroups.com
Carlos, vale a pena sim.
Já que você está utilizando o GitHub a mais tempo, não se prontifica a enviar os arquivos para uma conta lá?

Abraço,

Gustavo Weber Denardin
 Universidade Tecnológica Federal do Paraná (UTFPR)
 Campus Pato Branco - Departamento de Eng. Elétrica (DAELE)
 Via do Conhecimento, Km 1 -     Pato Branco - PR -   CEP: 85503-390
 Fone / Fax: (46) 3220-2570
 Home Page: http://pessoal.utfpr.edu.br/gustavo/

Gustavo Denardin

unread,
Dec 7, 2014, 11:40:46 AM12/7/14
to br...@googlegroups.com
Olá Miguel, tudo bem?

Ficou bem legal o demo com o BRTOS na Nucleo F401.

No entanto, se você quiser melhorá-lo tenho três ressalvas. 

1. Você pode evitar aquele while dentro do putchar utilizando a interrupção de transmissão da porta serial. Estou te enviando em anexo um exemplo de como implementar essa modificação, desenvolvido para o demo da STM32F4-DISCOVERY.

2. A prioridade do mutex normalmente é uma acima da prioridade da tarefa de maior prioridade que utilizar o recurso compartilhado. Como as tuas tarefas tem prioridade 1 e 2, o ideal seria o mutex com prioridade 3.

2. Se fosse possível, seria interessante incluir o mutex dentro do printf, pois assim o usuário não seria obrigado a adquirir e liberar o recurso toda vez que fosse utilizá-lo. Não parece ser muito difícil de implementar, pois você tem a implementação do printf em um arquivo da stdio no projeto: "/blob/master/stdio/printf.c"

Qualquer dúvida estou a disposição.

Abraço,


Gustavo Weber Denardin
 Universidade Tecnológica Federal do Paraná (UTFPR)
 Campus Pato Branco - Departamento de Eng. Elétrica (DAELE)
 Via do Conhecimento, Km 1 -     Pato Branco - PR -   CEP: 85503-390
 Fone / Fax: (46) 3220-2570
 Home Page: http://pessoal.utfpr.edu.br/gustavo/

UART.c
UART.h

Carlos Henrique Barriquello

unread,
Dec 7, 2014, 11:52:12 AM12/7/14
to br...@googlegroups.com
Gustavo,

vou fazer isso então.

Abraço,

Miguel Moreto

unread,
Dec 7, 2014, 2:08:06 PM12/7/14
to br...@googlegroups.com
Valeu Denardin,

vou fazer isso!

sobre a mutex, daria para usar ela dentro da implementação da função putchar? Essa implementação tá no próprio arquivo main do meu projeto:

PUTCHAR_PROTOTYPE
{
  /* Place your implementation of fputc here */
  /* e.g. write a character to the USART */
  USART_SendData(USART2, (uint8_t) ch);
  /* Loop until the end of transmission */
  while (USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET)
  {}
  return ch;
}

Bastaria apenas substituir pela implementação que tu fez (UARTPutChar), que usa um semáforo e interrupção, bem melhor mesmo.

Assim não precisaria modificar a função printf que é aquela que o coide insere pelo repositório.

Sobre o github, também acho que vale a pena, mas vocês vão ter que decidir qual manter (git ou svn), pois ficar mantendo os dois vai ser trabalhoso. Eu gostei bastante do git, gostei da ideia de ter o repositório no próprio diretório do projeto (ser apenas um usuário, nem precisaria de um servidor online como o github). Além disso, tem também o site bitbucket que oferece projetos privados (porém limitados a 5 usuários).

Bom, vou tentar fazer as modificações que tu sugeriu ainda hoje.

Até!

Moreto


Miguel Moreto

Gustavo Denardin

unread,
Dec 7, 2014, 3:09:23 PM12/7/14
to br...@googlegroups.com
Miguel, infelizmente não dá pra colocar o mutex dentro do putchar. Veja que na minha implementação fiz um putchar e um putstring (que seria algo tipo printf) separado.

O motivo é que se você usar o mutex dentro do putchar, ele vai ser adquirido e liberado a cada carácter escrito. Assim, quando o mutex fosse liberado poderia ocorrer a troca de contexto para outra tarefa e, a frase que estava sendo escrita seria interrompida no meio. Ex.:

Estava sendo escrito "Botão pressionado". Mas no meio do processo outra tarefa consegue adquirir o driver e escreve "teste". O  resultado seria "Botão pretestessionado".

Você verá na implementação PutString que o mutex é adquirido antes do laço e liberado ao final do laço, permitindo assim que uma string inteira seja escrita sem ser interrompida.

Qualquer dúvida é só perguntar.

Abraço.

Gustavo Weber Denardin
 Universidade Tecnológica Federal do Paraná (UTFPR)
 Campus Pato Branco - Departamento de Eng. Elétrica (DAELE)
 Via do Conhecimento, Km 1 -     Pato Branco - PR -   CEP: 85503-390
 Fone / Fax: (46) 3220-2570
 Home Page: http://pessoal.utfpr.edu.br/gustavo/

Miguel Moreto

unread,
Dec 7, 2014, 3:16:01 PM12/7/14
to br...@googlegroups.com
Denardin,

acabei de testar aqui e é realmente isso!! Eu simplesmente usei o teu driver (só atualizei para usar a USART2) e coloquei tua função de UARTputchar dentro da putchar que eu tinha. Funcionou muito bem, mas se eu fico pressionando o botão, volta e meia a string que é enviada a cada segundo acaba interrompida.

Com isso, tenho uma questão:

1) Há perda de desempenho em ficar adquirindo e liberando a mutex a cada caracter?

Até,

Moreto
Reply all
Reply to author
Forward
0 new messages