Topic permanente di programmazione newbie

[legolas93]

Michee..ehh   io mi sono rifatto al titolo!

Grazie Leo72..era la velocità impostata diversa  :~ La cosa bella è che è una cosa che so e che avevo anche controllato..   Questi sono proprio errori da newbie.

Vediamo se ora della Maturità riesco a tirare fuori qualche progetto carino da portare alla commissione  

[menniti]

Grazie Leo72..era la velocità impostata diversa  :~ La cosa bella è che è una cosa che so e che avevo anche controllato..   Questi sono proprio errori da newbie.

E per questo sei degnamente finito su questo Topic 

[menniti]

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

Fatte le prove "LI CONTI TORNANO" (ultimo dialogo tra la Morte e Brancaleone): effettivamente, rimossi i blocchi che avevo messo, al LOCK BITS BYTE nel suo insieme riesco a dare qualsiasi valore, quindi posso programmare sia i BLB e i LB. Il vero problema che mi si pone ora è capire tutto il casino che ruota attorno a questi 6 bit (due non sono usati); attenzione, non mi riferisco alla questione protegge/non protegge, già abbondantemente chiarita, ma proprio come si dovrebbe usarli. E per quanto sono riuscito a comprendere io spiegherei questo in prima battuta:
Il LBB è così organizzato:
7-6 : non usati
5-4 : Protezione della Sezione Bootloader della memoria Flash
3-2 : Protezione della Sezione Application della memoria Flash
1-0 : Protezione della memoria Flash e EEPROM

Cioè a me pare di capire che mentre i bit 5-4 e 3-2 agiscono solo sulla specifica sezione di memoria flash (la Application va da 0x0000 all'inizio della Bootloader, che è fissato dai fuse: 512-1024-2048-4096 byte), i bit 1-0 agiscono sull'intera memoria flash e anche sulla EEPROM (sempre che non sia protetta dall'attivazione dell'apposito Fuse.

Tutto ciò lo ricavo dal Rev. 8271D-AVR-05/11 del 328P (salvo eccezioni sul 48P) pag. 283 par. 27.5 e pag. 297 par. 28.1 e la cosa mi sembra confermata dalla nota "Program the Fuse bits and Boot Lock bits before programming the LB1 and LB2" che ora finalmente capisco; infatti se è come ho intuito è ovvio che i LB siano più "potenti" dei BLB, che verrebbero ignorati; e infatti riesco a programmare nella direzione FF->FE->FC ma non nella direzione opposta.

Ma il mio inglese… :~ vi chiedo conferma, ho capito bene secondo voi?

[leo72]

Concordo con te. Ma la parte più significativa secondo me è la coppia di tabelle a pagina 284, dove spiega "chi" e "dove" può accedere. Vedi infatti le distinzioni fra area dell'applicazione ed area del booloader nonché i permessi della programmazione seriale e parallela.

Ah, piccola precisazione. Questo non è corretto:

la Application va da 0x0000 all'inizio della Bootloader, che è fissato dai fuse: 512-1024-2048-4096 byte

In realtà quei valori indicano la dimensione, non l'indirizzo di partenza. Il bootloader occupa sempre la parte più alta della memoria. Ma penso che tu abbia solo scritto male.

Comunque per chiarezza facciamo un esempio. Se abbiamo un Atmega168, la sua memoria va da 0000 a 16383 ($0000-$3FFF). Se impostiamo un bootloader di 512 byte, la memoria dell'applicazione va da $0000 a $3DFF, poi da $3E00 a $3FFF c'è il bootloader. In un 328, lo stesso bootloader occupa da $7E00 a $7FFF.

[Maurotec]

Menniti se non ricordo male (due settimane fa ho letto circa i 6 bit nel datasheet del 328)  il tuo inglese questa volta è stato sufficiente.
Possiamo dire che LB è Global Lockbit, e BLB e BLB1 sono Specific Lockbit.

Come usarli non lo so, io in avrdudequi li ho implementati come si vedono nel datasheet, con la stessa descrizione "pessima" perchè non ho saputo trovare niente di meglio e in mancanza ho preferito lasciare le note di Atmel.

Ciao.

Anticipato da leo:

Comunque per chiarezza facciamo un esempio. Se abbiamo un Atmega168, la sua memoria va da 0000 a 16383 ($0000-$3FFF). Se impostiamo un bootloader di 512 byte, la memoria dell'applicazione va da $0000 a $3DFF, poi da $3E00 a $3FFF c'è il bootloader. In un 328, lo stesso bootloader occupa da $7E00 a $7FFF.

Vero anche io penso che abbia scritto sbagliato ma sa come stanno le cose.

[menniti]

Grazie ragazzi, mi conforta questa cosa
Allora chiarisco che mi sono spiegato male ma che ho ben presente la questione dell'area di bootloader: l'ho approfondita studiando i fuse bits in questi giorni; so che l'area Bootloader è nella parte alta della memoria e che l'indirizzo di partenza dipende da quanta memoria viene riservata ad essa, essendo tale valore variabile in base al settaggio dei fuse bits.
Ora mi pare di aver capito anche ciò che dice lo specifico, pes. i due bit della sezione Application:
1 1 No restrictions for SPM or LPM accessing the Application section. (sezione non protetta)
1 0 SPM is not allowed to write to the Application section. (protetta da scrittura)
0 0 SPM is not allowed to write to the Application section, and LPM executing from the Boot Loader section is not allowed to read
from the Application section. If Interrupt Vectors are placed in the Boot Loader section, interrupts are disabled while executing
from the Application section. (protetta da scrittura e anche dalla lettura da parte del bootloader, eventuali vettori di interrupt collocati nel BL vengono disabilitati durante l'esecuzione dalla sezione Application)
0 1 LPM executing from the Boot Loader section is not allowed to read from the Application section. If Interrupt Vectors are placed
in the Boot Loader section, interrupts are disabled while executing from the Application section. (come sopra ma solo per ciò che riguarda la protezione dalla lettura)

che dite?

[Maurotec]

che l'area Bootloader è nella parte alta della memoria e che l'indirizzo di partenza dipende da quanta memoria viene riservata ad essa, essendo tale valore variabile in base al settaggio dei fuse bits.

Non mi pare così, direi che l'indirizzo di partenza in cui risiede il bootloader è sempre 00, poi dopo tot byte (in base ai fuse) termina
l'area del bootloader e comincia quella così detta application area.

Ora mi pare di aver capito anche ciò che dice lo specifico, pes. i due bit della sezione Application:
1 1 No restrictions for SPM or LPM accessing the Application section. (sezione non protetta)
1 0 SPM is not allowed to write to the Application section. (protetta da scrittura)
0 0 SPM is not allowed to write to the Application section, and LPM executing from the Boot Loader section is not allowed to read
from the Application section. If Interrupt Vectors are placed in the Boot Loader section, interrupts are disabled while executing
from the Application section. (protetta da scrittura e anche dalla lettura da parte del bootloader, eventuali vettori di interrupt collocati nel BL vengono disabilitati durante l'esecuzione dalla sezione Application)
0 1 LPM executing from the Boot Loader section is not allowed to read from the Application section. If Interrupt Vectors are placed
in the Boot Loader section, interrupts are disabled while executing from the Application section. (come sopra ma solo per ciò che riguarda la protezione dalla lettura)
smiley-sweat
che dite?

Si in effetti ora è anche più chiaro, scrivilo tutto in italiano che ha più senso. Appunto se ho un bootloader installato e voglio evitare che l'utente lo usi per leggere l'application area devo selezionare l'ultima sequenza di bit 0 1. Ma il bootloader può scrivere però magari non offre questa capacità all'utente di suo. Insomma io non ho un buon motivo per usarle forse per questo non mi figuro un caso di uso.

Ciao.

[testato]

menny sono daccordo con la tua interpretazione/traduzion, mentre sul posizionamento fisico del bootloader anche io sapevo che era all'inizio della flash, mi sembra anche abbastanza logico, cioe' l'mcu inizia a lavorare sempre da 0000 e poi vediamo, se' ce' un bootloader il suo codice che mi indirizzera' all'applicativo, che e' piu' avanti fisicamente parlando

[leo72]

No, mi spiace contraddirvi. Il bootloader è nell'ultima sezione della Flash.
La tabella a pag. 18 fa vedere chiaramente come il bootloader sia posizionato proprio in alto (basta vedere gli indirzzi).

[astrobeed]

Non mi pare così, direi che l'indirizzo di partenza in cui risiede il bootloader è sempre 00, poi dopo tot byte (in base ai fuse) termina
l'area del bootloader e comincia quella così detta application area.

All'indirizzo 0x00 c'è il reset vector, cioè un jmp alla prima di memoria dove risiede il programma, poi c'è il vettore di interrupt, il bootloader è sempre posto in fondo alla flash, se è presente all'indirizzo 0x00 c'è un jmp alla prima locazione del bootloader, vedi tabella 11-1 del data sheet per i dettagli.

[menniti]

Sul bootloader ero certissimo, ho studiato a fondo i fuses, ora ho anche il conforto di Astro e Leo
Per il resto ho letto e riletto e tutto torna, quindi ora il Programmatore HV legge e programma correttamente l'intero Lock Bits Byte, «another brick in the wall» XD
Riepilogando:
2 bits controllano R/W della memoria bootloader
2 bits controllano R/W della memoria applicazioni
2 bits controllano R/W di entrambe le aree, quindi dell'intera flash memory ed anche dell'EEPROM e bloccano anche i fuse bits (cosa che non fanno i 4 bits precedenti) e/o i boot lock bits.
Quindi si può agire indifferentemente su lettura e/o scrittura delle due aree o contemporaneamente su entrambe.
La "novità" sta nel fatto che, contrariamente a ciò che mi era parso di capire nei giorni scorsi, sempre su questo Topic, i lock bits hanno maggior peso dei boot lock bits ed infatti il reference dice che i blb vanno programmati PRIMA dei lb.
Mi metto e scrivo tutto per l'articolo $) ora sto valutando se caricare le descrizioni sintetiche di tutte le combinazioni, ma mi sa che sono tante
Per il momento un dono alla vostra gentilezza e disponibilità: tabella riepilogativa (anteprima assoluta per gli amici del Forum!!) del Lock Bits Byte del mega328P XD

[leo72]

I BLB sono delle specie di custodi interni della memoria. Difatti servono per evitare che il codice possa scrivere sulla Flash a runtime.
I lock bit veri e propri sono, usando un'altra figura,come le sentinelle di ronda che controllano che tentativi di lettura/scrittura che provengono dall'esterno del micro possano passare.

[menniti]

Grazie del chiarimento. Mi pare che l'argomento possa ritenersi esaurientemente trattato, salvo richieste di approfondimenti

Invece vorrei ora parlare di un qualcosa che ho sfiorato marginalmente in questi giorni e mi ha fortemente incuriosito, cito il datasheet:

Calibration Byte
The ATmega48A/PA/88A/PA/168A/PA/328/P has a byte calibration value for the Internal RC
Oscillator. This byte resides in the high byte of address 0x000 in the signature address space.
During reset, this byte is automatically written into the OSCCAL Register to ensure correct frequency
of the calibrated RC Oscillator.

Ci sono due aspetti estremamente interessanti da capire:
1 - qui parla di una scrittura automatica del byte di calibrazione dell'oscillatore, ma la cosa significa che sarebbe possibile agire su 256 bit per tarare la frequenza dell'oscillatore interno?
2 - Se ben capisco il byte risiede nell'area della signature che dovrebbe essere protetta (probabilmente solo dall'esterno); ma secondo Voi potrebbe esistere un modo per riscrivere la signature (mi riferisco a quei 2313 che ho azzerato ma che continuano a funzionare anche senza signature) visto che in quest'area di memoria viene riscritto il registro OSCCAL?

[leo72]

Mi sa che hai frainteso. Dall'area di memoria dove risiede anche la signature viene letto il valore di calibrazione dell'oscillatore interno e copiato nel registro OSCCAL, che risiede in RAM ed è quindi modificabile.

Non l'inverso, perché la memoria dove risiede la signature dovrebbe essere di tipo PROM. Una volta scritta, è quella. Difatti mi pare che astro avesse scritto che, in uno scambio di mail con Atmel, era venuta fuori la questione che a "giocare" con le signature, forzando le programmazioni con avrdude ed il parametro "-f", si poteva rovinare l'area dove risiede la signature. A quel punto la signature era persa anche se il micro continuava a funzionare regolarmente. Solo alcuni programmatori "precisini", che leggevano la signature obbligatoriamente, potevano impuntarsi nel cercare di programmare questi chip senza nome.

Sul fatto del valore di calibrazione, ci sono dei micro che permettono di modificare tale valore. Ad esempio la V-USB!!! Te la ricordi Mike?  ]
Ti ricordi che l'Attiny85 viene calibrato internamente a 12 MHz agendo proprio su questo parametro?

[Maurotec]

No, mi spiace contraddirvi. Il bootloader è nell'ultima sezione della Flash.
La tabella a pag. 18 fa vedere chiaramente come il bootloader sia posizionato proprio in alto (basta vedere gli indirzzi).

Non mi pare così, direi che l'indirizzo di partenza in cui risiede il bootloader è sempre 00, poi dopo tot byte (in base ai fuse) termina
l'area del bootloader e comincia quella così detta application area.

All'indirizzo 0x00 c'è il reset vector, cioè un jmp alla prima di memoria dove risiede il programma, poi c'è il vettore di interrupt, il bootloader è sempre posto in fondo alla flash, se è presente all'indirizzo 0x00 c'è un jmp alla prima locazione del bootloader, vedi tabella 11-1 del data sheet per i dettagli.

Si ma io guardavo il monitor al contrario e il mio cervello era in negato ~, quindi ~FF= 00 e scusate. Ho lo sapevate che arrampicarsi sugli specchi è davvero difficile.

Ciao.