#include <DueFlashStorage.h>
DueFlashStorage dueFlashStorage;
byte data_store[] = {192,168,2,177,192,168,2,1,255,255,255,0};
void setup() {
delay(2000);
Serial.begin(9600);
virtual_eeprom_verify();
delay(2000);
virtual_eeprom_read();
}
void loop() {}
void virtual_eeprom_verify() {
int num_cell_write = 0;
for ( byte i = 0; i < 12; i++){
if(data_store[i] != dueFlashStorage.read(i)){
dueFlashStorage.write(i, data_store[i]);
num_cell_write++;
}
}
Serial.print("Numero celle FLASH sovrascritte ");
Serial.println(num_cell_write);
}
void virtual_eeprom_read() {
for ( byte i = 0; i < 12; i++){
Serial.print(dueFlashStorage.read(i));
Serial.print(" ");
}
Serial.println();
}
Tutto funziona, e ho fatto in modo che solo al primo avvio (dopo la compilazione) vengano scritti i valori sulla flash, poi ogni volta che si fa il reset non viene sovrascitta dato che i byte sono già presenti.
Ma la domanda è:
Ipotizziamo che questi valori byte data_store[] = {192,168,2,177,192,168,2,1,255,255,255,0}; arrivino dall'esterno tipo SD e se dovessi scrivere 8.000 - 16.000 byte chi mi dice che non vado a scrivere sopra al programma?
esistono delle regole precise? perchè il tipo comincia a scrivere dalla pos[0] sulla flash, ma quanto posso spingermi oltre senza sovrascrivere lo sketch? Le posizioni della flash sulle quali è presente il programma sono bloccate da scrittura?
L'ideale sarebbe andare a scrivere in coda allo sketch, qualcuno sa darmi qualche dritta?
Premetto una cosa, che sto parlando senza aver sottomano il datasheet.
Sull'Atmega328 lo sketch viene salvato partendo dalla locazione 0 in poi, quindi la memoria viene così usata:
XXXXXXXXXX____________OO
Dove "X" rappresenta la Flash occupata dallo sketch, "O" quella occupata dal bootloader.
Sulla DUE il bootloader è memorizzato in una ROM e quindi si può escludere.
Ma lo sketch non è salvato a partire da $0000?
pablos:
esistono delle regole precise? perchè il tipo comincia a scrivere dalla pos[0] sulla flash, ma quanto posso spingermi oltre senza sovrascrivere lo sketch? Le posizioni della flash sulle quali è presente il programma sono bloccate da scrittura?
L'ideale sarebbe andare a scrivere in coda allo sketch, qualcuno sa darmi qualche dritta?
Premesso che non ho la DUE, non conosco in dettaglio il micro che usa e non mi interessa conoscerlo :), però l'uso della flash come EEPROM virtuale è largamente utilizzato su i micro 32 bit perché quasi nessuno integra la EEPROM.
Di solito viene riservato una spazio dedicato alla EEPROM virtuale in fondo alla flash e tipicamente più grande di diverse volte, dipende molto da quanto ti serve e da come sono organizzate le pagine della flash, in modo da evitare la scrittura continua sempre sullo stesso blocco di flash anche se devi aggiornare pochi byte.
Tieni presente che la flash ha un numero molto limitato di scritture possibili rispetto ad una EEPROM, siamo ad un fattore 100x di differenza, sarebbe sempre meglio utilizzare una vera EEPROM I2C esterna.
La EEprom virtuale sarà presente sulla nuova Arduino Zero. Quindi immagino che il Team stia preparando anche una libreria per gestirla.
Comunque sono d'accordo con Astro. Meglio una EEprom esterna.
La monti su uno zoccolo e la cambi quando vuoi.
PaoloP:
Quindi immagino che il Team stia preparando anche una libreria per gestirla.
Esiste un'ottima libreria realizzata da Microchip per i dsPIC, "soffrono" dello stesso problema, perdendoci un pochino di tempo non è complicato farne un porting per Arduino DUE.
Grazie per l'intersessamento è tutto sperimentale per la scenza
ho provato a inserire 8192 byte (8K) su un programma qualsiasi ... ho detto "qui mi sa che faccio un casino!! vabbè al massimo la butto tanto la DUE non piace a nessuno "
Il programma funziona sempre ed è rimasto integro, lo store di 8192 byte sono esatti ho cambiato il primo e l'ultimo byte della serie per vedere che non sia un allucinazione!!
Ma dove lo scrive sto sketch??!! indagherò ...
ciao
@astro, certo ne sono consapevole dei limiti 10.000 .... tante quante ne posso fare in compilazione, e sono tante considerando che sulla eeprom virtuale o esterna ci andrei a scrivere 5-10 volte in un anno.
Queste cose vanno fatte con molta cautela e ponderazione, basta mettere la scrittura nel posto sbagliato che friggi la flash in poco tempo.
I tempi di lettura di una posizione sulla flash sono nettamente inferiori a quella di un I2C
Ho fatto la scansione della flash da 0 a 512000 posizioni, ho cominciato a trovare valori diversi da -1 (255) (0xFF) alla pos 262138 che dovrebbe essere il mio sketch anche se è molto piccolo, probabilmente sono vecchie scritture non più operanti.
Per logica parrebbe che lo sketch sia in fondo, bisogna vedere se quel dueFlashStorage.read(0) legge davvero la pos 0 della flash o fa qualche giro strano.
Non ho studiato la DUE ne tantomeno il suo bootloader hardware, ma se è simile agli altri dovrebbe caricare lo sketch compilato a partire dalla posizione più bassa della flash, non so se è 0000, e poi passargli il controllo con un jmp se non riceve segnali di una nuova programmazione.
Mi pare strano che nelle locazioni basse della flash non ci sia nulla.
Può essere che la legga al rovescio e scriva sulla parte finale, ma per comodità parta da 0 facendo le sottrazioni e in un certo senso sarebbe logico,
Può essere invece che parta da zero subito dopo lo sketch .......
comunque funziona anche con programmi molto più pesanti.
La controprova andrebbe fatta con la lettura della flash con le istruzioni del core partendo da 0x00000000 e verificare i contenuti
Ho dato un'occhiata velocissima al datasheet: c'è scritto che il bootloader avvia sempre il programma dalla locazione 0 per cui io intendo che il programma è scritto a partire da quella locazione. Altra cosa, esistono i lock bit che proteggono la flash a pagine, quindi immagino che sapendo la dimensione del programma si possa poi proteggere tutta la parte che esso occupa.
Nella manipolazione della flash che uso (in questo caso sul SAM3x) le librerie sono realizzate dalla Atmel, quindi non penso che nella ZERO faccia molta differenza, anzi variandone gli address e qualche altra cosina alla fine mi sa che sarà la stessa.
Copyright (c) 2011-2013 Atmel Corporation. All rights reserved.
efc.cpp
Copyright (c) 2011-2013 Atmel Corporation. All rights reserved.
efc.h
Copyright (c) 2011-2013 Atmel Corporation. All rights reserved.
flash_efc.cpp
Copyright (c) 2011-2013 Atmel Corporation. All rights reserved.
flash_efc.h
Ma secondo me (rimanendo in ambito Arduino senza cercare altre famiglie) le prestazioni e potenzialità che da questa scheda, nella ZERO ve la scordate
pablos:
Ma secondo me (rimanendo in ambito Arduino senza cercare altre famiglie) le prestazioni e potenzialità che da questa scheda, nella ZERO ve la scordate
Sulla DUE c'è un processore ARM Cortex M3 con un clock doppio rispetto a quello del processore ARM Cortex M0 presente sulla ZERO, va da se che la DUE è superiore alla ZERO anche senza scomodare la matematica
In teoria la ZERO dovrebbe essere la UNO con processore a 32 bit e deve costare circa come la UNO altrimenti è fuori mercato.
PaoloP:
Da Digikey oltre i mille pezzi l'ATmega328P viene 1,57 € mentre il Samd21G18 2,47 €.
Considera inoltre che la zero monta l'EDBG quindi costerà di più.
Si ma non c'è l'Xu2, alla fine i costi si compensano a vicenda e non è certo uno o due Euro in più per i micro che può fare una grossa differenza sul costo finale, se la ZERO costerà sensibilmente di più della UNO sarà un megaflop peggio della DUE
E' un flop anche se costa meno, siamo in 10 qui sul forum che si adatta al 3.3v . In questa ultima settimana ho già visto 3 SAM dove vengono collegati direttamente input 5v da sensori che lavorano a 5V, sfilze di led collegati ai pin senza R.
Le domande hardware arriveranno a raffica ta-ta-ta-ta-ta-ta-ta-ta
è tutto sperimentale per la scenza 
