Ciao MT, in poche parole:
usando Arduino come ISP a volte ci si scontra con questo problema dell'autoreset che impedisce di caricare sun un chip stand alone il bootloader o uno sketch qualsiasi. Il problema è legato al singolo hardware, si può verificare indifferentemente su una UNO o 2009 o anche su una compatibile, se si verifica, su quella board si verifica sempre. P.es. la mia UNO funziona senza problemi, la mia 2009 invece richiede la disabilitazione.
L'intervento hardware non è invasivo e serve comunque solo per questi casi.
Se ci fosse un flag software sarebbe certamente comodo, ma dubito che l'IDE lo preveda, invece questo nuovo optiboot "scoperto" da leo sembra risolvere il problema sulle UNO (almeno sulla sua), ma lo lascia sulle 2009, il cui bl è diverso.
Spero di esserti stato utile.
MauroTec:
perchè è necessario resettare arduino board sempre è comunque?
Infatti non è necessario, serve resettare solo per avviare il bootloader o per sbloccare una condizione di crash o loop eterno.
In effetti il DTR messo alto fà parte della prodedura di riconoscimento fatta da avrdude quando comunica con la board.
No, Avrdude non sa nemmeno cosa sia DTR, è un segnale standard della RS232 ed è gestito in automatico dall'hardware/software della seriale, non importa se è una vera com o una seriale virtuale, inoltre la stato alto è quello normale per DTR anche se la seriale non è in uso.
Dalla lettura dei post capisco che quando una board arduino viene usata come programmatore ICSP, questo auto reset su questa board non è gradito.
Il problema autoreset ISP a quanto pare si pone solo con la UNO, sulla 2009 non c'è o comunque è raro che si verifichi, dovrebbe essere legato alle diverse temporizzazione usate dall'optiboot e dal bootloader della 2009, non ho indagato a fondo su questa cosa.
In realtà il vero motivo per bloccare l'autoreset è l'uso pratico di Arduino quando serve comunicare tramite la porta seriale USB, ogni volta che la apri Arduino viene resettato perché DTR cambia di stato.
Quindi se ho capito bene, lato software basterebbe mettere nella configurazione dell'ide un flag, es autoreset.disable = true.
Non è così semplice, o meglio sarebbe possibile farlo sulla UNO visto che l'USB è gestita da un micro tramite il quale sarebbe possibile gestire il reset in diverso modo, p.e. tramite uno specifico comando inviato dall'IDE e non tramite un segnale della RS232.
Quanto detto mi fa pensare al fatto che il programma ICSP da mettere su arduino non prevede l'uso di un bootloader, cioè non ha necessità di "switchare" tra bootloader e user code, ma dall'altro lato leggo che per la uno board il nuovo bootloader risolve il problema.
Ribadisco quanto sopra, la questione ISP è secondaria, il vero problema è che l'autoreset resetta Arduino ogni volta che apri la seriale virtuale indipendentemente dal fatto che lo programmi o meno, per verificarlo basta che apri il terminale seriale mentre gira uno sketch e puoi constatare da solo come Arduino resetti ogni volta che lo fai.
Volendo si può bypassare la questione reset ogni volta che si apre la Vcom da un eventuale programma utente che riceve i dati da Arduino, ma non è una cosa semplicissima da mettere in atto e non è detto che il linguaggio di programmazione lo permetta.
Rimane comunque il fatto che spesso e volentieri la verifica/ricezione dati da Arduino viene fatta tramite il terminale dell'IDE o altro programma emulazione terminale che resettano sistematicamente Arduino ogni volta che si apre la comunicaizone.
La cosa è risolvibile lato software evitando di abilitare il DTR, quando si sta usando la board con il programma ICISP?
Si se sai come farlo e se disponi dei giusti strumenti di lavoro software, ma varrebbe solo per un software utente e non per l'IDE.
Ci sarebbe da vedere se questo segnale deve comunque essere cambiato perchè previsto dal protocollo implementato dal programma ICISP, se fosse così non c'è verso di aggire lato software, se non modificando il bootloader come sembra sia stato fatto per l'optiboot, anche se la cosa non mi convince.
Anche il bootloader non sa cosa sia DTR, e non gli serve saperlo, non esiste nessuna modifica al bootloader che può risolvere la questione visto che DTR altro non fa che portare il pin reset a 0 logico, non puoi bloccare l'autoreset dal bootloader.
Ciao Astrobeed, il mio penultimo intervento richiede la tua opinione, l'ultimo invece contrasta (per "esperienza") con un paio di tuoi punti, riguardo il problema con la 2009 (mie prove) e riguardo la questione dell'optiboot (almeno da quanto sostiene leo nel topic che ha aperto un paio di giorni fa).
Mi dai questi chiarimenti?
Grazie
Fatta la prova con il condensatore da 1uf, funziona perfettamente e la risposta del reset è praticamente identica a quella con il condensatore da 10 uf, idem per DTR.
Se metto una resistenza da 100 ohm in serie al condensatore per limitare il picco di corrente su DTR, si arriva al limite sul reset, nel mio caso ho rilevato 0 logico per 1.2 us, e infatti Arduino viene programmato, il che vuol dire che a seconda delle varie tolleranze ci si può trovare sia con l'autoreset bloccato che funzionante.
Tenuto conto che la resistenza in serie al condensatore era solo una precauzione al limite delle "pippe mentali", in realtà non ci sono problemi se non c'è, se proprio si vuole metterla deve essere al massimo da 33 ohm.
menniti:
Mi dai questi chiarimenti?
Partendo dal fatto che dei test su qualche UNO e qualche 2009, che per giunta forniscono risultati completamente opposti, ha valenza statistica 0 penso che a questo punto se non si fa una analisi attenta e dettagliata del fenomeno è impossibile dire la vera causa e quando è realmente necessario bloccare l'autoreset con lo sketch ISP.
La modifica all'optiboot che risolverebbe la questione non l'ho controllata, anzi non ho nemmeno guardato se è disponibile il sorgente, per il semplice motivo che non mi interessa, però al massimo risolve la questione ISP, ma non il vero problema del reset ogni volta che si apre la Vcom come ho puntualizzato qualche post sopra.
L'Optiboot v.4 risolve il problema dell'autoreset usando lo sketch ArduinoISP. E' disponibile anche il sorgente: se vai al thread che ho linkato nel mio post, puoi scaricartelo e guardartelo.
A differenza tua, però, che punti a disabilitare l'autoreset su Vcom, il mio problema era appunto trovare un modo per far funzionare quello sketch senza condensatori. E con l'Optiboot v.4 risolvo.
OT:
gli Attiny sono andati, non sono riuscito a capire il motivo. Gli attacchi li ho fatti come sempre, ormai in automatico da quante volte ho collegato i pin. Il condensatore tra +5V e RST l'ho provato anche per programmare un Atmega328 e con quello non ho avuto problemi, mentre di Attiny ne ho "fritti" 2 su 2.
Ciao Atrobeed ricordi questo post avrdude -p m328p -c arduino -b 19200 -P /dev/ttyUSB0 -t - #11 by Maurotec - Generale - Arduino Forum
No, Avrdude non sa nemmeno cosa sia DTR, è un segnale standard della RS232 ed è gestito in automatico dall'hardware/software della seriale, non importa se è una vera com o una seriale virtuale, inoltre la stato alto è quello normale per DTR anche se la seriale non è in uso.
Allora, vediamo se riusciamo a capirci, concordo con quanto dici, ma obbietto dicendo la seguente:
La seriale tipica dei pc è molto differente dalla comunicazione seriale implementate es sulla 2009, mancano alcuni segnali, cioè ci sono ma non vengono collegati al micro, tranne DTR che viene collegato come hai detto tu.
Il DTR come vedi da codice python è impostabile, è posso assicurarti che se non eseguo la sequenza:
print "Clear DTR and RTS to unload the RESET capacitor"
ser.setRTS(False)
ser.setDTR(False)
print "attende x tempo"
time.sleep(1)
print "Set DTR and RTS back to high"
ser.setRTS(True)
ser.setDTR(True)
Il bootloader se mi risponde mi dice cose strane insomma non mi dice che è in sync.
Quindi a raggion veduta il DTR è gestibile, lo posso mandare su o giù prima di aprire il device, occhio che qui si può capire male, diciamo che posso aprire il device file impostando il DTR = false, dopo aver aperto il device posso modificare lo stato di tutti i flags, se lo posso fare in python lo si può fare in C++ e in java.
C'è solo una cosa che obbliga ad aprire un device a chiuderlo e riaprirlo ed è il baudrate, in quanto non mi risulta sia possibile modificarlo a caldo.
@Menny
Scusa ho anglofizato il tuo nick, non t'incazà 
Allora avevo capito bene, non si capisce perchè in alcuni casi l'autoreset rompe ed in altri no.
Però non posso indagare sulle reali cause che fanno fallire l'operazione di scrittura, non ricordo se nel connettore
ICISP arrivi il reset, se si probabilmente è qua il problema, se per ipotesi prima di scrivere il micro su breadboard il programma ICISP invia il reset a questo pin e questo è connesso al pin reset di arduino questo si autoresetta.
Io l'ho sparata perchè non posso fare questi esperimenti al momento.
Ciao.
leo72:
L'Optiboot v.4 risolve il problema dell'autoreset usando lo sketch ArduinoISP. E' disponibile anche il sorgente: se vai al thread che ho linkato nel mio post, puoi scaricartelo e guardartelo.
Appena ho un attimo di tempo gli do uno sguardo.
gli Attiny sono andati, non sono riuscito a capire il motivo. Gli attacchi li ho fatti come sempre, ormai in automatico da quante volte ho collegato i pin. Il condensatore tra +5V e RST l'ho provato anche per programmare un Atmega328 e con quello non ho avuto problemi, mentre di Attiny ne ho "fritti" 2 su 2.
Questo è un bel mistero, però è ancora più strano che riesci a vederli dal programmatore e riprogrammarli, il danno che illustri non dovrebbe permettere questa cosa.
Oltretutto l'Optiboot v4. è anche più "compatto" rispetto a quello di serie. Inoltre risolve il problema dell'errato upload di sketch più grandi di ca. 30 kB nonostante lo spazio sul micro (32256 byte) permetterebbe l'operazione.
Guarda, se non sai spiegartelo tu, figurati io XD
So solo che è comparso un segnale fisso HIGH di 4,80V sul 7° piedino (quello collegato al pin 13 dell'Arduino in modalità ISP) e che la tensionein uscita su un pin impostato su HIGH è di 4,80V ma non riesce a far illuminare un LED, immagino quindi che la corrente che ne esce sia ben sotto alla richiesta media di un LED (15/20 mA). Curiosamente anche cambiando piedino di output il risultato non cambia.
Il LED non è bruciato perché ho provato a cambiarlo e dà sempre lo stesso effetto. Ho cambiato anche resistenza ed addirittura anche a collegare il LED senza resistenza ma la luce prodotta è pochissima (si intravede appena in condizioni di scarsa illuminazione). Ho notato inoltre stamattina una tensione di 4,80V anche in uscita dal pin di reset! Quindi in pratica il pin è "forato" e perde corrente da tutte le parti 
leo72:
OT:
gli Attiny sono andati, non sono riuscito a capire il motivo. Gli attacchi li ho fatti come sempre, ormai in automatico da quante volte ho collegato i pin. Il condensatore tra +5V e RST l'ho provato anche per programmare un Atmega328 e con quello non ho avuto problemi, mentre di Attiny ne ho "fritti" 2 su 2.
se sei sicuro che sono morti allora RIP 8) altrimenti, ripeto, conservali.
MauroTec:
@Menny
Scusa ho anglofizato il tuo nick, non t'incazà
E perché dovrei? già lo avevi troncato d un po' togliendo "ti", va a finire che fra poco scrivi solo "@" ed io capisco che "ce l'hai" (nel senso che ti rivolgi...) con me XD
Allora avevo capito bene, non si capisce perchè in alcuni casi l'autoreset rompe ed in altri no.
Io ho capito che è solo una questione di sincronismo, cioè in base al fatto se avviene qualche istante prima o dopo il momento cruciale, quindi una questione di tolleranza dei componenti hardware credo. Dovrei fare un po' di prove incrociate col DSO per vedere cosa succede con UNO (che mi funziona) e con 2009 (che non mi funziona), ma la differenza tra le due board potrebbe vanificare tutto, l'ideale sarebbe provare due board indentiche, una funzionate e l'altra no.
Però non posso indagare sulle reali cause che fanno fallire l'operazione di scrittura, non ricordo se nel connettore
ICISP arrivi il reset, se si probabilmente è qua il problema, se per ipotesi prima di scrivere il micro su breadboard il programma ICISP invia il reset a questo pin e questo è connesso al pin reset di arduino questo si autoresetta.
Io l'ho sparata perchè non posso fare questi esperimenti al momento.
Ciao.
Temo che in effetti questo sia un colpo di lupara la connessione ISP nelle nostre prove funziona "in uscita" e non "in entrata", e il pin reset di Arduino non viene usato in alcun modo, pur essendo presente sul connettore ISP
MauroTec:
Allora, vediamo se riusciamo a capirci, concordo con quanto dici, ma obbietto dicendo la seguente:
La seriale tipica dei pc è molto differente dalla comunicazione seriale implementate es sulla 2009, mancano alcuni segnali, cioè ci sono ma non vengono collegati al micro, tranne DTR che viene collegato come hai detto tu.
Il fatto che non tutti i segnali di handshake della 232, e sono tutti disponibili sul FTDI, non sono collegati al micro non vuol dire nulla, semplicemente non viene usato l'handshake hardware durante la comunicazione, ma questo non significa che i segnali in OUT dal FTDI non cambiano di stato in accordo a quanto previsto dal protocollo a meno che non siano stati inibiti a monte da software.
Quindi a raggion veduta il DTR è gestibile, lo posso mandare su o giù prima di aprire il device
Mica ho detto che non si può fare, ho detto che tocca saperlo fare e che non tutti i linguaggi di programmazione permettono di farlo nativamente, spesso servono plugin/ocx aggiuntivi che non sempre sono free, anzi spesso costano cari.
non ricordo se nel connettore ICISP arrivi il reset, se si probabilmente è qua il problema, se per ipotesi prima di scrivere il micro su breadboard il programma ICISP invia il reset a questo pin e questo è connesso al pin reset di arduino questo si autoresetta.
Sul connettore ISP c'è anche il reset perché viene utilizzato durante la procedura ISP, lo sketch ISP per resettare il micro da programmare usa un pin di Arduino, non mi ricordo quale, dedicato a questa funzione.
Il reset di Arduino rimane sempre e comunque dipendente da DTR , il motivo per cui su certe schede, a quanto pare sia UNO che 2009, non si riesce a programmare tramite lo sketch ISP è che non appena AVRdude inizia a parlare con l'ATmega quest'ultimo viene resettato perché DTR va basso in concomitanza con l'apertura della porta Vcom, come dimostrato dalle misure che ho fatto con il DSO.
Se il timeout previsto da AVRdude per ottenere una risposta dal programmatore (Arduino con sketch ISP) viene raggiunto per effetto della latenza introdotta dal reset ecco che scatta l'errore "not sync" o altro errore che blocca il tutto.
Volendo si può ovviare definitivamente al problema programmatore ISP, senza usare "trucchi hardware e/o bootloader non ufficiali, con un programma su misura per caricare il bootloader, ma volendo anche degli sketch, che invia la corretta riga di comando ad AVRdude bloccando nel contempo DTR.
In pratica un programma mirato alla sola gestione della funzionalità programmatore ISP dove inserire in un menù, configurabile da file .ini o xml, i vari tipi di bootloader da caricare e le varie tipologie di schede/micro.
Alla fine si otterrebbe un vero e proprio programmatore ISP dedicato, con un occhio di riguardo al mondo Arduino, facilmente realizzabile con pochi soldi su una scheda standalone, rammento che lo sketch ISP prevede anche l'uso di tre led per segnalare le varie fasi della programmazione.
Il pin di Arduino che gestisce il reset dello stand alone è il 10. A seguire 11-12-13 pilotano miso-mosi-sck, ora non ricordo in che combinazione; in effetti lo sketch ArduinoISP prevede 3 led, li ho provati una delle prime volte, poi in effetti c'erano quelli di Arduino che funzionavano in contemporanea, più o meno.
Lo schedino per la programmazione stand alone in effetti sarebbe semplice da realizzare, potrei occuparmene io, è l'unica cosa che riuscirei a fare da solo, certo poi ci vorrebbe il software per vostra gentile concessione di tempo.
@Menni tuttofare: XD
lo so, dovrò buttarli, mi dispiace tutto qui 
@astrobeed:
non credo che la questione stia come dici. L'Optiboot infatti risolve il problema dell'autoreset in maniera software. Sembra infatti che l'autoreset in fase di programmazione non dipenda tanto dal segnale di apertura della seriale ma da un errato dialogo tra Atmega8U2 e Optiboot v.2 (quello di "serie" dell'Arduino).
La procedura dovrebbe essere: avrdude inizia a dialogare con l'Atmega8U2; questo, accortosi che si sta richiedendo una programmazione del chip, invia un reset al micro. Il micro, resettato, esegue per primo l'Optiboot. L'Optiboot a questo punto risponde caratteri errati, e ciò pare che poi porti ad un errore del processo.
Da quel che ho letto su quel thread che ho linkato dove si trova l'Optiboot v4., questo semplicemente risponde con i "giusti" caratteri permettendo quindi di eseguire la procedura di riprogrammazione della Flash.
leo72:
@Menni tuttofare: XD
lo so, dovrò buttarli, mi dispiace tutto qui
sono un ometto infaticabile insisto, ma li hai visti friggere, bollire, evaporare, fetore di plastica fusa o che? non potresti semplicemente aver "scassato" un fuse? Se non mi dai una risposta certa devo insistere per farteli conservare, e se non hai la pazienza di aspettare mandali a me, pago io, ormai è una questione... Se invece sei certo che sono f....i piangi amico mio, sulla loro triste sorte, ma nn farti cruccio, non potevi agire diversamente, non hai alcuna colpa, rimetti la tua coscienza a posto =(
@astrobeed:
non credo che la questione stia come dici. L'Optiboot infatti risolve il problema dell'autoreset in maniera software. Sembra infatti che l'autoreset in fase di programmazione non dipenda tanto dal segnale di apertura della seriale ma da un errato dialogo tra Atmega8U2 e Optiboot v.2 (quello di "serie" dell'Arduino).
La procedura dovrebbe essere: avrdude inizia a dialogare con l'Atmega8U2; questo, accortosi che si sta richiedendo una programmazione del chip, invia un reset al micro. Il micro, resettato, esegue per primo l'Optiboot. L'Optiboot a questo punto risponde caratteri errati, e ciò pare che poi porti ad un errore del processo.
Da quel che ho letto su quel thread che ho linkato dove si trova l'Optiboot v4., questo semplicemente risponde con i "giusti" caratteri permettendo quindi di eseguire la procedura di riprogrammazione della Flash.
Il problema è, se ho ben capito, ch ci vorrebbe una versione idonea anche per il bl della 2009, altrimenti samo egoisti 
quindi ben venga qualcosa, magari di esterno a IDE, Optiboot, ecc., che risolva tutti i problemi di tutti.
leo72:
non credo che la questione stia come dici. L'Optiboot infatti risolve il problema dell'autoreset in maniera software.
Solo per la questione ISP, sicuramente hanno ritoccato i tempi di latenza, devo verificarlo, per quanto riguarda il reset quando apri la Vcom sicuramente c'è ancora.
Sembra infatti che l'autoreset in fase di programmazione non dipenda tanto dal segnale di apertura della seriale ma da un errato dialogo tra Atmega8U2 e Optiboot v.2 (quello di "serie" dell'Arduino).
Le cose stanno in modo diverso da come pensi, il firmware presente sul 8u2 è solo un device CDC per emulazione seriale, sono disponibili i sorgenti ed è facile verificare questa cosa, non ha nessun dialogo con AVRdude, si limita a fare quello per cui è stato programmato, cioè un surrogato del FTDI.
Se provi a monitorare con un led collegato tra gnd e il segnale DTR, prima del condensatore da 100 nf, puoi vedere da solo come vada a 0 logico non appena apri la Vcom e ci rimane per tutto il tempo che è aperta, oppure come va a 0 logico per circa 120 ms (un lampeggio veloce) quando inizi a fare l'upload dello sketch, poi torna a 1 e quindi nuovamente a 0 per pochi ms per due o tre volte e quindi a 0 fisso per tutta la durata del trasferimento dati.
@Menny:
no, il problema è che io fisicamente non li ho visti né friggere né divenire rossi né lievitare sopra alla breadboard. Semplicemente avevo l'Attiny che faceva lampeggiare un LED, ho mandato un'altra volta lo sketch del Blink ed il micro ha iniziato a comportarsi in quel modo. Ho provato anche a riprogrammare tutti i fuse con il programmatore esterno ma nulla. Ed il secondo micro idem.
L'unica è provare a resettarli ad alta tensione. Anzi, a proposito, mi servirebbe lo schemettino del tuo programmatore HV, se puoi.
@Astro:
beh, qui mi fermo perché tecnicamente non so.
Ed ecco la risposta a perché la nuova versione dell'optiboot funziona con lo sketch ISP, direttamente dai commenti in testa al sorgente :
- Edit History: /
/ /
/ 4.4 WestfW: add initialization of address to keep /
/ the compiler happy. Change SC'ed targets. /
/ Return the SW version via READ PARAM /
/ 4.3 WestfW: catch framing errors in getch(), so that /
/ AVRISP works without HW kludges. /
/ Google Code Archive - Long-term storage for Google Code Project Hosting.
/* 4.2 WestfW: reduce code size, fix timeouts, change /
/ verifySpace to use WDT instead of appstart /
/ 4.1 WestfW: put version number in binary. */
In particolare questa riga:
"catch framing errors in getch(), so that AVRISP works without HW kludges."
traduco in Italiano per chi non ha dimestichezza con l'inglese:
"individuati errori di framing nella getch(), così ora AVRISP funziona senza ricorrere ad hardware esterno"
La funzione getch(), nell'optiboot, è quella che legge i byte in arrivo sulla seriale, devo fare un controllo incrociato tra questa versione dell'optiboot e quella precedente per capire cosa hanno modificato esattamente in questa funzione e perché un reset all'inizio della transazione, che c'è anche con l'attuale release, causava errori di framing (lunghezza del pacchetto dati ricevuto non conforme a quanto atteso).
Inoltre le varie modifiche riguardano sopratutto il timing in generale e la temporizzazione del watchdog, se è come penso questa versione dell'optiboot ora dovrebbe funzionare senza problemi anche sulla 2009.
Mica ho detto che non si può fare, ho detto che tocca saperlo fare e che non tutti i linguaggi di programmazione permettono di farlo nativamente, spesso servono plugin/ocx aggiuntivi che non sempre sono free, anzi spesso costano cari.
Avevo inteso diversamente, cioè che fosse una cosa non modificabile da software, quello che mi dici mi suona nuovo in quanto non conosco java e windows e quindi non so se per java e windows è necessario sborsare denaro per fare quello che ho fatto io con python.
Alla luce di quanto mi hai detto la cosa sarebbe da implementare (linguagio, OS ecc permettendo) in questo modo:
Quando apri il serial monitor apri il device con il baudrate scelto e con DTR = false, e così la board non si resetta.
Quando devi dialogare con il bootloader devi chiudere il device file e riaprirlo con baud supportato dal bootloader e con la procedura DTR = true. Avrdude conosce circa il DTR tanto che quel codice python viene proprio dal codice di avrdude trasformato in python. Tutto questo sia chiaro vale solo per OS Linux Fedora 12, per windows e altro non mi pronuncio perchè ignorante.
Solo per la questione ISP, sicuramente hanno ritoccato i tempi di latenza, devo verificarlo, per quanto riguarda il reset quando apri la Vcom sicuramente c'è ancora.
Quando dici Vcom, ti riferisci genericamente alla virtual com, oppure alla com di windows, no perchè potrebbe essere che su windows il DTR va alto appena apri la porta e non c'è modo di intervenire come faccio con python.
Volendo si può ovviare definitivamente al problema programmatore ISP, senza usare "trucchi hardware e/o bootloader non ufficiali, con un programma su misura per caricare il bootloader, ma volendo anche degli sketch, che invia la corretta riga di comando ad AVRdude bloccando nel contempo DTR.
Purtroppo non c'è modo di intervenire dall'esterno per parametrizare avrdude per bloccare il DTR, e l'unica è quella di sistemare le cose in avrdude o nel bootloader. Oppure togliere il booloader totalmente e flashare il micro con Arduino ISP, sempre che si possa fare (credo di si).
Approfitto per chiedere la riga di comando di avrdude per flashare con Arduino ISP, alcuni esempi con le varianti di argomenti opzionali che la implemento in avrdudequi, così se c'è qualche volontario che si trova su linux può provare se funziona.
E perché dovrei? già lo avevi troncato d un po' togliendo "ti", va a finire che fra poco scrivi solo "@" ed io capisco che "ce l'hai" (nel senso che ti rivolgi...) con me smiley-lol
Non per averlo abbreviato "manni", ma per averlo aglofizato (sempre che questo termine esista), insomma la tua avversione con l'inglese, tutto è in inglese ora pure il mio nick, in questo senso.
Però dai suona bene Hi Manny, policeman are only chat and distinctive
Ciao.
Ciao.
Che poi c'è da capire anche come Windows, Mac e Linux gestiscono l'accesso alla seriale. Sarà lo stesso?
Si può anche intervenire sull'avrdude, ci sono i sorgenti. Difatti la versione distribuita con l'IDE di Arduino è patchata (è la 5.04 di qualche anno fa). E' stata modificata per poter far vedere l'Arduino come un programmatore ISP (emulazione dell'STK500v1, mi pare).
Infine, non si può flashare un micro senza bootloader montandolo sull'Arduino. L'Arduino è strutturata in modo che ci sia questo dialogo fra il bootloader ed il chip ausiliario (FTDI o 8U2). Puoi però usare l'Arduino per programmare un Atmega esterno, con o senza bootloader.