Topic permanente di programmazione newbie

astrobeed:
Altra cosa che ti sfugge è che sebbene è possibile riscrivere la flash a singoli blocchi senza usare l'erase è il modo sbagliato di procedere nel caso della riprogrammazione, da non usarsi mai salvo casi particolari e comunque in modo ponderato.
Il comando chip erase è indispensabile prima di riprogrammare un micro, non è una carenza dell'IDE e/o di avrdude che venga utilizzato di default.

Aggiungo, per completezza e dopo chiudo, che anche per l'auto-programmazione (Application note AVR109 pagina 3 paragrafo Page Erase) gestita dal codice del bootloader con l'istruzione SPM necessita, prima di essere effettuata, che la pagina interessata alla programmazione sia prima cancellata.
Inoltre, il comando AVRDUDE che esegue l'IDE di Arduino per programmare il micro, utilizza l'opzione -D (disabilita la cancellazione della flash) altrimenti il codice del bootloader andrebbe a farsi fott.. friggere.
Direi che non altro da aggiungere.

Ciao
QP

QuercusPetraea:
Inoltre, il comando AVRDUDE che esegue l'IDE di Arduino per programmare il micro, utilizza l'opzione -D (disabilita la cancellazione della flash) altrimenti il codice del bootloader andrebbe a farsi fott.. friggere.
Direi che non altro da aggiungere.

Esatto, infatti è il bootloader che provvede a cancellare la flash, dato che i relativi l.b. non gli impediscono di scrivere nella application area, e sono dominanti rispetto agli l.b. della flash, può tranquillamente cancellare il programma presente.

Alla fine ci siamo capiti sul fatto che la questione era puramente concettuale (o filosofica, come l'hai definita tu); mi permetto solo di riprendere una tua frase:

.... e sono dominanti rispetto agli l.b. della flash

per poter ancora di più affermare che questi L.B. sono una emerita cag :grin:, una sorta di cane da guardia che scodinzola a chiunque tenti di entrare in casa del proprio padrone, e magari gli indica pure qual è il materasso giusto $)
Va bene, penso davvero che si possa chiudere ragionevolmente la questione, al solito Astro ha ragione da vendere ed io mi devo accontentare della filosofia, beh, meglio che niente :smiley: :grin: :smiley: :grin:
Grazie a tutti di avermi dato corda in questa squilibrata, ma spero anche utile, tematica.

Andiamo in pace :slight_smile:

Riapro per approfondire qualche concetto, visto che sto studiando il Reference del mega328P ai fini dell'articolo teorico sul Programmatore HV.

Mi sa che stai sbagliando l'interpretazione dei fuse, su Arduino il fuse HIGH è settato a 0xDE (11011110) che prevede anche SPIEN a 0, ovvero abilitato, infatti se cambi il valore di SPIEN a 1 (disabilitato) il valore del fuse diventa 0xFE (11111110) perché cambia il bit 5 del fuse che è proprio quello del SPIEN.
Da notare che il fuse SPIEN non è accessibile da ISP, cosa voluta per evitare di settarlo involontariamente e bloccare il micro, cioè anche se disabiliti il fuse per errore non succede nulla se programmi da sketch ISP, per scrivere quel fuse devi utilizzare la programmazione JTAG (se supportata dal micro e il 328 non la prevede, la trovi sul 2560), oppure la HV.

astrobeed:

[quote author=Michele Menniti link=topic=95050.msg787091#msg787091 date=1336468525]
ho notato che di default il bit è settato, mentre su Arduino è su 1, quindi teoricamente non dovrebbe essere possibile programmare via ISP il micro originale di Arduino.

Mi sa che stai sbagliando l'interpretazione dei fuse, su Arduino il fuse HIGH è settato a 0xDE (11011110) che prevede anche SPIEN a 0, ovvero abilitato, infatti se cambi il valore di SPIEN a 1 (disabilitato) il valore del fuse diventa 0xFE (11111110) perché cambia il bit 5 del fuse che è proprio quello del SPIEN.
Da notare che il fuse SPIEN non è accessibile da ISP, cosa voluta per evitare di settarlo involontariamente e bloccare il micro, cioè anche se disabiliti il fuse per errore non succede nulla se programmi da sketch ISP, per scrivere quel fuse devi utilizzare la programmazione JTAG (se supportata dal micro e il 328 non la prevede, la trovi sul 2560), oppure la HV.

[/quote]
Sì, sì, non vedi che intanto avevo cancellato l'intervento lasciando solo la riapertura? :grin: Chiarisco: siccome sto lavorando con 6-7 file aperti, comprese alcune tabelle che ho disegnato specificatamente per spiegare il funzionamento dei Fuse, ad un certo punto ho confrontato il DE con la tabella dell'High, se ci fai caso risulterebbe proprio lo SPIEN disabilitato, allora ho scritto il post, dopo aver chiusu ho letto meglio e mi sono accorto della cxxt che avevo fatto e ho cancellato la domanda. :blush:

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?

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

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

@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.

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

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.

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:

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.

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?

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:

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

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 :wink: un si sa mai :slight_smile:

Se vuoi evitare problemi di basse tensioni, usa il brown-out al posto del watchdog: è fatto apposta. Ma che te lo dico a fare :stuck_out_tongue:

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).

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 :smiley: