Memorizzare dati

Salve,
nel mio progetto avrei bisogno di memorizzare dei dati tipo stringa e numerici, ho abbandonato la EEPROM perchè oltre che difficoltoso per memorizzare stringhe anche perchè avrei consumato la "vita" della EEPROM in breve tempo...
Ho pensato quindi ad una scheda TF, ma mi è difficile pensare all'organizzazione...
Provengo dal mondo del web e in tali casi mi affido ad un database nel quale memorizzo i miei dati e con semplicità con delle query li richiamo e organizzo con semplicità a mio piacere...
Nel caso specifico avrei bisogno del "lume" degli esperti per capire la "direzione".
Nel mio caso, ad esempio, dovrei memorizzare un processo di produzione di alcuni materiali e le loro quantità con relativa data.
esempio:
AD - 80X600X1200 - quantità 32 - data 25/10/2118
SB - 80X1000X1200 - quantità 50 - data 25/10/2118
ecc.
una volta memorizzati devo poterli richiamare tramite un sensore o un comando...
Se scrivo nella TF creo un file ma poi il problema e come fare per richiamare un prodotto specifico?
Spero di essere stato chiaro, vi ringrazio in anticipo.
Maurizio Filomeni

stabilito cosa vuoi menorizzare ti crei la stringa e la usi... nel tuo esempio:
AD - 80X600X1200 - quantità 32 - data 25/10/2118 = AD80X600X12003220181025
ad esempio

se non vuoi metterci caratteri alfanumerici li trasformi anche questi in numeri

sapendo che
A=65
D=68
X=88

AD - 80X600X1200 - quantità 32 - data 25/10/2118 = 656880886008812003220181025
ovvio che sei tu a dover sapere cove sono scritti e come sono organizzati.... ne più ne meno che sulla eeprom

quando li richiami dovrai leggere il contenuto della memoria filtrando i risultati a secondo di quello che vuoi cercare
es data=2018
controllerai che i caratteri in posizione 20-23 corrispondano a 2018
656880886008812003220181025
e così via...

Sempre grazie per la risposta.
Pian piano sto capendo che l'unico modo per memorizzare dati è con la eeprom! Quindi nel mio caso avrò filo da torcere scrivendo papiri immensi... Questi dati vengono immessi da un operatore tramite un display touch, quindi dovrei commutare tutte le possibili immissioni da parte dell'operatore in numeri, fare degli if ed assegnare il valore dei dati memorizzandoli in eeprom. Questa dovrebbe essere la logica di programmazione? (se si, bel lavoro che mi sono procurato :frowning: )
Mi faccio una domanda, non è possibile gestire con una TF micro SD, scrivendo in essa file di testo e poi rileggere il contenuto come dato memorizzato?
Quindi evitando di fare lunghe trasformazioni e comparazioni, poi siccome il flusso di lavoro si concentra nella continua scrittura, la eeprom avrebbe "vita corta".
Grazie
Maurizio Filomeni

filomeni:
Pian piano sto capendo che l'unico modo per memorizzare dati è con la eeprom!

Mah, la cosa che in genere bisogna chiarire (o chiarirti?) è: quanto di frequente aggiungi nuovi dati, se i dati sono ad accumulo (ossia aggiungi solamente nuovi record), se invece oltre a inserire nuovi record e leggere devi anche aggiornare dei dati esistenti, con quale chiave accedi a tali dati, e in caso di accumulo se devi cancellarli per obsolescenza e quindi quanti dati in totale devi memorizzare.

Vista la tua descrizione, devo dedurre che i dati siano da conservare in memoria non volatile, sono ad accumulo (inserisci nuovi record, niente aggiornamenti), ma dato che dici che devi poterli richiamare in base a qualcosa (codice articolo? data?), serve un qualche "indice", ma soprattutto non dici quanti dati devi tenere in memoria e come fare il purge (cancellazione dati obsoleti).

Visto tutto questo, salvo condizioni che non hai esplicitato, mi sembra che l'EEPROM non vada affatto bene perché è solamente una sequenza di (pochi) byte. Memorizza localmente un buffer, e scrivi via TCP/IP su un server dotato di database (consiglio di creare un piccolo web service REST per gestire l'inserimento e ricerca dati).

Ti svelo un segreto: qualunque cosa memorizzata in qualunque memoria di una CPU moderna è già un numero (o una serie di numeri).

char *str = "Antani";
EEPROM.put (0, str);

Rendo l'idea?

In ogni caso, che usi EEPROM o SD cambia poco, dovrai strutturare in qualche modo i record, scriverli, leggerli e iterare su di essi. Suggerisco la definizione di una struct di dimensione fissa, semplifica parecchio le cose.

... io invece suggersico di passare ad un qualche cosa dove tutto questo è moooolto più semplice da implementare ... Rasperry PI :smiley:

Arduino NON è nato per fare queste cose ... è un microcontrollore, non un computer !!!

Guglielmo

gpb01:
... io invece suggersico di passare ad un qualche cosa dove tutto questo è moooolto più semplice da implementare ... Rasperry PI :smiley:
Arduino NON è nato per fare queste cose ... è un microcontrollore, non un computer !!!

Esatto. Oppure un RPI ma usato come "server" (un piccolo web service di gestione non è difficile) per l'Arduino, ha risorse maggiori e può gestire anche piccoli DB su filesystem, fino ad interfacciasrsi con MariaDB (scusate, non nomino MySQL perché Oracle mi sta sur caz.. antipatico).

EDIT: effettivamente non ho ben capito i dati che vuole memorizzare se provengano da qualcosa (sensore, periferica, intervento divino) o se siano input di un operatore, perché in quest'ultimo caso non ha proprio senso usare Arduino.

... però puoi sempre nominare SQLite che per queste cose è comodissimo ... leggero, veloce, pratico :smiley:

Guglielmo

Ah beh, se non c'è qualche motivo particolare per dover usare Arduino, concordo che passare a un RasPi gioverebbe parecchio!

docdoc:
EDIT: effettivamente non ho ben capito i dati che vuole memorizzare se provengano da qualcosa (sensore, periferica, intervento divino) o se siano input di un operatore, perché in quest'ultimo caso non ha proprio senso usare Arduino.

Questi dati vengono immessi da un operatore tramite un display touch

si appunto :slight_smile:

gpb01:
... però puoi sempre nominare SQLite che per queste cose è comodissimo ... leggero, veloce, pratico :smiley:

Beh infatti ho detto genericamente "può gestire anche piccoli DB su filesystem" ed il principale esponente è SQLite... :wink:

Vi rilascio altre info per la precisione, si parla di programmare il sistema per dei cicli di produzione con diversi prodotti e tipologie. I dati vengono, come detto, immessi dall'operatore, il quale formula e conferma i dati di produzione: tipo, spessore, dimensioni, quantità. In seguito c'è il lavoro del processore... Tramite una serie di sensori, prelevo le caratteristiche e le confronto con quelle immesse dall'operatore. A fine produzione il programma rimane in memoria, perché se vogliamo consultare la produzione di una data posteriore dobbiamo poterlo fare... Io credo di aver trovato il sistema, ora lo sto pensando a soluzione lo posto... Grazie a tutti

Ma a quel punto perché non una scheda SD?

docdoc:
Ma a quel punto perché non una scheda SD?

Ma a quel punto perché non un PC ?

Guglielmo

gpb01:
Ma a quel punto perché non un PC ?

Guglielmo

Perché a quel punto chiuderesti il thread. :smiley:

speedyant:
Perché a quel punto chiuderesti il thread. :smiley:

:stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

Guglielmo

P.S.: ... ma sai bene che un PC sarebbe la soluzione più logica :wink:

Però se si “spiegasse” il processo industriale coinvolto, si potrebbe scoprire che arduino in qualche modo è coinvolto.

speedyant:
Però se si "spiegasse" il processo industriale coinvolto, si potrebbe scoprire che arduino in qualche modo è coinvolto.

Beh diciamo che in parte lo ha scritto:

I dati vengono, come detto, immessi dall'operatore, il quale formula e conferma i dati di produzione: tipo, spessore, dimensioni, quantità. In seguito c'è il lavoro del processore... Tramite una serie di sensori, prelevo le caratteristiche e le confronto con quelle immesse dall'operatore

Se così fosse, l'uso di Arduino, almeno per quella seconda fase di acquisizione dati, ci starebbe.
Ma limiterei Arduino solo a questo scopo, magari delegando l'inserimento dati ad un più comodo PC o tablet tramite il quale accedere ad un sito web locale per l'immissione di questi dati. Quindi il sistema centrale (oltre al web server avrà il suo DB, magari un MariaDB, ma può andar bene anche un Raspberry Pi 3 con sopra SQLite) riceverà da Arduino (o "gli" Arduino se distribuiti lungo la filiera di produzione) i dato man mano che i prodotti vengono misurati, ed in base a questo attivare warning

@Guglielmo! Perché dovrei chiuderlo! La discussione rimane sempre aperta... Dando possibilità di replica...

Sono 20 anni che uso PC... Consentì temi divertimento e utility... Per lo scopo sto pianificando l'uso di una SD, appena pronto lo posto e non chiudo :wink:
Saluti
Filomeni Maurizio