CMSIS vs HAL vs Standard Peripherals Library

Então, eu estou mudando de PICs para ARM e comprei uma placa de descoberta STM32F4. Até agora, entendo que, para programá-lo, você pode acessar todos os registros diretamente na memória (maneira óbvia) e também existem 3 bibliotecas principais que você pode usar para facilitar sua vida. Agora, minha pergunta é: qual desses 3 (CMSIS, HAL, Std Peripherals Lib) é o nível mais baixo? ie aquele com menos sobrecarga. Meu objetivo é aprender o funcionamento interno do controlador e não facilitar minha vida (apenas um pouco), então gostaria de saber qual deles está mais próximo do núcleo sem recorrer ao uso de montagem.

Definitivamente o CMSIS. Não é exatamente uma biblioteca, contém principalmente definições para os vários registros.

É exatamente o que é necessário acessar com facilidade os registros do microcontrolador, de modo a implementar seu próprio HAL. Não tem sobrecarga, já que você acabou de acessar os registros.

Lembre-se de que o CMSIS, diferentemente dos outros dois, é definido pelo ARM e não pelo ST. Isso significa que as várias bibliotecas CMSIS disponíveis para os vários microcontroladores são bastante semelhantes, o que ajuda muito na portabilidade.

Além disso, o CMSIS é o mais simples, por isso é (IMO) o mais versátil e mais confiável, com possivelmente menos (ou nenhum) erro. Algumas bibliotecas hal para os vários mcu que eu usei são bastante infames por seus bugs.

Por outro lado, o CMSIS precisa de muito mais trabalho de você. No entanto, é minha escolha pessoal, já que prefiro investir meu tempo criando bibliotecas de qualidade, que atendam às minhas necessidades e entendendo como o chip funciona, gastando tempo apenas para aprender apenas uma nova biblioteca.

Para aprender como funciona, você não deseja usar nenhuma das opções acima. Obtenha um compilador de cruz de braço e a documentação de st, done. Comece a codificar. esses chips geralmente são realmente fáceis de programar. a documentação informa quais bits nos registradores fazem o que.

Qualquer uma dessas bibliotecas destina-se a remover esse entendimento / carga / trabalho de você e fazer com que pareça apenas uma chamada de API, como uma experiência de programação de aplicativos. É o que muita gente quer. Você pode usar toda a fonte dessas bibliotecas para ajudar a entender, mas à medida que melhora, você encontra falhas e problemas nas bibliotecas, às vezes código muito assustador. código lançado juntos, escrito de maneira genérica e grosseira de um chip para outro, talvez recursos de suporte que seu chip não tenha, etc. E todos eles têm uma quantidade excessiva de sobrecarga. 10 a 100 vezes mais código para a tarefa, com certeza muito pode otimizar, mas por que tê-lo lá em primeiro lugar?

Independentemente de você escolher por si próprio ou usar uma dessas bibliotecas, você ainda deve procurar na fonte as bibliotecas que usa para ver se está confortável com o que elas estão fazendo, se faz sentido, corresponde à documentação do chip etc. Quando algo der errado, você provavelmente terá que vasculhar as coisas deles tanto quanto as suas para descobrir o porquê.

Observe que os documentos de chip também não são perfeitos, isso faz parte da diversão.

Não entendo por que a montagem surge em uma discussão sobre programação bare metal. Você pode conviver com muito pouca montagem. Para esses chips de córtex-m, tecnicamente você só precisa dessa quantia para inicializar:

.globl _start
_start:
.word 0x20001000
.word main

Você não pode confiar em dados nem em bss e não pode retornar do main com esse mínimo de asm. Mas esse é todo o asm que você precisa para o mais simples dos bare metal. Agora, se você quiser interromper, precisará de mais entradas na tabela de vetores. mais linhas .word. Eu recomendo mais asm, mas talvez 10 ou 20 linhas a mais.

este é tipicamente todo o asm que eu uso.

.cpu cortex-m0
.thumb
.thumb_func
.global _start
_start:
stacktop: .word 0x20001000
.word reset
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.word hang
.thumb_func
reset:
    bl notmain
    b hang
.thumb_func
hang:   b .
.align
.thumb_func
.globl PUT16
PUT16:
    strh r1,[r0]
    bx lr
.thumb_func
.globl PUT32
PUT32:
    str r1,[r0]
    bx lr
.thumb_func
.globl GET32
GET32:
    ldr r0,[r0]
    bx lr
.thumb_func
.globl GET16
GET16:
    ldrh r0,[r0]
    bx lr
.thumb_func
.globl dummy
dummy:
    bx lr
.end

Sim, diz córtex-m0, mas isso é bootstrap real para o meu código m4. Prefiro que seja polegar, não polegar2. E apenas reutilizo esse código de um córtex-m para outro, alterando o endereço do ponteiro da pilha conforme necessário, para que ele funcione para m0, m3 e m4. Ainda não tenho um m7 nem pesquisei muito.

A ativação da fpu pode exigir mais algumas linhas de asm, pois instruções específicas são necessárias. Mas o ponto é não confundir programação de baixo nível e asm. C tem o que você precisa para configurar o chip, além de escrever um aplicativo. As bibliotecas das quais você está falando estão escritas em C e não em asm, portanto, obviamente, elas também não precisam usar asm.

Se você quiser aprender o funcionamento interno, escreva seu próprio código. Não use essas bibliotecas além de como referência. Às vezes, é mais fácil invadir isso do que tentar ler seu código. (não apenas a ST, mas todos os fornecedores. Um dos fornecedores tinha uma linha de código tão alarmante que eu a uso como uma pergunta de entrevista, não publicando aqui).

Definitivamente, mas também outros fornecedores, para economizar energia, ter o clock ativado para seções do chip, portanto, antes de entrar e tentar piscar um led, você precisa encontrar o bit de habilitação para esse bloco gpio e ver se ele sai de redefinição ativada, se não ativada, conversando com essa lógica gpio sem um relógio, permitindo que simplesmente desligue o processador enquanto aguarda uma resposta da lógica que nunca responderá. Eles nem sempre falam sobre esses recursos. Uma vez ativado, eles às vezes orientam você no init para algum periférico específico. Os documentos de ST são muito bons. Vindo do microchip que obtém uma nota muito ruim para documentação, você não deve ter um problema.

Eu usei ambos, apenas acesso a registros bare metal e a biblioteca periférica std. Acho mais fácil lidar com os registros. Além disso, se você estiver usando um depurador, poderá visualizar os registros e confirmar se eles contêm o que você os programou. Eu acho que você aprende mais sobre a operação do chip dessa maneira também.

Vindo do mundo de 8 bits, eu sempre estava acostumado a programar periféricos via registradores. As folhas de dados do microcontrolador (ou seja, manuais de referência do STM32) descrevem os periféricos exclusivamente em notação de registro. Como o programador deve ler essa mesma documentação para saber sobre as funções e recursos periféricos antes de fazer qualquer tentativa de usá-lo, parece-me natural começar a programar os registros. Com um layout de código cuidadoso e comentários, acho que o código pode ser agradável de ler e modificar, mesmo depois de voltar meses depois.

Até agora, usei as definições do CMSIS e gostei de usar os registros diretamente. Enquanto isso, usei bibliotecas HAL em alguns projetos. Ele teve uma influência considerável no tempo de execução do código, então eu o encerrei. Embora o CMSIS sirva meu interesse, hoje em dia eu serei um fã do libopencm3 . É como LLbibliotecas fornecidas pelo ST. No entanto, abrange mais microcontroladores, mesmo nas famílias ST:

O projeto libopencm3 (anteriormente conhecido como libopenstm32) visa criar uma biblioteca de firmware livre / libre / de código aberto para vários microcontroladores ARM Cortex-M3, incluindo ST STM32, Toshiba TX03, Atiba SAM3U, NXP LPC1000 e outros.

observe que:

Apesar do nome, o libopencm3 também suporta outros microcontroladores "relacionados" ao ARM Cortex, como o Cortex-M0 ou o Cortex-M4 / Cortex-M4F, por exemplo.

Você pode encontrar a lista de microcontroladores suportados aqui .