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

Esattamente. L'altro giorno quando ho consigliato di incrociare RX e TX non mi ricordavo che con l'Arduino usato come convertitore seriale/USB si doveva far riferimento al chip Atmega8/16U2 e non all'Arduino.

Dando un'occhiata al datasheet si capisce la situazione degli "incroci pericolosi" :wink:
Il "problema", se così si può chiamare, del non dover incrociare le linee RX/TX sull'Arduino quando si usa la scheda senza il chip Atmega328 ma come convertitore seriale/USB nasce del fatto che sull'Arduino abbiamo già 2 chip che comunicano serialmente fra di loro, il già nominato Atmega832 ed il convertitore USB/seriale, l'AtmegaxxU2 (che può essere l'8U2 come il 16U2).
Come si vede dal datasheet, le linee RX e TX dall'AtmegaxxU2 vengono collegate rispettivamente con i pin TX ed RX dell'Atmega328, e poi sono riportate sui pin esterni della scheda. In sintesi, i pin esterni dell'Arduino usano l'indicazione RX e TX ma in riferimento all'Atmega328, e va bene così nell'uso normale della scheda.

Ma se si deve usare l'Arduino come convertitore per far dialogare l'AtmegauuU2 con un altro dispositivo seriale, le linee non si incrociano perché il pin dell'Ardino RX è collegato già con il pin TX dell'AtmegaxxU2, ed il pin TX con il piedino RX.

Oggi sono riuscito solo a mettere il bootloader sul 644, avevo tanto altro da fare; domani assemblo il collegamento seriale e provo tutti i sistemi di conversione che ho, poi aggiorno il Topic.

Ho fatto una serie di test di programmazione seriale su un 644PA, confermo al 100% i vostri esiti:
MCP2200 (due schede identiche): richiede R10k in serie e C 100pF in parallelo verso massa sulla linea RX del 644; da tenere presente l'ininfluenza delle due R da 1k in serie ad entrambi i segnali sulla mia schedina e la R di pull-up da 22k sull'RX del 2200 (quindi sul TX del 644)

FT232RL (due schede diverse): stessa identica situazione dell'MCP2200 solo che qui ho dovuto aggiungere il C100nF sulla linea del DTR, in quanto queste schede non lo prevedono, mentre sulle mie MCP2200 c'è.

CP2100 (Cavo Nokia): a suo tempo avevo inserito nello spinotto terminale il C da 100nF; il cavetto funziona anche senza il gruppo RC (quindi confermate le prove di PaoloS), ma non risente della sua presenza, quindi funziona anche se c'è.

Riepilogando: per far funzionare qualsiasi convertitore USB-Seriale al 100% conviene:

  • mettere un C da 100nF in serie alla linea DTR(Conv)-RESET(micro)
  • mettere una R da 10k in serie alla linea TX(Conv)-RX(micro)
  • mettere un C da 100pF tra la linea RX del micro e GND

Ora però voglio completare il ciclo di test con un 644A ed un 1284P, se ne parla nel pomeriggio, ma prima voglio cercare di capire qualcosa collegando il DSO alla sola linea RX del 644PA, visto che i problemi sono tutti lì.

Scusate, ma non ho letto tutto il topic.
Volevo sapere se le soluzioni trovate riguardano solo la programmazione seriale, mentre per quella ISP non è necessario alcun accorgimento.

PaoloP:
Scusate, ma non ho letto tutto il topic.
Volevo sapere se le soluzioni trovate riguardano solo la programmazione seriale, mentre per quella ISP non è necessario alcun accorgimento.

E' corretto. L'ISP non è influenzata.

Confermo Paolo, tant'è che usiamo regolarmente l'ISP per caricare il bootloader sui micro in test.
Ora inizio le misure col DSO, spero di capirci qualcosa :~

Intanto iniziamo con una cosuccia semplice. :sweat_smile:
Prendi lo sketch Blink, compilalo e cerca di inviarlo sul 644P tramite l'accoppiata seriale/bootloader con e senza filtro RC, per vedere a livello di segnali cosa succede sulla linea RX.

Dunque, osservando le immagini allegate potete vedere l'effetto del "filtro" RC che abbiamo usato finora: in pratica il fronte di salita dei segnali viene arrotondato e contemporaneamente l'ampiezza diminuisce leggermente, e i risultati li sapete.
Però ho notato che l'MCP2200 a volte soffre questa situazione, quindi ho fatto altre prove, tra cui quella di creare un partitore per diminuire il segnale ma senza distorcerlo, il risultato lo vedete nella seconda figura, l'ampiezza diminuisce e il segnale resta perfetto, in queste condizioni però funziona solo l'FT232RL, mentre l'MCP2200 risponde solo a volte e il CP2100 non ne vuole.
Ho notato un miglioramento con un C1nF ed una R4k7 entrambi tra RX del 644 e massa, ma comunque la situazione resta incerta; non cambia molto se levo la 4k7
Ora posso passare alle prove con altri micro, per il momento resta il fatto che la situazione non è molto affidabile; considerate però una cosa: io mando gli sketch a ripetizione, cioè finisce uno e spedisco immediatamente lo stesso, a volte si creano sovrapposizioni, ma comunque l'incidenza di ciò è abbastanza limitata.

DS0004.jpg

DS0005.jpg

La mia domanda (pertinente con il lavoro che stiamo facendo noi) è:
c'è una combinazione "sicura" per ogni tipo di convertitore? Oppure, c'è un convertitore che funziona senza?

Mi spiego, se io uso l'FT232 mi par di capire che il filtro RC non crei problemi, anzi.
Ma con l'MCP2200 qualche problema il filtro lo crea, per cui hai trovato un circuito filtrante "tollerato" dal convertitore oppure l'MCP2200 funziona anche senza? Questo non l'ho capito.

Attendo i testi del 1284.

Sono le domande che mi sto ponendo io, e le risposte non mi piacciono per niente :disappointed_relieved: Con due diversi 1284P non riesco a programmarli in alcun modo e con alcun convertitore, non ho provato l'Arduino perché non me ne frega niente, anche se a questo punto DEVO, se non altro per avere conferma che qualche spiraglio ci sia.
il 644A ha una diversa signature, francamente mi secca ora andare a modificare qualcosa per farlo funzionare, anche perché è "inutilizzabile" per i nostri scopi, non serve perderci tempo.
Prova un altro 644PA e poi uso Arduino, a tra poco....

OK

Tre su tre 644PA funzionano anche con Arduino UNO ed il solito RC, oltre che con FT232RL, il mio problema ora sono proprio i 1284P, che non vanno con nessun sistema: Arduino UNO, FT232RL, MCP2200, CP2100. A questo punto mi viene il dubbio che il problema non sia il bootloader, a me pare di aver usato la tua ultima versione, ma l'avevo scaricata forse un mesetto fa, come faccio a sapere se sto usando i file corretti? Secondo te potrebbe essere una cosa del genere?

Sul mio sito trovi un package aggiornato chiamato 644p_1284P_0102-002.zip
http://www.leonardomiliani.com/?p=625
Mi pare di aver ricompilato entrambi i bootloader, anche se non ne sono sicuro al 100% (nei giorni passati ho fatto talmente tante prove che ho perso la testa...).

So per certo però che la configurazione che ho suggerito, ossia R da 10K fra pin RX dell'Arduino e pin RX0 del 1284P, con C da 100pF in parallelo fra RX0 e GND a me a funzionato senza problemi. Ho usato l'Arduino UNO R1, quello con l'Atmega8U2 come convertitore con il firmware originale.

Ah, ho caricato il bootloader del 1284P con l'Arduino UNO con lo sketch ArduinoISP. Non so se lo hai fatto anche tu, altri programmatori più semplici (come l'USBtinyISP) non sono tutti capaci di scrivere oltre i 64 kB di Flash.

In buona sostanza, carica il bootloader ed accertati che funzioni. Per verificarlo, collega il 1284P su cui hai scritto il bootloader (quello che c'è nel mio package), attacca un LED al 2° piedino, dai alimentazione al chip e poi dagli un segnale di reset: se il bootloader è "vivo e vegeto", dovresti avere 3 flash veloci sul led (questa opzione viene compilata di default).

Io sto usando la 1.0.1, posso usare comunque questa tua versione per la 1.0.2?
Il test l'ho appena fatto ed il LED flasha regolarmente quindi ci siamo, ma vorrei provare ad usare l'ultimo tuo.

EDIT: porc...... ho il solito problema del download dal tuo sito, lo fa ma poi mi dice che non ci sono file da estrarre o mi tira fuori un file ridicolo che non serve a niente ]:smiley:

Per l'IDE 1.0.2 e 1.0.3 devi usare la versione 0102-002, perché con l'IDE 1.0.2 e 1.0.3 non serve più sovrascrivere i file del core di Arduino.
Il bootloader dovrebbe essere lo stesso ma se scarichi l'ultima versione è meglio. Come ti ho detto, mi pare di aver ricompilato il bootloader, ma non ne sono sicuro al 100%. Nell'incertezza, scaricala.

Il test l'ho appena fatto ed il LED flasha regolarmente quindi ci siamo, ma vorrei provare ad usare l'ultimo tuo.

OK

Ciao ragazzi.
Non ho seguito tutto il topic ma mi sembra di aver capito che i problemi che avete sono legati al pin rx del 644 che in alcuni casi siete riusciti a risolvere con filtro rc. Guardando i risultati del DSO postati da Michele con il filtro applicato non ha alcun senso che un segnale distorto sia più interpretabile dal micro rispetto ad uno ben squadrato se non per un "difetto" delle porte. Mi viene da pensare che forse basta solo tenere il livello di tensione del segnale entrante al 644 leggermente più basso dei volt di alimentazione.
Per arrivare a questo scopo e renderlo applicabile ai diversi tipi di convertitori si potrebbe provare ad inserire un diodo veloce in serie al segnale abbassando il livello logico 1 a Vcc-0,5. Non dispongo di 644 altrimenti avrei fatto anche io un po di prove volentieri.

MI sono spiegato male: posso usare il bootloader che hai preparato per la versione 1.0.2 con l'IDE 1.0.1? Puoi mandarmi ciò che devo usare per mail visto che il download dal tuo sito non mi funziona?

@ tonid: ma il diodo in serie non taglia le semionde negative? La prova ad abbassare il livello l'ho fatta anch'io con un partitore di tensione, forse ho esagerato, visto che l'ho portata a 3,4V, posso farla io la prova del diodo, sei sicuro di ciò che dici?

EDIT: ho messo comunque un BAT42 provandolo in entrambi i sensi e non cambia nulla; con il fatto di aver collegato il LED, sto notando una cosa, forse tra il RESET ed il primo segnale di TX per il sincronismo passa troppo poco tempo, ma intanto come posso fare a ritardare questa cosa?

Ciao Michele,il diodo se collegato con il catodo verso il pin rx del 644 lascia passare tutti i segnali positivi rispettando il senso della comunicazione portando il pin ai 5 volt meno la caduta del diodo.
Si può eventualmente aggiungere una R verso massa da una decina di K direttamente sul pin RX che tiene il pin a GND in assenza di segnale proveniente dal convertitore.

Ti avevo risposto editando il post precedente, comunque non va nemmeno con la R, l'errore che ottengo è "avrdude: stk500_getsync(): not in sync: resp=0x00", quindi il convertitore invia il segnale di sync al micro ma questi non lo riconosce e non risponde, infatti il TX del micro non dà alcun segno di vita :disappointed_relieved: