Salve a tutti,
qualche tempo fa ho avuto la sfortuna di corrompere il bootloader dell'arduino mega 2560, infatti continuo a ricevere questi messaggi quando provo a caricare degli sketch.
avrdude: stk500v2_ReceiveMessage(): timeout
avrdude: stk500v2_getsync(): timeout communicating with programmer
Purtroppo non ho alcun programmatore, però sono da poco in possesso di un raspberry pi 2 model b, e leggendo questo post ho pensato di provare ad adattare il procedimento per il Mega 2560.
Quindi ho collegato i rispettivi pin del raspi con i pin della porta ICSP dell'arduino, come potete vedere dall'immagine in allegato.
Se provo a lanciare il seguente comando dal terminale (non sono sicuro se questo comando sia valido...):
se guardi la foto lo vedi, se leggi all'inizio c'e scritto.
la rasp va a 3.3v la tua scheda a 5v....vai sul tuo store di fiducia e comprane uno, vanno dai 3€ in su.
al momento avevo provato ad "alzare" il voltaggio con dei transistor bc337, ma l'output si stabilizza intorno ai 4.4V, penso sia ancora troppo poco visto che ricevo lo stesso errore dei post precedenti. Proverò a cercare questi adattatori e farò sapere se funzionerà.
Arduino should normally be powered by 5V, but Raspberry Pi needs 3.3V on GPIO pins, so we will run the Arduino at lower voltage. It should be fine for the programming.
scusa avevo letto male, puoi anche senza convertitore, basta che alimenti arduino a 3.3v bypassando il regolatore.
dovrebbe andare lo stesso, quelli sono i valori testati e perfettamente funzionanti.
ma dovrebbe sopportare amche i 3.3v, prova tanto danni non ne fai.
vbextreme:
dovrebbe andare lo stesso, quelli sono i valori testati e perfettamente funzionanti.
ma dovrebbe sopportare amche i 3.3v, prova tanto danni non ne fai.
16 MHz a 3.3V sono tanti per un AVR, non è questione di overclock, è questione di limiti fisici, provare non costa nulla però c'è il rischio reale di brickare il micro se qualcosa va storto durante la scrittura del bootloader.
Comunque la questione è facilmente risolvibile, i pin della PI escono a circa 3.2V, livello sufficiente per essere interpretato come 1 logico da un ATmega2560 @ 16 MHZ (Valore minimo 0.6*Vcc).
Il problema è su MISO che è un input sulla PI e 5V sono troppi, c'è il reale rischio di danneggiare il GPIO, per risolvere basta un partitore resistivo, 10k + 18k, che riduce i 5V a 3.3V
è uscito un avr 2560 con tensione dai 2.7 ai 5 questo dopo che vari underclocker ne hanno testato l'efficenza, ovvio che l'hanno perfezionato.
non è troppo ma sicuramente non è una garanzia, ripeto, non danneggi nulla anche se il bootloader venisse scritto male potresti benissimo reinviarlo alri milioni di volte.
L'underclocking ed l'overclocking non sono mai stati pericolosi.
vbextreme:
è uscito un avr 2560 con tensione dai 2.7 ai 5 questo dopo che vari underclocker ne hanno testato l'efficenza, ovvio che l'hanno perfezionato.
Vedo che continui a sentenziare su questioni hardware senza sapere come stanno le cose esattamente, poco male a costo di sembrare antipatico ci penso io a correggere le cavolate che dici.
Basta prendere il data sheet del 2560, la versione più aggiornata è del Febbraio 2014, per scoprire come stanno esattamente le cose, ovvero allo stesso identico modo di quando è uscito l'ATmega2560 per quanto riguarda l'alimentazione e il clock.
Capitolo 31, paragrafo 2 (Speed Grades) del datasheet, c'è scritto chiaramente, con tanto di grafico, che a 2.7 V è possibile un clock massimo di 8 MHz, 16 MHz sono possibili solo con almeno 4.5V, con tensioni comprese tra 2.7V e 4.5V il clock massimo varia in modo lineare tra 8 e 16 MHz.
Basta fare un semplice conto per scoprire che a 3.3V il clock massimo ammesso è poco più di 10.5 MHz, arrivare a 16 MHz equivale ad un overclock del 53%, che non è poco.
Che non rischi di non danneggiare il micro è leggenda metropolitana, il rischio di fare danni c'è eccome, in particolare di brickare il micro perché quando vai caricare il bootloader vendono scritti anche i fuse e se l'operazione fallisce, facile se lo fai con clock troppo alto in funzione della tensione di alimentazione, puoi dire ciao ciao al micro visto che senza un programmatore HV non puoi risolvere,
Anche ammesso che disponi di un programmatore HV c'è il piccolo problema che il micro va dissaldato, montato su apposito zoccolo, riprogrammato e poi rimontato sulla scheda, tutte cose che l'Arduinista medio sa fare benissimo e dispone delle necessarie, costose, attrezzature oltre che l'indispensabile preparazione tecniche per svolgere le varie fasi del unbrick.
@astro stai sempre troppo dalla parte del sicuro, l'overclocking si fa a mano nel vero senso della parola, ci appoggi una bella manina sopra e fino anche riesci a tenerla tutto OK, subito dopo che l'hai levata Levi l'alimentazione.
si sta parlando poi di qualche minuto e non ora!
il datasheet dice che non garantisce tali velocità non che non ci possa arrivare!
vbextreme: @astro stai sempre troppo dalla parte del sicuro, l'overclocking si fa a mano nel vero senso della parola, ci appoggi una bella manina sopra e fino anche riesci a tenerla tutto OK,
Io non sto dalla parte del sicuro, sto dalla parte di chi sa perché ha studiato e perché ha verificato strumentalmente, in prima persona, come stanno le cose.
Poi se vuoi credere che le marmotte incartano la cioccolata liberissimo di farlo, però sei pregato di tenertelo per te, con certi consigli rischi di far buttare decine di Euro a che ti ascolta.
Qui non stiamo parlando di provare se il micro funziona a 3.3V con clock a 16 MHz, il fatto che magari fa il boot non significa che poi funziona sul serio al 100%, stiamo parlando di andare a scrivere i fuse, operazione molta delicata sugli AVR, con un clock troppo alto per la tensione di alimentazione, cosa decisamente stupida da fare e ad elevato rischio brick.
In tutti i casi il problema non esiste visto che basta usare un banale partitore resistivo, come ho già spiegato, per risolvere la questione 3.3V - 5V.
Poi se la PI riesce realmente a fare le veci di un programmatore ISP hardware avrei qualche dubbio in merito, più che altro per la precisione richiesta sulle varie temporizzazioni, cosa facile da ottenere con una MCU, molto difficile, se non impossibile, da ottenere con un S.O. non realtime.
non ho una mega 2560, quindi non so riguardo al dissaldare, però alcuni mesi fa (in pieno periodo attiny85) avevo trovato un link che dava delle istruzioni riguardo a un programmatore HV fai da te, lo tenevo li giusto in caso di cassate, e fortunatamente non ho mai dovuto usarlo, comunque il link è questo
@boschi : ... ma ritieni veramente che l'utente medio di questo forum sia in grado di dissaldare, riprogrammare e risaldare (... il tutto senza fare danni) un componente come questo ? ? ? :o :o :o
gpb01: @boschi : ... ma ritieni veramente che l'utente medio di questo forum sia in grado di dissaldare, riprogrammare e risaldare (... il tutto senza fare danni) un componente come questo ? ? ? :o :o :o
Inoltre quello schema va bene solo per i Tiny e non certo per un Atmega 2560, ma nemmeno per il 328.
astrobeed:
Inoltre quello schema va bene solo per i Tiny e non certo per un Atmega 2560, ma nemmeno per il 328.
... infatti ... meglio investire un po' di più (circa 60 €) ma prendersi un vero programmatore (... e strumento per il debug) come l'AVR Dragon
The AVR Dragon sets a new standard for low cost development tools for 8-bit and 32-bit AVR devices with On Chip Debug (OCD) capability. It can perform a symbolic debug on all devices with OCD with SPI, JTAG, PDI (selected devices), high voltage serial programming, parallel programming, and aWire modes, and supports debugging using SPI, JTAG, PDI interfaces.