Salve a tutti
Ho un file di testo, posizionato su una SD, che mi fa da setup per uno sketch.
In pratica all'interno sono contenture una 10na di righe con commenti e valori.
Ecco un esempio :
//file di config per lo sketch
//ideato da giggetto
//definisce il colore
<COLORE=VERDE>
//definisce la durata di on del relay
<RELAY_DELAY=2000>
//definisce il valore iniziale
<INIT=200>
Nel momento in cui modifico una variabile, vorrei aggiornare il file SD.
Per esempio : all'interno dello sketch, INIT diventa 100 e voglio aggiornarlo, oltre che in memoria, anche sulla SD.
importante : non voglio perdere i commenti, quindi il file aggiornato deve contenere tutte le righe.
La mia attuale conoscenza dello scenario mi porterebbe a :
- leggere il file riga per riga
- posizionare ogni riga in memoria in un char array
- ciclo for e scrivere un file temporaneo con le suddette righe array in append, sostituendo quanto modificato (nel nostro caso INIT)
- cancellare il vecchio file
- rinominare il nuovo col nome del vecchio
La domanda è :
esiste un modo differente e/o specifico a me sconosciuto o quello che ho scritto su è un metodo ok ?
nota :
attualmente SD.h e con i vari comandi non ho problemi a leggere le righe char per char e poi a definire le variabili contenute, distinguendo senza problema i commenti dai dati che servono.
grazie come sempre a chi mi potrà dare lumi
La tua idea di lavorare con i file di testo è giusta, ma è sbagliato lavorare con file di testo.
Probabilmente vuoi che il file sia leggibile e interpretabile da parte di un essere umano, è un tuo desiderio ma che sia veramente necessario è improbabile.
Se uno volesse salvare su SD delle impostazioni, potrebbe crearsi un record, una struct, e con i metodi read e write, leggere e scrivere tutto il record con una sola riga di codice, rendendo la cosa molto semplice.
Se tu vuoi usare per forza file di testo, non trovo alternative alla tua. 
Effettivamente non ci sono alternative a questo metodo
Se non di dettaglio, per ridurre l'occupazione di memoria
Bisogna che ci lavoro, ne:
la mia seconda volta...
torn24:
.. ma che sia veramente necessario è improbabile..
ahimè è molto "necessariamente probabile", invece.
il file deve essere leggibile da notepad o quant'altro, esattamente come fa l'ide con preferences.txt
questo perchè l'utente deve avere due possibilità :
- modificarlo da menù interno appropriato che utilizza un encoder rotativo (se si tratta di pochi dati)
- modificarlo da pc o mac se deve cambiare molti dati e quindi l'uso dell'encoder risulterebbe pesante. (i files sono in tutto 50).
utilizzare un dbase mi risoverebbe la vita in un primo momento ma poi me la renderebbe un inferno alla prima richiesta di info sulla gestione (da parte dell'utente di turno) simile a quanto detto al punto 2.
Quindi in teoria sono sulla giusta strada.
Nel frattempo mi leggo quanto indicato da @Standardoil
Io sono un fan dei file di testo come li stai usando tu.
Lavoro sui DB dalla mattina alla sera, e se ne abusa alla grandissima solo perchè si è imparato a fare così, ma se si può mettere tutto su file di testo, leggibili dall'umano, in molti casi è meglio e anche più prestante (cioè quando il DB si usa solo per memorizzare su disco e non per le sue caratteristiche, l'integrità referenziale, le sue ottimizzazioni per operazioni insiemistiche su grandi volumi di dati, ecc.).
Quindi, hai la mia benedizione 
Se non ci fosse l'interazione con l'umano che edita manualmente il file, sarei per l'ottimizzazione estrema come suggerito da @torn24, attualmente la sto facendo perchè i parametri che mi servono li salvo su EEPROM prima della trasmissione e sto lottando per recuperare singoli bit.
Ma per una configurazione editabile dall'utente non ci penso due volte al file di testo commentato, come hai fatto tu.
Maurizio
ciao,
magari il presente risulterà più un commento filosofico che tecnico...però dico la mia.
anch'io preferisco gestire file di testo (meglio csv) che DB veri e propri in quanto per tutto quello che ho sviluppato fin'ora non c'era nulla che realmente necessitasse una gestione con DB.
Aggiungo però che sono del pensiero che, in questi casi, i file di testo (o csv) non debbano essere modificati/modificabili direttamente dall'utente finale...si dovrebbe gestire, come si fa con il "preference" dell'IDE di arduino, tramite un'interfaccia grafica.
Questo potrebbe consentirti di fare anche delle verifiche sulla combinazione di alcuni registri/valori/parametri che potrebbero essere vincolati tra loro...e quindi alzare dei warning o forzare delle modifiche.
se lasci mettere mano direttamente al file potrebbero scrivere "bingo" dove ti aspetti un numero da 1 a 3...etc
Ma infatti l'utente non dovrebbe metterci le mani, a meno di una necessità oggettiva data dall'alto numero delle variabili da editare (come detto, nel mio caso, 30 per file per un totale di 50 files).
Nel caso scriva "bingo" è un suo problema, perchè se non ha seguito in modo dettagliato le info di come si inserisce la variabile, leggerà quella di default e in ogni caso cadrà nel famosissimo errore che ormai da molti anni fa parte di tutte le mie applicazioni e che spunta fuori quando l'utente si trova dolosamente in un vicolo cieco.
Si tratta dell' ERRORE PIDC (PI AI DI SI) ---> a roma è l'acronimo di "Pìatela In Der Cu...[censured]."
Eccone un esempio
Ho quindi la vostra benedizione nell'uso del file di testo come ho inizialmente ipotizzato ...
Proseguo tranquillo su questa strada.
Grazie a tutti
- leggere il file riga per riga
- posizionare ogni riga in memoria in un char array
- ciclo for e scrivere un file temporaneo con le suddette righe array in append
Piuttosto che caricarti tutto il file in memoria, potresti valutare la soluzione di leggere la singola riga, nel caso modificarla, e salvarla sul file temporaneo.
Certo sei obbligato ad aprire e chiudere alternativamente i due file, ma se hai problemi di memoria potrebbe essere una soluzione.
Una seconda alternativa, forse più critica, è quella di lavorare con le funzione ".seek()" e ".pos".
Per semplicità carichi comunque in memoria l'intera riga ed effettui la variazione, quindi la sovrascrivi sulla SD nella stessa posizione.
Il problema nasce dal fatto che la riga deve mantenere la stessa lunghezza originale, con gli stessi caratteri terminatori (in genere cr+lf).
Se la correzione è in difetto di byte
Prima <RELAY_DELAY=2000> Dopo <RELAY_DELAY=234>
allora la cosa la puoi risolvere aggiungendo uno spazio generico in una posizione non significativa, ma se la modifica è a debito di byte
Prima <RELAY_DELAY=99> Dopo <RELAY_DELAY=103>
allora devi trovare il modo di lasciare sulla riga originale qualche spazio isolato da poter utilizzare per garantirti di mantenere immutata la lunghezza della riga.
... se hai problemi di memoria ...
Noto che in tutti c'è una specie di paura (me compreso) nell'essere in difetto di memoria, quasi fosse una mancanza di ossigeno.
Ora ... se questo poteva essere vero nelle schede R3 o anche nelle MEGA o in quella più recenti, per fortuna questo problema è latente nei d1-mini e nell' esp32.
Per motivi pratici, devo NECESSARIAMENTE caricare tutto in memoria perchè la chiamata dei vari files è continua e deve essere veloce.
Ci sarebbe troppa latenza, da parte dell'esp 32 "main", nel leggere il file, decodificare quanto letto e passarlo via PJON ai tre esp32 "slaves" per poter gestire a loro volta messaggio midi ed invio all'usb-host.
Come accennato in altro thread, quello che sto facendo è una pedaliera avanzata per chitarristi.
Ogni file è un insieme di variabili che debbo appunto comandare vari devices sparsi qui e li, chi midi, chi usb host, chi dedicati.
Chi preme il pulsante deve avere tutto realizzato nel giro max di un secondo. Se leggo il file ogni volta che si preme il pulsante ci vuole almeno il doppio. Cosa assolutamente fuori dagli standard.
Debbo dire che con mio somma tranquillità ho fatto la prova a creare char array per 30 variabili a file (che sono 50) con una lunghezza totale di 1k a file e ad oggi ho occupato 46% di spazio per i programmi e 11% per le variabili, compreso tutto (gestione del display oled, dei relè, dei vari ammennicoli rtc-ads1115-sd etc)
Attenzione : non ho ancora eliminato tutti i serial.print che uso per il debug e quindi diciamo che ci sto dentro bene, anche perchè lo sketch è quasi terminato.
Quindi, per tornare al discorso principale, qui non si tratta di problema di memoria ma essenzialmente di gestione oculata della stessa e di gestione lettura-scrittura dei 50 files di setup.
Dopo i vostri consigli e le vostre riflessioni ho parzialmente modificato il mio modo di operare, lasciando solo le righe relative alle variabili.
Questo perchè ogni volta che andavo ad aggiornare il file, avrei dovuto caricarlo tutto in in char indefinito (potevano anche esserci commenti dell'utente) e poi riversarlo dentro la SD. Troppo problematico e non essenziale : i chitarristi si leggono le istruzioni fuori dal file e ... buonanotte.
fotosettore:
Dopo i vostri consigli e le vostre riflessioni ho parzialmente modificato il mio modo di operare, lasciando solo le righe relative alle variabili.
Questo perchè ogni volta che andavo ad aggiornare il file, avrei dovuto caricarlo tutto in in char indefinito (potevano anche esserci commenti dell'utente) e poi riversarlo dentro la SD. Troppo problematico e non essenziale : i chitarristi si leggono le istruzioni fuori dal file e ... buonanotte.
Le preoccupazioni erano su questo, appunto per la presenza dei commenti che portano via mooooolto più spazio rispetto alle variabili.
Le variabili vanno sicuramente tutte tenute in ram per i motivi che hai descritto, anche perchè, se sono tutte numeriche e si usano i tipi dato giusti, prima di essere a terra, anche sulla UNO, se ne devono fare di cose...
Il problema è di modificare un file su SD, che a causa dei commenti e delle spiegazioni, invece di pochi byte delle variabili, potrebbe diventare anche di qualche K.
Questo sarebbe problematico da riversare passandolo tutto prima in RAM, anche perchè non si sa di che lunghezza di stia parlando a priori.
E poi si trova sempre il chitarrista furbo che per allineare i commenti riempie il file di blank 
Alla via così!
Maurizio
Socio
Io concordo in pieno con la tua diagnosi
È sulla terapia che ho idee alternative
Come ho sempre detto i file e in generale gli input a caratteri vanno gestiti carattere a carattere e non come oggetti monolitici
Come flussi, quindi
La difficoltà è nel capire come, quando e dove reindirizzare tra loro i vari flussi di caratteri
Inutile dire che ho idee al riguardo
Ma stasera ho traffico in gonnella, quindi se ne parla magari nell'immediato futuro
maubarzi:
... E poi si trova sempre il chitarrista furbo che per allineare i commenti riempie il file di blank ...
cappero ... non ci avevo pensato a questo 
ancor di più una ragione per far fare tutto senza commenti e confermare l'inserimento dell'errore PIDC
Per il traffico in gonnella di @standardoil posso solo dire che fai la cosa migliore, altro che bitEbait
Per me, oramai ... (cit. cin.)
Ho una domanda su usb host e pendrive, apro un altro argomento ...
fotosettore:
...ancor di più una ragione per far fare tutto senza commenti e confermare l'inserimento dell'errore PIDC
Due cose:
- La decisione di eliminare i commenti è cosa buona e giusta, bravo che ci hai pensato tu da solo, la benedizione, su questa scelta, era implicita e ovvia, quindi era stata omessa.
- L'errore PIDC è fantastico! Forse l'unica vera panacea al mondo
Socio, sono tutto orecchi, ma tieni conto del fattore "chitarrista".
Che poi, tra il file di testo a prova di scimmia (ma forse non di chitarrista) e la RAM ci sia campo libero per tante belle ottimizzazioni, siamo d'accordo fin da subito.
@fotosettore: anche se eliminando i commenti i file diventano microscopici, tieni sempre la logica di scrivere su file nuovo e poi eliminare il vecchio e rinominare, perchè Murphy è sempre in agguato.
Maurizio
maubarzi:
... perchè Murphy è sempre in agguato...
marfi non esiste .... marfi sono io
Vero, c'è un Murphy in ognuno di noi!
Maurizio
Come avevo preavvisato ho messo in pratica le mie idee
la mia seconda volta comincia ad assomigliare a una terza...........
Standardoil:
la mia seconda volta comincia ad assomigliare a una terza...........
ho letto il tuo codice ed ho visto numerosi spunti interessanti ...
debbo provarlo