“Usura” variabili ritentive su SlimLine
Home › Forum › Controllori SlimLine e Netsyst (LogicLab) › “Usura” variabili ritentive su SlimLine
Taggato: SlimLine variabili ritentive memoria
- Questo topic ha 3 risposte, 3 partecipanti ed è stato aggiornato l'ultima volta 1 anno, 2 mesi fa da
Sergio Bertana.
-
AutorePost
-
Febbraio 12, 2024 alle 4:53 pm #75910
Edi Zobec
PartecipanteHo cercato informazioni a riguardo ma non ho trovato risposta. Sugli SlimLine (nello specifico, opero su SlimLine Cortex M7 codice MPS056A120) c’è la possibilità di avere le variabili ritentive nelle posizioni di memoria da 2048 a 4095. Fino a qui tutto chiaro.
Ma c’è da tener conto di un numero massimo di scritture di queste variabili – un po’ come succede con le schede SD – prima che il modulo fisico sul quale questa funzionalità è sviluppata si guasti? Oppure, detto in altre parole, è saggio che il mio programma vada a scrivere un nuovo valore di una variabile ritentiva ad ogni ciclo slow, rischio di trovarmi tra qualche mese o anno il sistema instabile?
Ho voluto allocare io gli indirizzi delle variabili per poter farle leggere al server web e rendere così disponibili i valori correnti del sistema in rete. Però effettivamente non tutte le variabili che ho dichiarato mi servono retain. Il fatto di averle dichiarate tutte nel range 2048 – 4095 mi ha fatto aprire questa riflessione.
Se uno volesse dichiarare manualmente gli indirizzi delle variabili, ma non vorrebbe danneggiare con la continua scrittura il modulo che le ospita, cosa dovrebbe fare? Allocarle nel range 4096 – 6144?
Poi però magari si scopre che per scrivere una variabile viene scritta tutta la memoria e quindi c’è sempre la stessa usura – che si scrivano 1 o 20 variabili il modulo deve cancellarsi e riscriversi.
Oppure magari è già tutto così calcolato che qualsiasi cosa si faccia, la memoria ritentiva ha una vita tanto lunga da non porre problemi…
Febbraio 12, 2024 alle 7:35 pm #75912Enrico Viviani
PartecipanteRispondo per quanto ne so, e per esperienza personale. La memoria ritentiva dovrebbe essere su FeRam che promette un minimo di 10^10 cicli. Essendo simile alla DRam necessita di due cicli anche per la lettura perché quest’ultima è “distruttiva” per i dati contenuti.
Per esperienza personale, variabili ritentive riscritte almeno un migliaio di volte al giorno per, finora, quasi dieci anni non hanno causato problemi.
Febbraio 17, 2024 alle 1:26 pm #76056Edi Zobec
PartecipanteSiccome stavo lavorando su un progetto diverso su tutt’altra architettura (ESP32), dove devo salvare delle variabili in memoria, e siccome lì consigliano di non eccedere le 10 000 scritture, mi è venuto questo dubbio per alcuni progetti che mantengo con lo SlimLine.
Rivedendo il codice che ho scritto al tempo per questo SlimLine, ho dichiarato delle variabili globali nel range di memoria 2048 – 4095 e quindi ho ottenuto la loro persistenza. Su alcune era voluto, ed essendo input utente non ci sono problemi sui cicli. Altre invece sono letture di sensori collegati e cambiano valore ad ogni ciclo slow (10x al secondo). Su queste non mi interessa la persistenza, tanto alla riaccensione possono benissimo essere ricalcolate. 10^10 sembra infinito, ma al ritmo di 10 scritture al secondo sono 32 anni di vita. Accettabile, ma credo non sia il modo corretto di procedere.
Quindi domanda: se voglio continuare ad allocare manualmente le variabili, e non voglio che siano persistenti, devo farlo nel range di memoria 4096 – 6144? Ovviamente sempre rispettando la divisibilità dell’indirizzo, quello mi è chiaro.
E, a questo punto, per curiosità, la memoria da 0 a 2047 a cosa serve? Se alloco qui delle variabili, cosa succede?
Febbraio 19, 2024 alle 8:25 am #76060Sergio Bertana
Amministratore del forumIntanto veniamo alla memoria FRAM, nello SlimLine si utilizza la FM25V02A della Cypress che da datasheet garantisce:
- High-endurance 100 trillion (10^14) read/writes
- 151-year data retention
Ma nella tua applicazione specifica giustamente è inutile allocare in memoria di backup variabili che non hanno la necessità di essere mantenute, quindi puoi allocarle proprio nella DB100 nel range da 0 a 2047. Infatti l’area DB100 è suddivisa in due parti da 2048 bytes, la prima parte da 0-2047 non è tamponata, la seconda parte da 2048-4095 viene tamponata in FRAM.
Le variabili globali si allocano manualmente in DB100 solo se devono essere gestibili da Modbus (Esempio pannello operatore), altrimenti si possono definire Auto delegando a LogicLab la loro allocazione. Anche le variabili Auto possono essere mantenute allo spegnimento, basta dichiararle RETAIN, ed anche in questo caso verranno appoggiate su FRAM.
Le variabili RETAIN a differenza di quelle allocate nella DB100 pur mantenendo il loro valore allo spegnimento del sistema, al caricamento di un nuovo programma vengono inizializzate (Vedi topic).
-
AutorePost
- Devi essere connesso per rispondere a questo topic.