next topic »

[Reply #195 on:]

Il problema è che noi abbiamo usato anche l'altra seriale come esperimento, ma non è cambiato nulla. Ieri sera ho scritto all'Agente ATMEL per l'Italia, spiegando la cosa e riportando il lotto dei miei micro, vediamo se mi risponde. Sarei tentato di comprarne un altro, ma francamente ne ho già 5 inutilizzati, un paio hanno lavorato per le prove dei miei due Programmatori, ma gli altri fino a queste prove erano intatti.

Se è una persona seria, non lo smentirà, il che equivale ad una conferma implicita 

[Reply #196 on:]

MI ha risposto ieri (di domenica!!!) fornendomi l'indirizzo diretto dell'assistenza ATMEL ed un altro nominativo (italiano) acui scrivere per conoscenza, e mo' mi tocca tradurre in inglese la mia lettera

Comunque ho fatto una serie di altre prove: ho scollegato i 5V dell'USB e alimentato il micro con una tensione esterna di 4,5V ed ho aggiunto una pull-down al tx del micro ed ora vedo che il micro risponde alle "sollecitazioni" del programmatore, però c'è un problema di sincronismo a mio modesto parere. Vedremo cosa mi rispondono (semrpe se capiscono quello che gli scrivo )

[Reply #197 on:]

MI ha risposto ieri (di domenica!!!) fornendomi l'indirizzo diretto dell'assistenza ATMEL ed un altro nominativo (italiano) acui scrivere per conoscenza, e mo' mi tocca tradurre in inglese la mia lettera

Comunque ho fatto una serie di altre prove: ho scollegato i 5V dell'USB e alimentato il micro con una tensione esterna di 4,5V ed ho aggiunto una pull-down al tx del micro ed ora vedo che il micro risponde alle "sollecitazioni" del programmatore, però c'è un problema di sincronismo a mio modesto parere. Vedremo cosa mi rispondono (semrpe se capiscono quello che gli scrivo )

Uhm... mi fa pensare questa cosa.
Sul mio sito un lettore mi ha scritto che lui ha programmato i suoi 1284P alimentandoli separatamente dall'Arduino che usava per programmarli

[Reply #198 on:]

Ormai preso dalla disperazione ho provato di tutto, variando il range da 3 a 5,5V, come dicevo ora si accende il led tx e poi quello rx, in pratica il micro si accorge che gli è arrivata qualcosa e da una risposta, ma non conosco il protocollo di comunicazione, non so se la risposta del micro è quacosa tipo "eh, cos'hai detto?" oppure "sì, ho capito", ma poi non capisce il programmatore a sua volta; comunque ho lasciato le masse in comune, non avrebbe senso non farlo, secondo me; nei prossimi gg farò altre prove "strane".

[Reply #199 on:]

comunque ho lasciato le masse in comune, non avrebbe senso non farlo, secondo me

Beh, sì. Certo. Altrimenti non tornerebbero neanche i livelli della seriale.

[Reply #200 on:]

comunque ho lasciato le masse in comune, non avrebbe senso non farlo, secondo me

Beh, sì. Certo. Altrimenti non tornerebbero neanche i livelli della seriale.

la cosa curiosa è questa: normalmente il livello TX è allo stato HIGH e così com'è non dà segni di vita; se metto una pull-down da 10k lo porto allo stato LOW, ed in questo modo vedo l'attività sul pin, ma nun ce sto a capì na piotta
Comunque ho scritto all'assistenza, vediamo se mi rispondono

[Reply #201 on:]

Beh, sono veloci, anche se ti trattano come un deficiente

Dear customer,
Please make sure that the hardware connection is correct.
You can test UART function with application firmware but not bootloader. The easy code can verify hardware connection and firmware.Pin 15 is used for UART0 but not UART1, so please check which UART you are using.
And please be noticed that the memory size is different between ATmega664PA and ATmega1284.
Thanks.
Best Regards,
Atmel Technical Support Team

La questione dell'USART0/1 è colpa mia perché ieri sera ho parlato di prima seriale e lui l'ha interpretata come "1" invece di "0".
Prima di rispondergli spiegando che non sono così sprovveduto e che conosco le differenze di memoria tra 644 e 1284 qualcuno gentilmente mi spiega il significato STRETTO della frase che ho colorato in rosso?

[Reply #202 on:]

Mi par di capire che suggerisca l'uso di un test condotto con un firmware (penso inteso nel senso di programma) e non di un bootloader, programma che può verificare la funzionalità della connessione hardware.
Cioè, capisco che ti sta dicendo che forse il problema è dato da un errore nelle connessioni.

[Reply #203 on:]

Mi par di capire che suggerisca l'uso di un test condotto con un firmware (penso inteso nel senso di programma) e non di un bootloader, programma che può verificare la funzionalità della connessione hardware.
Cioè, capisco che ti sta dicendo che forse il problema è dato da un errore nelle connessioni.

Allora avevo capito bene. La questione delle connessioni se la sta ponendo perché pensa che io abbia fatto confusione tra USART0 e USART1, ma noi sappiamo che così non è. Testare un firmware invece di un bootloader significa che vado a caricare via ISP un qualsiasi software che faccia uso della seriale 0 e verifico se funziona, ma io sono ragionevolmente sicuro di sì, e comunque non potrei avere il problema su 5 micro.
Inutile che gli risponda ora, al limite gli dico che faccio altri test; per scrupolo metto via ISP un qualsiasi sketch che usa la seriale e poi gli allego lo schema applicativo dei test che sto facendo e la copia del bootloader che sto usando, e gli spiego che a me quello serve e non la semplice funzionalità del micro.

[Reply #204 on:]

Ciao gente,ho montato il 644P ma prima di iniziare a fare delle prove volevo chiarire alcune cose su cui non ho fatto ancora esperienza.
Ho scaricato il pacchetto dal sito di Leo e ho sistemato il tutto nell'ide 1.0.1,poi per caricare il bootloader in ISP seleziono la board di testo ATmega644p@16MHz w/Arduino as ISP e poi carico il bootloader con il tasto burn bootloader che è presente nei tool dell'ide.
A questo punto monto il chip in stand alone con il quarzo ecc. ed è pronto per essere programmato in seriale ma quale board di testo devo selezionare per caricare uno scketch ?

[Reply #205 on:]

Allora, ho usato la board di testo  ATmega644p@16MHz w/bootloader ed il convertitore MCP2200 con i seguenti collegamenti:
-nessun condensatore in serie al reset del MCP2200;
-R da 1k tra TX del MCP2200 e pin RX del 644;
-R da 1k tra TX del 644 e RX del MCP2200;
-nessun filtro RC sull'RX del 644;
-ATmega644PA-PU in stand alone con quarzo 16MHz ed R di reset in pull-up da 10k.
Ho caricato una decina di volte il blink con successo variando i valori di delay e verificando anche il lampeggio sul pin 19(D13).
Se invece inserisco il condensatore in serie al reset non trova il chip andando in "not in sync".

edit. Ho provato anche a scaricare uno dopo l'altro gli scketch aspettando giusto il messaggio dell'ide done uploading e l'esito è sempre positivo......fin'ora ne ho scaricati una 40ina .
Se avete bisogno di più info o misurazioni chiedetemi ,lascio tutto montato.

[Reply #206 on:]

Riguardo l'IDE conviene usare tutti l'ultima versione ufficiale, la 1.0.3, per evitare che piccole differenze nel codice si ripercuotano nei test.

[Reply #207 on:]

Sarebbe una buona cosa ma nel mio caso spaventa cambiare perchè non ho particolare dimestichezza con file e cartelle

[Reply #208 on:]

Se invece inserisco il condensatore in serie al reset non trova il chip andando in "not in sync".

Sul pin di reset lascia solo la resistenza di pull-up (da 10 a 30K), il C (da 0.1uF ceramico) mettilo eventualmente  in parallelo, che aiuta a tenere il pin un pochino più pullato basso finché la VCC non si è stabilizzata.

[Reply #209 on:]

Riguardo l'IDE conviene usare tutti l'ultima versione ufficiale, la 1.0.3, per evitare che piccole differenze nel codice si ripercuotano nei test.

Concordo. Oltretutto non devi più cambiare i file del core dato che la 1.0.3 supporta nativamente sia il 644P che il 1284P.