quanto scendere a basso livello sugli ARM

[pusillus]

Scusate la mia ignoranza: ma conviene costruirsi a mano il protocollo I2C quando stm32 ha già pronta la sua implementazione hardware di questo protocollo?
xyz ho dato un occhiata agli esempi per stm32 delle openocm e la libreria mi sembra molto simile alla SPL di St che sto utilizzando. Purtroppo ST le sta abbandonando in favore delle HAL che ho provato e non mi piacciono per niente. In più ne parlano tutti male perché parecchio bacate.

[luxinterior]

Su STM32 ho verificato proprio oggi (stimolato dalla discussione) che anche per STM32F4 c'è la nuova versione della libreria con la separazione del basso livello dal resto. Secondo me almeno quel livello (i file con prefisso ll_) vale la pena di utilizzarlo Sono praticamente le SPL riscritte, aggiornate e ampliate ai nuovi modelli.

Quanto all'I2C, chiaro che per dadduni alle prime armi può sembrare impegnativo, scrivere il driver muovendo un bit alla volta aiuta sicuramente a capire le cose. Personalmente ho trovato molto semplice utilizzare la periferica degli STM basta gestire i bit nella routine di interrupt per fare avanzare la macchina a stati dell I2C. Nessun delay a numero di istruzioni fa tutto la periferica che alza un bit con relativo interrupt quando ha finito un'operazione.

[pusillus]

luxinterior
In effetti ho visto che la ST si sta impegnando a sviluppare le LL per tutti i core. C'è anche un tool per migrare da SPL a LL:
http://www.st.com/content/st_com/en/pro ... erter.html

probabilmente si sono accorti che le HAL non sono state gradite e stanno correndo ai ripari. Spero che le LL vengano supportate presto da MDK.

[TardoFreak]

Io mi chiedo perché la ST continui a tirare fuori pxttxnate di continuo.
Basterebbe una buona libreria standard, ben documentata (non solo con il Doxigen ma con dei pdf e parecchi esempi) che comprenda tutti i modelli e che si posso utilizzare con i vari sistemi di sviluppo come il Keil, IAR e magari con la toolchain gnu.
A mio avviso stanno facendo solo un casino monumentale che crea confusione per niente.

[luxinterior]

Concordo fanno e disfano di continuo sia nel fw che nell'hw
Hanno una miriade di versioni di micro e se non scegli il filone giusto fai pure fatica a trovarli.
Io stavo per diventare isterico con i registri del power control di un STM32L0 Secondo me nemmeno loro sanno destreggiarsi tra le Nmila opzioni da abilitare/diabilitare a destra e a manca.

Il vantaggio è che nel marasma ci sono cose notevoli a prezzi abbordabili. A suo tempo usavo texas, un altro mondo, fw delle llibrerie scritto in modo meraviglioso ma prezzi molto molto più alti.

Credo che la strada inidcata da Tardofreak sia la migliore usare il minimo indispensabile magari la versione LL vista l'età della SPL e costruirsi da soli gli strati sopra limitandosi a quello che serve.

[pusillus]

Sto leggendo questo:
https://www.google.it/url?sa=t&source=w ... FvYXM3Gtke

Mi pare che le LL siano più o meno quello che chiedeva tardofreak.
Non so quanta documentazione sia disponibile.

[TardoFreak]

Io ho risolto la portabilità del firmware scrivendo funzioni che utilizzano puntatori a funzioni. Faccio un esempio: le classiche funzioni per pilotare i display LCD alfanumerici. Uso questa funzione di inizializzazione:

Codice: Seleziona tutto

void HD44780init(uint32_t linee, uint32_t colonne, uint32_t lineeHW,
                 void (*writeDigitFnc) (uint32_t dato),
                 void (*setEfnc) (uint32_t val),
                 void (*setRSfnc) (uint32_t val),
                 void (*delay10UsFnc) (uint32_t val))

Dove
- writeDigitFnc E la funzione che scrive i 4 bit nelle linee D4-D7
- setEfnc 1 o 0 per pilotare la linea E
- setRSfnc 1 o 0 per pilotare la linea RS
- delay10UsFnc per generare un ritardo di n * 10us.

ho scritto le funzioni per praticamente ogni dispositivo che uso insieme ai micro, sia che siano ARM o AVR o PIC.
Per interfacciarmi, per esempio, con una FLASH esterna devo solo scrivere le funzioni per leggere/scrivere bytes o blocchi e per cancellare la memoria o un determinato blocco, e via dicendo. Il modulo contiene invece molte funzioni (anche complesse) per organizzare i dati all'interno della memoria.
Scrivere queste funzioncine che svolgono questi semplici compiti è un lavoro semplicissimo. A volte uso le funzioni di libreria ma il più delle volte non le uso perché, ripeto, sono facili da scrivere.
Con buona pace di tutte le astrazioni messe a disposizione.
Inoltre ho il vantaggio di usare sempre gli stessi moduli indipendentemente dal micro.

E, cosa non da poco, evito di correre sempre dietro alle nuove release delle librerie. Se dovessi farlo diventerei pazzo.

[dadduni]

io conoscevo il C in maniera abbastanza approfondita su PC, poi quando ho studiato il VHDL mi sono detto che era troppo difficile rispetto al C e mi sono dedicato a quello, dopo di che adesso che sto tornando al C su micro non ci sto capendo più nulla

[pusillus]

luxinterior
Cube genera correttamente il codice LL per MDK. E' utile come base di partenza. Vedo che con le LL sono supportati tutti i core...molto bene.
Non riesco a trovare la documentazione... tocca spulciarsi i sorgenti o c'è qualcosa in giro?
grazie

[EcoTan]

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

Mi scuso per il parziale OT, sto affrontando lo stesso problema con un pic32.
Col compilatore XC16 esisteva una directory support contenente i file .h descrittori per le singole MCU, bastava includere il file giusto nel sorgente e si potevano usare direttamente i nomi dei registri.
Adesso col pic32 ci vuole il compilatore XC32 e questo va bene, ma pare che i file .h siano spariti, come debbo fare?

P.S. sembra che la frase magica adesso sia:
#include <xc.h>
però non funziona ancora: compila, programma, verifica ma poi non esegue. Stranezze coi fusebit?