Salve ragazzi mi sta accadendo una cosa che non avevo mai visto utilizzando la mia mega2560.
Sto utilizzando il laser lidar per effettuare delle misurazioni e tutto sta filando liscio tranne per il fatto che dopo 2 o 3 volte che faccio parire il mio codice, il programma inizia ad andare lentissimo come se il processore della mega fosse drammaticamente occupato.
A questo punto se rivoglio vedere il mio codice girare veloce come nella norma, devo compilare uno sketch vuoto e staccare il cavo usb.
Dopo qualche secondo riattacco il cavo, ricompilo il mio codice e di nuovo lo stesso: 2 o 3 esecuzioni del mio codice dopodiche' il programma torna lentissimo..
A questo punto mi chiedo, potrebbe essere un problema della memoria della mega?
Ogni volta che si esegue il codice dall'IDE di Arduino, non vengono cancellate tutte le informazioni e dati manipolati nella passata esecuzione?
Perchè staccando il cavo usb (e eseguendo uno sketch vuoto) torna tutto ok?
aldoz:
No sono appena al 18% di memoria dinamica utilizzata e comunque il rallentamento avviene solo dopo che ho avviato il programma gia' 2 o 3 volte.
Lo dici perché te lo dice il compilatore o perché hai inserito le apposite chiamate per verificare a runtime quale è VERAMENTE l'occupazione della memoria ?
Cosa significa "... dopo che ho avviato 2 o 3 volte il programma" ? ... Che lo carichi, parte, spegni il tutto (stacchi l'alimentazione), alimenti di nuovo e il programma riparte, spegni di nuovo e ... a questo punto se riaccendi parte rallentato ?
B) utilizzo processing2 per seguire l'andamento del mio programma (potrei anche direttamente utilizzare il monitor seriale di Arduino)
C) Una volta terminata la "sessione" chiudo processing e mi fumo una bella sigaretta
D) Rifaccio partire processing o il monitor seriale per controllare altre cose del mio programma
E) chiudo nuovamente processing..
F) ora vorrei ricontrollare altre cose del programma quindi faccio ripartire processing (che appunto riavvia il mio programma) e a questo punto l'andamento del programma è lentissimo...
Per far si di riavere il programma alla velocita' normale, devo compilare uno sketch vuoto, staccare il cavo usb, ricollegarlo, avviare nuovamente il mio codice ed ecco che il programma e' nuovamente veloce come in origine....
Non basta ricaricare il codice dall'ide.. rimane l'esecuzione lentissima.. devo proprio staccare il cavo usb.
@gbp01 No non sto controllando in diretta l'evolversi della memoria..
che chiamate posso fare per ottenere un valore di memoria da verificare in diretta con l'andamento del programma?
aldoz: @gbp01 No non sto controllando in diretta l'evolversi della memoria..
che chiamate posso fare per ottenere un valore di memoria da verificare in diretta con l'andamento del programma?
@vbextreme
Eh il codice è lunghissimo tra gestione del movimento del robot, del giroscopio, dei sensori tattili, del laser............ non oserei mai farvi tuffare in tale caos
Comunque lo sketch del laser che sto utilizzando è questo (che poi ho intersecato pezzo per pezzo dentro il codice del mio robot):
#include <I2C.h> #define LIDARLite_ADDRESS 0x62 // Default I2C Address of LIDAR-Lite. #define RegisterMeasure 0x00 // Register to write to initiate ranging. #define MeasureValue 0x04 // Value to initiate ranging. #define RegisterHighLowB 0x8f // Register to get both High and Low bytes in 1 call.
void setup(){
Serial.begin(115200); //Opens serial connection at 9600bps.
I2c.begin(); // Opens & joins the irc bus as master
delay(100); // Waits to make sure everything is powered up before sending or receiving data
I2c.timeOut(50); // Sets a timeout to ensure no locking up of sketch if I2C communication fails
}
void loop()
{
// Write 0x04 to register 0x00
uint8_t nackack = 100; // Setup variable to hold ACK/NACK resopnses
while (nackack != 0)
{ // While NACK keep going (i.e. continue polling until sucess message (ACK) is received )
nackack = I2c.write(LIDARLite_ADDRESS,RegisterMeasure, MeasureValue); // Write 0x04 to 0x00
delay(1); // Wait 1 ms to prevent overpolling
}
byte distanceArray[2]; // array to store distance bytes from read function
// Read 2byte distance from register 0x8f
nackack = 100; // Setup variable to hold ACK/NACK resopnses
while (nackack != 0)
{ // While NACK keep going (i.e. continue polling until sucess message (ACK) is received )
nackack = I2c.read(LIDARLite_ADDRESS,RegisterHighLowB, 2, distanceArray); // Read 2 Bytes from LIDAR-Lite Address and store in array
delay(1); // Wait 1 ms to prevent overpolling
}
int distance = (distanceArray[0] << 8) + distanceArray[1]; // Shift high byte [0] 8 to the left and add low byte [1] to create 16-bit int
// Print Distance
Serial.println(distance);
}
@gpb01:
Grazie gpb01, massimo domani e vi diro' se sto esaurendo la memoria. Quasi lo spero.. sarebbe almeno un punto di partenza; ora sono proprio disorientato..
utilizzando la funzione freememory() ottengo, sia quando il programma è veloce, sia quando è lento, il valore di 6635 (che non varia durante lo svolgimento del programma).
Non credo sia un problema di ram quindi..
Tant'e' che da quando sto utilizzando il lidar (con il suo codice), sto nuovamente vivendo i problemi che avevo con il giroscopio tempo fa.
Il giroscopio restituisce nuovamente errori di calcolo improvvisi.
Avevo risolto questo problemaccio degli errori del giroscopio modificando la libreria "MPU6050_6Axis_MotionApps20.h" esattamente in questa linea: 0x02, 0x16, 0x02, 0x00, 0x01 // D_0_22 inv_set_fifo_rate
L'ultimo 0x01 lo modificai in 0x04 e ottenni una frequenza di "chiacchierata tra mega e giroscopio" più consona, tant'e' che da quel momento non ottenni più errori da parte del giroscopio.
Ora, utilizzando il laser, tali errori sono ricomparsi (insieme a questo rallentamento generale del programma... )....
speedyant:
Fai una prova senza ricaricare lo sketch, togliendo solo l'alimentazione o pigiando il tasto reset.
Si ecco! Il programma torna alla velocita' originale anche solo staccando il cavo usb (che in questo caso è anche l'alimentazione) e riattaccandolo.
Non c'e' bisogno ne di caricare uno sketch vuoto ne di ricaricare il codice.
Diciamo che è una cattiva, ma pur sempre una notizia. Lo stesso effetto dovresti averlo pigiando il bottone di reset sulla scheda.
Andrebbe verificato se ad un certo punto la lentezza non si trasformi in "morte", perché a quel punto sarebbe quasi certo un problema con lo sketch...
Allora ragazzi.. sembra che sia proprio una roba brutta ma devo dirvi che se ricarico la versione del mio codice precedente l'innesto del codice di gestione del lidar, tutto torna perfetto e posso avviare quante volte voglio il mio programma (e far durare la sessione quanto desidero) senza il minimo rallentamento e con il giroscopio che rifunziona perfettamente senza il minimo errore.
Appena riapro la versione che include il codice di gestione del laser allora si ritorna a questi casini.
Ma se avessi fatto danni hardware anche il mio vecchio codice dovrebbe funzionare male no?
ho allegato lo sketch perchè il codice è troppo lungo per essere postato qui.
Hai dei buffer overflow, quindi vai a scrivere in aree della memoria che non dovresti causando ogni sorta di problema.
Cerca di usare una corretta indentazione del codice! è importante!
aldoz:
Ma se avessi fatto danni hardware anche il mio vecchio codice dovrebbe funzionare male no?
Guarda che sopra stavo scherzando, non esiste il motivatore dell'oscillatore
Impossibile che hai fatto danni hardware, molto probabilmente è un problema legato alla I2C e alle attese che può imporre.