Newsgroup: it.hobby.elettronica.digitale
Titolo: debugWire e ATmega48A

Non conosco gli AVR e sto per iniziare con un ATmega48A.  Quindi farò 
sicuramente una domanda stupida.
 
Vorrei comprare (o realizzare, se esiste un clone funzionante con schemi 
e firmware) un programmatore/debugger low-cost (intorno ai 100EUR).  Ho 
visto che il JTAGICE3 dovrebbe essere compatibile con la programmazione 
in-circuit e il debugWire dell'ATmega48A, ed ha grosso modo questo 
prezzo (esiste un clone affidabile da realizzare in casa?).
 
Mi sembra di aver capito che, da configurazione di fabbrica, il 
debugWire non è abilitato (il fuse DWEN non è programmato).  Quindi è 
necessario prima programmare questo fuse con la tecnica ISP, che 
coinvolge altri pin del micro.
 
In soldoni devo prevedere un connettore 6 poli con i seguenti segnali (a 
parte la massa):
- SCK
- MISO
- VTG
- /RESET
- MOSI
Questo dovrebbe permettermi di programmare e debuggare.  Ma se voglio 
evitare di "perdere" tutti questi pin?
 
Poi mi sembra di capire che è possibile arrivare a situazioni in cui 
sono disabilitati sia il debugWire (DWEN fuse) che la programmazione SPI 
(SPIEN).  In questo caso serve una terza modalità di programmazione, 
denominata high-voltage che sembra il JTAGICE3 non fa.
 
Potrei evitare di abilitare il debugWire e rinunciare al debugging, ma è 
un peccato.
 
Insomma, mi sembra un po' complicato.  Avete esperienze in merito da 
condividere?  Suggerimenti su come procedere?

 condividere?  Suggerimenti su come procedere?
 
Potresti prevedere sul prototipo dei pin ad inserzione in modo da
poter essere utilizzati sia dal connettore ISP che da jumper in modo
da isolare (jumper disinseriti) i segnali MISO/MOSI/SCK/RST.
In una prima istanza levi i jumper, inserisci il connettore di
programmazione e programmi i fuse che ti servono.
Poi reinserisci i jumper in modo da riassegnare i pin del micro alle
loro funzioni I/O.
Ancora più comodo e prevedibile su schede in produzione, sostituire ai
jumper delle piazzole da cortocircuitare con una goccia di stagno.
Ridotto all'estremo, si può evitare anche il connettore ISP e lasciare
6 vias metallizzate con un passo di poco inferiore ai 100mil in modo
da poter inserire a pressione un connettore maschio 6 pin passo
100mil.
A causa della lieve differenza di passo, il contatto è garantito
(basta tener spinto il connettore sul PCB il tempo necessario alla
programmazione).
Una volta programmato il micro si passerà a cortocircuitare le 4
coppie di piazzole MISO/MOSI/SCK/RST per l'utilizzo definitivo.
In fase di sviluppo ci si può avvalere di un deviatore multiplo 2
posizioni/4 vie per passare da una fase all'altra in un clack.
Se l'applicazione lo consente, al posto delle piazzole da cc possono
bastare delle semplici resistenze in serie ai segnali in modo da poter
permettere al programmatore di imporre i segnali.
 
Piccio.

 denominata high-voltage che sembra il JTAGICE3 non fa.
bisogna volutamente programmare quel fusibile rendendo il micro inaccessibile, inoltre la procedura di programmazione HV è molto "invasiva" e personalmente non l'ho mai vista implementata. Basta fare un pò attenzione con quel fuse che peraltro c'è su tutti i micro AVR


 condividere?  Suggerimenti su come procedere?
 
Ah, quel micro ha anche la possibilità di caricarci un bootloader...
 

 permettere al programmatore di imporre i segnali.
 
Questa è forse la soluzione migliore.  Che tipo di accorgimenti devo 
prendere per essere sicuro che il mio circuito sui pin di programmazione 
non disturbino durante la programmazione/debugging?
 

 montaresulla scheda) hai bisogno del connettore con quei segnali. Comunque
 > SCK, MISO e MOSI, prendendo le dovute precauzioni, non vanno persi
 
Che tipo di precauzioni?
 


Sì, ma non penso di svilupparne uno per questa applicazione.  Magari in 
futuro.
 
 

 futuro.
 
Attenzione!
L'ATmega88 consente il bootloader nel senso che ha delle zone della
flash diversamente protette ed indipendenti.
L'ATmega48, invece, pur condividendo le mappature dell'88, non ha zone
separate di flash (gestite da fuse-bit diversi).
Meglio verificare...
 
Piccio.

 non disturbino durante la programmazione/debugging?
 
Innanzitutto i segnali non devono essere condivisi da periferiche
"impegnative".
Mi spiego: se i segnali MOSI e MISO vanno verso un display LCD, in
fase di programmazione lo streaming di dati verso il micro (ma
"casuali" rispetto all'LCD) non hanno effetto pernicioso; al massimo
vedrò qualche insignificante carattere visualizzato sul display solo
in questa fase e poi tutto ok.
Se i pin, invece, vanno a pilotare dei tiristori e l'alimentazione di
rete deve essere presente anche in programmazione (per accendere anche
il micro che nel caso particolare magari non può essere alimentato
esternamente), allora potresti trasformare la scheda in un'ottima
saldatrice ad arco.
Un altro esempio che mi tocca da vicino è nel caso di comando di
servomeccanismi: durante il debug, se non tolgo tensione alla scheda-
servo, partono gli assi in fuga per cui dovrei sempre sconnettere e
riconnettere l'alimentazione principale per non far danni.
Ma io sono furbo: posiziono l'asse a metà e quando parte in fuga non
fa in tempo a sbattere che la riprogrammazione del micro è
terminata.  :)
Bello eh? ;)
 
Piccio.
 

condividere?  Suggerimenti su come procedere?
 
Io lo trovo molto semplice, e usare il DebugWire � molto comodo.
 
Se non disabiliti il fuse perdi solo il RESET\ dal pin, ma da power on, watch
dog eccetera funziona, quindi potresti non notare la differenza.
Meglio comunque alla fine del debug togliere il fuse riabilitando la
programmazione con la SPI.
 
Buona anche l'idea (del buon Bertolazzi se ricordo bene) di usare un passo
leggermente inferiore per i 6 pins, io uso 2.28mm.
Questo mi consente di saldare una strip nel prototipo per il debug in sicurezza
e di programmare facilmente il tutto in produzione usando solo delle strip
lunghe.
 
Esempio:
https://dl.dropbox.com/u/2370367/prog.jpg
 
 
--
ciao
  Stefano


Grazie Piccio, in effetti queste precauzioni a livello di "applicazione" 
mi erano note.  Io intendevo precauzioni a livello elettrico per evitare 
che il programmatore o il mio circuito potessero non funzionare o per di 
più rompersi visto che condividevano gli stessi segnali.
 
Penso che un modo abbastanza indolore è quello di collegare dei tasti 
momentanei ai segnali di programmazione SPI (a parte il RESET).  Durante 
la programmazione i tasti non vengono premuti e quindi "comandano" i 
segnali dal programmatore.  Si rompe niente se, per un qualche motivo, 
si dovesse premere un tasto?
 
Sul RESET penso che basti un 100k verso Vcc.  Questo dovrebbe andare 
bene sia in programmazione (essendo il RESET un open-drain) sia durante 
il normale funzionamento.
 
 

 
https://dl.dropbox.com/u/2370367/prog.jpg
 
 
Usi strip lunghe per essere sicuro che facciano contatto?  Non si 
rischia di rovinare il via per trascinamento?

 rovinare il via per trascinamento?
 
Se i tuoi vias si possono rovinare per un contatto del genere, ti 
consiglio di cambiare fornitore di pcb   :-)
 
Scherzi a parte, mai avuto alcun problema
 
--
ciao
 Stefano
 
 

 No, ci vuole in Jtag MkII
 
Sicuro?  Leggi qui:
http://www.atmel.no/webdoc/avrdragon/avrdragon.supported_protocols.html
 
 
 


Non conosco il dragon, ero convinto che non avesse un hw abbastanza potente per
il debug ad un costo cosě basso.
Evidentemente mi sbagliavo   :-(
 
--
ciao
  Stefano


ecco, erano proprio questi gli accorgimenti a cui mi riferivo. se adoperi la SPI per qualche periferica ti conviene prevedere la possibilità di sconnetterla per la programmazione