per carità il codice funziona bene e non salta mai un'accensione ma siccome ogni tanto (1-2 volte al mese) la mia scheda wemos si riavvia, vorrei cercare di alleggerire un pò di righe. Voi che approccio avreste per una cosa del genere? Grazie
Cioè tu vuoi alleggerire perchè si riavvia?
Sta facendo troppa fatica?
Scusa ma la premessa è stata alquanto curiosa ;D
Hai provato ad indagare il motivo per cui si riavvia?
Perchè altrimenti avrai un codice scritto diversamente che si riavvia comunque un paio di volte al mese.
Poi se vuoi modificare comunque il codice, si apre un mondo: abbellire e ottimizzare... il primo è soggettivo, il secondo va indicata la dimensione da ottimizzare, tempo, uso di memoria, ...
il motivo dei riavvii è sempre exception, penso a causa di una eccessiva frammentazione della ram. faccio gà uso di variabili locali e macro F per le stringhe litteral
Quindi usi la classe String a piene mani?
Se si, allora inizia a debellare quella, perchè nel codice che hai postato non mi pare di vedere cose che possono spiegare gli sciopamenti.
no uso la macro F in casi come questi u8g2.print F(("hPa")); e nelle risposte testuali che il bot telegram mi invia . Non uso stringhe anche se la libreria telegram che uso ne fa uso per memorizzare il testo del messaggio ricevuto.
Il mio maggiordomo, dopo il suo riavvio, grazie a pestifero nipote che mi ha regalato indietro una esp12, sta andando ininterrottamente da 51 giorni e qualche ora
Il precedente record, prima di un guasto hw, era di oltre 121 giorni
io con questi moduli non supero il mese. ad esempio ho quei cloni D1 MINI PRO che a volte non so come usare, se come moduli generici o come D1 MINI PRO in quanto ho problemi poi con il corretto funzionamento della EEPROM (la scrivi e al primo riavvio si cancella). Ho trovato la quadra selezionando la scheda ESPINO, ma mi resta sempre il dubbio se per caso fosse questa la causa reale dell'instabilità di queste schede....
Anche gli oggetti String contenuti nelle librerie sono un potenziale problema.
Quindi debella, debella, debella.
Vedi se riesci a trovare una libreria "String free" e vedrai che risolverai il problema dei riavvii.
Sempre che non ci siano altre librerie galeotte in giro.
Purtroppo non uso telegram per cui non ho già fatto verifiche dirette io in proposito.
Si ma quale eccezione viene sollevata, perché non è detto che sia legata alla allocazione della memoria.
In pratica so che installando qualcosa puoi ottenere maggiori info in merito alla eccezione e da li indagare sulla causa.
Se installi il tool per analizzare il dump dell'eccezione sollevata, puoi ottenere informazioni utilli a trovare il punto in cui si creano problemi. Già anche solo il tipo do eccezione (watchdog, illegal instruction etc etc) può aiutare in quel senso.
Potrebbe tornarti utile anche monitorare l'andamento nel tempo della memoria libera totale e del blocco "contiguo" massimo disponibile per allocare memoria.
In caso di problemi dovuti alla frammentazione, dovresti vedere quest'ultimo valore che piano piano si riduce fino a diventare inutilizzabile, se rimane costante nel tempo (qualche oscillazione è normale), il problema è altrove.
// an abstract class used as a means to proide a unique pointer type
// but really has no body
class __FlashStringHelper;
#define FPSTR(pstr_pointer) (reinterpret_cast<const __FlashStringHelper *>(pstr_pointer))
#define F(string_literal) (FPSTR(PSTR(string_literal)))
In pratica garantisce solo la compatibilità del codice scritto, ma non fa nulla.
Ciao, Ale.
Grazie per i vs. interventi ragazzi, cerco di darvi qualche dettaglio in più:
dunque uso questa libreria telegram:
che come vi dicevo fa uso di stringhe ma che ha un altro grosso problema, usa una comunicazione sincrona con il server di telegram e ciò appesantisce di molto la fluidità del codice. Sto cercando di passare ad un altra libreria che forse è di uno di voi (a cui faccio i complimenti):
che ha il vantaggio di supportare una comunicazione del tipo asincrona ma ho ancora problemi nel passaggio.
In merito all'eccezione, quando ebbi modo di beccare un riavvio della scheda fintanto che era collegata al pc ricordo di un problema non ben precisato circa la scrittura errata di qualcosa in un settore non consentito. Da qui la mia idea che si tratti di problema di ram. Nel mio codice controllo sempre attraverso telegram la quantità di memoria ram libera (10kb) e della sia frammentazione che ad ogni riavvio è di 2-7% per salire poi intorno al 30% e poi kabum il riavvio. Accolto volentieri l'idea di misurare il max blocco contiguo. Grazie cotestatnt...
Non sono un informatico di estrazione ma ho voluto imparare per divertirmi con arduino &co ma purtroppo qui saltano fuori i miei limiti. Per rispondere a Guglielmo invece posso dire di usare già quel tool ma il progretto è ormai installato a parete e aggiorno via ota per cui per ora non posso ricavare l'eccezione specifica. Comunque non si tratta ne di whatcdog sw che hw, ne di problemi all'alimentazione. Tutti risolti nel tempo.
Inoltre in merito a quel dubbio circa il tipo di scheda da selezionare sull'IDE di arduino cosa potete dirmi?
che ha il vantaggio di supportare una comunicazione del tipo asincrona ma ho ancora problemi nel passaggio.
Si l'utente in questione sono io, grazie 8) Se posso aiutarti nella transizione, lo faccio ben volentieri.
Nella libreria AsyncTelegram, credo che l'unica String che potrebbe causare realmente frammentazione è quella inserita nella struct che tiene memoria del messaggio ricevuto.
Si tratta dell'eredità della libreria che mi ha ispirato (CTBot), ma in fondo non è nemmeno troppo complicato farne a meno (quando ho un po' di tempo libero, magari me ne occupo).
Io comunque ho fatto numerosi test sull'utilizzo della memoria, ed ho 3/4 progetti in giro tra personali ed amici/parenti che la usano ormai da diversi mesi senza disservizi.
A ecco il nome mi era famigliare. Bravo la tua libreria è un razzo e vorrei usarla a tendere in tutti i miei progetti.
Per ora ho difficolta ad integrarla con la libreria wi-fi manager in versione non blocking con wm.process() , funzione OTA e parametri di configurazione aggiuntivi nel captive portal. In pratica fondo tutto e non si avvia la comunicazione. Sbaglio sicuramente io qualcosa ma non capisco cosa.
Poi per la tua libreria sarebbe bello che per esp 8266 funzionassero gli esempi ota del ram dev, che ci fosse una connessione basata su bearssl .
Se hai bisogno di qualcuno per testare le tue versioni su esp8266 conta pure su di me. Puoi anche scrivermi in pvt.
Nel weekend provo a riprendere il lavoro sul branch dev e a sistemare quello che non va con ESP8266 ( si tratta solo di aggiustare qualche #ifdef credo ).
Il codice è stato testato solo con ESP32 (che purtroppo nasconde un insidioso bug sul WiFiClientSecure ed ogni volta che c'è un errore sulla connessione, si tiene un po' di ram per se, il maledetto!)
Riguardo al WiFi Manager, non ha molto senso usarlo in modalità non-bloccante per tre ragioni:
La configurazione è una cosa che esegui molto raramente;
Tieni in RAM inutilmente la classe senza poi andare realmente ad usarla;
La libreria AsyncTelegram, per essere inizializzata, ha bisogno che la connessione sia attiva per comunicare con il server e quindi dovresti gestire manualmente il momento in cui chiami il begin()
Usandola in modo bloccante nel setup() invece oppure usando un pulsante, l'istanza del wifimanager la dichiari localmente (come negli esempi) cosi quando esci dalla funzione viene liberata la memoria relativa.
Se vuoi, intanto potresti installare come editor Visual Code + il plugin platformio.
In questo modo posso inviarti tutto l'archivio contenente, oltre allo sketch e la configurazione del progetto, anche la libreria dev aggiornata senza che vai a dar fastidio a quelle installate con l'IDE Arduino.
Uso la funzione non bloccante di WM perchè nel progetto ci sono cose che devono assolutamente continuare a funzionare anche in caso di mancanza di connessione wi-fi, per esempio devono essere garantite delle accensioni relè schedulate(quelle di cui parlavo ad inizio post) quindi deve funzionare un RTC, deve continuare ad aggiornarsi un oled e devono funzionare dei pulsanti (3 in tutto) nonchè un sensore BME280. Se va via la connessione si bloccherebbe tutto. Pensi possa essere questa la causa dei miei riavvi?
Attendo con ansia il tuo aggiornamento.
No, al massimo si bloccherebbe solo in caso di reset del micro perché viene eseguito nuovamente il setup(), ma non credo sia quella la causa dei riavvii.
Comunque in questo caso, potresti impostare un timeout passato il quale lo sketch riprende a fare quel che deve.
Meglio ancora, potresti vincolare l'esecuzione del wm ad un evento esplicito come la pressione di un pulsante, oppure ad un doppio reset o qualcosa del genere, in modo da eseguirlo solo quando realmente necessario.
droidprova:
Capisco, e se facessi una cosa del genere come la vedi?
Non cambia nulla perché una verifica del genere è fatta già internamente dalla classe.
Comunque, la tua esigenza mi ha dato l'idea per realizzare un esempio un po' più avanzato, ci ragiono su e poi allego il progetto.
In sostanza sarà un timer settimanale con l'utilizzo del wifimanager per la configurazione del Wifi (ed eventualmente un primo setup di qualche timer) con la possibilità di gestire la schedulazione via Telegram e l'aggiornamento del firmware da remoto.
E' più meno quello che stai realizzando, display ed RTC a parte?
P.S. Visto che c'è il wifi, una volta sincronizzato il tempo con un server NTP, il modulo RTC diventa inutile secondo me. Ci pensa l'ESP ad aggiornare l'ora, anche se la connessione dovesse cadere successivamente.
