Go Down

Topic: Upload Sketch su Arduino Mega 2560 da rete o via SD (Read 7397 times) previous topic - next topic

Testato

quindi ricapitolando mi stai dicendo che attualmente con l'ide ufficiale non posso caricare il bootloader su una Mega usando arduino uno e mega come isp ?

il discorso della toolchain vecchia credevo influisse soltanto sul caricamento degli sketch via usb, cosa c'entra la toolchain nel momento in cui uso lo sketch ArduinoIsp via ICSP ?
E' quindi colpa dello sketch ArduinoIsp che, compilato con la vecchia toolchain, non riesce a scrivere oltre i 128K via ICSP ?
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

PaoloP

Se non ricordo male non era un problema di scrittura ma di indirizzamento oltre i 128K.

Michele Menniti


Se non ricordo male non era un problema di scrittura ma di indirizzamento oltre i 128K.

Sì, il problema NON riguarda il caricamento di sketch, via ISP o USB che sia, ma il loro funzionamento e, prima ancora, la loro compilazione, laddove sia necessario usare la flash oltre i primi 128 kB ed anche oltre i primi 64 kB, se non ricordo male, se i dati non vengono indirizzati correttamente.
Test, ma perché invece di fare chiacchiere e "supposte" :D al vento non ti leggi le 5 paginette dell'articolo che abbiamo pubblicato sul n.165 della Rivista? L'articolo perlatro lo abbiamo reso libero sul blog; quegli articoli si rifacevano all'uso dell'IDE 1.0.0 che aveva il problema della velocità dell'ArduinoISP, infatti troverai citata ed usata la versione "automatica" di Leo, oggi non serve più, le nuove versioni hanno corretto il problema. Buona lettura. ;)
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Testato

Ricordavo l'articolo, l'ho riletto per ripasso, ma le domande restano le stesse.
L utente qui si lamenta del non riuscire a caricare il bootloader via icsp. Il bootloader è un file.hex, non viene compilato, viene solo scritto nella flash, per questo non capisco cosa centra il problema del compilatore. Lunico sw che viene chiamato in causa durante un caricamento voa Icsp è avrdude
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Michele Menniti

#64
Aug 30, 2013, 02:24 pm Last Edit: Aug 30, 2013, 02:30 pm by Michele Menniti Reason: 1
SICURAMENTE i problemi che sta avendo non c'entrano nulla con la questione che hai "riesumato", e questo è quanto, inutile insistere su questa strada, vedrai che alla fine, seguendo correttamente le istruzioni, tutto riuscirà.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Testato

Mica ho riesumato io, siete voi che avete messo in mezzo dubbi su BL e bug 128kB  :)

Purtroppo non ho 2 mega per fare un test
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Michele Menniti


Mica ho riesumato io, siete voi che avete messo in mezzo dubbi su BL e bug 128kB  :)

Purtroppo non ho 2 mega per fare un test

sì sì, hai perfettamente ragione, sono io che ho fatto casino con l'altro Topic, quindi scusami.
C'è una affermazione di Leo che non mi convince e riguarda il bootloader della mega che non sarebbe in grado di fare upload maggiorni di 128kB, non ne ho notizia, se fosse vero bisognerebbe a questo punto capire se la cosa è legata al solito problema di compilazione, nel qual caso si risolverebbe automaticamente con l'upgrade della toolchain, forse semplicemente ricompilando il bootloader.
Io ho una MEGA ma il mio tempo è ormai ufficialmente sotto 0. =(
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

leo72

Neanch'io ho una Mega per provare per cui non so dirti molto di più.
Il bootloader potrebbe essere capace di scrivere lo sketch oltre i 64 kB, perché ragionandoci sopra... lui dovrebbe passare i dati al circuito integrato nel micro che si occupa della scrittura materiale sulla Flash. Quindi è il micro che materialmente mette i dati sulla Flash. Ma per sapere in che pagina scrivere, dovrà essere istruito per fare questo, ma gli indirizzi li dovrebbe ricevere da avrdude. Io non ho approfondito la scrittura su Flash via ISP per cui mi fermo qui. Magari tu Michele, che hai studiato a fondo la cosa per il tuo programmatore, ne sai più di me.

cece99

Il Vero Programmatore non ha bisogno di manuali sull'assembler, sono
  sufficienti i data sheet dei microprocessori.

Michele Menniti

No, purtroppo non ho studiato il comportamento a livello di registri. Possiamo solo andare per intuito e logica. Partiamo dalla via bootloader. Il problema non è l'upload e quindi l'IDE non c'entra ed il booloader nemmeno. Questo posso dirlo con certezza in quanto la questione all'epoca nacque perché mi contattarono alcuni dei partecipanti al contest di Elettronica In sul TiDiGino che lamentavano comportamenti strani dei loro firmware (tutti diversi, era proprio lo scopo del contest), regolarmente caricato, e quei firmware a mia memoria occupavano intorno ai 120-130k; qualcuno disse che disattivando alcuni moduli tutto andava meglio ma riattivandoli e disattivandone altri tutto andava ancora bene, segno che era proprio un problema di memoria e non di programmazione. Loro avevano su TDG un mega2560 con bootloader "originale" Arduino perché la stessa TDG era una rielaborazione del TDG in chiave di collegamenti GPS, UMTS, GPRS, ecc. Questo lascia un solo colpevole, se non sbaglio, il compilatore, il quale non dava alcun errore in fase di compilazione ma, evidentemente, sbagliava la "traduzione" in assembly (è questo l'hex, vero? abbiate pietà per qualche strafalcione); a questo bisognava sommare una questione puramente tecnica che Astro mi spiegò e che inserimmo nell'articolo, riguardante la corretta allocazione dei dati rispetto al programma, e questo era qualcosa che però dipendeva esclusivamente dal programmatore (v. articolo per i particolari...). Se ora passiamo all'ISP comprendiamo ben facilmente come la tecnica non c'entri assolutamente nulla visto che fondamentalmente la differenza tra seriale e ISP consiste nel fatto che la prima viene autorizzata e pilotata dal bootloader mentre la seconda è gestita da ArduinoISP; la differenza sostanziale sta nel fatto che nella seriale non c'è il chip erase preventivo. Alla fine tutto rimane a carico del compilatore e, se non sbaglio, l'aggiornamento della toolchain va proprio a toccare qualcosa che riguarda la fase di compilazione (correggetemi se sbaglio).

A tal proposito ho fatto un ragionamento circa il fatto che inviando uno sketch con la tecnica ISP si sovrascrive il bootloader; questa è una deduzione che facemmo all'epoca, ignorando alcune cose che approfondimmo in seguito. Il bootloader non viene sovrascritto ma cancellato dal chip erase; e se disattivassimo il chip erase, lavorando con avrdude da riga di comando? a mio parere il bootloader resterebbe operativo e funzionante, specialmente se non tocchiamo i fuse, lasciando quelli arduiniani; ragioniamo: oggi sappiamo che i fuse riservano un'area al bl ma a partire dall'ultima locazione di memoria ed a scendere, in base all'impostazione del fuse high; quindi l'area "application", quella che accoglie lo sketch parte sempre da $0000. Se usiamo un micro con i fuse di Arduino UNO, avremo gli ultimi 512 B riservati al bootloader, se carichiamo su questo micro, mediante ISP standard il bootloader e poi carichiamo uno sketch qualsiasi (max 32k - 0,5k) via avrdude e disattivando il chip erase, metterei la mano sul fuoco che il chip piazzato su Arduino Uno funzionerebbe a meraviglia.

Che ne dite di tutto ciò?
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

Testato

sul discorso che si puo' non far cancellare il bootloader sono daccordo, ed ho fatto prove in tal senso quando approfondii il criptico uso del bootloader da avrdude via usb, per fare cose non previste dall'IDE, se ricordi feci test di lettura flash, lettura eeprom, copia flash incluso bootloader, ecc ecc. poi mi spostai sull ICSP e ricordo di aver verificato che si puo' tranquillamente scrivere uno sketch via ISP sia senza perdere il bootloader (basta che lo sketch non invada il suo spazio), si che si puo' ripristinare in un solo colpo bootloader e sketch.

Sul discorso compilatore anche concordo, INfatti se e' vero che con l'ide si puo' scrivere uno sketch via ICSP, ed in questo caso il compilatore entra in campo, nulla centra quando e' il bootloader ad essere scritto via ICSP. Il BL e' gia' compilato e viene preso e sbattuto in flash da avrdude
- [Guida] IDE - http://goo.gl/ln6glr
- [Lib] ST7032i LCD I2C - http://goo.gl/GNojT6
- [Lib] PCF8574+HD44780 LCD I2C - http://goo.gl/r7CstH

Michele Menniti

Perfetto, grazie della conferma, era un'analisi che avevo fatto da tempo e volevo provarla, ma ora sono certo che è così. Riguardo il bootloader, la sua funzione non ha nulla a che vedere con la problematica over 128k, come detto svolge solo un paio di funzioni ed al massimo fornirà 'indirizzo iniziale $0000 di allocazione meoria per lo sketch in arrivo dalla seriale; proprio perché non entra nelle operazioni di compilazione lo tiene alla larga dalle problematiche.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

leo72

1) confermo: solo il chip erase cancella tutte le celle della memoria del micro; senza chip erase, la programmazione avviene solo per le pagine effettivamente da scrivere, tutte le altre non vengono toccate. Questo è fatto per evitare di riscrivere celle di Flash non interessate dal processo, in modo da non intaccare il loro numero di riscritture. Questo comporta che se il chip aveva uno sketch di 2048 byte scritto sopra ed io ne spedisco uno di 1024 senza chip erase, dal 1025° byte in poi sul chip resta scritto il vecchio sketch (anche se poi il codice dell'ultimo non ci accede). Ciò vale anche per il bootloader, che infatti è in fondo alla Flash. Oltretutto in un'area di memoria che, se non esplicitamente cancellata, è protetta da scritture accidentali dai fuse. Quindi si può spedire anche un firmware di 32 kB esatti ma gli ultimi 256 byte, senza un chip erase, non saranno materialmente scritti perché andrebbero sull'area protetta del bootlader: il risultato sarebbe uno sketch che ad un certo punto dà errori durante l'esecuzione perché manca l'ultimissima parte.
2) l'analisi di Michele conferma quanto da me supposto, ossia che la scrittura avviene correttamente ma che poi è il codice compilato male dal compilatore incapace di usare il 3° byte indirizzi (RAMPZ) per cui i salti a dati oltre i 64 kWord non funzionano.

Michele Menniti


Il problema è che stia usando un qualcosa (Arduino UNO con sketch ArduinoISP?) che non riesca a scrivere oltre la barriera dei 128K di Flash. Siccome il bootloader sta nella parte più alta della memoria, il programmatore DEVE per forza passare oltre i 128K. Magari scrivendo il suo sketch  tale limite non lo supera e l'errore non si presenta.

Quindi era per sapere che versione di Arduino usava e capire quale fosse il bootloader sopra caricato.

Tutta la discussione era nata da questa affermazione; oggi siamo arrivati alla conclusione che il problema non dovrebbe essere questo, visto che un eventuale problema riguarderebbe solo l'utilizzo della memoria da parte dello sketch e non la collocazione di quest'ultimo in fase di upload, men che meno del bootloader che, direttamente, non gestisce dati di alcuna natura. Però, se ragioniamo in termini di ArduinoISP come sketch, allora esso potrebbe essere affetto dal problema, ma in questo caso basterebbe l'aggiornamento della toolchain no?
Sono ragionevolmente sicuro di aver caricato il bootloader sull'Arduino MEGA ADK, via ISP, usando Arduino UNO, quando ho aggiornato la Guida, però non potrei giurarlo né ho tempo in questo periodo purtroppo.
Guida alla programmazione ISP e seriale dei micro ATMEL (Caricare bootloader e sketch):
http://www.michelemenniti.it/Arduino_burn_bootloader.php
Guida alla Programmazione ATmega328 noP:
http://www.michelemenniti.it/atmega328nop.html
Articoli su Elettronica In:
http://www.michelemenniti.it/elettronica_in.html

leo72

Purtroppo, non ho una Mega ed i miei sono ragionamenti.
Non posso provare praticamente le cose.

Go Up