gingardu:
mah.. qualcosa di "strano" sembra che c'è,
Non c'è nulla di strano, semplicemente non vengono visualizzati gli zeri non significativi, p.e. 0b0001000 viene stampato come 1000.
Quoto.
astrobeed:
erpomata:
Per non dover ricordare un comando strano
Sarà strano per te, per noi è la norma
Quoto anche questo, e rispondo alla domanda di erpomata dicendo che il motivo è semplice: essendo ormai molti mesi che spippolo coi registri dei micro, mi viene più naturale scrivere quella riga che andare ad includere una libreria e poi usarne i metodi per fare ciò che mi serve.
Si mi scuso, avevo aggiornato "a mano" il codice che stavo studiando in università.
Quel ciclo while (k<100) mi serve per ottenere una migliore simmetria del segnale in uscita.
Se provi ad escluderlo, vedrai che la simmetria "sballa" di molto.
Io ho letto qualcosa sulla programmazione in c puro.
Forse a qualcuno potrebbe interessare, quindi posto questo link:
La cosa pero' che non capisco è la seguente:
se io programmo usando avrstudio, vado in qualche modo a compromettere il funzionamento della scheda in ambiente IDE?
In altre parole, se decido di programmare con avr studio, poi in futuro l'ambiente IDE non riconoscerà più la mia schedina arduino?
carichi i 32 byte in un array da cui lo leggi poi ad una velocità molto maggiore rispetto a fare continue letture dalla EEPROM;
Io avevo letto che la SCRITTURA in EEPROM è lenta mentre l'accesso avviene in 4 cicli di clock.
The EEPROM read access takes one instruction, and the requested data is available immediately. When the EEPROM is read, the CPU is halted for four cycles before the next instruction is executed.
Io dovrei leggere 9 array simili a quelli presenti nel programma.
Dato che il tempo di accesso è sempre il medesimo, ottengo, in linea di principio una buona simmetria del segnale in uscita.
Si mi scuso, avevo aggiornato "a mano" il codice che stavo studiando in università.
Quel ciclo while (k<100) mi serve per ottenere una migliore simmetria del segnale in uscita.
Se provi ad escluderlo, vedrai che la simmetria "sballa" di molto.
Io ho letto qualcosa sulla programmazione in c puro.
Forse a qualcuno potrebbe interessare, quindi posto questo link:
gingardu:
mi sa che l'unica cosa che si tocca è l'atmega, al max atmega con botloader fresco e tutto ritorna come nuovo,
Perché mai dovresti cancellare il bootloader ? Mica l'ha ordinato il dottore, nulla vieta di scrivere un programma in C tramite AvrStudio e caricarlo su Arduino grazie il suo bootloader utilizzando AvrDude da riga di comando, o più semplicemente uno script.
Quoto Astro, una volta generato il file in formato hex, da riga di comando si può caricare su Arduino, è importante però usare l'opzione "- D" per evitare che venga eseguito prioritariamente, un chip erase che cancellerebbe tutta la flash, compreso il bootloader; in mancanza di esecuzione del chip erase, i lock bits non vengono toccati e di conseguenza bloccano l'accesso alla parte alta della flash, quella che contiene appunto il bootloader.
dr.benway:
Io avevo letto che la SCRITTURA in EEPROM è lenta mentre l'accesso avviene in 4 cicli di clock.
In scrittura la EEPROM del 328 richiede circa 3,3 ms. Ed è ovviamente lentissima.
In lettura, come hai detto tu, richiede 4 cicli di clock. Ma la SRAM ne richiede solo 2.
Quindi anche in lettura la SRAM risulta sempre più veloce.
Se tu prendi il tuo ciclo e lo fai eseguire 1000 volte, alla fine 32 letture per 1000 sono 32000*4=128000 cicli di clock, mentre con la SRAM ne hai eseguiti la metà, 64000.
in mancanza di esecuzione del chip erase, i lock bits non vengono toccati e di conseguenza bloccano l'accesso alla parte alta della flash, quella che contiene appunto il bootloader.
Mi sembra allora di capire che E' POSSIBILE programmare il 328 senza intaccare il bootloader.
Quindi terminato questo progetto, potrei tranquillamente riprogrammare la scheda in ambiente IDE. 8)
Quoto Astro, una volta generato il file in formato hex, da riga di comando si può caricare su Arduino, è importante però usare l'opzione "- D" per evitare che venga eseguito prioritariamente, un chip erase che cancellerebbe tutta la flash, compreso il bootloader; in mancanza di esecuzione del chip erase, i lock bits non vengono toccati e di conseguenza bloccano l'accesso alla parte alta della flash, quella che contiene appunto il bootloader.
Ottima info. Sarebbe utile organizzare un thread/tutorial per la programmazione avrstudio.
Magari se non c'è già qualcosa sul forum, lo apro io nei prossimi giorni, per condividere la mia esperienza.
Ma la SRAM ne richiede solo 2.
Quindi anche in lettura la SRAM risulta sempre più veloce.
