MarlinKimbra & MK4duo

EEPROM

0 votes, average: 0,00 out of 50 votes, average: 0,00 out of 50 votes, average: 0,00 out of 50 votes, average: 0,00 out of 50 votes, average: 0,00 out of 5 (0 votes, average: 0,00 out of 5)
You need to be a registered member to rate this post.
Loading...

Vedo se riesco a fare un po di chiarezza sulla funzione della eeprom.
Capisco che è una situazione a metà, a me piacerebbe che fosse totalmente gestibile via firmware la configurazione della stampante, vedi firmware tipo RRF o altri come quello della GH. Ma per fare questo c’è bisogno di memoria per le variabili, il DUE non ha problemi tutti e 512k sono utilizzabili per il software o per le variabili, purtroppo il mega ha solo 8 Kb di RAM per le variabili. Nel firmware stesso ci sono variabili cioè locazioni dove sono contenuti dati che variano nel tempo, per esempio la temperatura attuale di un riscaldatore o quella impostata come target dall’utente, la posizione degli assi (compreso E), la destinazione, e tante altre.
L’approccio dei firmware nati con il mega o inferiori è stato quello di definire costanti inizialmente alla compilazione del firmware per non occupare, la già poca, memoria del processore. Quindi valori come Z_MAX_POS o il pin del sensore o ancora i pin di una fan o le direzioni dei motori o le home sono costanti e definiti all’inizio nella configurazione. Le costanti non occupano spazio in RAM perché appunto costanti quindi occupano spazio come il software, questo lascia liberi quei pochi Kb di RAM per variabili di lavoro. Questo è perfetto per un funzionamento con il mega, ma costringe l’utente a dover compilare e scaricare il firmware per cambiare queste costanti. Per carità è nulla da dire su questa scelta, anzi la trovo perfetta per quello che serviva…
Alcune variabili però sono rimaste come gli step per mm, le velocità e le accelerazioni, variabili, che con gcode o con il display, è possibile modificare senza scaricare il firmware ricompilato. Ora questi valori però se modificati essendo in ram allo spegnimento della stampante tornano a essere quelli che erano inizialmente cioè quelli dettati dalle configurazioni, per esempio se si varia la velocità da 100 a 110 per un asse, durante tutto il funzionamento della stampante quel valore sarà 110, ma alla nuova accensione tornerà a essere 100 costringendo l’utente a inserire gocde negli start gocde per rimettere a 110 quel valore. Ecco che ci arriva in aiuto la EEPROM, cioè una memoria scrivibile dal software stesso permanente finche non sovra scritta.Quindi se io modifico il valore della velocità con il display o con il gcode e lo porto a 110 e poi lo memorizzo in EEPROM (se attiva), alla nuova accensione verrà letta la EEPROM e invece di mettere a 100 (come settato nella configurazione) la velocità il firmware la mette a 110. Ora se modifico il firmware mettendo come velocità 90 e lo scarico di nuovo nella scheda, quello che accade è la stessa cosa dell’accensione il firmware trova il valore 110 in EEPROM e quindi la velocità sarà 110 e non 90 come messo nella configurazione… In questo caso bisognerà portare il valore a 90 o con il gcode o con il display e poi memorizzarlo in eeprom per sovrascrivere solo questo e non perdere gli altri eventualmente salvati, l’alternativa è resettare la EEPROM con M502 portando tutti i valori di default (cioè quelli scritti nei file di configurazione) per poi di nuovo scriverli in eeprom con M500.
Detto ciò arriviamo al dunque, oltre ai consueti valori ho piano piano portato a variabili e non più costanti altri valori che normalmente erano solo definiti, appunto come i riscaldatori, le fan e altre cosuccie. Facciamo un esempio pratico: Configuro il firmware in modo che la fan 0 è sul pin 10, salvo in EEPROM, dopo di che vado nella configurazione e modifico il pin della fan 0 in 11, scarico il firmware senza fare altro il pin 11 non sarà mai usato perché in memoria EEPROM ho ancora il pin 10 e di conseguenza il firmware continuerà a usare il pin 10 per la fan 0.
Cosa bisognerà fare in questo caso?
Semplicemente due cose: O si cambia con il relativo comando il pin della fan0 e poi si salva in EEPROM oppure si resetta la EEPROM per riportare TUTTI i valori come scritti nella configurazione.
Ed è qui che viene la domanda, perché modificarli da configurazione invece di modificarli direttamente dal firmware con il gcode in modo più rapido senza dover compilare e scaricare ogni volta?
Altrimenti la eeprom non ha senso averla attiva, si cambia tutto da configurazione e basta cosi è tutto più facile.
Però volete mettere che io posso con un comando gcode far diventare il bed con i pid o bangbang senza dover riscaricare tutto??
Oppure modificare i pid al volo per abs o pla o tpu, o ancora cambiare tipo di sensore che monto se cambio al volo un hotend con un altro?
Per me queste sono un plus, ma forse non sono riuscito a farmi e farle capire queste cose. Questo però vuol dire che quando si configura e si modificano certi parametri bisogna fare un po di attenzione se sono valori salvati in eeprom oppure no. Come ho detto all’inizio sarebbe bello che tutti lo fossero, ma per rimanere ancora compatibile con le 8 bit, tutti è impossibile…
Spero che un po si sia capito come discorso. Intanto con RRF si modifica tutto via web browser e noi si compila ancora togliendo le // o mettendole per attivare o disattivare le funzioni…