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

Riassumo brevemente, anche alla luce di quanto affermato ultimamente nella sezione internazionale.

Il problema di questi chip sembra che risieda nella vicinanza del pin RX0 al pin XTAL1 del chip. Il pin XTAL1 è quello più importante dei 2 a cui si collega il quarzo. Stranamente, rispetto ad esempio all'Atmega328, la coppia di pin XTAL1/2 è stata invertita, così che XTAL1 sia accanto al pin RX0. Se ci fosse stato il pin XTAL2 ci sarebbero stati meno problemi. Un altro problema deriva dai fuse. Impostando il fuse basso per un clock esterno in realtà si abilita il micro ad attendersi un segnale di clock sul pin XTAL1, con tensioni e corrente interne basse, passibili di interferenze esterne. Usare quindi il valore $FF non è una buona idea. In diversi hanno suggerito l'uso del fuse $F7, che abilita il micro ad usare un cristallo esterno ("full swing"), gestito tramite dei segnali con più corrente in modo che siano un po' più insensibili ai disturbi arrecati dal flusso di dati che può transitare sul pin RX0.
In diversi hanno detto che usando questo valore per il fuse hanno risolto i problemi di programmazione usando l'Optiboot 4.5 modificato da maniacbug. In diversi concordano poi che la breadboard non è la soluzione migliore per eseguire questo genere di test per via della capacità parassita delle sue piste. In diversi hanno poi suggerito di evitare di far passare i segnali sui 2 pin XTAL1 e RX0 molto vicini, su un PCB, e di usare un piano di massa intorno ai pin del cristallo..
Io tutte queste prove non posso farle, non producendomi i PCB in casa.

Questa la teoria... adesso la mia pratica.
Io senza la R sulla linea RX0 non riesco a programmare il chip, anche usando il valore $F7 per il fuse basso. Ed usando il bootloader standard, quello a 57K, perché con l'Optiboot e la sola R non riesco, devo usare l'accoppiata R+C.

Insomma, un gran casino.

Azz.. quindi per fare dei veri test, si dovrebbe fare un pcb specifico prestando molta attenzione a interferenze e spurie varie.
Ma la configurazione (usb-serial converter-R-C) migliore, per te, qualè ?

Io non ho molta scelta, ho usato solo l'Atmega8U2 della UNO.
Quindi non faccio casistica :sweat_smile:

ok...
vediamo cosa dice Michele, le sue considerazioni...

se mi date il tempo...ecco la mia.....
Con l'unico bootloader per 644 (chiamiamolo quello "di Leo" per capirci, visto che si può scaricare anche dal suo sito) io riesco a programmare con la famosa resistenza.
Per programmare il 1284 invece devo ricorrere alla versione di giugno 2012 (sempre maniacbug), sia standard che optiboot, in entrambi i casi devo usare la resistenza.
Ho fatto a suo tempo la prova con il generatore di clock esterno a 16MHz, una bella onda quadra a 5V applicata all'XTAL1 con fuse $F7, senza alcun risultato positivo. Non credo troppo alle prove "PCB" anche se proprio in questi giorni sto sperimentando la notevole differenza di comportamento di un circuito "serio" montato su breadboard o su PCB. Credo piuttosto che ci siano problemi di tempistica di questi micro, che variano anche da lotto a lotto, e che nelle migliaia di prove fatte dagli utenti, alcuni abbiano trovato una propria soluzione, che però spesso non funziona agli altri.
In definitiva concordo con Astrobeed, il problema è nel bootloader. Se così non fosse la prova che mi ha fatto fare il supporto ATMEL (estremamente disponibile!) non sarebbe andata a buon fine, invece se carico via ISP un qualsiasi programma che fa uso anche intenso della seriale funziona tutto a meraviglia, quindi non c'è assolutamente alcuna influenza reciproca tra XTAL1 e RX0.
Astrobeed è una persona seria, quindi se non ci ha fornito il bootloader che ci aveva promesso è perché alla fine anche lui probabilmente sta avendo gli stessi problemi nostri e sta cercando di risolverli, compatibilmente con le altre mille cose che ha da fare.
L'unica cosa strana è che non ci abbia aggiornati, ma non sarò certo io a rompergli i maroni, l'ho già fatto fin troppe volte in passato, e solo quando altri hanno cominciato a fare lo stesso con me ho capito cosa significava :grin:
Tanto lui questi interventi li legge di sicuro, quindi sta a lui intervenire o meno.......

@ sz: ho usato indifferentemente 8u2, MCP2200 e FT232RL, sai il migliore qual è? il PL2303, un chippetto che si trova nei vecchi cavi USB Nokia, l'unico col quale ho programmato il 644 perfino senza resistenza; l'ho messo da parte perché è un TSSOP, scomodissimo da saldare, e perché non voglio legare l'idea di funzionamento a qualcosa di obbligato, quando siamo in uno standard.

Devi considerare la capacità "parassita" introdotta dai circuiti interni del MCU, quidi una R da 120K, con qualche decina di picoFarad (stima a naso) in parallelo, possono certamente ritardare un segnale in maniera misurabile.

Comunque sia nel precedente post ho descritto i miei risultati, visto che tu ne hai aperto un altro provo a rispondere lì per vedere se sei nelle mie stesse condizioni, però il 644 lo abbiamo programmato tutti, in un modo o nell'altro.....

Il problema sono solo le mille cose che devo fare in questi giorni, e parlo di cose di lavoro che per ovvi motivi hanno la precedenza su tutto.

astrobeed:

[quote author=Michele Menniti link=topic=136740.msg1106877#msg1106877 date=1360171625]
Astrobeed è una persona seria, quindi se non ci ha fornito il bootloader che ci aveva promesso è perché alla fine anche lui probabilmente sta avendo gli stessi problemi nostri e sta cercando di risolverli, compatibilmente con le altre mille cose che ha da fare.

Il problema sono solo le mille cose che devo fare in questi giorni, e parlo di cose di lavoro che per ovvi motivi hanno la precedenza su tutto.

[/quote]
è quello che ho scritto io no? :slight_smile: Personalmente so quanto sei incasinato, e la prova pubblica possiamo considerarla il Topic sulla lib del display I2C. Comunque è ovvio che noi ormai ci siamo arenati, nel senso che siamo arrivati a soluzioni più o meno barbare per riuscire a programmare sia il 644 che il 1284, però la differenza comportamentale tra i nostri vari chip fa capire che il problema sia a monte, ecco perché restiamo con la speranza che tu possa trovare un momento per risolvere la cosa, se ti resta qualche dubbio le prove le facciamo noi e così almeno ti leviamo questo onere.

Ciao a tutti, sono nuovo del forum e penso per chi come me è alle prime armi è fondamentale.
Vengo al sodo : mi sono imbattuto in un 1248p standalone e dopo svariati giorni di lettura e prove, sono riuscito a caricare il bootloader (quello modificato da http://www.leonardomiliani.com/) e il classico blink. Fin qui tutto bene fino a quando ho provato a far blinkare il pin D18-19-20 (pins 24-25-26 del 1284p) con il solito led+resistenza, niente!!!!
Qualcuno sa dirmi se quei pins si possono usare come output? Sbaglio qualcosa? Vi prego illuminatemi!

il blink come lo hai caricato, via seriale o ISP?

Via seriale

Ciao,dovresti dare un po più di informazioni..
Come avrai letti nel topic non a tutti carica gli sketch in seriale,tu come lo hai collegato?
Quindi hai caricato il BL in ISP e poi in seriale hai caricato il blink e tutto ha funzionato,poi hai provato a caricare un'altro sketch,sempre in seriale,che doveva fare dei blink sui pin 24/25/26 ed invece non ha funzionato..Ma l'ide che messaggi ti ha dato?
Più cose spieghi e più è semplice capire ed aiutarti :wink:
Ciao

Ok, mi spiego meglio:
ho caricato il BL via isp, poi come da manuale, ho tolto il micro dall' arduino, ho collegato il TX RX sui pin corrispondenti ed ho iniziato a caricare gli scheth senza problemi, cambiando (dall'esempio blink) di volta in volta il pin di output e spostando il led sul pin corrispondente. Quando sono arrivato al pin 24 (D18) e i tre sucessivi mi sono accorto che ( anche prima di caricare lo schetch) notavo che il led gia' leggermente si accendeva(pensavo fosse perche' non avevo ancora uploadato) ma una volta caricato lo schetch non davano nessun segno di vita.
Domanda: puo' essere che quelle porte siano difettose o che magari ho combinato qualche cavolata innavvertitamente?

se ti funziona su altri pin, potrebbe essere un problema del PORT corrispondente a quei pin o più semplicemente che quei pin NON corrispondano ai pin digitali che stai usando nello sketch

Ho provato a fare un ciclo FOR su tutti i pins e con pazienza collegare tutti i led a tutti. Il risultato è che tutti i led blinkano tranne quelli.
Cosa intendi per un problema di PORT, hw o sw? C'è qualcosa che si può fare per verificarlo?
Intanto grazie al vostro aiuto penso di avere capito che in teoria dovrebbero funzionare........ sbaglio?

Altra prova:
Ho provato a configurare il pin24 (D18) come input e led su pin2 (D1).....

void setup(){
Serial.begin(9600);
pinMode(18, INPUT_PULLUP);
pinMode(1, OUTPUT);
}
void loop(){
int sensorVal = digitalRead(18);
Serial.println(sensorVal);
if (sensorVal == HIGH) {
digitalWrite(1, LOW);
}
else {
digitalWrite(1, HIGH);
}
}

ma niente............

controprova cambiando input (es. D15), e funziona regolarmente.............

mmmmmmmhhhhhhhhhh!!!!!

Lo lancio dalla finestra??????

Ciao,dovrebbe funzionare tutto regolarmente,a questo punto penso che i pin si possano essere danneggiati in qualche maniera.
A me ,sinceramente ,non è mai capitata una cosa simile.

Lo penso anch'io, ma non riesco a capire come posso averli danneggiati !!! Dovrei averne uno di vergine per assicurarmi di questo e credo che lo ordino anche subito, vi aggiornerò appena non avrò il nuovo 1284.
Intanto grazie a tutti.............

  1. che core stai usando?
  2. hai collegato l'alimentazione anche sui pin 30 e 31?