Ciao, in risposta alla domanda del perchè l'uso di byte per le array...
Diciamo che principalmente perché avendo la necessità di avere in SRAM tante array (mappe) caricate per velocità di calcolo, e per poter usufruire della UNO l'ho impostato fin dall'inizio sulla riduzione di memoria occupata. Non vorrei memorizzare i dati delle mappe in flash, quindi preferisco siano memorizzati in EEPROM, diciamo che allo stato attuale, dal conteggio che ho, sommariamente, mettendo tutti i dati byte che ho in arrays e singoli dati variabile/costanti, sto già sulla soglia del limite della EEPROM della UNO, ma se non dovessi apportare ulteriori aggiunte o ampliazioni, mi avanzerebbero circa 70-90 bytes su 1024 disponibili. Comunque adesso questo non è un problema, presto passerò il progetto su Atmega1284P che di flash ne ha 128Kb, di EEPROM ne la bel 4Kb e di SRAM ben 16Kb.
Per ora, con la SRAM, considerando che non ho ancora tutto funzionante e quindi tutto quello che ho in teoria inizializzato come variabili, costanti e arrays non utilizzate da nessuna parte, il compilatore semplicemente le esclude, ma una buona parte è già funzionante, usando "freeRam" messo sparso un po dappertutto a fine funzioni, ottengo che ho ancora circa 1400-1450 bytes di SRAM, non male, ma ovviamente, credo che a fine progetto, ne resteranno si e no 400-500 liberi e non so fino a che punto siano sufficienti per fare cose che non posso misurare dove stanno messe. Per fortuna il passaggio alla 1284p risolverà indirettamente, anche questo ipotetico eventuale problema che potenzialmente potrò incontrare.
In realtà la scelta della 1284p è stata dettata per vari fattori:
1-ha 2 timers 16 bit, mi servono assolutamente.
2-ha 2 timers 8 bit, necessari per alcune funzioni da implementare in secondo momento.
3-funziona a 20 MHz (anche la UNO potrebbe farlo, la MEGA da datasheet NO) quindi un buon 25% di potenza in più.
4-Ha 128Kb di Flash (anche se per ora, non uso tanta flash da saturare la UNO).
5-Ha 4 Kb di EEPROM, mi darebbe respiro e consentirebbe anche l'implementazione di multi mappe, feature molto richiesta nel motorsport, e mi piacerebbe inserirla se possibile.
6-Ha 16 kb di SRAM e questo non può che giovare al progetto.
7-il formato TQFP44 è perfetto per un progetto stand alone, lo posso saldare agevolmente quello della MEGA non tanto.
8-il chip 1284P costa meno della metà di quello della MEGA.
della Mega invidio solo i 4 timers a 16 bit, adesso che ho visto cosa si può fare sfruttando i timers con OCRnX, più ce ne sono meglio è.
Altra ragione dell'uso di byte per la memorizzazione dei dati, è che essendo queste organizzate in byte, se dovessi memorizzare un dato "int" o "unsigned int" essi occuperebbero 2 byte giusto? formando una word a 16 bit giusto? un double 4 byte e i float? non me lo ricordo, ma il consiglio che ho visto spesso in giro é: evitarli come la peste, si mangiano Flash, RAM ed EEPROM come niente e inchiodano le prestazioni. E qui, le prestazioni sono tutto o quasi, siamo quasi nel "Real Time" e voi mi insegnate...
Quindi anche per mia facilità, memorizzare/leggere un byte è più facile che con una word, dove poi devo andare a decidere di leggere il MSB e LSB, con i quali ancora faccio fatica a ragionarci, e si sa, "make it simple" recita un famoso detto gringo, ed ha ragione.
Consapevole delle mie grandi lacune Tecniche in materia Hardware/programmazione tento di ridurre tutto a codice che per me sia comprensibile, almeno fin tanto non imparo nuove cose, purtroppo questo rende le prestazioni del sistema più lente o addirittura inutilizzabili...
Ho analizzato il codice sorgente di diversi progetti di ECU basati su Arduino/Freescale ecc e ho riscontrato diverse strade per fare le stesse cose, questo mi da da pensare, che la strada non è standarizzata, e quello che per me può essere un'incubo per qualcun'altro sarà normale amministrazione...