Topic permanente di programmazione newbie

International Italiano Generale
#490

Mi interessa approfondire due aspetti che non ho mai affrontato: DebugWire: da quanto capisco si attiva sul pin RESET del micro e sul datasheet ci sono una serie di indicazioni su come deve essere usato (pull-up, condensatore, collegamento a Vcc), ma a cosa serve esattamente?

WatchDog: questo è un termine che ho letto diverse volte nelle discussini del Forum, se non erro a proposito dei micro che si bloccavano sulla comunicazione seriale col PC, a motivo di un errore di programmazione, ma in sostanza cosa fa e di che si occupa questa funzione?

#491

DebugWire: non sono sicuro ma dovrebbe essere un sistema per il quale puoi conoscere lo stato di registri e variabili ad ogni istante nel micro. in oltre credo tu possa simulare il clock, facendo quindi un debug passo-passo delle istruzioni asm.

WatchDog: è una specie di timer, quando raggiunge un certo valore resetta il mirco. Ovviamente tu puoi resettare quando vuoi questo timer senza far resettare il tutto.
E’ utile, per esempio se la Wire ogni tanto si impalla, allora metti un watchdog per esempio a 2secondi, e ogni loop lo resetti. Nel momento in cui il micro rimane bloccato, dopo 2 secondi dall’ultimo reset il watchdog resetta il micro.

può essere pericoloso se per esempio setti tempi di reset inferiore a meno di 2 o 3 secondi: infatti il bootloader (almeno in alcune sue versioni) non spegne il watchdog, edato che il boot impiega più tempo e non resetta nemmeno il timer, il micro finisce per andare in reset infinito.
E’ risolvibile riprogrammando il micro da ISP

#492

Grazie, spero di avere degli ulteriori approfondimenti, dovrei scriverci qualcosa se possibile, e devo comprendere le problematiche più a fondo.

#493

@Mike: confermo quanto detto da lesto.

Il debugWire è una particolare modalità di debug per la quale serve però un programmatore a tutti gli effetti. Eseguendo il codice con tale modalità attiva, il programmatore può leggere i registri interni del micro man mano che avanza l'esecuzione del codice accedendo ad essi tramite 1 solo pin.

Il watchdog, in italiano "cane da guardia", è un sistema per evitare blocchi del codice. Il watchdog va attivato dandogli un tempo di allarme. Se il timer supera quel valore, il micro viene resettato a forza. Bisogna stare attenti col watchdog, si rischia il briccaggio del chip dato che se si imposta un timer inferiore al tempo che occorre al codice per resettare il timer, il micro viene resettato a forza entrando in un circolo vizioso.

#494

non sono daccordo con la definizione del cane. non e' che il watchdog evita "blocchi di codice", il codice se si blocca si blocca, non puoi far altro che trovare il bug e risolverlo, il watchdog assodato che il codice e' bloccato fa un reset.

metti un arduino in una montagna, spero che non si blocchi, ma se proprio si blocca invece di salire in montagna a resettare il cane da guardia lo fa per me

#495

Per "blocchi del codice" intendo "blocchi del dispositivo causati da codice scritto senza che il programmatore ne abbia tenuto conto".

Cioè, il watchdog serve per evitare che l'esecuzione del codice si blocchi in loop non previsti. Ad esempio, se mi metto in ascolto di un segnale in arrivo sulla seriale e questo segnale non arriva perché un bimbominchia mi ha tagliato i fili? Se non ho previsto un timeout, il mio codice "muore" lì: resta vita natural durante in ascolto di un byte che non arriverà mai.

Testato: metti un arduino in una montagna, spero che non si blocchi, ma se proprio si blocca invece di salire in montagna a resettare il cane da guardia lo fa per me

Attenzione a questa cosa. Non prendiamo il watchdog come un taumaturgo. Se il codice è buggato, come ho detto sopra, è e resta buggato e la condizione di blocco si ripresenterà nuovamente se le condizioni scatenanti si ripresentano anch'esse.

#496

vero, però prendi il caso eth shield: alcune persone lamentano il blocco della shield e quindi delle comunicazioni. una soluzione sarebbe quella di usare chiamate non bloccanti, ma complica un sacco il codice, un'altra è di mettere il watchdog.

Diciamo che è più "una pezza" che una soluzione :grin:

#497

leo72: Per "blocchi del codice" intendo "blocchi del dispositivo causati da codice scritto senza che il programmatore ne abbia tenuto conto".

Il vero scopo del watchdog è far ripartire il programma in caso di eventi disastrosi che mandano in crash il codice o il micro, in particolar modo disturbi sulla alimentazione o di natura elettromagnetica che possono far impazzire letteralmente il codice, non ha nulla a che vedere con i bug di programmazione per i quali è assolutamente inutile, anzi può essere più dannoso che utile, il watchdog si attiva solo quando il codice è stabile e debuggato. Va da se che non basta attivare il watchdog e resettarlo ad ogni ciclo del main loop, o all'interno di eventuali funzioni a lunga durata, è indispensabile che il codice stesso sia strutturato per l'utilizzo del watchdog.

#498

Ecco, comincio ad avere le idee più chiare su questi due argomenti; però l'ultima frase di Astro mi fa sorgere un dubbio, quindi faccio un esempio pratico: i miei 7 nanetti ormai stanno lavorando da mesi ininterrottamente, avendo messo i tx w/less(con led) all'interno degli infissi l'attività del LED mi conferma la cosa; ma se un giorno un nanetto di dovesse bloccare, sarei costretto ad aprire il cassonetto per resettarlo manualmente. Allo stato attuale posso ben dire che il software è perfettamente funzionante, quindi mi basterebbe aggiungere un paio di righe di comando (quali???) per mettermi al riparo da questa evenienza?

Introduco un altro argomento, o meglio lo riprendo, quello dei Lock bits: ora è chiaro che i boot lock bits ed i lock bits sono 6 bits dello stesso byte; nelle prove non mi è mai balenata l'idea che potesse essere così e non ho provato valori diversi da FF, FE, FC (i tre che agiscono sui lb); ma nelle note di programmazione del reference non vedo traccia della programmazione dei BLB, in quanto parla sempre e solo di lb. Non ho l'HV se non mi rispondevo da solo :grin: Secondo Voi per programmare anche i BLB mi basterebbe semplicemente inserire un valore, tra quelli permessi, contemplando anche lo status 0/1 che voglio dare ai blb? P.es. con CF potrei programmare i due blb più alti lasciando il resto a 1?

#499

Riprendo l'appunto di astro e rispondo parzialmente anche a Mike. In giro per la rete oggi ho letto di tutto sul watchdog, anche che un reset è "salutare". Cioè anche se il software gira bene, ogni tanto dargli un reset può starci, come uno scappellotto ad un figlio birbone, giusto per ricordargli le vecchie "buone maniere". Insomma, il watchdog non solo per salvare il micro da eventi hw disastrosi (i tanto pericolosi sbalzi di tensione) ma anche per rimettere le cose a posto. Un esempio sono i calcoli che consumano molta memoria: per esperienza diretta, posso affermare che nel momento in cui la ram va in esaurimento, possono accadere le cose più impensate. Però secondo me si torna al mio discorso: se non si elimina la causa del blocco (sia esso sw o hw) il watchdog da solo serve il giusto.

PS: Non entro nel merito dei lock bit, dopo giorni in cui non se ne parla e dopo essermi concentrato su altro, ho rimosso quasi del tutto l'argomento dalla mia memoria :sweat_smile:

PPS: @Mike: http://www.logicaprogrammabile.it/arduino-resettare-automaticamente-la-scheda-utilizzando-il-watchdog-timer/

EDIT: ripensavo ai problemi hw. Ricordo che il watchdog resetta il microcontrollore ma non l'hardware agganciato per cui se la condizione di blocco è esterna ed il dispositivo è bloccato, bisogna pensare a creare un sistema di reset anche per quell'hardware (tipo un transistor per togliere l'alimentazione, un segnale su un eventuale pin di reset eccc) altrimenti non abbiamo risolto nulla

#500

Sui lock bits spero di fare qualche prova diretta, non avendo risposte certe, sono andato al lab e ho recuperato il Programmatore; solo che avevo "blindato" l'input in modo da non poter fornire valori diversi dai "3" e quindi mi tocca rimetterci mano, ci sta :sweat_smile:, se dovesse andar bene sarebbe sempre una funzione in più; con tutto il lavoraccio che ho fatto sulle routine di lettura e scrittura.....

Sul WD il link che mi hai dato pare proprio fatto per i tardi come me, grazie :D; ora me lo studio; se mai arrivasse un giorno che un nanetto si blocchi o si scarichi la batteria (ma ho calcolato 5 anni :sweat_smile:) o, più facilmente, si dovesse rompere una corda, approfitto per aggiornare il firmware ;) un si sa mai :)

#501

[quote author=Michele Menniti link=topic=95050.msg787589#msg787589 date=1336496817] Sul WD il link che mi hai dato pare proprio fatto per i tardi come me, grazie :D; ora me lo studio; se mai arrivasse un giorno che un nanetto si blocchi o si scarichi la batteria (ma ho calcolato 5 anni :sweat_smile:) o, più facilmente, si dovesse rompere una corda, approfitto per aggiornare il firmware ;) un si sa mai :) [/quote] Se vuoi evitare problemi di basse tensioni, usa il brown-out al posto del watchdog: è fatto apposta. Ma che te lo dico a fare :P

Se vuoi esser sicuro di non ritrovarti con il codice infilato in un loop infinito o piantato perché le piogge radioattive ti hanno mandato a meretrici il micro, allora pensa al watchdog con i tempi massimi consentiti (mi pare sia 2s il max impostabile sui Tiny).

#502

Letto e [forse] capito: (scusa Leo, ti leggo mentre posto) uso la libreria wdt.h in setup setto il tempo di WD (lì però non consiglia di NON scendere sotto i due secondi come diceva lesto....ma a me risulta che abbia ragione lesto, quindi?) in un punto strategico del loop, ma non necessariamente ad ogni ciclo..., resetto il WD. Il punto strategico lo fisso in un punto al quale il software arriva solo se è andato tutto bene fino a quel momento. E a quel punto il siftware deve arrivare sempre prima del tempo impostato per il WD, altrimenti il micro si resetta perennemente. Quindi se imposto il timer del WD a 4 secondi, io devo scegliere il punto di reset in modo che normalmente esso azzeri il timer PRIMA che passino i 4 secondi; se succede qualcosa il timer non viene resettato e quindi WD interviene (allo scadere dei 4 secondi) e resetta il micro. Ho capito bene :fearful:? Il brown-out l'ho disattivato Leo, per un circuito a batteria lo vedo invece "pericoloso", comunque lo sto proprio descrivendo ora nell'articolo :D

#503

http://www.nongnu.org/avr-libc/user-manual/group__avr__watchdog.html

Sì, è vero. Anche i Tiny consentono tempi di 4 e 8s. Andavo a memoria.

Per il resto è come hai interpretato. Fissi un punto di azzeramento del contatore del watchdog, che valuti in base a come hai strutturato il codice. Se non passa da quel punto, il tuo codice significa che si è piantato ed il watchdog farà il suo dovere.

#504

Dando ragione a lesto mi riferivo al fatto di NON impostare tempi sotto i due secondi per non rischiare l'impallo sotto forma di reset perenne, in quando al riavvio il bootloader ci metterebbe più tempo di quello del reste WD per diventare operativo. Come stanno le cose? Se c'è questo rischio come mai prevedono tempi inferiori a quelli di riattivazione del BL (probabilmente perché i tempi del WD li stabilisce ATMEL mentre il BL è specifico di Arduino?)

#505

A logica non si corre questo pericolo perché se andiamo ad analizzare la sequenza di avvio del micro, abbiamo:

  • accensione
  • controllo passato al bootloader: questo esegue il controllo sulla seriale per vedere se arriva uno sketch
  • se non arrivano sketch da flashare, passa il controllo al programma dell'utente
  • parte il programma dell'utente che, solo a questo punto, imposta e gestisce il watchdog

Per dirla tutta, c'è un watchdog anche internamente al bootloader, per resettarlo nel caso si pianti in ascolto. Ma che si può evitare di considerare. Se il tuo sketch imposta 2 secondi, i 2 secondi sono conteggiati al suo interno. Essi sono impostati nel setup, quindi il tempo del bootloader non entra nel conteggio.

#506 
/* CAGNACCIO
sketch di esempio per imparare ad usare il watchdog (by Leo72)
*/

#include  //libreria necessaria per gestire il watchdog
const byte LED=13; //led sul pin 13
byte statoLed=1; //stato del led

void setup() {
    pinMode(LED, OUTPUT); //led come ouput
    flashStart(); //salutiamo
    //Watch out! Watchdog! (Pericolo! Cane mordace!)
    cli(); //stop agli interrupt
    wdt_reset(); //resettiamo il cagnaccio
    wdt_enable(WDTO_4S); //4 secondi di attesa prima del reset
    sei(); //riattivo gli interrupt
    
}

void loop() {
    delay(1000); //1 secondo d'attesa
    statoLed^=1; //cambio di stato del led
    digitalWrite(LED, statoLed); //lampeggio del led
    
    //**********
    //delay(3500); //commenta/decommenta questa riga per vedere il cagnaccio in azione
    //**********
    wdt_reset(); //resettiamo il contatore
}
    

//semplice routine per verificare il reset della scheda
//esegue 5 flash veloci del led integrato
void flashStart() {
    for (byte i=0; i<5; i++) {
        digitalWrite(LED, statoLed);
        delay(50);
        statoLed^=1;
        digitalWrite(LED, statoLed);
        delay(50);
    }
}

Piccolo sketch di esempio. Caricatelo sull'Arduino. 5 flash del led e poi lampeggi regolari ogni secondo. Se decommentate la riga delay(3500) avrete la soprersa. Vedrete in azione il watchdog: 5 lampeggi veloci, led acceso fisso per 3,5 secondi e poi altri 5 lampeggi veloci ecc.. Questo perché il tempo complessivo supera i 4 secondi impostati per il watchdog ed il circuito resetta l'Atmega.

#507

Ragazzi, primo programma con Arduino e subito sono in crisi. Cavolo non capisco proprio perchè non funzioni..

  int x = 9;
  int y = 3;
  int z;

void setup(){

  z = x/y;
  Serial.begin(2400);
  
}

void loop(){
  
  Serial.println(z);
  
}

Apro serial monitor e guardate cosa trovo:

(una sfilza infinita...)

Non dovrei avere una sfilza di "3"?..Mi sto perdendo in un bicchiere d'acqua, nonostante ciò non trovo l'errore..Cosa sono questa serie di X accompagnate da un simbolo strano?

#508

1) non si vede bene 2) hai messo la stessa velocità sul monitor seriale? 3) i numeri stampali con Serial.println(z, DEC)

#509

Mi stavo per incavolare per l'"intrusione" di legolas93, poi mi sono ricordato che il titolo al Topic l'ho dato proprio io..... :sweat_smile: Ho copiato il tuo code, lo proverò; hai ragione su quello che dici, solo non ricordo più perché tempo fa più di qualcuno bloccò Arduino usando male il WD, tu ne hai memoria?