Devo passare da Arduino Mega 2560 ad Due, alcuni dubbi....

Grazie Pablos, come avrai capito nel mio progetto la memoria è importante, se ti va prova a caricare un qualche fonts e cerca di superare i 135KB, prima di rifare tutto vorrei essere sicuro che anche la DUE non abbia lo stesso problema, sopratutto se la colpa sembra non sia della scheda ma del compilatore.

Grazie mille per l'aiuto!!!!

Mandami un link non farmi cercare :slight_smile:

astrobeed:
Non mi risulta che nella versione stabile dell'IDE, la 1.0.5 r2, sia cambiato qualcosa, ovvero il limite dei 128k rimane, però la colpa è del compilatore e non del programmatore.

Se non mi sbaglio,

  • la 1.0.5 usa come compilatore avr-gcc-4.3.2.exe
  • la 1.5.7 usa avr-gcc-4.8.1.exe
    Nel tuo link si parla di aggiornarsi al avr-gcc-4.5.1.exe quindi mi viene da pensare che con la 1.5.7 il problema sia superato. O no ?!?

ho caricato sulla MEGA tutti questi font (allegato)..... che sono tanti sull'IDE 1.5.7

nemmeno un graffio alla ram, possibile?
alla compilazione completa senza errori mi da questi valori :fearful: :fearful:

Lo sketch usa 630 byte (0%) dello spazio disponibile per i programmi. Il massimo è 258.048 byte.
Le variabili globali usano 9 byte (0%) di memoria dinamica, lasciando altri 8.183 byte liberi per le variabili locali. Il massimo è 8.192 byte.

font.txt (305 KB)

nid69ita:

  • la 1.5.7 usa avr-gcc-4.8.1.exe
    Nel tuo link si parla di aggiornarsi al avr-gcc-4.5.1.exe quindi mi viene da pensare che con la 1.5.7 il problema sia superato. O no ?!?

Se non usi la toolchain Atmel te lo puoi scordare di superare il limite dei 128k, o 64 kword se preferisci, il complitore avr gcc non patchato da Atmel non riesce ad indirizzare oltre quel limite indipendentemente dalla sua versione.
Tutte le versioni del IDE superiori alla 1.05 r2 sono delle beta pertanto non affidabili e non conviene utilizzarle per lo sviluppo, vanno bene solo se vuoi fare da beta tester.
Ti faccio un esempio di applicazione open source dove hanno riempito completamente l'ATmega 2560 senza nemmeno utilizzare bitmap da visualizzare su un display, il programma è MultiCopter o MegapirateNG, il secondo è il porting del primo su un hardware diverso come pinout.
Tutte e le applicazioni girano su delle schede basate sul Mega2560 con configurazione Arduino Like, con tanto di relativo bootloader, si tratta di applicazioni per la flight controller dei droni, sono arrivati al limite della flash, il programma compilato è poco meno di 240k, per la compilazione usano un IDE 1.x di Arduino modificato sia per supportare l'HAL (serve per le varie versioni delle schede) sia con la toolchain Atmel proprio per il limite dei 128 k.

astrobeed:
.. il complitore avr gcc non patchato da Atmel non riesce ad indirizzare oltre quel limite indipendentemente dalla sua versione.

Ok, quindi non è solo una questione di versione. Ok. Grazie per la info. :smiley:

pablos:
ho caricato sulla MEGA tutti questi font (allegato)..... che sono tanti sull'IDE 1.5.7

nemmeno un graffio alla ram, possibile?
alla compilazione completa senza errori mi da questi valori :fearful: :fearful:

Lo sketch usa 630 byte (0%) dello spazio disponibile per i programmi. Il massimo è 258.048 byte.
Le variabili globali usano 9 byte (0%) di memoria dinamica, lasciando altri 8.183 byte liberi per le variabili locali. Il massimo è 8.192 byte.

In che senso caricato?
Cosa fa lo sketch?

Se avete problemi con la 1.5.7 consiglio di usare la 1.5.6r2 con il vecchio compilatore avr-gcc.

lo scketch non fa assolutamente nulla il setup() è vuoto e il loop() pure, ho solo messo 1.000.000 di variabili in ram XD

comunque il problema non sussiste più ....

APS650:
.....
Con 64k si farà pure un centralino non discuto, ma una quindicina di schermate su un display TFT 5" con 3 tipi di carattere, icone varie logo del costruttore etc etc non ci stanno!!!! ...o almeno io non ne sono capace!

La soluzione al tuo problema è semplice , le mappe delle schermate non le mettere in flash ma in una memoria esterna, in una SST25VF016B da 2Mbytes SPI oppure se ancora non ti bastano in una SD da 4Gbytes sempre in SPI

OK astrobeed , per l'impossibilità di superare il banco da 64kword imputato al compilatore, pensavo fosse imputato al programmatore, meglio! Così posso continuare a fornire i programmatori economici senza dover comperare programmatori prof.

Non che ci sia bisogno di confermare quanto dice uno come Astrobeed XD ma solo per portare ulteriore testimonianza. L'articolo di cui parla lo abbiamo pubblicato su Elettronica IN n.165 (Aprile 2012) e quindi tradotto in inglese per il blog (il link che ha già postato lui). Lo studio di Astrobeed (io ho avuto solo il ruolo di sperimentatore nella collaborazione, sia ben chiaro!) nacque da una mia richiesta legata ad un problema che Elettronica In stava affrontando con un suo Contest, basato sul TiDiGino, una scheda multifunzione con a bordo un ATmega2560. Coloro che si stavano cimentando nello sviluppo di un firmware per sfruttare tale scheda, incontrarono tutti lo stesso problema, in alcuni casi già a 64K (se non erro quando i dati finivano nei secondi 64k, perché non gestiti correttamente). Da quello studio nacquero le istruzioni per l'aggiornamento della Toolchain, con il quale vennero risolti TUTTI i problemi over 64kW. Nella sezione MegaTopic c'è un Topic specifico nel cui primo post sono riportate le istruzioni, sempre valide, per effettuare tale aggiornamento.

@ Guglielmo e Pablos: poiché conosco i vostri caratteri ho sempre pensato a che spasso sarebbe stata una diatriba tra voi, visto che nessuno dei due avrebbe mai lasciato l'ultima parola all'altro o avrebbe fatto un passo indietro rispetto alle proprie posizioni. Eccomi finalmente accontenato: UN MEGA-SPASSO!!!! Vi adoro XD XD XD XD .... ma occhio al ban, siete proprio sul filo del rasoio :grin:

Pablos per impegnare la memoria i fonts oltre che caricarli li devi usare!!
Metti a video una parola con 10 fonts diversi e vedrai quanta memoria se ne và.

Icio, il display che uso dispone di una SD, ma non sono riuscito ad usarla, senza contare che con tutta probabilità legge una FAT16 da massimo 1 o 2 Gb mentre in qualsiasi negozio non si trovano SD meno di 8 Gb.

cmq nessuno usa la DUE con uno sketch da 150 o più Kb?????????

In giro si trovano microSD diciamo "obsolete" da 1Gbyte a 1 euro - 1.5euro , per fare memorie messaggi o la tua applicazione vanno benissimo

:smiley: :smiley: :smiley:

Non ci siamo mica offesi .... è solo una divergenza di opinioni su un singolo argomento. Io stimo gpb01 è uno che sa quello che dice, come molti altri qui, spero che questo non freni la voglia di aiutarmi nel caso avrò bisogno.

ciao

Ps: facciamo pace gbp? :smiley: :smiley: :smiley:

APS650 Il fatto le si riesca a leggere FAT16 o FAT32 dipende solo da programma che fai tu o che usi tù , qualsiasi AVR ce la fà a leggere/scrivere sia FAT16 che 32, con la FAT32 si arriva facilmente a leggere/scrivere anche le SD da 4Gbytes

pablos:
Ps: facciamo pace gbp? :smiley: :smiley: :smiley:

:astonished: :astonished: :astonished: ... perché ... abbiamo litigato ???? :astonished: :astonished: :astonished:

Guglielmo

APS650:
Metti a video una parola con 10 fonts diversi e vedrai quanta memoria se ne và.

Dipende dal display.
Quale usi?
Io da quando ho scoperto i cosiddetti "display intelligenti", dotati di memoria, SD e processore, gestisco tranquillamente anche più di 10 schermate con la UNO.

paulus1969:
Io da quando ho scoperto i cosiddetti "display intelligenti", dotati di memoria, SD e processore, gestisco tranquillamente anche più di 10 schermate con la UNO.

Hai un esempio (un link a un prodotto) ? Thank you :smiley:

Texas Instruments ha recentemente aggiornato il duo CodeComposeStudio in modo tale da poter diventare un altro IDE per Energia, il corrispondente dell'IDE Arduino per la famiglia dei microcontrollori della TI.
Questa novità permette il debug degli sketch in hardware senza dover inserire dei serial.print con la possibilità del passo-passo e altro ancora.
http://energia.nu/import-energia-sketch-to-ccsv6/

Ma Atmel non potrebbe fare lo stesso?

Guglielmo, sono quasi d'accordo con te. Il quasi deriva dal fatto che l'elettronica si orienta decisamente verso i 3.3v, tanto che gli shield per Arduino hanno spesso gli adattatori di livello, e che gli ARM si stanno decisamente diffondendo. Semmai il problema è che ci sono troppe board con ARM, ognuna con il suo scarso seguito, rispetto ad Arduino. Per cui anche io, se dovessi usare un ARM, probabilmente non userei la DUE ma qualcos'altro (si accettano consigli).

nid69ita:

paulus1969:
Io da quando ho scoperto i cosiddetti "display intelligenti", dotati di memoria, SD e processore, gestisco tranquillamente anche più di 10 schermate con la UNO.

Hai un esempio (un link a un prodotto) ? Thank you :smiley:

Io mi sto trovando bene con i display della 4DSystem.
Come questo:
http://www.elettroshop.com/7-0-diablo16-intelligent-display-module/
si tratta di un 7", ma ce ne sono altri di dimensioni più contenute e che costano meno.
Il bello è che comunica via seriale quindi ti impegna solo 2 pin (tre se consideri anche quello per il RESET del display).
Il display si occupa di gestire grafica e touch, ha anche degli in/out interessanti...
Diciamo che si potrebbe pilotare anche con un ATTINY85 :smiley:

zoomx:
Ma Atmel non potrebbe fare lo stesso?

Che c'entra Atmel ? Se usi il loro Atmel Studio il debug lo fai eccome, e senza i Serial.print ... se poi il Debug non è implementato nel IDE di Arduino ... non è colpa loro ... :roll_eyes:

E comunque ... aspettiamo di vedere Arduino ZERO, che ha un chip per il debug on-board e che probabilmente ... verrà sfruttato dal IDE :wink:

zoomx:
Guglielmo, sono quasi d'accordo con te. Il quasi deriva dal fatto che l'elettronica si orienta decisamente verso i 3.3v ...

Ma guarda che io non ho nulla contro i 3.3V anzi, tutt'altro ... le schede che faccio sono molto spesso, per ragioni di consumo a 3.3V.
Il discorso mio riguarda il "principiante/hobbista/amatore" e ciò che trova attualmente "pronto all'uso" ... :wink:

Guglielmo