programmazione ISP ATMega8

[pier]

Ciao a tutti.
Sono un nuovo iscritto ed ho sempre programmato gli Atmel con un programmatore parallelo. Nel nuovo progetto che utilizza un ATMega8 vorrei andare di ISP.
Leggendo il manuale del micro mi pare di capire che dopo il reset lo stesso sia settato come SLAVE e SPI abilitato che immagino sia la configurazione che accetta la programmazione ISP. Vedo anche che il fuse SPIEN non è disponibile nella programmazione ISP.
Nel mio progetto posso lasciare totalmente disponibili i pin PB3, PB4 e PB5 mentre il PB2 è previsto come input chiuso a GND con una resistenza (riceve uno switch normalmente aperto). Il PC.6 è dedicato al reset (con condensatore).
Ho una serie di dubbi che vado ad elencare:
Non mi è chiaro se occorra prevedere qualche istruzione a livello software quali il config dell'SPI e/o la sua abilitazione nonchè la gestione del pullup del PORTb.3 (MOSI) e del PORTb.5 (SCK).
Per i primi 2 punti basta settare nelle opzioni del compilatore BASCOM "use hardware SPI" ?
Questa opzione DEVE essere comunque usata nel caso di utilizzo del micro in oggetto nella configurazione SPI standard?
Ci sono possibilità di problemi nei confronti della capacità usata per il reset e per il PB2 così come utilizzato?
Un paio di dubbi ulteriori:
Non essendo disponibile lo SPIEN nella programmazione ISP ed essendo che i settaggi fatti a livello sw intervengono dopo una eventuale programmazione forse potrei usare i pin dedicati di default alla ISP anche come input/output GPIO ma il fatto di non poter disabilitare la SPI non determina comunque l'impossibilità di un simile uso riservando tali pin proprio alla ISP?
Nel caso di una programmazione del RSTDISBL per attivare il reset "interno" e rendere disponibile il PC6 ad altri scopi non rende inutilizzabile la programmazione ISP senza peraltro intervenire sui relativi pin che resterebbero SPI dedicati e costringendo ad eventuali successive programmazioni solo per via parallela?

Grazie a tutti in anticipo
Pier

[deluca]

@Pier,
Per programmare in modalità ISP, non hai bisogno di configurare via sw la spi degli AVR,
ti necessita un programmatore di tipo ISP con il relativo software per la programmazione, collegare i pin della SPI al connettore ISP e avviare la programmazione.
Avviata la programmazione, il micro si "accorge" della presenza di dati sulla SPI e si mette in modalità programmazione.... diciamo che questa è una spiegazione semplicistica, ma è quello che avviene realmente.

Di programmatori ce ne stanno di commerciali, tipo l'avrisp mkII che è originale Atmel e costa una 30-ina di euro, oppure puoi anche autocostruirlo, a te la scelta.
Sul piedino di reset non deve essere collegata alcuna capacità, deve essere inserita invece una resistenza da 10K tra il pin e Vcc.

Una raccomandazione:
stai molto attento ai fuse bits poichè una errata configurazione (es: uso del reset come pin I/O) renderebbe il chip inutilizzabile per altre riprogrammazioni)

[pier]

Vedo che non sono il solo davanti ad un monitor!
Grazie per la cortese e sollecita risposta. Speravo proprio che fosse così ed ora sono più tranquillo.

Mi confermi che debbo stare attento al RSTDISBL e non pensare di utilizzare il reset per altri scopi ma, accidenti, io avevo sempre messo un condensatore verso GND per assicurare il reset all'accensione. Mi confermi che questo è garantito anche con un semplice pullup?

Approfitto della tua disponibilità per chiarirmi altri dubbi utili per il futuro e cioè, come dicevo, è possibile pensare ad utilizzi dei pin ISP dedicati di default anche come GPIO (reset escluso) riconfigurandoli via SW?

Pier

[Leonardo]

Aggiungo solamente che il condensatore sul pin reset preclude la possibilità di Debug tramite DebugWire, è pertanto sconsigliato aggiungerlo. La funzionalità BOD Brown-out Detection se abilitata permette di tenere il reset il micro se la tensione non è sopra una certa soglia.

I pin utilizzati per ISP non vanno riconfigurati, sono utilizzabili normalmente come pin di I/O, eventuali collegamenti al momento della programmazione possono però creare problemi.

Ciao

[pier]

Grazie Leonardo. Ricevuto forte e chiaro!
Userò il BOD (come peraltro ho quasi sempre fatto quando mi serviva usare il pin del reset come I/O).
Perdona se "sono de coccio". Fatta salva l'attenzione ad evitare possibili interferenze in fase di programmazione da quanto collegato, quando dici "non vanno riconfigurati, sono utilizzabili normalmente come pin di I/O" intendi che NON VANNO riconfigurati (nel senso che posso usarli come I/O SOLO rispettando la loro direzione di default (SCK, SS, MOSI e MISO) o possono all'occorrenza esserlo per deciderne la direzione?
Altro quesito: onde evitare input aperti è conveniente utilizzare pullup su questi pin?

Un saluto alla cara Parma (di cui ho solo bei ricordi) da un triste Milano.

P.S. non mi sono ancora del tutto assuefatto alla "goduria" di comunicare in italiano!

[deluca]

I pin utilizzati nella programmazione ISP, ovvero MISO, MOSI e CLK assumeranno lo stato e la direzione indicata nel firmware appena il chip viene resettato,
quindi possono essere riconfigurati tenendo conto delle periferiche ad essi connessi.

E' chiaro che se i pin interferiscono in termine di direzione con altre periferiche è necessario staccare sempre il connettore ISP dopo la programmazione.
Se ad esempio sulle linee x ISP cè collegato un display potrebbe capitare di visualizzare caratteri strani, o veder lampeggiare il cursore ecc ecc.

PS. The most important thing è non collegare all'isp periferiche tipo "rele, motori, attuatori" che cambiando di stato durante la programmazione potrebbero nuocere all'incolumità delle persone.

[Leonardo]

@pier: Con non vanno riconfigurati intendevo dire che non bisogna applicare nessuna istruzione particolari per utilizzarli come I/O, la direzione andrà poi naturalmente impostata e potranno essere utilizzati come Input oppure come Output.

Da http://www.atmel.com/images/doc0943.pdf: Note that the AVR microcontroller will automatically set all its I/O pins to inputs, with pull ups disabled, when Reset is active

Puoi impostare la pull-up interna senza problemi nel tuo firmware, per entrare nella modalità di programmazione il programmatore attiva il reset e tutti i pin di I/O vengono impostati automaticamente come ingressi con pull-up disabilitate, il problema quindi non sussiste.

Ciao

[pier]

Grazie a tutti!!
Ragazzi, siete stati di una efficienza e chiarezza incredibili e vi ringrazio ancora per la disponibilità dimostrata. Ora tutto è chiaro come il sole.
Caro Deluca, ho visto tardi il tuo invito in chat, possibilità assai interessante.

Grazie ancora e alla prossima

Pier

[js-bascom]

preclude la possibilità di Debug tramite DebugWire,

Nel caso del Mega8 no ci sono problemi perche' no esiste il DW pero' il punto e validissimo quando utilizzerai qualcosa di piu' recente come un Mega88 o M168 o M328

non mi sono ancora del tutto assuefatto alla "goduria" di comunicare in italiano!

Io sudo freddo per scrivere in Italiano ma sto imparando di nuovo lentamente.

[pier]

Grande js_bascom!
A ciascuno i propri "sudori" e così puoi comprendere i miei quando parlo inglese. Comunque stai andando alla grande. Complimenti!

Per il DW per quanto mi riguarda è prematuro. Chissà se prima o poi dovrò occuparmene. Continuo ad usare il Mega8 perchè debbo aggiornare un vecchio apparato e recupero parte del vecchio sw inoltre, essendo questo un micro con un buon compromesso tra semplicità, prestazioni e pin, lo trovo mooooolto comodo.

Comunque grazie per le informazioni.

Ma quest'anno nessuno va in vacanza?

Ciao
Pier

[js-bascom]

Chissà se prima o poi dovrò occuparmene

Io non posso iniziare un progetto senza avere un modo di debuggare (che simpatica parola ) il software o hardware.

debugWire lavora bene con i chips piu' piccoli come i Tiny e alcuni Mega come il M88 che e' 100% compatibile con il M8 anche se il software avra bisogno di piccole modifiche che saranno piu' o meno facili secondo come il codice fu scritto dal principio.

VACANZE che bel sogno per me!

[pier]

Beh, ovviamente anche io non posso evitare il debug che è quasi il cuore del progetto ma finora mi è sempre bastata la simulazione di Bascom.

Vi ringrazio della segnalazione di DebugWire.

Caro js, coraggio, prima o poi i sogni si avverano (almeno vale la pena di crederlo) e sappi che ti sono compagno di sventura così forse ti sentirai meno "sfigato"...

Ciao
Pier

[Fagos]

Benvenuto pier,
diciamo che tra sfigati ci si capisce meglio. Un ricordo lontano le vacanze di 15gg.

Certo che l'isp è eccezionale, ma ancora non riesco a rinunciare al sample electronic programmer, http://www.delucagiovanni.com/files/PROG%20PAR.pdf
finchè avrò per le mani un pc con una parallela penso che difficilmente riuscirò a tradirlo.
tempo fa seguii i consigli di deluca e da allora non ho mai bruciato un micro.

ciao a tutti e buone vacanze

[pier]

Caro Fagos, anche io sono un appassionato della prog parallela che non mi ha mai tradito ma ora, anche se cerco di mantenere vivo un vecchio PC con porta parallela con la respirazione bocca a bocca, questo comincia a scricchiolare e poi ci sono i collaboratori che questa possibilità proprio non l'hanno e quindi ob torto collo... Mah, magari scopro una cosa carina seppure impone qualche complicazione almeno hardware.

Se ti può consolare le mie ultima vacanze sono di 2 anni fa (e ad agosto del 2012 ho fatto 2 traslochi!!!!) mentre per quest'anno speriamo di farci stare 5 o 6 gg di montagna anche se io amo più il mare. Oggi ho appena trangugiato un toast e via così fino a quando?
Dicono che averci il lavoro oggi è una fortuna (ma se almeno ti pagassero).

Quel che ti frega è la passionaccia!!

Ciao