Libreria di periferiche CMSIS vs HAL vs standard

Quindi sto passando da PIC a ARM e ho acquistato una scheda di rilevamento STM32F4. Finora ho capito che per programmarlo puoi accedere a tutti i registri direttamente in memoria (modo ovvio) e ci sono anche 3 librerie principali che puoi usare per semplificarti la vita. Ora la mia domanda è: quale di questi 3 (CMSIS, HAL, Std Peripherals Lib) è il livello più basso? vale a dire. quello con meno spese generali. Il mio obiettivo è imparare il funzionamento interno del controller e non semplificare la mia vita (solo un po '), quindi vorrei sapere quale di questi è più vicino al nucleo senza ricorrere all'uso dell'assemblaggio.

Sicuramente il CMSIS. Non è esattamente una libreria, contiene principalmente definizioni per i vari registri.

È esattamente ciò di cui si ha bisogno per accedere facilmente ai registri del microcontrollore, in modo da implementare il proprio HAL. Non ha costi generali, poiché accedi ai registri.

Tieni presente che CMSIS, a differenza degli altri due, è definito da ARM e non da ST. Ciò significa che le varie librerie CMSIS là fuori per i vari microcontrollori sono abbastanza simili, il che aiuta notevolmente nella portabilità.

Inoltre, CMSIS è il più semplice, quindi è (IMO) il più versatile e affidabile, con forse meno (o nessun) bug. Alcune librerie hal per i vari MCU che ho usato sono abbastanza famose per i loro bug.

D'altra parte, CMSIS ha bisogno di molto più lavoro da parte tua. È comunque una mia scelta personale, poiché preferisco dedicare il mio tempo alla creazione di librerie di qualità, che soddisfino le mie esigenze e alla comprensione di come funziona il chip, che spendo solo tempo per imparare solo una nuova libreria.

Per sapere come funziona, non utilizzare nessuno dei precedenti. Ottieni un compilatore a braccio incrociato e la documentazione da st, fatto. Inizia a scrivere codice. questi chip sono generalmente molto facili da programmare. la documentazione ti dice quali bit in cosa fanno i registri cosa.

Qualsiasi / tutte queste librerie hanno lo scopo di rimuovere quella comprensione / onere / lavoro da te e farla sentire come una semplice chiamata api come esperienza di programmazione dell'applicazione. Questo è ciò che vogliono molte persone. Puoi usare tutta la fonte per queste librerie per capire, ma man mano che migliora, trovi buchi e problemi nelle librerie, a volte codice molto spaventoso. codice messo insieme, scritto genericamente e approssimativamente portato da un chip all'altro, forse supportando le caratteristiche che il tuo chip non ha, ecc. E tutti hanno un sovraccarico eccessivo. Da 10 a 100 volte troppo codice per l'attività, sicuramente molti di essi possono ottimizzare via ma perché lo hanno lì in primo luogo?

Sia che tu vada da solo o utilizzi una di queste librerie, dovresti comunque cercare l'origine delle librerie che usi per vedere se sei a tuo agio con quello che stanno facendo, se ha senso, corrisponde alla documentazione del chip, ecc. Quando qualcosa va storto probabilmente dovrai scavare tra le loro cose tanto quanto le tue per scoprire perché.

Nota che i documenti sui chip non sono perfetti, questo fa parte del divertimento.

Non capisco perché l'assemblaggio emerge in una discussione sulla programmazione bare metal. Puoi cavartela con pochissimo assemblaggio. Per questi chip corteccia-m, tecnicamente hai bisogno di così tanto asm per essere avviato:

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

Non puoi fare affidamento su dati né su bss e non puoi tornare dal principale con quel minimo di asm. Ma è tutto ciò di cui HAI BISOGNO per il nudo metallo nudo. Ora se vuoi fare degli interrupt hai bisogno di più voci nella tabella vettoriale. più righe .word. Consiglio più asm, ma forse 10 o 20 righe in più.

questo è in genere tutto l'asm che 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

Sì, dice cortex-m0 ma questo è il vero bootstrap per il mio codice m4. Preferisco che questo sia pollice non pollice2. E ho appena riutilizzato questo codice da una corteccia-m all'altra, modificando l'indirizzo del puntatore dello stack secondo necessità, quindi funziona per m0, m3 e m4. Non ho ancora un m7 né l'ho studiato molto.

Abilitare la fpu potrebbe richiedere qualche altra riga di asm in quanto sono necessarie istruzioni specifiche. Ma il punto è non confondere la programmazione di basso livello e l'asm. C ha ciò di cui hai bisogno per configurare il chip, oltre a scrivere un'applicazione. Le librerie di cui stai parlando sono scritte in C non asm, quindi ovviamente non hanno nemmeno bisogno di usare asm.

Se vuoi imparare il funzionamento interno, scrivi il tuo codice. Non utilizzare queste librerie se non come riferimento. A volte è più semplice hackerarlo piuttosto che provare a leggere il loro codice. (non solo ST ma tutti i venditori. Uno dei venditori aveva una riga di codice così allarmante che lo uso come una domanda di intervista, non ho intenzione di pubblicarlo qui).

ST sicuramente, ma anche altri fornitori, per risparmiare energia, hanno abilitazioni di clock per sezioni del chip, quindi prima di entrare e provare a battere un led, devi trovare il bit di abilitazione per quel blocco gpio e vedere se esce di reset abilitato, se non poi abilitarlo, parlando con quella logica gpio senza un clock che lo abilita semplicemente blocca il processore in attesa di una risposta dalla logica che non risponderà mai. Non ti dicono sempre di queste abilitazioni. Una volta abilitati, a volte ti guidano attraverso l'init per alcune periferiche particolari. I documenti ST sono abbastanza buoni. Proveniente dal microchip che ottiene un punteggio piuttosto scarso per la documentazione, non dovresti avere problemi.

Ho usato entrambi, solo l'accesso al registro bare metal e la libreria periferica std. Trovo più semplice gestire i registri. Inoltre, se si utilizza un debugger, è possibile visualizzare i registri e confermare che contengano ciò che sono stati programmati. Penso che in questo modo imparerai di più anche sul funzionamento del chip.

Venendo dal mondo a 8 bit, ero sempre abituato a programmare periferiche tramite registri. Le schede tecniche del microcontrollore (ovvero i manuali di riferimento STM32) descrivono le periferiche esclusivamente in notazione di registro. Dal momento che il programmatore deve leggere la stessa documentazione per conoscere le funzioni e le funzionalità periferiche prima di tentare di utilizzarlo, mi sembra naturale iniziare a programmare i registri. Con un attento layout del codice e commenti, trovo che il codice possa essere piacevolmente letto e modificato anche dopo essere tornato mesi dopo.

Fino ad ora ho usato le definizioni CMSIS e mi è piaciuto usare direttamente i registri. Nel frattempo, ho usato le librerie HAL in alcuni progetti. Ha avuto una notevole influenza sul tempo di esecuzione del codice, quindi l'ho chiuso. Anche se CMSIS è al mio interesse, in questi giorni sarò un fan di libopencm3 . È come le LLbiblioteche fornite da ST. Tuttavia, copre più microcontroller anche nelle famiglie ST:

Il progetto libopencm3 (precedentemente noto come libopenstm32) mira a creare una libreria firmware gratuita / libre / open-source per vari microcontrollori ARM Cortex-M3, tra cui ST STM32, Toshiba TX03, Atmel SAM3U, NXP LPC1000 e altri.

si prega di notare che:

Nonostante il nome, libopencm3 supporta anche altri microcontrollori "correlati" ARM Cortex come Cortex-M0 o Cortex-M4 / Cortex-M4F, per esempio.

puoi trovare l'elenco dei microcontroller supportati qui .