next topic »

[Reply #210 on:]

Ciao Leo,ho aggiunto il C da 100nF in parallelo alla pull-up ma devo comunque eliminare quello in serie al reset altrimenti non va.
La cosa strana è che a me funziona benissimo senza filtro RC e,se lo aggiungo,carica bene lo stesso...
Mi pare di ricordare che il problema lo avevate su entrambi i chip 644/1280,giusto?

[Reply #211 on:]

Ciao Leo,ho aggiunto il C da 100nF in parallelo alla pull-up ma devo comunque eliminare quello in serie al reset altrimenti non va.

Te lo avevo detto anche io:

il C (da 0.1uF ceramico) mettilo eventualmente  in parallelo

La cosa strana è che a me funziona benissimo senza filtro RC e,se lo aggiungo,carica bene lo stesso...

Il filtro RC serve (ma non sempre) per i 1284P, i 644P non necessitano di esso.

[Reply #212 on:]

Ah,ricordavo che con l'MCP c'erano dei problemi anche con il 644

[Reply #213 on:]

Ah,ricordavo che con l'MCP c'erano dei problemi anche con il 644

L'unico che so che abbia avuto dei problemi con il 644P durante la programmazione via bootloader è stato Michele.
A lui il 644P funziona con filtro RC mentre il 1284P proprio non riesce a programmarlo.

Io ho sempre programmato il 644P senza filtro, mentre mi serve assolutamente il filtro con il 1284P.
Però preciso che io ho usato per ora solo l'Arduino UNO con l'Atmega328 staccato, quindi invece dell'MCP2200 ho usato l'Atmega8U2. Non so se questo fa la differenza. A parte il convertitore, anche in rete ho letto di problemi solo in relazione al 1284P.

[Reply #214 on:]

Ricordavo bene allora che c'era un problema ma non ricordavo che lo avesse  Michele....Appena passa di quì vediamo se posso tornargli utile.
Il 1284 non me lo hanno dato disponibile quindi non posso fare prove anche con quello,dovrei vedere "sotto casa" se ne hanno ma la vedo dura.

[Reply #215 on:]

Intanto io sto usando la 1.0.1.
All'inizio ho fatto prove con CP2100, MCP2200, FT232RL e 8u2, i risultati sono riportati qui. Quindi l'unico modo che ho io per programmare il 644P è usare il filtro o un partitore sulla linea rx del micro, eccetto il CP2102 che funziona direttamente; invece nessuno di essi va con il 1284P né con filtro e né senza.

[Reply #216 on:]

Ciao Michele,anche io uso l'ide 1.0.1 ed ho usato l'MCP come convertitore ma,avendo fatte le prove come rimasti qualche post fa,devo dire che non mi ha dato particolari problemi se non dovuti al condensatore in serie al reset che,una volta bypassato,mi ha permesso di caricare sckecth senza l'ausilio di filtri RC sul RX del 644.

[Reply #217 on:]

Ho ordinato questa mattina il 1284p,dovrebbe arrivare mercoledì/giovedì,appena arriva faccio due prove anche io su quello e vi dico.
Ciao.

[Reply #218 on:]

Purtroppo ho altre dieci cose da fare nel pochissimo tempo che ho disponibile per il lab; ora non può che venirmi il dubbio che sia il portatile, perché qui secondo me è una frazione di qualcosa....
Il fatto è che altri sul Forum Internazionale sono nelle mie stesse condizioni, la cosa che mi toglie voglia di insistere è il fatto di non aver MAI visto funzionare un 1284P.
Comunque ho fatto una piccola ma dettagliata relazione all'Assistenza ATMEL, inviando loro materiale per fare le prove ed il link al Topic del F.I. in modo che vedano che non sono un visionario e che comunque, anche chi va meglio (v. Leo) è costretto a ricorrere al filtro RC. Sarebbe ora interessante vedere la tua prova col 1284P, se e quando ti arriva. Una sola info: il tuo convertitore MCP2200 lo hai realizzato sul mio schema o hai apportato modifiche particolari? Nella versione che ho dato alla Rivista ho messo il C in serie al DTR (RTS in realtà....) però ho previsto anche un jumper a saldare, in parallelo ad esso per bypassarlo in situazioni come questa.

[Reply #219 on:]

Per ora le prove le ho fatte tutte con il fisso.
MIke, hai provato a dare alimentazione all'Atmega1284P separatamente e non attraverso il convertitore (e quindi il portatile)?

[Reply #220 on:]

Per ora le prove le ho fatte tutte con il fisso.
MIke, hai provato a dare alimentazione all'Atmega1284P separatamente e non attraverso il convertitore (e quindi il portatile)?

sì, lo leggi qualche post addietro, quella sera che ho poi messo una pull-down sul tx del micro ed a quel punto ho iniziato a vedere attività di risposta, invece dei soliti 3 lampeggi a vuoto, ma comunque ottenendo lo stesso errore. MI era venuto il dubbio dei livelli ed ho provato ad alimentare il micro separatamente da 4,5 a 5,5V mentre il convertitore era alimentato dall'USB, ovviamente masse in comune

[Reply #221 on:]

Sarebbe ora interessante vedere la tua prova col 1284P, se e quando ti arriva. Una sola info: il tuo convertitore MCP2200 lo hai realizzato sul mio schema o hai apportato modifiche particolari? Nella versione che ho dato alla Rivista ho messo il C in serie al DTR (RTS in realtà....) però ho previsto anche un jumper a saldare, in parallelo ad esso per bypassarlo in situazioni come questa.

Ma,l'ho ordinato questa mattina tramite un amico che ha un negozio di comp,aveva da chiudere un ordine ad RS e gli ha infilato il mio chip,comunque spero mi arrivi presto. Per quanto riguarda l,MCP2200 ho fatto una nuova scheda dove posso sia ponticellare il condensatore con un jumper che la resistenza da 1K (famosa)che in alcune situazioni particolari poteva dare fastidio ma lo schema è lo stesso tuo.
Le prove che ho fatto io sul 644 sono state fatte da portatile e non da fisso.
Ora a parte tutto non entro troppo in merito all'architettura di un micro in quanto sono ignorante ma se è prevista la programmazione seriale è giusto che essa debba funzionare e visto che così non è il problema lo hanno loro (atmel) e dovrebbero a mio parere risolverlo o quanto meno trovare una soluzione che sia sempre funzionale.

[Reply #222 on:]

il tecnico con cui sono in contatto finora è stato gentile e disponibile, vediamo ora che siamo al nocciolo della questione.....
i miei MCP2200 ora sono in Rivista perché sul numero di febbraio esce l'articolo, quando rientrano posso fare la prova a bypassare le due R da 1K ed eliminare la pull-up sull'rx dell'MCP, intanto aspetto le tue prove.

[Reply #223 on:]

Va bene..

[Reply #224 on:]

Ecco la risposta ATMEL:

Dear customer,

Here are some suggests about your issue:

1. When you program bootloader and USART firmware to the chip, please make sure which entrance (application or bootloader) the firmware runs from when power on.

2. If the bootloader affects USART, please add bootloader code step by step and check which part affects USART

3. I soppose RC filter doesn't affect USART communication, please measure the wave of TXD and RXD with oscilloscope to check if they are nomal

Hope this will help you to solve the problem.

Quindi loro pensano che il problema sia nel bootloader, e d'altra parte se io carico via ISP un firmware che gestisce la seriale non ho alcun problema. Secondo loro il filtro non influisce sulla programmazione ed io sono d'accordo e l'ho sempre detto: penso che quei due componenti non svolgano funzione di filtro, visto che deformano l'onda, ma servano o per ritardare l'invio del segnale di TX rispetto all'azione del bootloader o per abbassare la soglia del segnale; in quest'ultimo caso l'ha prova ve l'ho fornita; io che sono costretto ad usare il "filtro" anche col 644, ho provato a sostituire il C con una R, creando di fatto un partitore che diminuiva di circa 1V il segnale, lasciandolo però perfettamente quadro, e a me la programmazione ha funzionato comunque. Purtroppo col 1284 nel mio caso non c'è niente da fare.
La cosa interessante, se ho ben capito il punto 1 è questa: se analizziamo il comportamento tipo del bl, vediamo che quanto il programmatore inizia la sua attività, per prima cosa manda un RESET, in seguito ad esso il bl verifica se c’è attività sulla seriale, altrimenti va ad eseguire l’eventuale firmware. A me pare di aver notato che normalmente l’interrogazione della seriale avvenga ad opera del micro con l’invio di un segnale mediante il proprio TX, al quale il convertitore risponde, e quindi inizia il dialogo; quindi (magari se qualcuno può fare una prova al volo anche col solo Arduino me lo conferma) dopo il reset c’è prima un impulso sul LED tx (se parliamo di Arduino, rx se parliamo di un convertitore esterno) e poi la risposta con l’altro LED. Nel mio caso questo impulso di richiesta NON C’È quindi potrebbero aver ragione loro che il bl non sia in esecuzione o sia troppo in ritardo. Come suggeriscono loro, è possibile seguire passo-passo cosa succede nel bl e provare ad introdurre dei ritardi alla sua esecuzione, dopo l’arrivo del RESET al micro. Ho sempre detto che secondo me il convertitore parte troppo presto rispetto al reset. Insomma sono idee buttate, la verità è che dovremmo metterci in due: uno fa le prove col DSO e l’altro analizza parallelamente il comportamento del sw, ma purtroppo ciò non è possibile, allora chiedo: è possibile, “leggendo” il bootloader, scrivere la sequenza delle operazioni che esso compie nella fase iniziale, comprese ‘uso dell’USART0? Questo mi potrebbe aiutare ad analizzare col DSO il comportamento del micro, e secondo me alla fine ce la facciamo.