Buongiorno.
tempo fa ho letto articolo redatto da Mr.Guglielmo ( gpb01) al riguardo delle NVSRAM, e Sua libreria.
Tramite TME.it ne ho acquistata una per esperimenti.
Obbiettivo: usarla su un MegaRev3 come store dati Temperatura/umidità
per relativi trend su TFT. Ora funziona con dati salvati su Ram del Mega.
Chip acquistato : 23LCV512 I/P della Microchip.
Problema: sia con la libreria NVSRAM-main da GitHub [GitHub - gpb01/NVSRAM: Arduino library for Microchip 23LCV512 and 23LCV1024 NVSRAM.]
che con istruzioni base dedotte dalla medesima libreria e/o web non funziona "quasi" per nulla.
Visto l'insuccesso con gli INT allora scrivo Byte con nessun miglioramento.
Succede che se scrivo dati "estremi", cioè 0 (zero) o 255 allora rileggo tali numeri.
In tutti gli altri casi non sono veritieri, sia dopo backup della alimentazione sia con letture successive dopo 2 secondi.
Come muletto per prove utilizzo Uno rev3, anche su un secondo Uno rev3 stessa identica problematica.
Provato modulo SD che usa stesso protocollo SPI e questo funziona senza problemi.
NVSRAM si trova come unico device.
Nessuna breadboard, tutto saldato su zoccolo 8 Pin e collegamenti di 15 centimetri.
Ridotto frequenza SPI, nulla di fatto.
Usato inizializzazione Sequenziale 0x40 ( default a manuale) e a Byte 0x00, nulla di fatto.
Allegati esempi di output e software.
Guarda, la libreria funziona perfettamente e posso garantirti che è ampiamente collaudata con entrambi i tipi di NVSRAM che supporta (chip, nel tempo, sempre acquistati da Mouser) ... c'è anche un'apposito shield per montarla su schede Arduino (vd. Elettronica In n.252, Marzo 2021).
Ah ... solo UN utilizzatore mi scrisse in Inglese (uno straniero) che stava incontrando problemi nell'usarla con NodeMCU ... dopo uno scambio di eMail in cui abbiamo fatto un po' di prove (si pensava ad un problema sul bus SPI) s'è scoperto che il problema risiedeva ... nel clock impostato nella NodeMCU (la stava facendo lavorare a 80MHz invece che i classici 160MHz) ... questa la sua ultima risposta:
NodeMCU test: it was not the SPI lines. Surprisingly, it was the CPU cycles.
I changed it from 80 MHz to 160 MHZ, and it began working.
Grazie per la risposta immediata !
Inizialmente ho usato la libreria che indichi, per testare il componente anche se parti della libreria non mi servivano ( solo int e/o byte ).
Quindi istruzioni write/read e put/get.
Però non dava risposte corrette con i float.
Cambiato il load byte proposto da 127 a 128 e non funzionava bene, valori diversi.
Attualmente se la uso i float danno "nan", i byte a casaccio e anche gli int.
Gli array pure...
Quindi temo fortemente che sia un problema di chip.
Se non ti vengono altre idee, organizzo di passare da Futura Elettronica e acquisto un altro chip ( costo 3.90€) .
Se poi tutto funziona, lo comunico in questo post.
Comunque, ti pare che il SW semplificato sia errato ?
Questo per capire più che altro.
Nel frattempo, grazie 1001...
Ho controllato allo sfinimento le connessioni (4 fili), penso che il chip sia difettoso, visto che al primo impatto e con la tua libreria/demo ha funzionato eccetto che con i float.
Scaricato e letto il data sheet Microchip.
... se puoi raggruppa magari un po' di componenti e compra sempre da distributori "ufficiali" ... con Mouser, sopra una piccola spesa (non ricordo se 55€ o giù di li), hai la spedizione gratuita e sei sicuro della qualità dei componenti!
Figurati ... NON è MAI tempo perso ... è sempre utile
Acquistata nuova RAM, installata, stesso risultato di dati incongruenti.
A questo punto, se con due Arduino Uno originali ho lo stesso risultato e che la libreria di Guglielmo è certificata funzionante su molti esemplari , ne deduco che o i collegamenti sono "troppo lunghi" o che le RAM non sono di "prima scelta".
Quindi accorcio i collegamenti a 2 centimetri, consapevole che non posso a questo punto usare il tutto su una millefori, ma lo faccio.
Risultato ancora non corretto. Non leggo i valori scritti.
Ultimo pensiero è che ci sono problemi di "squadratura" dei segnali oppure di impedenza, il mio vecchio oscilloscopio a tubo catodico decido di non usarlo ( banda passante scarsa) e sperimentare da me.
Utilizzo un 74LS14 , uno Schmitt Trigger purtroppo invertente, mi bastano 3 collegamenti ( metto 2 porte in serie ) e il gioco è fatto.
... infatti, hai dovuto usare uno Schmitt Trigger ... il bus SPI è una brutta bestia perché è molto più veloce del bus I2C (che, anche lui, su collegamenti un po' lunghi da problemi) e viaggia nell'ordine dei MHz per cui è soggetto alle capacità dei cavi, a come vengono messi, ecc. ecc.
Non per nulla, sull'articol che ti avevo indicato, io avevo fatto uno shield da montare direttamente sopra Arduino
Comunque ... sono contento che hai trovato il modo per risolvere
Ok, non disegnato,vero, ma lo avevo messo fin dal giorno zero...
Ho lavorato tantissimo con il digitale e analogico, e sempre a priori tutto è filtrato da un condensatore da 0.1mF a 1 mF , come minimo, sul bus alimentazione vicino ai pin Vcc e Gnd. In questo caso ho ecceduto con 330mF + 100nF visti i fili di collegamento non cortissimi.
Mi sa che nello shield di Elettronica In n.252 magari un filtro capacitivo di bypass serve con SRAM più "suscettibili", anche se i collegamenti sono"corti", perché non è presente.
Grazie Ale per averlo ricordato. Aggiorno immagine per chi leggerà.
Saluti.
Mauro.
