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

[leo72]

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


@paolo:
non se ne parla nemmeno 

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

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.

[leo72]

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.

[menniti]

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.

[leo72]

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

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.

[menniti]

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.

[leo72]

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.

[menniti]

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 

[tonid]

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.

[tonid]

@Leo
Dimenticavo di dirti che io per portare i segnali alla seriale uso i cavetti con i coccodrilli lunghi una 40ina di cm.

[leo72]

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?

Ho letto di questo bootloader ma non l'ho trovato.
Dovrei ricercarlo.

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 

Vero, dimenticavo.
Allora la questione del reset toccando il pin RX0 che lamenta l'utente a cosa è dovuta? A spike di microcorrenti causati dall'elettrostatica? Se basta un segnale del genere per far saltare la stabilità di un micro, andiamo bene 

[tonid]

Ho fatto altri test con un Atmega 328,utilizzando gli stessi valori di R usati con 644/1284 e tutto funziona a dovere......
Nel 328 ho messo l'optiboot ma no so che versione sia.....
Se volete che faccia altri test ditemelo,ho tutte le board montate e posso fare in un attimo.

[leo72]

Ho fatto altri test con un Atmega 328,utilizzando gli stessi valori di R usati con 644/1284 e tutto funziona a dovere......
Nel 328 ho messo l'optiboot ma no so che versione sia.....

Se stai usando l'IDE dalla 0023 in poi o un Arduino R3 siamo sicuri che l'Optiboot sia il 4.4.

[tonid]

Si Leo,sto usando la 1.0.1.
Tu hai avuto modo di provare?

[leo72]

Si Leo,sto usando la 1.0.1.
Tu hai avuto modo di provare?

Mi sto accingendo ora...