Topic permanente di programmazione newbie

[quote author=Michele Menniti link=topic=95050.msg766035#msg766035 date=1334856147] Anch'io ho sempre inteso ESATTAMENTE che sia la funzione 2 che la 3 mi bloccassero la programmazione ISP [/quote]

Certo che la bloccano, però a condizione che non esegui prima un erase, operazione che viene sempre fatta di defualt da tutti i programmatori, se inibisci tale comando non puoi riscrivere la flash. Detto in altri termini, in realtà negli AVR non è obbligatorio fare un erase prima della programmazione, puoi semplicemente sovrascrivere quello che c'è, però se lo fai ti ritrovi con la flash "sporca" con tutte le conseguenze che questo può portare, p.e. acquisizione di valori assurdi nel caso di puntatori che vanno oltre il limite previsto. Quando fai la programmazione ISP la prima operazione è un erase, infatti se c'è un bootloader precaricato viene cancellato, quindi non esiste nessun l.b. che ti può proteggere, solo il blocco della modalità ISP e JTAG permette questo livello di protezione, però se lo fai su un micro saldato poi ti puoi scordare di ripristinare la normale operatività visto che sei obbligato ad usare la modalità HV con tutte le relative problematiche.

Sì, ormai mi è tutto chiarissimo, sono duro di comprendonio, ma alla fine le prove mi aiutano a capire. Non dimentichiamo che tra me e te c'è la stessa comunicabilità tecnica di chi parla a bassa voce dal terrazzo di un palazzo (tu) e chi cerca di ascoltare ciò che dici in mezzo alla strada (io), se non "scendi a terra" hai voglia di parlare con me :~ :~ :~ Poi succede che tu mi stavi dicendo "spostati che le macchine ti investono", io non sento e quando la macchina mi investe dico "czz, ragazzi, ho scoperto che se restate in mezzo alla strada prima o poi qualcuno vi investe con l'automobile" :grin: Quindi alla fine arrivo empiricamente dove tu volevi portarmi teoricamente qualche ora prima. Il risultato è quello che conta, no? Ingessature a parte :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: Quindi alle prove dei fatti, restano valide le mie conclusioni PRAGMATICHE da incorniciare: [quote author=Michele Menniti link=topic=95050.msg765654#msg765654 date=1334837910] il mio intento esatto è: impedire la lettura e/o la scrittura, ecco perché NON ho raggiunto il 100% del mio scopo: oggi posso impedire la lettura, posso impedire la lettura e la scrittura, ma NON posso impedire la scrittura lasciando libera la lettura. [/quote] Cioè, il problema non è che si può evitare di finire investiti non restando in mezzo alla strada, ma che, se si resta in mezzo alla strada, prima o poi si finisce investiti. Dite la verità, una metafora del genere me la fa guadagnare la mia sedia all'UNI o no? XD

[quote author=Michele Menniti link=topic=95050.msg766074#msg766074 date=1334858060] Quindi alle prove dei fatti, restano valide le mie conclusioni PRAGMATICHE da incorniciare: [quote author=Michele Menniti link=topic=95050.msg765654#msg765654 date=1334837910] il mio intento esatto è: impedire la lettura e/o la scrittura, ecco perché NON ho raggiunto il 100% del mio scopo: oggi posso impedire la lettura, posso impedire la lettura e la scrittura, ma NON posso impedire la scrittura lasciando libera la lettura. [/quote] Cioè, il problema non è che si può evitare di finire investiti non restando in mezzo alla strada, ma che, se si resta in mezzo alla strada, prima o poi si finisce investiti. Dite la verità, una metafora del genere me la fa guadagnare la mia sedia all'UNI o no? XD [/quote]

Si, però quello è un limite degli AVR e non del tuo lavoro :D Giusto per affondare il forcone nelle terga dei fanboy avr, nei pic questi problemi non esistono, ovvero non è possibile brickarli se sbagli qualcosa in fase di programmazione, non serve una complessa procedura con mille mila pin impegnati per cancellare tutto a fondo, è possibile bloccare la flash sia in lettura che in scrittura in modo indipendente ed è possibile scegliere su varie arie di memoria, cioè non solo per il bootloader o per la flash generale, mi fermo qui altrimenti mi bannano però la lista è lunga :grin:

Se vogliono bannarti dovranno passare sul mio cadavere, sei troppo utile alla "causa". Io sono un fanboy (boy... :~) avr ma solo perché ho ripreso l'elettronica (lasciata ai tempi delle logiche non programmabili) partendo da Arduino, i cui meriti per me sono indubbi. Diventa sempre più chiaro, ad ogni tua forconata :fearful:, che se avessero realizzato l'Arduino con un PIC invece che con un ATMEL, probabilmente oggi avremmo molti meno casini e tanti vantaggi in più, ma ne siamo sicuri? Cioè, dal punto di vista software, compilatori, tool vari, interfacce, il mondo PIC è altrettanto ben fornito? Bada, la mia non è una domanda retorica, è una domanda e basta, non ne so niente del mondo PIC, e tu lo sai bene (a proposito, non scordarti che aspetto una risposta in MP :D), mi piacerebbe avere le idee più chiare, tutto qui, visto che non riesco a capire perché dei micro così tanto meglio attrezzati, pur essendo stra-diffusissimi, non abbiano attecchito così tanto sul popolo ignorante come invece è capace di fare atmega.

Ottimissimo,

si e' arrivati ad una chiarezza eccellente, metterei due puntine utili a tutti, specialmente per chi legge velocemente il tutto, su elementi che sono da ricordare sotto l'aspetto anticopia (che e' la vera cosa importante dei LockBit) uscite da questo topic :

1- Attivare il lockbit di massima protezione 2- Non lasciare mai il bootloader a bordo, altrimenti anche con la protezione il cinese fa festa lo stesso 3- l'aspetto protettivo in scrittura, che e' stato il piu' difficile da sviscerare, non interessa per scopi anticopia, perche' nel momento in cui il cinese ha cancellato/scritto in flash si e' fregato con le sue mani :)

Ho provato anche io le due combinazioni di lock utilizzando AVR Studio e Dragon in modalità ISP (e con erase disabilitato):
Con FE posso riprogrammare la flash (anche con un altro .hex) e leggerla senza problemi.
Con FC posso riprogrammare la flash ma non posso leggerla/verificarla, più esattamente sembra che la legga ma poi ottengo un file .hex pieno di FF.
In pratica ha ragione Mike, FE ed FC non bloccano la riprogrammazione :stuck_out_tongue:
Ora bisogna capire cosa intenda Atmel quando dice " Further programming disable".

Ciao
QP

QP, te lo dico di cuore: GRAZIE!

Test, puoi aggiungere che la disabilitazione del fuse SPI, seguita da una qualsiasi delle due modalità LB (FE o FC è indifferente), impediscono in ogni modo lettura e scrittura e, visto che il bootloader non c'è (parliamo sempre di stand-alone), l'unico modo per poter riscrivere è l'HV per dare un chip erase e poi riabilitare il fuse SPI, ma intanto il firmware si cancella e finché non si arriva a questa manovra volontaria, il chip è anche ragionevolmente protetto contro scritture accidentali.

Mi pare che tanta discussione abbia prodotto davvero buoni frutti, ora che siamo tutti sulla stessa lunghezza d'onda XD

[quote author=Michele Menniti link=topic=95050.msg766119#msg766119 date=1334860435] ma ne siamo sicuri? Cioè, dal punto di vista software, compilatori, tool vari, interfacce, il mondo PIC è altrettanto ben fornito? [/quote]

Sotto il profilo tool di lavoro il mondo pic è sempre stato molto più fornito di quello avr, però fino a poco tempo fa erano disponibili solo per Windows, dato che Arduino è multipiattaforma, in particolare il MAC visto che nell'ambiente in cui è nato è maggiormente diffuso questo s.o., la scelta è caduta sugli avr perché erano gli unici micro, al tempo della nascita di Arduino, per i quali fosse disponibile un ambiente di lavoro free per tutti e tre i sistemi operativi.

E' da tanto che son tentato.... non foss'altro per l'IDE nativo per Linux... risolverei i miei sbattimenti continui.... :sweat_smile:

x mike: il mio ultimo "riassunto" era dichiaratamente diretto alla funzione anticopia, indi come gia' detto in tal senso non interessa proteggere dalla scrittura.

x QT: a me sembra chiarita la questione, infatti con i LB non e' possibile RIPROGRAMMARE, ma solo PRIMA CANCELLARE E POI PROGRAMMARE. In tal senso va letto il datasheet (cosa facile da asserire ora, ma che prima di certo non era chiara, anzi Atmel dovrebbe spiegare meglio la cosa) Probabilmente, come dicevo, essendo la funzion anticopia la cosa piu' importante, la protezione da scrittura ha solo senso in ambito didattico, non c'e' nessun motivo per implementarla in un progetto commerciale.

Test, non facciamo questioni di lana caprina, volevi riassumere ed ho completato, altrimenti riassumi solo ciò che interessa te :grin:

vedi che è QP, non QT ;) Comunque io li ho spiegati i motivi per i quali anche un prodotto commerciale o comunque fornito a terzi potrebbe necessitare di una protezione da scrittura, evitare danni accidentali; metti il caso che tu realizzi un qualcosa per qualcuno su un micro e questo qualcuno poi si mette a smanettare (ormai Arduino ce l'hanno pure le colf) e cancella tutto, poi ti dice che non ne sa niente e via le questioni; invece lo proteggi e almeno sai che se l'ha cancellato è uno che sa il fatto suo :) Un po' come quelli che ti vendevano i film originali in videocassetta e spezzavano la linguetta in modo che tu non potessi cancellarli accidentalmente; certo che se gli mettevi un pezzo di nastro adesivo poi erano tazze tue, ma almeno risparmiavi l'incidente. Poi siamo nel campo delle ipotesi, a me personalmente non interessa, ciò che faccio viene non solo pubblicato e reso disponibile, ma perfino spiegato riga per riga, quindi stiamo solo parlandone. :)

Testato: x QT: a me sembra chiarita la questione, infatti con i LB non e' possibile RIPROGRAMMARE, ma solo PRIMA CANCELLARE E POI PROGRAMMARE. In tal senso va letto il datasheet (cosa facile da asserire ora, ma che prima di certo non era chiara, anzi Atmel dovrebbe spiegare meglio la cosa)

Dalla prova che ho fatto NON è necessario prima cancellare, tant'è che ho disabilitato l'auto-erase in AVR Studio ed il log nella finestra di output lo conferma (a meno che AVR Studio non mi pigli per il cuxo), ma puoi riprogrammare a piacere. Nel mio test, con protezione 'light' che permette la lettura, ho RIprogrammato la flash con un binario diverso ed ho successivamente scaricato il contenuto della stessa ottenendo un file .hex assolutamente identico all'originale. Resta il fatto che con la protezione massima non puoi leggere la flash e questo ti assicura la protezione 'intellettuale' del codice binario. Se vuoi una protezione integrale devi ricorrere al fuse SPIEN.

Ciao QP

Spettate, allora si stanno sostenendo due cose diverse ?

astrobeed: Certo che la bloccano, però a condizione che non esegui prima un erase, operazione che viene sempre fatta di defualt da tutti i programmatori, se inibisci tale comando non puoi riscrivere la flash.

QuercusPetraea: Dalla prova che ho fatto NON è necessario prima cancellare, tant'è che ho disabilitato l'auto-erase in AVR Studio ed il log nella finestra di output lo conferma (a meno che AVR Studio non mi pigli per il cuxo), ma puoi riprogrammare a piacere.

Testato: Spettate, allora si stanno sostenendo due cose diverse ?

Il test l'ho fatto e con la protezione in scrittura della flash attiva non è possibile caricare un nuovo programma tramite spi se prima non si esegue un erase, dal punto di vista pratico sembra che l'operazione va a buon fine, esattamente come la lettura della memoria protetta, però la flash rimane inalterata. Oggi rifaccio il test con calma, l'altro giorno li ho fatti in fretta ed è possibile che mi è sfuggito qualcosa.

Per quanto mi riguarda, non ho provato l’opzione -D, perché non mi interessava concettualmente, per i motivi più volte spiegati; il chip_erase resetta i lock bits (è proprio una delle sue funzioni e io l’ho provata) e quindi è ovvio che dopo si possa scrivere; però in un mio precedente intervento ho scritto

ma in condizione FC ho messo il chip con bootloader caricato direttamente su Arduino e sono riuscito ugualmente a caricare un blink, quindi il blocco continua a non avere alcuna utilità.

e questa operazione, se esegue un chip erase lo fa parzialmente perché resta protetta l’area del bl, ma per me chip_erase significa cancellazione totale di flash, eeprom e reset dei lb. Ma se QP dice che disabilitando il chip_erase scrive lo stesso io ci credo. Peraltro sarebbe la prova assoluta di ciò che sostengo da un po’ di pagine: la protezione in scrittura è una cag :grin:
Se Astro dedica un po’ di tempo magari tira fuori qualcosa di interessante.

Rettifica e smentita di ciò che ho affermato: Dopo aver lasciato sfiammare i neuroni (settimana di lavoro pesante; come dice Karl Popper "Tutta la vita è risolvere problemi"), ho riprovato con l' "Hello, world" di Arduino cioè Blink, prima con lampeggio ad 1 secondo, poi lampeggio con 5 secondi. Ebbene... Il lampeggio resta ad 1 secondo anche se la riprogrammazione sembra andare a buon fine. In pratica mi sono preso per il cuxo da solo. :blush:

Una volta impostati i lock bit NON si può riprogrammare il micro.

Ciao QP

QuercusPetraea: Una volta impostati i lock bit NON si può riprogrammare il micro.

Quindi confermi che, anche se la programmazione "sembra" andata a buon fine, difatti non è così?

QuercusPetraea: Il lampeggio resta ad 1 secondo anche se la riprogrammazione sembra andare a buon fine. In pratica mi sono preso per il cuxo da solo. :blush: Una volta impostati i lock bit NON si può riprogrammare il micro.

Ok, quindi confermi quello che avevo visto pure io, sembra che si riprogramma, ma rimane inalterato.

x Menny. Se programmi da Bootloader è normale che il micro viene riscritto anche se hai settato i l.b. per la protezione in scrittura perché in questo caso devi settare i relativi l.b. del bootloader che hanno una priorità maggiore rispetto a quelli della flash generica. Per farla breve, con il blocco in lettura e scrittura della flash generica non puoi scriverla tramite ISP, a meno di non fare un erase, e non puoi scriverla dal software applicativo, non puoi leggerla tramite ISP. Se non setti nessun l.b. del bootloader questo può tranquillamente leggere e scrivere la flash generica indipendentemente da come settati i relativi l.b. Relativamente al bootloader hai due distinti livelli di blocco, uno che riguarda solo la flash generica (application) che ti permette di inibire singolarmente la lettura e/o la scrittura, l'altro è relativo al bootloader stesso e anche in questo caso puoi inibire singolarmente lettura e/o scrittura per un totale di 8 differenti condizioni come permesso dai relativi quattro l.b. C'è solo un punto oscuro relativamente ai l.b. della flash generica, due bit consentono quattro diverse combinazioni però ne vengono sfruttate solo tre, apparentemente la condizione che blocca solo la lettura, e non la scrittura, non è permessa toccherebbe verificare se è una carenza del data sheet oppure è un limite reale In tutti i casi da AvrStudio il menù di settaggio dei l.b. per la flash prevede solo i tre stati indicati sul data sheet il che mi porta a pensare che effettivamente il blocco della sola lettura non sia possibile.

mi autopropongo come coordinatore nazionale dei test :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

grazie QP per il ri-test, Astro tu puoi esimerti dal rifarlo. :)

Si. Confermo!

Appena ho un po' di tempo provo con avrdude, che sembra possa vedere AVRDragon, con l-opzione -D che disabilita l'auto-erase e senza bootloader.

Ciao QP