ElectroYou

salve a tutti,
vengo da una cultura microcontrollistica in cui programmando PIC e piccoli AVR si lavorava sempre e solo a livello di bit impostando registri e stando sempre a basso basso livello a contatto con l'hardware mi chiedo: con gli ARM ha senso fare cosi? Cioè, usare middleware o funzioni di libreria ha senso o questo distacco dal basso livello in quache modo è dannoso?
Ad esempio molte IDE includono esempi e funzioni già scritte (che si possono comunque esplorare approfonditamente) secondo la vostra esperienza conviene usarle o meno?
Davide

Ti rispondo con: "Inutile reinventare la ruota"
La cosa importante è sapere cosa usi. Usare le librerie non significa dimenticarsi della struttura hw delle periferiche del micro, ignorare come funziona una SPI o una I2C.
Diciamo che l'approccio non dev'essere Arduino style: pesco da internet - provo- non funziona - cerco altro.
Se conosci il micro e le sue periferiche e sei in grado di leggerti il codice delle librerie perché non usarle.
L'aspetto negativo è che ti leghi mani e piedi a quel micro e a quella struttra del firmware con i suoi vantaggi e i suoi limiti.

ma esistono delle librerie "ufficiali"?
perché ad esempio io ho comprato un M3 a bordo di una discovery invece in facoltà abbiamo un'altra board con un altro sistema disiluppo anche se il micro è lo stesso e le librerie sono completamente diverse

Posso segnalare un caso preso dalla realtà quantunque amatoriale.
Dovevo replicare un meccanismo parecchio delicato ma già collaudato, usando dei nuovi sensori I2C al posto dei vecchi sensori analogici.
Non desideravo che ci fossero storie coi tempi di latenza, tutto sempre in memoria come prima e vai.
Il colloquio I2C me lo sono inventato faticosamente riga per riga, probabilmente molto più ridondante del necessario ma così ho risolto.
Chiuso l'incidente, mi piacerebbe passare alle MCU con 32 bit ma qualcosa mi trattiene.. solo pigrizia?
Per fare uno sciocco paragone, il mio primo PC a 40 MHz mi rispondeva più presto dei sistemi attuali (con possibilità non paragonabili, ovviamente).

Se devi ottimizzare la risposta non c'è storia devi scriverti un driver tuo, le librerie tipo la CUBE di STM sono strati generici prevedono tutti i possibili casi, non sono otimizzate per la tua applicazione.

Per STM so che esiste la CUBE. Ho provato a usarla qualche anno fa su STM32F4 con scarso successo. Non so se adesso è migliore ma non ho letto in un forum dei commenti ironici sulla sua complessità.
Ultimamente ho usato la versione per cortex L0 dove c'è uno strato minimale formato dai files con prefisso LL (credo acronimo di Low Level) che è un vestito cucito sopra i vari registri. Ottimo per avere un'interfaccia già pronta con nomi standard predefiniti e i controlli di debug sui parametri.

Per le tue schede Dadduni se aggiungi qualche dettaglio forse si può rispondere.

Con gli STM32 uso ancora la Standard Peripheral Library praticamente solo per le inizializzazioni.
Per il resto vado con i bit.
In questo modo risparmio tempo per le inizializzazioni ed ho programmi compatti e molto veloci.

La board acquistata da me per fini didattici è questa: STM32VLDISCOVERY e programmo con Atollic True Studio
In facoltà abbiamo le LPC1549 della NXP e programmiamo con MCUXpresso.

Mi vien da dire che alcune operazioni come l'I2C non sia affatto banale da codificare a mano senza alcune librerie

ARM rilascia ufficialmente la Cortex Microcontroller Software Interface Standard:

https://developer.arm.com/embedded/cmsis

scaricabile qui:

https://github.com/ARM-software/CMSIS
https://github.com/ARM-software/CMSIS_5

mette insieme tutte le inizializzazioni a basso libello per i vari compilatori, presente in molti SDK per ARM anche commerciali.

Per una libreria di supporto a più alto livello io uso la libopencm3:

http://libopencm3.org
https://github.com/libopencm3/libopencm3

disponibile per i microcontrollori ARM che uso. E' open source, quindi è possibile esaminare il contenuto di tutte le sue parti e integrarla facilmente in progetti più complessi. Qui trovate esempi già pronti che la usano:

https://github.com/libopencm3/libopencm3-examples

Per quanto riguarda la librerie C esiste la newlib sopportata direttamente dal ARM insieme al GNU toolchain completo:

https://sourceware.org/newlib
https://developer.arm.com/open-source/g ... ain/gnu-rm

ST per me dovrebbe limitarsi a fare solo hardware e rilasciare la documentazione e smettere di tirare fuori ambienti di sviluppo dove tenta di semplificare al massimo la complessità della programmazione non riuscendoci.

dadduni ha scritto:Mi vien da dire che alcune operazioni come l'I2C non sia affatto banale da codificare a mano senza alcune librerie

Mah, se non devo usare DMA la I2C la sintetizzo bit per bit, come si faceva a gli albori. Ho così anche il vantaggio di poter scegliere qualsiasi pin

dadduni ha scritto:(...) Mi vien da dire che alcune operazioni come l'I2C non sia affatto banale da codificare a mano senza alcune librerie

hai ragione, ma qui si ricade nell'ovvietà: di quel che non si conosce può essere difficile avere una prospettiva, viceversa forse no.
Non è immediato, e forse nemmeno intuitivo, se non s'è sperimentato un pochino a basso livello, ma prima, in modo simile a quanto scritto da @TardoFreak, la I2C te la facevi scalpellando bit per bit utilizzando i pin che avevi a disposizione.
Nulla di eroico, si faceva con quello che c'era.

Saluti