Go Down

Topic: Autoreset, questo sconosciuto (Read 35095 times) previous topic - next topic

menniti


@Menny
Scusa ho anglofizato il tuo nick, non t'incazà :smiley-mr-green:

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
Quote

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.

Quote

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  :smiley-mr-green: 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
Manuale "Arduino e le tecniche di programmazione dei microcontrollori ATMEL"
http://www.michelemenniti.it/manuale_di_programmazione.html
http://www.michelemenniti.it/offerta.html
Articoli ElettronicaIN
http://www.michelemenniti.it/elettronica_in.html

astrobeed


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.

Quote

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.

Quote

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.
Scientia potentia est

menniti

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.
Manuale "Arduino e le tecniche di programmazione dei microcontrollori ATMEL"
http://www.michelemenniti.it/manuale_di_programmazione.html
http://www.michelemenniti.it/offerta.html
Articoli ElettronicaIN
http://www.michelemenniti.it/elettronica_in.html

leo72

@Menni tuttofare:  XD
lo so, dovrò buttarli, mi dispiace tutto qui  :smiley-sweat:

@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.

menniti


@Menni tuttofare:  XD
lo so, dovrò buttarli, mi dispiace tutto qui  :smiley-sweat:

sono un ometto infaticabile  :smiley-mr-green: 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  =(

Quote

@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  :D quindi ben venga qualcosa, magari di esterno a IDE, Optiboot, ecc., che risolva tutti i problemi di tutti.
Manuale "Arduino e le tecniche di programmazione dei microcontrollori ATMEL"
http://www.michelemenniti.it/manuale_di_programmazione.html
http://www.michelemenniti.it/offerta.html
Articoli ElettronicaIN
http://www.michelemenniti.it/elettronica_in.html

astrobeed


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.

Quote

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.

Scientia potentia est

leo72

@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.

astrobeed

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.           */
/*  http://code.google.com/p/arduino/issues/detail?id=368n*/
/* 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.
Scientia potentia est

Maurotec

Quote
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.

Quote
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.

Quote
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.

Quote
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 :smiley-mr-green:

Ciao.

Ciao.

leo72

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.

astrobeed


Quando apri il serial monitor apri il device con il baudrate scelto e con DTR = false, e così la board non si resetta.


E come fai ad aprire il serial monitor dell'IDE senza abbassare DTR ?

Quote

Avrdude conosce circa il DTR tanto che quel codice python viene proprio dal codice di avrdude trasformato in python.


Non ho mai guardato i sorgenti di AVRdude, però non mi risulta che ci sia una opzione da riga di comando che non permette di abbassare DTR, questo va bloccato prima di invocare AVRdude, e non è detto che funzioni perché se AVRdude quando inizializza la seriale abilita i vari segnali di handshaking rimuove anche il blocco imposto prima.

Quote

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.


Vcom è semplicemente il modo generico per indicare una seriale virtuale indipendentemente da come viene vista dal sistema operativo, in Windows hai il pieno controllo di tutte le funzionalità della seriale.

Quote

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).


Si può anche prendere in considerazione una modifica ad AVRDude per fargli bloccare il DTR.
Il problema non è se mettere o meno il bootloader sui micro che programmi, dipende da dove vanno, è il bootloader presente sul micro che costituisce il programmatore stesso.
Scientia potentia est

astrobeed


Che poi c'è da capire anche come Windows, Mac e Linux gestiscono l'accesso alla seriale. Sarà lo stesso?


Come funziona la seriale, non importa se fisica o virtuale, non dipende dal sistema operativo, dipende dal protocollo che è stato sancito tanti anni fa con le varie integrazioni nel tempo per adattarla alle nuove disponibilità hardware.
Sono i sistemi operativi che si devono adattare al protocollo della seriale e non viceversa.

Quote

E' stata modificata per poter far vedere l'Arduino come un programmatore ISP (emulazione dell'STK500v1, mi pare)


Si perché l'emulazione è solo parziale, infatti Arduino con sketch ISP non viene riconosciuto come programmatore da altri software, se viene riconosciuto poi va in errore non appena si inizia a programmare.
Scientia potentia est

Maurotec

Quote
E come fai ad aprire il serial monitor dell'IDE senza abbassare DTR ?

No per l'ide non saprei io mi riferivo al modo correntto per implementare un serial monitor(ho dimenticato di specificarlo che non mi riferivo all'ide di arduino, ma pensavo si capisse dal momento che sto sviluppando software), ed a meno di problemi legati a java e/o al sistema operativo ed ai costi a cui facevi riferimento anche in java dovrebbe essere possibile fare quello che faccio in python. Quanto prima provo con C++ e vediamo come si comporta.

Quote

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.


Ci sarebbe di meglio, avrdudequi è pensato in questo modo dove ogni programmatore ha un file xml che lo descrive, di meglio c'è che introdurre in avrdudequi supporto per i plugin ci vorrebero 3 giorni, in questo modo il plugin descrive in dettaglio il programmatore (sia dati che gui, che protocollo di trasmissione) con un controllo fine sul funzionamento con la gui che cambia in base al programmatore selezionato.

Purtroppo introdurre i plugin non significa farli tutti in 3 giorni ma semplicemente introdurre il caricamento del plugin, scrivere un plugin farlocco per testare. Mentre per ogni programmatore si dovrà scrivere un plugin e quindi bisogna scrivere la documentazione per permettere a terzi di sviluppare plugin. Verrebe fuori una cosa molto bella.

Ciao.

astrobeed


Ci sarebbe di meglio, avrdudequi è pensato in questo modo dove ogni programmatore ha un file xml che lo descrive


Mi ero completamente scordato di AvrdudeGUI, non idea di quanto sia complicato adattarlo alle nostre esigenze, però è sicuramente meglio che partire da 0.
Mi pare che c'è anche SinaProg che fa da GUI per Avrdude, se ben ricordo include pure un calcolatore dei fuse offline, e supporta direttamente Arduino come ISP, sarebbe il caso di fare qualche prova.
Scientia potentia est

Maurotec

Quote
Mi ero completamente scordato di AvrdudeGUI

ahaha, no no, non è un errore di battitura sto parlando di AvrDudeQui.
https://gitorious.org/avrdudequi/avrdudequi

Quote
Mi pare che c'è anche SinaProg che fa da GUI per Avrdude, se ben ricordo include pure un calcolatore dei fuse offline, e supporta direttamente Arduino come ISP, sarebbe il caso di fare qualche prova.

Non lo conosco, mi dai link, tanks.

Ciao.


Go Up