Eclipse + GNU ARM + STM32 - HAL o SPL


10

Inizierò con lo sviluppo ARM (dopo 2 anni di AVR) e ho raccolto la scheda STM DISCOVERY con il microprocessore stm32f4 su di essa.

Ho deciso di andare con eclipse + ARM gcc poiché non mi piace il limite di codice su Keil e non ho i soldi per ottenere una versione a pagamento.

Seguendo i tutorial ho installato eclipse insieme a gcc ARM tools + openocd + make utils ecc.

La mia domanda riguarda il plugin "pacchetti". Come ogni principiante, sono confuso se utilizzare il nuovo STM HAL o il vecchio SPL.

La mia comprensione è che HAL ha implementato l'astrazione a un livello in cui può essere indicato come equivalente Arduino per arm. SPL d'altra parte fornisce l'astrazione appena sufficiente per rendere la codifica più veloce ma è ancora necessario occuparsi a livello di chip.

Con questa comprensione, vorrei attenermi a SPL per capire meglio le cose piuttosto che usare HAL.

Quello che vorrei sapere è che l'uso dei pacchetti per STM mi costringe implicitamente a usare HAL? In tal caso, qualcuno può indicarmi come utilizzare SPL con la mia configurazione?


1
"i tutorial" è un po 'vago, quindi non conosco "il plugin" pacchetti "e non ho idea di cosa sia SPL (libreria periferica STM?) o SPCL. Forse non sono qualificato per questa domanda, ma lavorare con STM32 da oltre due anni mi ha fatto meravigliare ...
Arsenal,

2
SPL è Standard Peripheral Library , d'altra parte non conosco neanche SPCL.
Bence Kaulics,

2
Il modo preferito e supportato di STM oggi è utilizzare STM32CubeMX, che sta generando codice basato su HAL. E devo ammettere che è abbastanza utile, anche se non sono un fan degli strumenti automatizzati in quanto nascondono cose importanti ..
Eugene Sh.

1
Anche se dovrebbe essere per lo più compatibile con altre versioni SPL del processore STM32, non credo che ST abbia SPL per STM32F7.
Tut

Mi dispiace per il bit SPCL. È stato un errore. Mi sto ancora abituando agli acronimi. Ho appena ricontrollato e la mia scheda è la variante stm32f4. Un altro errore Rimangono comunque le domande generali, come posso usare la libreria periferica standard con eclipse?
Ankit,

Risposte:


6

L'SPL, come vedo, non ha nulla a che fare con quale IDE stai usando. Puoi semplicemente includere i moduli pertinenti (ad es. Stmf4xx_dma.c e stmf4xx_dma.h) nel tuo progetto e utilizzare le funzioni esposte (e descritte molto bene) nei file .c e .h. In effetti sto imparando sul nucleo stmf411 con gcc, openocd e SPL usando solo il prompt dei comandi di Windows; nessun IDE. I pacchetti in eclipse probabilmente ti costringerebbero ad usare l'HAL (poiché all'interno della cartella 'Pacchetti' scaricata per eclipse, vedo solo i moduli HAL).

L'IMO stesso sembra molto più stratificato del necessario. Mentre l'accesso ai registri diventa direttamente noioso ed è difficilmente leggibile. L'SPL sembra giusto. clive1, il guru sul forum di st.com, preferisce anche SPL su HAL. Ecco la mia domanda su quel forum ... potrebbe essere utile.

Hai bisogno di aiuto con USART su Nucleo stmf411


1
Sono totalmente d'accordo con te in questo. Sembra che HAL abbia esagerato con l'intero concetto di astrazione. Sebbene con esso si svilupperebbero programmi più velocemente, non si imparerebbe davvero cosa sta succedendo esattamente, che ritengo essenziale per l'apprendimento e per essere una prova futura. Come test ho creato un progetto in Uvision e selezionato il supporto legacy al posto dei pacchetti software e che sembra aver incluso i file SPL. Grazie anche per il link!
Ankit

1

Non ho alcuna esperienza con HAL, ma ho usato SPL molte volte per risparmiare tempo. Ritengo che la community di destinazione di questo processore integrato sia composta da 2 gruppi: primo gruppo che non è interessato a interagire con i livelli hardware. Programmatori di software, soliti hobbisti e Arduino, adoratori di lamponi. se fai parte di questo gruppo sembra che HAL sia una buona scelta per te. Secondi che provengono dalla comunità elettronica e hardware, che preferiscono

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

per

LED_On(1)

per aver acceso il LED e vuoi sapere cosa stanno facendo fondamentalmente. quindi se hai in questo gruppo e hai abbastanza tempo per leggere il manuale di riferimento e il manuale di programmazione della tua MCU, forse la programmazione a livello di registro è un'altra scelta. ma se vuoi decidere solo tra le opzioni sopra 2: HAL ha un futuro migliore grazie al supporto di ST ma SPL è un modo più semplice per capire per un nuovo antipasto. Forse questo può aiutare http://www.eevblog.com/forum/microcontrollers/stm32-and-their-hal-library/


1
Grazie per il link, lettura interessante! Hai ragione, per i principianti SPL sembra il modo migliore per imparare (e questo è anche il modo in cui ho scelto). A proposito, nella tua risposta dovrebbe essere LED_Off
Ankit,

1

Ottieni questo IDE: System Workbench per STM32 - è gratuito, basato su Eclipse e ha sia arm-gcc che openocd in un unico pacchetto.

E sulle biblioteche: oltre a SPL e HAL ora esistono LL. Ogni uno ha alcuni vantaggi e svantaggi, e devi scegliere ciò di cui hai bisogno. E a quanto ho capito , tutti hanno uno status sperimentale per ST. Di seguito i miei voti per ciascuno di essi:

  • SPL: vecchio, ingombrante, nessun utilizzo extra di ariete, flessibile
  • HAL: effettivo, ingombrante, utilizzo di ram extra, non flessibile
  • LL: effettivo, leggero, nessun utilizzo extra di ariete, flessibile

Breve descrizione per i miei voti:

  • ingombrante - grande utilizzo del flash, funzioni "super" universali per lavorare con la periferia
  • utilizzo extra di ariete - si tratta di HAL, ha una copia dello stato periferico in strutture situate a ram e lo usa ovunque e in qualsiasi momento
  • non flessibile - e di nuovo su HAL, ha molte funzioni per diversi casi, ma! la maggior parte di essi non è utilizzabile per dispositivi reali (le persone cercano di reinizializzare HAL per ricevere byte per byte da usart >_<, tutte le funzioni per TIM + DMA sono implementate per riscrivere il registro TIM e nessun altro ...)

Per un po 'riabilitare HAL: ha un grande vantaggio per i principianti: è supportato da STMCubeMX.

MODIFICARE:

Dimentico libopencm3 : è una libreria alternativa. Non l'ho usato.

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.