Topic permanente di programmazione newbie

Sì, faccio la prova del "doppio" blink e speriamo bene.

Ok, ora ho capito: 3, 1, 0 sono il decimale del byte e li uso come Case; bene, per ora sono a posto, stasera provo e posto.

Grazie Maestro XD

[quote author=Michele Menniti link=topic=95050.msg762008#msg762008 date=1334566372] Sì, faccio la prova del "doppio" blink e speriamo bene. [/quote] E' il test più semplice da fare.

Ok, ora ho capito: 3, 1, 0 sono il decimale del byte e li uso come Case; bene, per ora sono a posto, stasera provo e posto.

Sì, 3, 1 e 0 sono il decimale rispettivamente dei valori binari 0b00000011, 0b00000001 e 0b00000000. Puoi mettere case 0b00000011 al posto di case 3, non cambia nulla.

Grazie Maestro XD

Ma dai XD

Primi aggiornamenti: -Confermo che la programmazione dei LB si può eseguire da un livello al successivo ma non in senso contrario: FF->FE->FC, quindi se passo da FF a FE, poi posso ancora passare a FC, se passo da FF a FC, non posso più tornare a FE.

-La brutta notizia è che anche in protezione FC (massima) riesco tranquillamente a scrivere uno sketch via ISP, sovrascrivendo il precedente; questa operazione naturalmente riporta i LB a FF (condizione free); servirebbero spiegazioni.....

la board ?

uno.bootloader.unlock_bits=0x3F uno.bootloader.lock_bits=0x0F

Ma credo sia ininfluente, sto lavorando sul tiny84, i valori erano entrambi su FF, ho messo: attiny84at1.bootloader.unlock_bits=0xFF attiny84at1.bootloader.lock_bits=0xFC ma non cambia assolutamente nulla, con i LB impostati su FC si programma e i LB si resettano a FF. MI viene il dubbio che il fimrware ArduinoISP possa avere implementato il chip_erase (che mi risulta si possa eseguire anche via software). Boh, davvero non ne comprendo la logica. Ora provo anche un 328 in HVPP, vediamo.

@Mike: invia lo sketch in modalità "verbose", ossia premendo contemporaneamente il tasto SHIFT mentre clicchi sull'icona UPLOAD e guarda tra le prime righe che compaiono nel terminale dell'IDE i parametri che vengono passati ad avrdude, postali qui per capire se passa l'erase del chip mentre invia i firmware al micro, almeno capiamo cosa succede

leo72: @Mike: invia lo sketch in modalità "verbose", ossia premendo contemporaneamente il tasto SHIFT mentre clicchi sull'icona UPLOAD e guarda tra le prime righe che compaiono nel terminale dell'IDE i parametri che vengono passati ad avrdude, postali qui per capire se passa l'erase del chip mentre invia i firmware al micro, almeno capiamo cosa succede

mentre faccio upload del blink?

avrdude -CC:\arduino-0022\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\\.\COM60 -b19200 -Uflash:w:C:\DOCUME~1\DOTT~1.MIC\IMPOST~1\Temp\build1887152033353859677.tmp\Blink_FAST.cpp.hex:i 
Using Port            : \\.\COM60
         Using Programmer      : stk500v1
         Overriding Baud Rate  : 19200
avrdude: ser_open(): setting dtr
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Send: 0 [30]   [20] 
avrdude: Recv: 
avrdude: Recv: 
         AVR Part              : ATMEGA328P
         Chip Erase delay      : 9000 us
         PAGEL                 : PD7
         BS2                   : PC2
         RESET disposition     : dedicated
         RETRY pulse           : SCK
         serial program mode   : yes
         parallel program mode : yes
         Timeout               : 200
         StabDelay             : 100
         CmdexeDelay           : 25
         SyncLoops             : 32
         ByteDelay             : 0
         PollIndex             : 3
         PollValue             : 0x53
         Memory Detail         :

nei dettagli del micro quel chip erase delay non mi dice nulla di buono :(

Qui si sta scoprendo qualcosa di interessante :)

[quote author=Michele Menniti link=topic=95050.msg762640#msg762640 date=1334607572] nei dettagli del micro quel chip erase delay non mi dice nulla di buono :( [/quote] Non ti preoccupare, quelli sono i parametri che avrdude ha nel file avrdude.conf relativamente al chip che sta gestendo, quindi è un sunto di tutto, anche di ciò che non usa in quel particolare momento. La riga che ci interessa è questa:

avrdude -CC:\arduino-0022\hardware/tools/avr/etc/avrdude.conf -v -v -v -v -patmega328p -cstk500v1 -P\.\COM60 -b19200 -Uflash:w:C:\DOCUME~1\DOTT~1.MIC\IMPOST~1\Temp\build1887152033353859677.tmp

I parametri sono: -v -v -v -v: specifica una modalità "super verbose", ossia che manda a video qualsiasi messaggio generato -patmega328p: specifica atmega328p -cstk500v1: specifica il tipo di programmatore (stk500v1 è l'emulazione che offre l'ArduinoISP) -P\.\COM60: porta usata -b19200: velocità -Uflash:w:C:.....: fimware usato e memoria programmata, ossia la flash

Quindi, non c'è nessun dettaglio relativamente alla cancellazione del chip, che sarebbe il parametro -e, che opera un erase totale della flash, della eeprom e dei fuse del micro. Il parametro "-e" dovrebbe essere usato dall'IDE solo quando programma il bootloader.

Boh, l’unico dato certo è che con le opzioni FE o FC non riesco più a programmare i fuse, segno che i lb stanno funzionando, niente da fare invece sulla questione programmazione, gli sketch passano che è una bellezza.
Sarebbe interessante il parere di qualcuno che li ha usati, ma ho idea che non c’è nessuno.
Comunque stanotte ho terminato i due firmware (PC e LCD) con la gestione lettura/scrittura dei Lock bits, la procedura funziona, non posso entrare nel merito del funzionamento dei lb, anche se mi piacerebbe capirlo.

Avevo chiesto se avete un qualcosa di semplice con cui possa “leggere” il contenuto della flash del micro, naturalmente non mi interessa alcuna estrapolazione o traduzione di codice, solo capire se almeno la lettura viene impedita.

Ora mi dedico ad altre cosette, tra qualche giorno (devo smaltire :disappointed_relieved:) riprendo tutto e scrivo il terzo ed ultimo articolo sull’HV.

Non so che dirti, non ho ancora avuto mai il modo di doverli usare.
So solo che anche l’IDE di Arduino li programma (basta aprire il file boards.txt per vedere la voce dei lockbit).
Mi viene da pensare che un “programmatore” software qual è l’ArduinoISP non riesca a compiere l’operazione, e che forse ci vorrebbe un programmatore “vero”.

Astro Astro Astro

(chiamato a gran voce stile "Il Gladiatore") :) :) :)

sorry ma sono di fretta :) date una lettura a questo documento: http://www.avrfreaks.net/modules/FreaksFiles/files/382/DN_020.pdf

BrainBooster: sorry ma sono di fretta :) date una lettura a questo documento: http://www.avrfreaks.net/modules/FreaksFiles/files/382/DN_020.pdf

Arrivi tardi, l'ho già segnalato un paio di volte ;) Cmq lì si parla anche di "protezione in scrittura", non solo di lettura però Mike non riesce a proteggere i chip da tale operazione.

Astro interviene d'ufficio di solito, evidentemente non ha seguito questa parte di discussione oppure nemmeno lui ha mai sperimentato fisicamente i lock bits. Purtroppo le ho provate tutte, il comportamento a monte è perfetto: da stato FF (free) posso passare a FE (write protect) o direttamente a FC (write e verify protect), da FE posso passare a FC, tutte le altre direzioni non sono consentite; posso solo resettare a FF con un chip erase oppure inviando uno sketch che, sulla carta, non dovrebbe accettare. Nelle condizioni FE o FC non riesco più a programmare i fuse, nemmeno con l'HV, e questa per me è la prova che i lock bits, almeno qui, stanno facendo il loro dovere; infatti sul reference è scritto chiaramente che i fuse non sono programmabili se i LB non sono settati su FF. Poi, tutto felice, vado a mandare una blink qualsiasi e passa che è una bellezza, allora a che cavolo serve tutto sto casino? MI sembra tanto la storia del signore medievale che andava in guerra dopo aver messo la cintura di castità alla bella moglie e poi le lasciava la chiave appesa al collo :P; dopo i primi 15 giorni di guerra l'elmo gli stava sollevato sulla testa di 30cm :stuck_out_tongue_closed_eyes:

Uhm... forse ho capito. Leggendo il datasheet, pagg. 283 e seguenti, mi par di capire che ci siano due coppie di lock bit, una coppia protegge la memoria del bootloader e l'altra coppia protegge la memoria flash dell'applicazione. Mi sa che il bandolo della matassa sia questo. Difatti a pag. 297 si dice che il 328 ha ben 6 lock bit.

oh porc... :0, me la leggo bene anche se mi sono sempre riferito alle tabelle di programmazione e lì parla di due bit e basta.

leo72: Mi sa che il bandolo della matassa sia questo. Difatti a pag. 297 si dice che il 328 ha ben 6 lock bit.

Non mi dite che non vi siete mai accorti che ci sono due distinti blocchi di L.B. ?

astrobeed:

leo72: Mi sa che il bandolo della matassa sia questo. Difatti a pag. 297 si dice che il 328 ha ben 6 lock bit.

Non mi dite che non vi siete mai accorti che ci sono due distinti blocchi di L.B. ?

Chi??? Noi????? Ceeeeeerrrrrtoooooooo :sweat_smile:

Allora, cerchiamo di capirci: a me del blocco dei BLB non frega assolutamente nulla, avendolo intepretato come riguardante l'area riservata al bootloader; io ho sempre parlato di LOCK BITS, che sono due e riguardano la memoria flash e l'eeprom:

LB Mode LB2 LB1
1 1 1 No memory lock features enabled.
2 1 0 Further programming of the Flash and EEPROM is disabled in
        Parallel and Serial Programming mode. The Fuse bits are
        locked in both Serial and Parallel Programming mode.(1)
3 0 0 Further programming and verification of the Flash and EEPROM
        is disabled in Parallel and Serial Programming mode. The Boot
        Lock bits and Fuse bits are locked in both Serial and Parallel
Programming mode.(1)
“1” means unprogrammed, “0” means programmed

la nota conferma che il byte 0b11111100 rappresenta la massima protezione. Ora se mi dite che invece di questi devo programmare il BLB va bene, ma Vi chiedo gentilmente di darmi indicazioni chiare, io faccio grande fatica con i data-sheet in inglese, e a me dappertutto è sembrato che la protezione della flash si facesse con i LB e NON con i BLB :disappointed_relieved: