[Risolto] Due Arduini non funzionano bene dopo aver provato Frequencytimer2!!

Buonasera Ragazzi!

Poco fa stavo lavorando ad un mio progetto che implicava la generazione di tre segnali digitali 0-1 su tre pin che mi funzionava benissimo, poi ho pensato di vedere se esisteva altro metodo per farlo e mi sono imbattuto nella libreria ->Frequencytimer2 che ho scaricato e installato nella directory delle librerie, creato uno scketch nuovo di zecca usando l'esempio del repository del playground...

Ho avuto questi problemi:

1.lo sketch non compilava, va bene, fa niente, era solo un test, ho pensato.

2.Sono ritornato a programmare il "mio" sketch che funzionava bene e mi sono accorto che i dati sulla seriale erano corrotti e il timing era lentissimo.

3.Ho pensato forse avessi Io pasticciato con quale dei due Arduino stavo programmando (ho una UNO R3 ed una UNO*PRO con sopra un Atmega1284P), quindi scollego uno dei due e ricontrollo se stavo programmando la scheda con il processore giusto. Ripeto la programmazione, niente, stesso risultato.

4.provo a programmare un volgare blink e mi da errore di compilazione, mi dice "LED_BUILTIN was not declared in this scope" (il pin interno 13) non e dichiarato?? quindi ho pensato si è fregato qualcosa nell'IDE... o peggio, nei due Arduini?

5.Disinstallo l'IDE, scarico nuovamente l'installer e ripeto l'installazione. Niente... Continua a non funzionare...

6.Dopo diversi tentativi, la UNO riprende le sue funzioni, mentre l'altra, la UNO*PRO con il 1284P continua a fare i capricci, se metto uno sketch di esempio tipo ->ReadAnalogVoltage funziona benissimo, mentre sia BLINK che BlinkWithoutDelay mi da sempre lo stesso errore.

Qualcuno sa dirmi che HO COMBINATO? Non so più dove Sbattere!!

Grazie

(PS. La libreria e sketch di esempio sono stati cestinati immediatamente, ma e servito a niente)

Update:

Adesso senbrano di funzionare entrambi, ma continuano a rifiutare lo sketch BLINK, mentre se sostituisco il "LED_BUILTIN" per "13" funziona.

Come seconda cosa, ho costatato che il mio sketch a cui stavo lavorando (erano aperte diverse pagine IDE con diversi sketch) anch'esso si comportava in modo anomalo. Quindi ho incominciato ad isolare pezzo per pezzo tutto il codice fino a trovare cosa rendeva "pazzo" i due Arduini... la funzione ->pulseIn() ma tutto questo, solo da quando ho provato quella libreria (FrequencyTimer2).

Io sospetto che abbia pasticciato con i fuse? e se si, con lo scaricamento degli sketch non vengono settati? io non ricordo nulla sui fuse, Aiutooo!!

hiperformance71:
Io sospetto che abbia pasticciato con i fuse?

  1. Difficile, dato che per modificarli occorre usare un programmatore ISP ... ::slight_smile:
  2. Quella libreria fa operazioni solo sui registri dei Timers ...
  3. Hai qualche cosa di corrotto sul disco. Purtroppo NON basta cancellare la cartella Arduino e reinstallare; l'IDE crea files sparsi un po' qua e un po' la ... per questo io consiglio sempre le installazioni di tipo "sandboxed" racchiuse su loro stesse ...

Guglielmo

Grazie Guglielmo,

temevo fosse quello che mi hai detto, documentandomi sui Fuse anche io ho costatato che dall'IDE non si possono modificare, solo da ISP, e quello, per ora non l'ho usato da un po (e ho dovuto anche disinstallare AVR Studio 7 perche non mi funzionava bene, poi vedrò di re-installarlo meglio).

Del fatto che l'IDE lasci file un po di qua e di la me ne sono accorto qualche annetto fa, mi si era corrotto qualcosa del compilatore perche non riuscivo a compilare nulla, mentre funzionava tutto bene se mi loggavo come Guest in windows(!) ho dovuto arrangiarmi così per un bel po (con la conseguente demotivazione per dedicarmi alla programmazione) e la re-installazione non servi a nulla. Per fortuna, arrivo qualche aggiornamento dell'IDE e si risolse da solo!

Come sarebbe far funzionare l'IDE sandboxed? io conosco solo il mio antivirus (Comodo) che lo fa per programmi sospetti non riconosciuti.

Forse ti riferisci all'IDE standalone? mi sembra di averlo letto anni fa, non ricordo bene adesso.

Scarica l'IDE in formato Zip
Scompattalo in una cartella.
Dentro la cartella crei una cartella chiamata portable.
Lanci l'IDE dalla cartella cliccando sull'eseguibile.

Ti ritrovi con un IDE vergine, senza le librerie scaricate, usa il library manager o mettile a mano nella cartella portable\sketchbook\libraries

hiperformance71:
... Come sarebbe far funzionare l'IDE sandboxed? ...

Come ti ha sipegato zoomx, devi scaricare la versione .zip dell'IDE, la scompatti in una cartella dove tu puoi sia leggere che scrivere, poi vai dentro la cartella Arduino che hai scompattato e crei tu una cartella di nome "portable".

A quell'punto quando lanci l'IDE lo troverai vuoto, senza "core" aggiuntivi e senza "librerie" aggiuntive poichè lui NON uscirà mai dalla cartella Arduino che hai installato se non per leggere i tuoi .ino che, ovviamente, possono stare ovunque.

Come al solito, nelle preferenze dovrai aggiungere i .json per eventuali "core" aggiuntivi e poi, da "Board Manager " e da "Library Manager", dovrai aggiungere tutti i "core" e le "librerie" che effettivamente usi. Vedrai che quello che aggiungi NON viene messo in giro per il disco, ma tutto in sotto cartelle della "portable" che hai creato. :slight_smile:

Questo è molto comodo per avere, ad esempio, più versioni differenti dell'IDE, configurate in modo differente, ciascuna con le sue cose e indipendente dalle altre installazioni.

Guglielmo

zoomx:
Scarica l'IDE in formato Zip
Scompattalo in una cartella.
Dentro la cartella crei una cartella chiamata portable.
Lanci l'IDE dalla cartella cliccando sull'eseguibile.

Ti ritrovi con un IDE vergine, senza le librerie scaricate, usa il library manager o mettile a mano nella cartella portable\sketchbook\libraries

Grazie!

Mi hai confermato il mio intuito, sto facendo proprio cosi (tranne il fatto di creare la cartella portable che provvedero a creare adesso e riprovare a vedere se va).

zoomx:
Scarica l'IDE in formato Zip
Scompattalo in una cartella.
Dentro la cartella crei una cartella chiamata portable.
Lanci l'IDE dalla cartella cliccando sull'eseguibile.

Ti ritrovi con un IDE vergine, senza le librerie scaricate, usa il library manager o mettile a mano nella cartella portable\sketchbook\libraries

Grazie dell'informazione, me ne serviro tra poco, ci stavo appena provando (ma senza sapere della cartella portable).

La cartella portable credo vada creata prima di lanciare per la prima volta l'IDE, così lui crea in portable alcuni file fra cui quello delle preferenze.
Non so se fa lo stesso una volta lanciato l'IDE ma senza la cartella portable.

Mi intrometto per chiedere se la procedura suggerita può essere seguita anche per la distribuzione Ubuntu 18.03 LTS, una Linux a 64bit.

Il file da scaricare è "arduino-1.8.9-linux64.tar.xz". Posto in una cartella (nel mio caso: ArduinoPortable) e estratti i file ha dato origine a una cartella "arduino-1.8.9-linux64", contenente la cartella "arduino-1.8.9" a sua volta contenente le cartelle: examples, hardware, java, lib, libraries, reference, tools, tools-builder e i file: arduino, aruino-builder, arduino-linux-setup.sh, install.sh, revisions.txt, uninstall.sh.

Una roba così:
ArduinoPortable
|-arduino-1.8.9-linux64.tar.xz
|-arduino-1.8.9-linux64
|-arduino-1.8.9
|-cartelle: "examples, hardware, java, lib, libraries, reference, tools, tools-builder"
|-file: "arduino, aruino-builder, arduino-linux-setup.sh, install.sh, revisions.txt, uninstall.sh."

Vorrei capire in che cartella aprire la nuova cartella "portable" prima di lanciare l'IDE

Grazie,

Ciao,
P.

Va nella cartella arduino-1.8.9 che potresti anche spostare, la cartella arduino-1.8.9-linux64 non serve, infatti contiene solo la cartella arduino-1.8.9

Ragazzi ci sto provando, ma niente, questo problema persiste! (ho anche disinstallato l'IDE ovviamente) Stavolta, nemmeno usando l'account GUEST di windows sembra fare differenza...

Adesso riesco a vedere che al lanciare l'IDE mi carica uno sketch vuoto, mentre prima no, mi prendeva l'ultimo su cui avevo lavorato... Ma continua a non funzionare non appena tolgo i commenti a ->pulseIN(), e come se chiamando questa funzione, i tempi del micro siano sballati, il Serial.print() mi si aggiorna almeno ogni 2 secondi, mentre nello sketch dovrebbe essere a max. velocità (come avviene quando commento pulseIn() ) e questo mi fa pensare che in qualche modo, ho corrotto due arduini con due processori diversi (la Uno con il 328P e la Uno*Pro con il 1284P)?

Magari si potesse aver corrotto il bootloader ai due?

Per il primo (la UNO con 328P) non vedo difficile l'idea di riprogrammare il bootloader e provare, ma ho paura per quella con sopra il 1284P che anche se ho trovato il file hex (optiboot_atmega1284p_hex) sono restio a tentare, non voglio "perdere" questa MCU incasinandola ulteriormente.

Update:
Ho appena constatato con AVR Studio 7 e Dragon che i fuse High e Extended erano cambiati sulla scheda con il 1284P e adesso che ricordo, questo mi era accaduto qualche annetto fa quando la presi.

Definitivamente, credo sia successo qualcosa qui, ecco copia dei dati che ho letto dal 1284P prima di provare i due bit non corrispondenti a quello che il fabbricante della scheda ha specificato:

BODLEVEL = 2V7
OCDEN = [ ]
JTAGEN = [ ]
SPIEN = [X]
WDTON = [ ]
EESAVE = [X]
BOOTSZ = 512W_FE00
BOOTRST = [X]
CKDIV8 = [ ]
CKOUT = [ ]
SUT_CKSEL = FSOSC_16KCK_65MS_XOSC_SLOWPWR

EXTENDED = 0xFD (valid)
HIGH = 0xD6 (valid)
LOW = 0xF7 (valid)

mentre questo e quello che il Fabbricante ha specificato:

##############################################################

uno_pro.name=Arduino Uno*Pro

uno_pro.upload.tool=avrdude
uno_pro.upload.protocol=arduino
uno_pro.upload.maximum_size=130048
uno_pro.upload.maximum_data_size=16384
uno_pro.upload.speed=115200

uno_pro.bootloader.tool=avrdude
uno_pro.bootloader.low_fuses=0xFF
uno_pro.bootloader.high_fuses=0xDE
uno_pro.bootloader.extended_fuses=0xFD
uno_pro.bootloader.unlock_bits=0x3F
uno_pro.bootloader.lock_bits=0x0F
uno_pro.bootloader.file=optiboot/optiboot_atmega1284p.hex

uno_pro.build.mcu=atmega1284p
uno_pro.build.f_cpu=16000000L
uno_pro.build.board=AVR_UNO_PRO
uno_pro.build.core=arduino
uno_pro.build.variant=uno_pro

##############################################################

Sono un completo novello qui, ma mi pare di capire che sta settato con un cristallo esterno da 8 MHz invece dei soliti 16MHz??

pgiagno:
Mi intrometto per chiedere se la procedura suggerita può essere seguita anche per la distribuzione Ubuntu 18.03 LTS, una Linux a 64bit.

Sicuramnete SI dato che io, in realtà, sono su macOS (che, come noto ... sotto, sotto è un sistema UNIX :wink:).

Guglielmo

>hiperformance71: ... NON puoi aver rovinato nulla, quindi ... toglitelo dalla testa !

Si tratta sicuramente di un errore di programma e, il rallentamento che vedi è, probabilmente, perché la "pulseIn()" se non riesce a misuare l'impulso, BLOCCA il codice fino al timeout!

timeout (optional): the number of microseconds to wait for the pulse to start; default is one second. Allowed data types: unsigned long.

Guglielmo

Guglielmo:

Grazie per rincuorarmi che non ho fatto nulla, ma il fatto e che di sicuro non è lo sketch, ho riportato il problema su uno sketch vuoto isolando tutto:

int Sensor2_pin=9;
unsigned long Sensor2_duration_H;
unsigned long Sensor2_duration_L;

void setup() {
  // put your setup code here, to run once:
  Serial.begin(9600);
  
}

void loop() {
  // put your main code here, to run repeatedly:
  //Sensor2_duration_H = pulseIn(Sensor2_pin, HIGH);
  //Sensor2_duration_L = pulseIn(Sensor2_pin, LOW);

  Serial.print("Prova");
}

Se compilo e programmo il 1284P ottengo che "prova" viene stampata sul terminal alla massima velocita consentita dal baudrate, mentre se tolgo i commenti alle due linee di pulseIn() la stampa di "prova" avviene almeno ogni 2 secondi. Qui ti do ragione, anche a me sembrava un overflow ma il problema e perche si ripercuote anche su Serial.print()?

Prima di questo problema, tutto funzionava benissimo!

Mi sai dire qualcosa su quello che ho postato, sui Fuse bits che ho letto con Dragon e quello che il fabbricante della sckeda dice?

hiperformance71:
Se compilo e programmo il 1284P ottengo che "prova" viene stampata sul terminal alla massima velocita consentita dal baudrate, mentre se tolgo i commenti alle due linee di pulseIn() la stampa di "prova" avviene almeno ogni 2 secondi.

.. e io che ti ho detto? La pulseIn() è bloccante (ferma il programma) ed ha un timeout di 1 secondo che, per due pulseIn() da 2 secondi !!!

Guglielmo

Scusami Guglielmo! Io Apprezzo molto il Tuo Aiuto, e che avvolte, per farmi entrare un concetto nella Capoccia ci vuole un po :confused: (si inceppa facilmente quando si presentano problemi inattesi :slight_smile: )

Update:

Ho aggiunto dei timeot all'interno delle funzioni pulseIn() e sembra funzionare meglio, Non come Ieri sera prima del "collasso" dove non ho capito più nulla (ahh.. la capoccia!) ma definitivamente meglio.

Grazie.

hiperformance71:
Ho aggiunto dei timeot all'interno delle funzioni pulseIn() e sembra funzionare meglio

Ma tu stai dando dei segnali ai pin che leggi con la pulseIn() ? ? ?

Altrimenti il programma si fermerà sempre e comunque per tutto il tempo del timeout ... perché quella funzione, se non riesce a misurare nulla, si ferma li e aspetta, come fa la delay(), con un tempo pari al timeout.

Guglielmo

Hai ragione, forse ho fatto confusione, stavo programmando le due schede quasi allo stesso tempo, ma con sketch diversi per due processori su due seriali diverse,

scheda 1: Arduino UNO com 3 ->genera 3 segnali usando timer2/OCRx ecc e funzionava a meraviglia (unico timer che faceva partire 3 pin contemporaneamente)

scheda 2: Arduino UNO*PRO con Atmega1284P che misura i segnali in entrata, sia HIGH che LOW, somma le due letture, fa dei calcoli del periodo e altro e poi invia queste letture alla seriale per essere ricevuti dal display Nextion (simulatore).

Fino allo "scatafascio" pasticcioso, tutto funzionava a meraviglia, ma mi e venuta l'idea di provare anche la libreria FrequencyTimer2 su uno sketch vuoto ed esempio dal playground.

Forse ho messo il programma che legge dentro l'arduino che doveva generare il segnale e quindi, di conseguenza, una volta rimesso il giusto file dentro quello che "legge", non riceveva più i 3 segnali e senza timeout impostato manualmente, lo faceva come dici tu per raggiunto overflow.

Beh... Almeno adesso posso trarre alcune esperienze "positive" da questa storia:

1-Ho imparato che e meglio usare l'IDE sandboxato.
2-Ho imparato che meglio mettere due IDE separati sandboxati uno per la UNO e l'altro per la 1284P che per non sbagliare, cartella e nome eseguibile sono specifici per 1284P e anche il thema e completamente diverso!!, cosi non faccio pasticci nel passare tra due processori/porte COM diversi (almeno, spero!).
3-Ho imparato che la funzione pulseIn() meglio metterci il timeout.
4-Ho rispolverato Dragon dopo anni di Oblivio.
5-Ho fatto pratica con la lettura/programmazione del atmega1284 e 328 da AVR Studio e Dragon in ISP
6-Programmato i bootloader sia del 1284 che del 328 (si, ad un certo punto, li ho incasinati non so come!, dopo riprogrammati funzionano ok)
7-Forse e meglio non fare le ore "piccole" con questi progetti più articolati :grinning: :o

Grazie di Tutto.

Per zoomx e Guglielmo: grazie delle precisazioni.

Ciao,
P.