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

[menniti]

certamente, vedi solo se puoi dare risposta alle due domande che ti ho fatto nell'ultimo post.... così al limite stamattina faccio un'altro paio di prove prima di dedicarmi a tempo pieno al mio "progetto dell'anno 2013" XD

[leo72]

Poi due domande:
1 - in qualche modo il lampeggio del LED sul pin 2, subito dopo il reset che il convertitore dà al micro, visto che quasi istantaneamente gli manda il sync tramite il TX, può creare problemi di una qualche natura?

No. E' il comportamento standard dell'Optiboot. Lo fa anche l'Arduino.
Semplicemente, il lampeggio viene eseguito prima che si instauri la comunicazione con avrdude.

2 - è il caso di provare la seriale a 2500bps? può avere problemi col bootloader?

Il bootloader è compilato per lavorare a 115200 bps.
Penso che possa accettare qualsiasi velocità inferiore però dovresti:
1) ricompilare il bootloader per la nuova velocità
2) cambiare la velocità nella board relativa

Comunque io ho provato a 57600, quando facevo i test e non mi andava. E non ho risolto.

[menniti]

naturalmente intendevo scrivere 2400 , ok, rinuncio alle altre prove, io purtroppo non mi sento nelle condizioni di scrivere ad ATMEL; forse tu potresti sentire BOB per sapere se nel tempo gli è capitato qualche altro guaio e come lo ha risolto o meglio ancora aprire un Topic internazionale con la problematica, tanto la cosa quella è: nonostante il filtro non c'è verso di programmare il 1284P; se hai qualche minuto aprilo il Topic e mandami il link così me lo seguo durante la giornata.
Ora vado al lab.

[leo72]

Guarda, dei problemi relativi al pin RX0 se ne è già discusso sul forum internazionale. Ho anche guardato su AvrFreaks.
La soluzione è sempre quella: filtro RC.

Casomai ho trovato una cosa nuova, tu che usi l'FT232 e l'MCP2200 potresti provarla.
Il circuito di reset che fanno è questo:

Code: [Select]


    +---|<|----+
    |          |
5V--+-- R10K --+-- PIN_RST
               |
               = C 100nF
               |
          PIN_DTR

Non so se si capisce.
In pratica, R di pull-up da 10K tra VCC e pin di reset con diodo in antiparallelo.
Condensatore non pol. da 100 nF in serie sulla linea che va dal pin DTR del programmatore al pin di reset del microcontrollore.

[menniti]

Questo è il normalissimo circuito di reset, solo con l'aggiunta del diodo che, se ricordi, hanno messo anche sulle ultime versioni di Arduino; se ne parlò abbondantemente tra Astro e Testato, quanto quest'ultimo scriveva la sua Guida sull'IDe 1.0.
Mettere un diodo non mi costa nulla, provo....
Niente da fare, il problema ormai è chiaro per me: non c'è dialogo tra Convertitore e micro, a motivo del fatto che l'RX del micro non riconosce i segnali in arrivo dal TX del convetitore.

[leo72]

Niente da fare, il problema ormai è chiaro per me: non c'è dialogo tra Convertitore e micro, a motivo del fatto che l'RX del micro non riconosce i segnali in arrivo dal TX del convetitore.

E' questo, è il famoso bug HW delle versioni DIP del micro.
Per curiosità, di che produzione è il tuo micro?
Cioè, sopra al chip ci sono delle scritte:
ATMEL
ATMEGA1284P
PU
XXYY

Cos'hai scritto al posto di XXYY? Per capire il lotto, se è uguale al mio.

[menniti]

1021

[leo72]

A memoria non è uguale al mio, il mio mi pare sia marchiato 1039.
Sto spulciando nel forum alla ricerca di quella discussione sul 1284 in cui si parlava anche di questi problemi... discussione che non riesco a ritrovare... incredibile... 30 pagine sparite.. o sono orbo io...
Cmq trovo un sacco di gente che si lamenta di non riuscire a caricare via seriale col bootloader...

[leo72]

Ecco, ho ritrovato il mio post dove segnalavo il problema e la soluzione.
http://arduino.cc/forum/index.php/topic,80483.msg958603.html#msg958603

Ora che rileggo, vedo che ho fatto una cosa che a te non ho suggerito. Pare una ca**ata ma all'epoca funzionò: tagliare i piedini del condensatore da 100pF affinché siano i più corti possibili e metterlo il pin più vicino possibile ai pin del 1284P.
Pare fantascienza, ma puoi provare.

[menniti]

niente da fare, sono accorgimenti da RF, in questo caso penso solo che si tratti di situazioni vado/non vado; comunque sia non ci possiamo certo affidare ad accorgimenti del genere, quin  bisogna studiare a fondo e capire dov'è il vero problema

[Maurotec]

Vi seguo e se si tratta di un bug sarebbe bello leggere un comunicato ufficiale Atmel per capire dove il problema così da cercare una soluzione a ragion veduta.

Ciao.

[cece99]

Guardate, se posso essere di aiuto ho un progetto di comprare un 644 e ho degli mcp2200 quindi se volete vi do una mano a fare prove

[leo72]

Dopo investigazione in rete per rinfrescarmi la memoria, ho trovato il bug.
Esso sembra risiedere in un problema interno che porta a reset imprevisti del microcontrollore se durante l'esecuzione di un programma arrivano dati sulla linea RX0, cioè la linea di ricezione della prima seriale hardware.
Questi dati interferiscono col bus della memoria Ram causando errori che spaziano dall'alterazione dei dati fino al reset del microcontrollore.

La soluzione proposta è solo quella del filtro RC.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=107115
http://www.seanet.com/~karllunt/1284pmemprob.html
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=600128
http://uzebox.org/forums/viewtopic.php?f=4&t=49

Lì si parla solo di frequenze di 20 MHz ma qui noi abbiamo chip a 16 MHz col bug.

[menniti]

@ Mauro: bisognerebbe contattare ATMEL, se se ne parla su AVRFreaks penso che la cosa sia nota, ma io non so dove mettere mani né come contattarli, chissà Astro, ma mi sa che se n'è andato a sciare da qualche parte XD

@ cece: ovviamente ci stiamo muovendo "pubblicamente", chiunque vuole può fare prove, ma il problema col 644P non si pone, è il 1284P che fa le bizze

@ leo: la vedo sempre peggio, specialmente se abbiamo conferma che è un bug del pdip. Ma dimmi, non potremmo usare la seconda seriale per l'upload???

[leo72]

@ Mauro: bisognerebbe contattare ATMEL, se se ne parla su AVRFreaks penso che la cosa sia nota, ma io non so dove mettere mani né come contattarli, chissà Astro, ma mi sa che se n'è andato a sciare da qualche parte XD

Il bug è di vecchia data. Se ne parla già in riferimento a chip del 2008. Atmel, da quel che ho letto su AvrFreaks, ufficialmente ha detto solo che quei chip erano dei preserie e quindi secondo loro i micro di produzione non avrebbero avuto il problema. Il... problema è che invece anche i chip costruiti successivamente ce l'hanno.
Quindi Atmel non affermerà mai che sono buggati.

@ leo: la vedo sempre peggio, specialmente se abbiamo conferma che è un bug del pdip. Ma dimmi, non potremmo usare la seconda seriale per l'upload???

In teoria sì. Penso basti prendere il bootloader e modificare la USART usata. Il problema è che questo bug colpisce anche la normale comunicazione seriale per cui basta un segnale su RX0 per resettare il micro.

Mike, però mi suona strana 'sta cosa. Saresti l'unico a cui il filtro RC non ha funzionato. Eppure su AvrFreaks tutte le discussioni aperte per il bug della USART0 del 1284 sono state chiuse con [Risolto] proprio grazie a questo filtro.