Vai al contenuto

“Usura” variabili ritentive su SlimLine

Home Forum Controllori SlimLine e Netsyst (LogicLab) “Usura” variabili ritentive su SlimLine

Stai visualizzando 4 post - dal 1 a 4 (di 4 totali)
  • Autore
    Post
  • #75910
    Edi Zobec
    Partecipante

    Ho 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…

    #75912
    Enrico Viviani
    Partecipante

    Rispondo 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.

    #76056
    Edi Zobec
    Partecipante

    Siccome 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?

    #76060
    Sergio Bertana
    Amministratore del forum

    Intanto 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).

Stai visualizzando 4 post - dal 1 a 4 (di 4 totali)
  • Devi essere connesso per rispondere a questo topic.