Eclipse + GNU ARM + STM32 - HAL ou SPL


10

Começarei com o desenvolvimento do ARM (após 2 anos de AVRs) e peguei a placa STM DISCOVERY com o microprocessador stm32f4.

Decidi usar o eclipse + ARM gcc, já que não gosto do limite de código do Keil e não tenho dinheiro para obter uma versão paga.

Seguindo os tutoriais, instalei o eclipse junto com as ferramentas gcc ARM + openocd + make utils etc.

Minha pergunta é sobre o plugin 'packages'. Como todo iniciante, estou confuso quanto ao uso do novo STM HAL ou do SPL mais antigo.

Meu entendimento é que o HAL implementou a abstração em um nível em que pode ser chamado de equivalente do Arduino para arm. O SPL, por outro lado, fornece abstração apenas o suficiente para tornar a codificação mais rápida, mas você ainda precisa lidar com o nível de chip.

Com esse entendimento, gostaria de manter o SPL para entender melhor as coisas, em vez de usar o HAL.

O que eu gostaria de saber é: o uso de pacotes para o STM me força implicitamente a usar o HAL? Se sim, alguém pode me indicar como usar o SPL na minha configuração?


1
"os tutoriais" é um pouco vago, por isso não conheço o "plugin '' packages '" e não tenho ideia do que é SPL (STM periférica library?) ou SPCL. Talvez eu só não estou qualificado para esta pergunta, mas trabalhar com STM32 para mais de dois anos me fez pensar ...
Arsenal

2
SPL é a Biblioteca Periférica Padrão , por outro lado, também não conheço o SPCL.
Bence Kaulics

2
A maneira preferida e suportada pelo STM hoje é usar o STM32CubeMX, que está gerando código com base no HAL. E devo admitir que é bastante útil, embora não seja fã de ferramentas automatizadas, pois ocultam coisas importantes.
Eugene Sh.

1
Embora deva ser principalmente compatível com outras versões SPL do processador STM32, não acredito que o ST tenha SPL para STM32F7.
28515 Tut

Desculpe pelo bit SPCL. Isso foi um erro. Ainda estou me acostumando com as siglas. Também verifiquei duas vezes e minha placa é variante stm32f4. Outro erro. Ainda permanecem as questões gerais, como uso a biblioteca periférica padrão com o eclipse?
Ankit

Respostas:


6

O SPL, como eu vejo, não tem nada a ver com o IDE que você está usando. Você pode simplesmente incluir os módulos relevantes (por exemplo, stmf4xx_dma.c e stmf4xx_dma.h) em seu projeto e usar as funções expostas (e descritas muito bem) nos arquivos .c e .h. Na verdade, eu tenho aprendido sobre o stmf411 nucleo com gcc, openocd e SPL usando apenas o prompt de comando do Windows; sem IDE. Pacotes no eclipse provavelmente o forçariam a usar o HAL (uma vez que dentro da pasta 'Packages' baixada para o eclipse, eu vejo apenas os módulos HAL).

O HAL em si parece muito mais estratificado do que o necessário. Considerando que acessar os registros diretamente se torna cansativo e dificilmente legível. O SPL parece perfeito. clive1, o guru no fórum st.com, também prefere o SPL ao HAL. Aqui está a minha pergunta nesse fórum ... pode ser útil.

Precisa de ajuda com USART no Nucleo stmf411


1
Eu concordo totalmente com você nisso. HAL parece ter exagerado com todo o conceito de abstração. Embora com ele se desenvolva programas mais rapidamente, você realmente não aprenderia o que exatamente está acontecendo, o que acho essencial para aprender e ser à prova do futuro. Como teste, criei um projeto no uvision e selecionei o suporte legado em vez de pacotes de software e isso parece ter incluído os arquivos SPL. Também obrigado pelo link!
Ankit

1

Não tenho nenhuma experiência com o HAL, mas usei o SPL várias vezes para salvar meus tempos. Na minha opinião, a comunidade-alvo desses processadores embarcados são 2 grupos: Primeiro grupo que não está interessado em se envolver com as camadas de hardware. Programadores de software, amadores habituais e adoradores de Arduino, framboesa. se você estiver nesse grupo, parece que HAL é uma boa escolha para você. Segundos provenientes da comunidade eletrônica e de hardware, que preferem

GPIO_A->PIN &= ~(1 << 15);

para

LED_On(1)

por ligar o LED e quero saber o que eles estão fazendo basicamente. se você tiver nesse grupo e tiver tempo suficiente para ler o manual de referência e o manual de programação do seu MCU, talvez a programação em nível de registro seja outra opção. mas se você quiser decidir entre apenas a opção acima de 2: o HAL tem um futuro melhor por causa do suporte a ST ', mas o SPL é uma maneira mais fácil de entender para um novo iniciante. Talvez isso possa ajudar http://www.eevblog.com/forum/microcontrollers/stm32-and-their-hal-library/


1
Obrigado pelo link, leitura interessante! Você está correto, para iniciantes, o SPL parece ser a melhor maneira de aprender (e esse é o caminho que eu também escolhi). Btw na sua resposta deve ser LED_Off
Ankit

1

Obtenha este IDE: System Workbench for STM32 - é gratuito, baseado no Eclipse e possui arm-gcc e openocd em um pacote.

E sobre bibliotecas: além de SPL e HAL agora existem LL. Cada um tem algumas vantagens e desvantagens, e você deve escolher o que precisa. E pelo que entendi , todos eles têm status experimental para ST. Abaixo das minhas notas para cada um deles:

  • SPL: antigo, pesado, sem uso extra de ram, flexível
  • HAL: uso real, pesado e extra de RAM, não flexível
  • LL: real, peso leve, sem uso adicional de ram, flexível

Breve descrição para minhas notas:

  • pesado - uso de flash grande, funções universais "super" para trabalhar com periféricos
  • uso extra de RAM - trata-se de HAL, possui cópia do estado periférico em estruturas localizadas em RAM e usa-o em qualquer lugar e sempre
  • não é flexível - e novamente sobre o HAL, ele tem muitas funções para casos diferentes, mas! a maioria deles não é utilizável para dispositivos reais (as pessoas tentam reinicializar o HAL para receber byte por byte da usart >_<, todas as funções do TIM + DMA são implementadas para reescrever o registro TIM e nenhuma outra ...)

Para um pouco de reabilitação do HAL: ele tem uma grande vantagem para o novato - é apoiado pelo STMCubeMX.

EDITAR:

Eu esqueço o libopencm3 - é uma biblioteca alternativa. Eu não usei.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.