Topic permanente di programmazione newbie

astrobeed: x Tutti Il punto chiave della questione, e che continua a sfuggirvi, è che i l.b. relativi alla flash generale fanno quello che devono fare, ovvero se settate la protezione in scrittura è impossibile alterare la flash oltre che dal firmware anche da SPI/Jtag e pure da HV. Se durante la programmazione, non importa con che sistema, viene inviato un comando di reset, cosa che tutti i programmatori eseguono di default come prima operazione, i fuse vengono riportati al loro stato iniziale, ovvero nessun protezione nel caso dei l.b., e diventa possibile riprogrammare il micro. Possibile che non vi entra in testa questa cosa tanto semplice ?

NON è possibile, ed infatti siamo tutti completamente d'accordo su questa cosa. Su cosa fanno i Lock Bits mi pare che QP col suo ultimo intervento abbia piantato una pietra miliare, penso che non sia più necessario spiegare altro.

Possibile che non capite che se bloccate nel vero senso della parola la cancellazione del micro tramite programmatore poi lo potete buttare via se dovete aggiornarlo ? Una volta esistevano i micro OTP (One Time Programming) che si programmavano solo una volta, sono spariti non appena la flash è scesa a costi accettabili perché era veramente assurdo dover sostituire il micro per fare un update del software.

Anche questo è chiarissimo ed io avrò scritto parecchie volte che non aspiro a realizzare il micro bloccato per sempre, sarei stupido! Quindi nessuno nega tutto questo, e questo era il senso delle mie affermazioni precedenti. La questione che sto ponendo e su cui orami quasi tutti sono d'accordo è che: - L'utente standard di Arduino programma un microcontrollore o mediante IDE o mediante AVRDUDE e, nella stragrandissima maggioranza dei casi, NON è in condizione di attivare/disattivare parametri. - Se gli consegni un micro programmato per lavorare in standalone e con i lock bit settati per la protezione in lettura (non vuoi che possa copiare il firmare) e scrittura (non vuoi che lo possa sovrascrivere accidentalmente) e lui lo collega al suo Arduino via ISP, per vedere se è vero :grin:, cosa ottiene? a - effettivamente non riesce a leggere b - però riesce a scrivere e fa la czzt e perde il firmware (lasciamo stare se è sciocco o meno) e tutto questo senza fare niente di particolare, perché? perché ArduinoISP e AVRDUDE (che poi è la stessa cosa...) hanno abilitato di default il chip_erase.

Cioè TUTTO si riduce ad una sola cosa: per me è ridicolo dare la possibilità di proteggere un micro mediante programmazione e poi impostare gli strumenti ordinari di manipolazione in modo tale che la protezione venga spazzata via anche se l'utente NON lo desidera (qui non parliamo di programmatori nel senso stretto del termine, tipo il Dragon). E' come se io esco di casa, metto 4 mandate di chiave di sicurezza e poi lascio la chiave attaccata alla porta. IO NON HO DETTO CHE LA PORTA NON SI CHIUDE con questo sistema, ma solo che il sistema è inutile perché la chiave è attaccata alla porta :D.

Chiudo dicendo che tutta sta discussione non si sarebbe mai fatta se semplicemente si fosse mantenuto il chip erase disabilitato di default. In questo caso l'utente standard NON sarebbe stato messo in condizioni di poter sbagliare involontariamente, mentre quello più evoluto avrebbe potuto a suo piacimento attivare l'opzione chip_erase e cancellarlo.

[quote author=Michele Menniti link=topic=95050.msg768542#msg768542 date=1335082057] Chiudo dicendo che tutta sta discussione non si sarebbe mai fatta se semplicemente si fosse mantenuto il chip erase disabilitato di default. [/quote]

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. Poi se vogliamo filosofeggiare su quanto può essere "ignorante" (nel vero senso del termine) l'utente medio di Arduino, pertanto è facile che commette azioni con esiti disastrosi ed irreversibili, allora è un altro paio di maniche ed è un discorso che ha ben poco a che vedere con i lock bit :D

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 :D :grin: :D :grin: Grazie a tutti di avermi dato corda in questa squilibrata, ma spero anche utile, tematica.

Andiamo in pace :)

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

[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. [/quote]

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

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