STM32F4 e HAL


23

Quindi ho provato un po 'di tempo con STM32F407 (sono nuovo di ARM) e ho deciso di scrivere una semplice app usando le librerie HAL poiché sembra che ST abbia interrotto le librerie di periferiche standard. Quindi la mia domanda è: qual è il punto in HAL? StdPeriph non stava facendo il suo lavoro? Perché dovrebbero interromperlo per HAL? A me sembra che HAL sia un casino completo.

La documentazione è FANTASTICA, almeno per StdPeriph c'è un riferimento completo organizzato abbastanza bene da trovare facilmente quello che vuoi ( http://stm32.kosyak.info/doc/ ). Per HAL esiste un PDF scadente ( http://www.st.com/st-web-ui/static/active/jp/resource/technical/document/user_manual/DM00105879.pdf ) che ha una struttura apparentemente casuale. Leggendo qualsiasi sezione, ad esempio per quanto riguarda una periferica, non riesco a capire i requisiti per configurarlo e personalizzarlo correttamente. Sembra più una nota personale di qualcuno che non vuole dimenticare cose, che un riferimento.

So di poter usare CubeMX per inizializzare GPIO e configurare le periferiche, ma il mio obiettivo è farlo da solo, quindi capisco meglio il loro funzionamento, non ho un software che faccia tutto per me. Sto facendo qualcosa di sbagliato? È il principiante ARM in me che mi confonde? O è la documentazione disponibile che male?


Qualcosa come ChibiOS potrebbe adattarsi meglio a te? Hanno un RTOS ma anche un ottimo HAL che puoi usare senza RTOS.
IgorEE,

ST non ha esattamente interrotto le librerie di periferiche standard, ma non ne rilascerà nuove versioni per le famiglie più nuove. Hanno dichiarato (da qualche parte sul loro forum, ma non riesco a trovarlo) che continuerebbero a supportare SPL per le famiglie per le quali è stato rilasciato (incluso STM32F4). Dato che sei nuovo di ARM, probabilmente è meglio andare con HAL. Ho già scritto molti moduli con SPL, quindi la transizione sarà un problema e l'ho rimandata. Questo è male dal momento che una volta che decido di utilizzare una nuova famiglia, ci sarà ancora più codice da trasferire su HAL
Tut

Questo ebook: leanpub.com/mastering-stm32 è una buona introduzione per i principianti (ma anche per i professionisti) nel mondo STM32.
Lorenzo Melato,

Risposte:


13

Creare le tue librerie è abbastanza semplice. La loro documentazione sulle specifiche del registro è piuttosto buona, la maggior parte se non tutte le periferiche sono facili da configurare. Trovo molto più doloroso usare le loro librerie. ma forse sono solo io. Questo è vero per st, nxp, ti, atmel per citarne alcuni (non tanto per Intel e microchip).

Perché cambiano le biblioteche, possono essere un numero qualsiasi di ragioni, alcuni nuovi capi hanno preso il controllo, alcune divisioni sono state chiuse, un'altra ha preso il controllo. Il marketing voleva una nuova immagine per il prodotto. Come accennato da ElectronS, potrebbe essere un tentativo di allontanarsi maggiormente dall'hardware per attirare utenti non disposti o in grado di fare bare metal. Vorrei andare oltre e dire che probabilmente stanno cercando di competere con il fenomeno Arduino. Quale mbed e tutti gli altri hanno sempre cercato di fare e fallito (anche prima di Arduino).

In ogni caso, più lontano dall'hardware diventa più gonfio e più lento, quindi più devi spendere per unità per rom, ram e mhz. Solo così potresti dedicare lo stesso tempo alla programmazione? Lo stai facendo diversamente?

Dici di venire dal mondo PIC, ora hanno fatto un buon lavoro con gli strumenti, anche se i loro documenti sui chip erano terribili, alcuni dei peggiori. hanno compensato con biblioteche e sandbox.

Alla fine della giornata, prova le varie opzioni, prova i prodotti concorrenti per vedere come si confrontano i loro strumenti. Molte cose che puoi fare gratuitamente solo per vedere se ha senso e puoi compilare cose. Forse anche usare un simulatore di set di istruzioni. Trova quello che fa per te.

Nota, l'opzione senza librerie fisse è SEMPRE a tua disposizione. Non si è limitati a quale toolchain è possibile utilizzare, quale sistema operativo host, quale ide, editor, ecc. Potrebbero attenersi a te sulla programmazione delle parti, se le loro opzioni sono estremamente limitate a tale riguardo passare a qualche altro chip o fornitore se puoi.

Per vendere un prodotto con chip in questo modo devono fornire un ambiente di sviluppo che sia tutto loro o materiale gratuito che hanno incollato insieme. E tendono a mettere insieme una biblioteca di qualche tipo. Deve solo sembrare abbastanza buono e il battito di ciglia dell'esempio principale funziona abbastanza bene da indurre la tua direzione o il tuo team hardware a progettare il loro prodotto, quindi quando il tuo prodotto di bordo viene lanciato sul muro al software, è quando il dolore non arriva o non arriva Se funziona quasi, ma non del tutto, è una grande vittoria per il fornitore di chip in quanto ora pagherai il supporto tecnico per l'ultimo bit. Quindi è nel loro interesse essere quasi lì, ma non del tutto.

I venditori di chip devono solo avere un bell'aspetto per vincere il design. Devono continuare a migliorare (? Cambiare) il prodotto per attirare nuovi e vecchi clienti. Quindi avranno delle modifiche, quanto distanti e quante librerie precedenti continuano a supportare, varia. Quindi alla fine qualsiasi libreria a cui ti abituerai andrà via. Quindi impara ad adattarti (o non usare le loro cose e andare per conto tuo, che puoi supportare indefinitamente). Concesso, idealmente, devi solo sviluppare l'applicazione una volta per prodotto, rendere perfetto il tuo firmware (buona fortuna se usi librerie di terze parti) e non dovrai tornare indietro e trovare un computer che caricherà la loro toolchain se riesci a trovare un copia di esso, e ricorda come usare quella vecchia biblioteca. Ricorda che non solo dovresti salvare il tuo codice sorgente, ma dovresti salvare tutti i loro strumenti e documenti.

Le loro librerie sono supportate solo su una toolchain, sotto una forse due IDE e talvolta solo su Windows e determinate versioni. Ancora una volta non hai nessuna di queste limitazioni, sicuramente non per ARM, se fai le tue cose. Puoi sempre leggere qualsiasi / tutte le loro librerie per vedere come fanno le cose. Ma questo è spesso molto spaventoso, non usano i loro sviluppatori del team A per le biblioteche, ho estratto alcune righe di codice per chiedere ai candidati dell'intervista cosa c'è di sbagliato in questo codice.

per risparmiare tempo e fatica sia sul lato del silicio che sul lato software, molto spesso riciclano lo stesso IP, quindi una volta che vedi come funziona la periferica su uno dei suoi chip, spesso funziona allo stesso modo su molti altri chip. Sì, i sistemi di clock possono essere complicati con o senza le loro librerie. Elevate possibilità di brickare il chip, ecco dove è avvenuta la maggior parte del mio brick / chip. Aiuta a capire come funzionano i loro chip, ad esempio gli AVR, la maggior parte se non tutti, possono essere riprogrammati mentre il chip è resettato, quindi qualsiasi codice errato che rovina i pin necessari per riprogrammare o blocca la logica necessaria per riprogrammare, non importa, puoi riprogrammare quei chip. Alcuni di questi venditori (st is one) ha un bootloader interno che puoi selezionare usando un cinturino (BOOT0 per esempio nel mondo st),

Taglia unica adatta a nessuno. Particolarmente vero per il software. Quindi qualsiasi tentativo di sottrarre l'hardware, lo rende solo lento e gonfio. Potrebbe anche ottenere un chip più grande ed eseguire Linux su di esso, se è quello che stai veramente cercando. Gran parte di questo è il risultato degli sviluppatori, che non vogliono sporcarsi le mani, quindi in pratica lo abbiamo chiesto e stanno cercando di fornirlo.

Ancora una volta, non bloccare te stesso in un fornitore o in uno qualsiasi (a meno che non sia troppo tardi e la direzione e il team hardware non te lo abbiano attaccato, nota che i prodotti stm32 sono belli e facili da usare). Guardarsi intorno. TI sta mettendo molte uova nel cestino della corteccia-m4. Puoi eseguire le operazioni mbed su alcuni di questi prodotti arm e sulle soluzioni supportate dal fornitore.

Una cosa su cui puoi sempre fare affidamento è che di tanto in tanto cambieranno le librerie e alla fine smetteranno di supportare quella a cui ti sei abituato.


Grande argomento sullo sviluppo delle tue librerie, quasi convinto e mi piacerebbe provarlo, cosa pensi che mi servirebbe oltre al manuale di riferimento stm32fxx? dovrei anche leggere il manuale del core del braccio? userò CMSIS? come accederò ai registri e alla memoria? potresti approfondire o fornire esempi su come iniziare
ElectronS,

alcune altre cose a cui pensare. ogni riga di codice aumenta il rischio. spiegando al tuo capo che stai pianificando di usare decine di centinaia di migliaia di righe di codice di qualcun altro, senza rivedere tutto ciò che stai usando. strati di codice, specialmente durante l'astrazione, fanno sì che i binari siano più grandi e le prestazioni diminuiscano. Quindi, ancora una volta, spiegando al tuo capo che i 10 milioni di unità di prodotto costeranno 35 centesimi in più per 3,5 milioni di dollari perché hai scelto di usare una biblioteca perché sei pigro.
old_timer

il tuo capo potrebbe assumere un esercito di persone per rimpiazzarti con quel tipo di denaro, sottoporre a revisione ogni riga di codice in modo che non riescano a ottenere 10.000 unità e scoprono di doverle distruggere in tutto un bug del software causato dall'uso di software rischioso. e usa una parte più piccola che costa meno con una frequenza di clock più lenta che consuma meno energia e dura più a lungo con una carica della batteria. a volte vale la pena. e certo, a volte no.
old_timer

grazie per gli altri punti che hai dichiarato, ma potresti rispondere alla mia domanda, sul modo migliore per iniziare? utilizzando i file CMSIS e HAL .h per i nomi dei registri e le posizioni di memoria ??
ElectronS

Non c'è "migliore", l'uso di quella parola rende l'opinione personale, non un dato di fatto. Basta sceglierne uno e iniziare, o fare come potrei, provarne uno fino a quando non si colpisce un blocco stradale, quindi provare un altro e un altro, e andare in giro spingendo ciascun blocco stradale fino al blocco successivo fino a quando uno o tutti sfondano.
old_timer

14

Lascia che ti dica che molti di noi condividono la stessa delusione che hai con le biblioteche HAL, sono davvero scarsamente e vagamente documentati e ancora nuovi contengono molti bug.

Quindi, per rispondere alla tua domanda, perché ST ha deciso su HAL è semplice:

  1. Vogliono creare uno strato di astrazione hardware che, in parole povere, significhi che lo sviluppo del software e il codice sono indipendenti dal microcontrollore, quindi se oggi scrivi un codice per stm32f4 e dopo un paio d'anni devi migrare su stm32f7 sarà facile e il codice sarà altamente modulare.

  2. Ciò consente inoltre a più sviluppatori come programmatori di software di lavorare con il microcontrollore senza realmente comprendere o entrare nei dettagli di come l'hardware sta realizzando un'attività. Aziende come ST e TI (che iniziano ora questa strada) stanno cercando di rendere lo sviluppo embedded simile allo sviluppo del codice PC in cui si utilizzano driver di alto livello per sviluppare codice FAST. La goffaggine e la mancanza di ottimizzazione nei driver e nelle librerie è compensata dalle elevate prestazioni dei dispositivi ARM.

  3. Penso che STM32cubeMX sia un ottimo strumento se stai usando le librerie HAL, perché il lavoro che richiede più tempo è l'inizializzazione delle periferiche e ora puoi farlo in pochissimo tempo, con un'interfaccia visiva che può essere facilmente modificata senza influire sul codice utente (se scrivi il tuo codice nel posto appropriato) Puoi usare Stm32cubeMx e quindi rivedere il codice e provare a capire come e perché stanno usando ciascuna funzione, in questo modo stai provando a risolvere un esercizio e hai un manuale di soluzione nelle vicinanze per la correzione che è grande IMO.

  4. Il core ARM è piuttosto complesso, quindi i vecchi metodi che abbiamo usato su micro controller a 8 bit come la gestione diretta dei registri (scrivendo C in modo assembly) non sono fattibili, richiedono molto tempo e rendono il codice difficile da mantenere a causa dell'architettura complessa (controlla il impostazione dell'orologio per esempio)


6
Tutto ciò è molto comprensibile, tuttavia tutti questi si applicano anche a StdPeriph, vero? Voglio dire, è già una libreria di astrazione hardware, quindi che senso ha crearne una nuova invece di migliorare quella vecchia? Sono sinceramente curioso, sono molto nuovo di ARM, utilizzo i PIC da molti anni.
Giovanni

Ancora di più per le librerie conformi al CMSIS
Scott Seidman,

1
@john, per quanto ho capito, l'HAL è più astratto e meno dipendente dall'hardware rispetto alle librerie standard.
ElectronS

12

So che questo sarà lungo e supponente, ma dato che abbiamo appena rilasciato (con successo) il nostro nuovo prodotto usando l'HAL, penso che valga la pena di essere preso in considerazione. Inoltre, non lavoro per ST, ho odiato ogni parte dell'HAL, ho quasi riavviato il progetto con StdPeriph, ho sentito il dolore - ma ora capisco perché.

Innanzitutto, un po 'di background. Sviluppiamo sistemi di telemetria a bassissima potenza e il nostro prodotto è alimentato da un STM32L1. Quando abbiamo iniziato a lavorare sul firmware, avevamo le solite scelte per i dispositivi ST (bare metal): fare tutto a mano, utilizzare le librerie StdPeriph o andare con l'HAL. I ragazzi della ST ci hanno convinto ad andare con l'HAL - così abbiamo fatto. È stato doloroso, abbiamo dovuto aggirare i bug nel software (la parte I2C ci ha fatto impazzire per un bel po 'di tempo) e ancora non mi piace l'architettura generale. Ma funziona

Quando sono passato da desktop a incorporato, poco più di un anno fa, sono rimasto sbalordito da qualcosa di strano che non potevo nominare o nemmeno cogliere. Nel tempo sono stato in grado di capire cosa fosse - o meglio, cosa fosse - in corso: il mondo embedded è in fase di transizione. Il silicio diventa più economico ogni giorno e gli MCU sono più potenti e versatili. Sempre più dispositivi, indipendentemente dalle loro dimensioni, esigenze di alimentazione, fanno affidamento su MCU generici. Sempre più aziende si uniscono al gioco, portando un'orda di nuovi sviluppatori con vari background. La cultura "cattiva" si allontana dal tradizionale "ragazzo EE con capacità di programmazione magica" a "ragazzo SW con una vaga conoscenza dell'hardware".

Se questo è buono o cattivo è irrilevante. Succede e basta. In realtà, è successo anche al mondo del software, più di una volta. Il boom del web nel 2000 ha attirato i neofiti di PHP / MySQL - vai a dire che ci sono registri nella CPU, risponderanno "Sto usando Linux, quindi non c'è registro nel mio sistema operativo". I precedenti sistemi operativi multiutente in esecuzione in modalità protetta consentivano agli sviluppatori pigri di non impostare mai un ISR in tutta la loro carriera e di stare bene . Ancora prima, le tastiere e i produttori di stampanti e stampatori di schermi facevano impazzire.

E sì, le tendenze attuali mi rendono personalmente triste, poiché vedo gli sviluppatori ignoranti in soggezione con le ultime tecnologie luccicanti, pur essendo totalmente incapace di collegarle alla storia. Quando vedo un giovane che sto programmando un gioco in Javascript con WebGL nel 2015, voglio gridare "Non c'è nulla di nuovo! Ho fatto lo stesso con C ++ e 3Dfx SDK nel 1995!". Ciò che la storia non racconta è che il suo gioco funziona sul mio telefono cellulare, mentre il mio aveva bisogno di un PC giocatore (e di un programma di installazione, e non potevo inviare aggiornamenti dal web). La verità è che potrebbe sviluppare un gioco in un mese, in cui ho fatto lo stesso in sei o dodici.

Ovviamente, né ST o TI o Intel né chiunque produca chip vuole perdere il turno. E hanno ragione. L'HAL è la risposta di ST ed è in realtà abbastanza solida, non solo dal punto di vista commerciale o di marketing, ma anche dal punto di vista ingegneristico. Il motivo per cui è il suono sta nel nome:

Livello di astrazione hardware

Se non altro, questo è ciò che dovresti ricordare. L'HAL è uno sforzo per allontanarsi dall'hardware. È una buona ingegneria perché ci consente di disaccoppiare la funzionalità dai dettagli. La stratificazione è ciò che consente di sviluppare programmi complessi: un'astrazione sopra l'altra, fino all'hardware. L'astrazione è in realtà lo strumento più potente che abbiamo per gestire la complessità . Dubito fortemente che chiunque su questo pianeta sarebbe in grado di programmare un browser Web in assembly per una CPU specifica.

Il cambiamento culturale è davvero difficile da digerire, ma poiché devo pensare che non è necessario aver letto l' Arte della Programmazione Informatica di Knuth per sviluppare applicazioni Web, il mondo EE deve ammettere che ci sono nuovi arrivati ​​che possono (e lo faranno!) Sviluppare codice incorporato senza aver letto il manuale di riferimento Holy Fucking .

La buona notizia è che i nuovi giocatori non significano meno lavoro per i giocatori più grandi, anzi, il contrario, IMHO. Chi chiameranno quando le cose "non funzionano?". Se hai RTFM (a differenza di loro) e se sai cosa fa ogni bit di questo oscuro registro di configurazione, hai un vantaggio.

Tra letture ed esperimenti, vai con l'HAL. Nuovo MCU? Nessun problema. Nuova linea MCU? Nessun problema. (Ho codificato un test su un Nucleo STM32F4 in un solo giorno con CubeMX, e poi l'ho semplicemente trasferito sul nostro dispositivo ... sembrava giusto ). Deridere per i test unitari? Nessun problema. L'elenco potrebbe continuare all'infinito, perché l'astrazione è buona.

Naturalmente, lo stesso HAL non è OK al 100%. La sua documentazione è terribile (ma hai RT F HRM, vero?), Ci sono bug, ST ci ha appena scaricato una versione beta (sembra piuttosto standard in questi giorni) e il loro supporto pubblico è uno scherzo. Ma non rilasciare l'HAL sarebbe stato anche peggio.


Vedo da dove vieni. A quanto ho capito, le cose (purtroppo) vanno alla maniera di Arduino, cercando di nascondere la maggior parte della realtà al programmatore per attirare più persone di software di alto livello nella programmazione hardware, e questo è il motivo dietro tali librerie come HAL. Vedendo tuttavia quanto sia mal documentato e anche un casino completo, non credo che riusciranno a farlo in qualunque momento presto.
John

@John: HAL non nasconde alcuna "realtà". Tutto è lì per te da modificare. Tutte le parti sono opzionali - ad esempio, potresti voler utilizzare solo le macro per accedere ai registri, oppure solo un driver specifico (ad es. I2C) o tutto, compresi gli ISR ​​e la configurazione dell'orologio. La tua scelta. Tuttavia, sono d'accordo che la documentazione fa molto schifo. (Ho detto a ST e hanno promesso che ci stavano lavorando BTW)

Stiamo ripetendo di fare lo stesso con nuovi strumenti. Perché i nuovi strumenti promettono di rendere il lavoro più semplice e veloce, quindi economico. Ma stiamo ancora facendo lo stesso, perché gli esseri umani sono sempre gli stessi, non importa se fosse il 2095 o il 1995. La scelta che ci resta è se seguiamo i nuovi strumenti o restiamo con i nostri strumenti già familiari.
Jony,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.