programmare il 644 ... ma come????

Deduco che arrivi l'alimentazione dal convertitore, giusto?
Allora il punto in questione è il (2). Il registro MCUSR del microcontrollore registra la causa del reset.
Se il riavvio è dovuto ad una causa esterna, viene lanciato lo sketch utente. Il primo avvio ricade in questo caso.
Quindi, collegando il convertitore ma non programmando, il bootloader salta al programma senza mettersi in ascolto sulla seriale.

2 - apro uno sketch sull'IDE e lo invio al micro (ti confermo che questa operazione inizia con un reset)
vedo i lampeggi del LED sul pin 2, a seguire solo tre lampeggi del TX del convertitore (quello collegato all'rx del micro).

In questo caso il bootloader continua dal punto 3).
Fa quindi lampeggiare i led, apre la seriale e si mette in ricezione.
Le operazioni che seguono sono in risposta ai comandi che il bootloader riceve da avrdude.

Servono altri dettagli?

Allora il punto in questione è il (2). Il registro MCUSR del microcontrollore registra la causa del reset.
Se il riavvio è dovuto ad una causa esterna, viene lanciato lo sketch utente. Il primo avvio ricade in questo caso.
Quindi, collegando il convertitore ma non programmando, il bootloader salta al programma senza mettersi in ascolto sulla seriale.

Il problema potrebbe essere legato al fatto che non riesce a distinguere la causa del reset e passi sempre e comunque ad eseguire codice utente.
Potrebbe?

Ciao

MauroTec:

Allora il punto in questione è il (2). Il registro MCUSR del microcontrollore registra la causa del reset.
Se il riavvio è dovuto ad una causa esterna, viene lanciato lo sketch utente. Il primo avvio ricade in questo caso.
Quindi, collegando il convertitore ma non programmando, il bootloader salta al programma senza mettersi in ascolto sulla seriale.

Il problema potrebbe essere legato al fatto che non riesce a distinguere la causa del reset e passi sempre e comunque ad eseguire codice utente.
Potrebbe?

Ciao

Non credo. Perché quando l'Atmega8U2 spedisce il segnale di reset al chip, il led di stato lampeggia, segno che il bootloader ha letto correttamente il registro. D'altronde, stiamo parlando dell'Optiboot, è lo stesso montato sull'Atmega328, corretto per poter gestire Flash con dimensioni superiori ai 64 kB.

Sì, in queste prove standard l'alimentazione viene dal convertitore, proveniente dall'USB.
Confermo che quando faccio l'upload il reset avviene perché lampeggia il LED messo sul pin 2 del micro, proprio per tale verifica, cosa che non succede all'accensione.
Vorrei sapere questo: posto che tu trovi riscontro in quello che "racconto" seguendo il tuo schema sequenziale, secondo te, nel momento in cui il micro preleva il primo carattere dalla seriale , non dovrebbe chiederglielo?? cioè non dovrei vedere lampeggiare il LED RX del convertitore, segno che il micro sta chiedendo qualcosa? Come sai scrivo da casa, dove non ho nulla per fare prove, poi tutto ciò che esce dalle discussioni diventa oggetto di prova e verifica. Vorrei che tu verificassi il 644 (che lavora senza filtro da te) per darmi conferma di questa cosa, anche se forse i LED di Arduino sono siglati lato micro e non lato 8u2, verifica tu.
In pratica dopo il lampeggio del LED 2 mi aspetterei un flash del led rx del convertitore, seguito da un flash del led tx, e poi tutta la "discussione" con entrambi che lavorano ininterrottamente.

Michele, te porti male XD
Oggi senza filtro RC non riesco a programmare il mio Atmega644P. ]:smiley:

Vabbè.... andiamo avanti :sweat_smile:

Premetto: mi baso su cosa faccia l'Atmega8U2 perché i led dell'Arduino UNO sono pilotati da questo chip.
Detto questo, il bootloader non chiede i dati sulla seriale, semplicemente si mette in attesa. Se arriva qualcosa, lo interpreta. Altrimenti se non arriva nulla il watchdog provvederà al timeout, cioè all'uscita dopo tot periodo senza nulla con un bel reset. Questo lo verifico perché premendo il reset e resettando l'Atmega644P, il led RX sull'Arduino non lampeggia, segno che il bootloader verso il chip non invia nulla.

Questa è la mia analisi dei dati, attendo ora le tue conclusioni. :wink:

Leuccio mio :* non ti farei del male nemmeno se tu fossi l'ultimo ostacolo tra me e la Bellucci (sono sicuro che ti scanseresti di tuo ]:D)
Se ti può consolare ti ricordo che la mia prima vittima sono me stesso 8), quindi non chiedermi che ti succede, ma se non hai dimenticato qualcosa, ciò che ti accade non è altro che la prova dell'inaffidabilità di questa comunicazione....
Conclusioni? secondo ciò che dici tutto va bene ed invece non va bene nulla.
Per cui a questo punto, avendo molto più chiari (grazie a te XD) i meccanismi del dialogo, non mi resta che collegare il DSO, appena sarà possibile..., e fotografare i vari momenti dei pin reset, tx e rx, sia sul 644 che sul 1284, con e senza filtro. Un bel servizio da mandare a mamma ATMEL per farle vedere i sui figlioli quanti capricci fanno, sperando ci capiscano qualcosa, maremma seriale ]:smiley: ]:smiley: ]:smiley:

Manco morto! ]:slight_smile:

Se ti può consolare ti ricordo che la mia prima vittima sono me stesso 8), quindi non chiedermi che ti succede, ma se non hai dimenticato qualcosa, ciò che ti accade non è altro che la prova dell'inaffidabilità di questa comunicazione....
Conclusioni? secondo ciò che dici tutto va bene ed invece non va bene nulla.
Per cui a questo punto, avendo molto più chiari (grazie a te XD) i meccanismi del dialogo, non mi resta che collegare il DSO, appena sarà possibile..., e fotografare i vari momenti dei pin reset, tx e rx, sia sul 644 che sul 1284, con e senza filtro. Un bel servizio da mandare a mamma ATMEL per farle vedere i sui figlioli quanti capricci fanno, sperando ci capiscano qualcosa, maremma seriale ]:smiley: ]:smiley: ]:smiley:

Ho deciso, per il mio compleanno mi compro un DSO anch'io... mi sento troppo limitato senza :sweat_smile:

Sarebbe ora! fatti consigliare da Astro :wink: ti aggiorno appeno potrò fare prove :slight_smile:

A me andrebbe bene un DSO come il tuo, non pretendo strumenti professionali: 1) non saprei come usarli, 2) la moglie mi rincorrerebbe :stuck_out_tongue_closed_eyes:

leo72:

[quote author=Michele Menniti link=topic=136740.msg1085758#msg1085758 date=1358978077]
Sarebbe ora! fatti consigliare da Astro :wink: ti aggiorno appeno potrò fare prove :slight_smile:

A me andrebbe bene un DSO come il tuo, non pretendo strumenti professionali: 1) non saprei come usarli, 2) la moglie mi rincorrerebbe :stuck_out_tongue_closed_eyes:
[/quote]
:fearful: GW-INSTEK GDS2064

:fearful: GW-INSTEK GDS2064
[/quote]

Leo, questo lo compri per te e a tua moglie il Bimby --> http://bimby.vorwerk.it/it/home/ :wink:
Il prezzo è il medesimo. :astonished:

@Mike:
in quel prezzo c'è uno zero di troppo $)
:stuck_out_tongue_closed_eyes: :stuck_out_tongue_closed_eyes:

@paolo:
non se ne parla nemmeno :stuck_out_tongue:

Oggi ho ritirato il 1284 ed ho fatto adesso qualche prova sulla seriale usando l'mcp2200 come convertitore.
Mettendo RC ,che più che un filtro è più una rete di ritardo sul rx del 1284 carico senza problemi gli scketch in seriale,se invece non metto nulla non si trova in sincronia con il programmatore.
@Michele
ti do ragione sul fatto che il convertitore parte troppo presto con i dati da inviare al 1284,l'anticipo del segnale è di qualche microsecondo e lo si nota sovrapponendo i segnali ottenuti prima e dopo la rete di ritardo.

Per riuscire a programmare entrambi i micro 644/1280 basta mettere in serie al pin rx una R di 120K ed eliminare il condensatore,ho fatto diverse prove con entrambi i micro e nel mio caso il problema non si presenta.

tonid:
Oggi ho ritirato il 1284 ed ho fatto adesso qualche prova sulla seriale usando l'mcp2200 come convertitore.
Mettendo RC ,che più che un filtro è più una rete di ritardo sul rx del 1284 carico senza problemi gli scketch in seriale,se invece non metto nulla non si trova in sincronia con il programmatore.
@Michele
ti do ragione sul fatto che il convertitore parte troppo presto con i dati da inviare al 1284,l'anticipo del segnale è di qualche microsecondo e lo si nota sovrapponendo i segnali ottenuti prima e dopo la rete di ritardo.

Ti ricordo che il bootloader è lo stesso Optiboot dell'Atmega328 solo modificato per poter gestire il 3° registro indirizzi che serve a programmare memorie più grandi di 64 kB (limite dei registri a 16 bit).
Per curiosità, potresti analizzare anche i tempi di risposta di un Atmega328 con Optiboot per capire se è il micro che è più rapido del 1284 oppure se la modifica SW influisce sui tempi di risposta del bootloader?
Altra cosa, a te ha influito la lunghezza del collegamento? A me sì. Nel senso che se anche uso la rete RC (chiamiamola così visto che non è un filtro, quindi) se antempongo un jumper troppo lungo il chip non risponde correttamente.

Per riuscire a programmare entrambi i micro 644/1280 basta mettere in serie al pin rx una R di 120K ed eliminare il condensatore,ho fatto diverse prove con entrambi i micro e nel mio caso il problema non si presenta.

Domani provo questa configurazione.

Leo, non mi pare che tu mi abbia accennato a questa cosa dei cavetti lunghi.....

Tonid: infatti è da parecchio che su questo Topic vado predicando che secondo me il "filtro" compie un'azione ritardante e non di filtro vero, in quanto i segnali si "rovinano" anche se il micro li legge ancora. Nel caso del 644 io ho usato un partitore 10k+22k e mi funzionava lo stesso, mentre il 1284P non sono riuscito a farlo andare. Una cosa non capisco: come fa a ritardare il segnale una sola R da 120k senza condensatore? Ovviamente la proverò anch'io, ma sono un pò dubbioso sul buon esito della prova.

E' una cosa di cui mi sono accorto solo l'altro giorno quando ho fatto le ultime prove prima di smontare il chippone.

Tonid: infatti è da parecchio che su questo Topic vado predicando che secondo me il "filtro" compie un'azione ritardante e non di filtro vero, in quanto i segnali si "rovinano" anche se il micro li legge ancora. Nel caso del 644 io ho usato un partitore 10k+22k e mi funzionava lo stesso, mentre il 1284P non sono riuscito a farlo andare. Una cosa non capisco: come fa a ritardare il segnale una sola R da 120k senza condensatore? Ovviamente la proverò anch'io, ma sono un pò dubbioso sul buon esito della prova.

Michele, prova anche i tempi su un Atmega328 con Optiboot 4.4.
Per capire insomma se l'Optiboot 4.5 di maniacbug introduce dei ritardi software oppure se è il micro che risponde con lentezza.

Posso risponderti subito, quando mi hai detto che non avevi apportato modifiche ho scaricato nuovamente gli originali e lì c'era sia il 4.4 che il 4.5, li ho provati entrambi. Io non credo che il problema sia proprio del bootloader ma dei tempi "interni" della gestione della seriale del micro, solo così si spiegano i differenti comportamenti tra i nostri vari micro; ovvio che parliamo di tempi piccolissimi, ma bastano per fare la differenza, purtroppo.

Però in diversi che hanno avuto problemi con l'USART0 sui 1284P, usando la USART1 questi problemi pare non ci siano.
Nel thread sul forum internazionale ci sono alcuni interventi interessanti pubblicati negli ultimi giorni.
Uno riprendeva ciò che era emerso da un altro possessore di chip che, 2/3 anni fa, aveva avanzato l'ipotesi di "noise", "disturbo", che se presente sul pin RX0 andava ad alterare i dati in transito sul bus interno.
Questo utente scriveva che se lui toccava il pin RX0 con un dito, il chip si resettava. Questo secondo lui confermava la questione che il 1284 fosse "nato male", cioè che avesse qualcosa di sbagliato a livello di die interna.

La rete RC, secondo lui, era un filtro RC vero e proprio che serviva a pulire il segnale sul pin RX0 in modo che il disturbo non entrasse nel chip corrompendo il bus dati dello stesso.

Allora significa che esiste da qualche parte un bootloader che usa l'USART1, io ho provato quello modificato da te, ma senza successo, se ricordi avevo avanzato anch'io il dubbio e ti avevo chiesto di modificare il bl per me; puoi reperire questa versione che hanno provato altri?
Riguardo il filtro, ti ricordo che ho pubblicato in questo Topic, un po' di post fa, un'immagine del DSO con il segnale che esce dal Convertitore (che non si capisce perché debba essere disturbato, in quanto funziona con altri 7-8 tipi ci MCU) e la porcheria che si vede sul pin rx, vattelo a guardare e dimmi se ti sembra una ripulitura :sweat_smile:

Altra cosa, a te ha influito la lunghezza del collegamento? A me sì. Nel senso che se anche uso la rete RC (chiamiamola così visto che non è un filtro, quindi) se antempongo un jumper troppo lungo il chip non risponde correttamente.

Questo potrebbe essere causato dalle capacità parassite introdotte dal cavo stesso(piccolissime) che mettendosi in serie al C ne riducevano il valore.
Anche le misurazioni che ho fatto non sono del tutto veritiere perchè bisognerebbe tener conto della capacità della sonda dell'oscilloscopio
quindi ho solo guardato più o meno come arrivavano i segnali....
L'idea di togliere il condensatore e aumentare il valore della resistenza mi è venuta perchè il ritardo da creare era talmente piccolo che si poteva provare solo ritardando il flusso degli elettroni con una resistenza abbastanza grande da ottenere il risultato.
Mi rimaneva da fare la prova con il 644 per vedere se in quel caso invece avrebbe dato problemi ed ha funzionato bene.
Queste sono mie teorie......sarei contento se passasse astro per illuminarci.

Edit. @Leo
La R ed il C così collegati sono un filtro passabasso e guardando i segnali postati da Michele,quella distorsione,è l'effetto che ha un filtro su un segnale ma il fatto che quel filtro porti a far funzionare la seriale è solo perchè ritarda il segnale,lo riterda perchè il condensatore impiega un certo tempo a caricarsi fino a Vcc tramite la R,più grande è la R e più distorcerà il segnale.