[WIN] Aggiornam. compilatore IDE 0022-0023-1.0 all'ULTIMA VERSIONE ATMEL

Sono 2 misure della stessa grandezza. Come quando scrivi 0.1uF o 100nF che si equivalgono.
Occupa 32768 byte oppure 16384 word oppure 8192 long word oppure 65536 nibble (mezzo byte). Come preferisci :wink:

leo72:
Sono 2 misure della stessa grandezza. Come quando scrivi 0.1uF o 100nF che si equivalgono.
Occupa 32768 byte oppure 16384 word oppure 8192 long word oppure 65536 nibble (mezzo byte). Come preferisci :wink:

OTTIMO e chiaro quindi su un mega328P è possibile caricare fino a 16384 word.
Prendiamo il 2560, che è dato per 256Kbyte, giusto? un tizio mi scrive e mi dice ho scritto un firmware di 75Kb e sul mega2560 non funziona, se lo porto a massimo 64Kb funziona, però Astro mi dice che il 2560 con il vecchio compilatore può ricevere fino a 64word, quindi 128byte, quindi?

Tornando sulla memoria, questo è ciò che dice il datasheet:

The ATmega48A/PA/88A/PA/168A/PA/328/P contains 4/8/16/32Kbytes On-chip In-System
Reprogrammable Flash memory for program storage. Since all AVR instructions are 16 or 32
bits wide, the Flash is organized as 2/4/8/16K x 16.

Quindi si tratta, come ti ho detto, di "organizzazione" della memoria, cioè di come il micro accede al suo contenuto. A noi "utenti" non ce ne importa, tant'è che anche Atmel stessa dice che il 328 ha 32 kbyte di memoria.

Ora il bug. In realtà il bug dei 64 kB è... doppio.
Siccome per gestire il PC, il program counter, sono usati 2 registri da 8 bit, si possono indirizzare fino ad un massimo di 65536 valori. Siccome la memoria è organizzata in word, come detto, il bug si presenta nel caso di un salto che vada oltre i 128 kB, ossia oltre i 64kword. Per ovviare a questo bug il nuovo compilatore avr-gcc 4.7 usa infatti 3 registri.
Però c'è anche il bug che affligge il codice compilato: se il codice compilato sorpassa come dimensioni i 64 kbyte, va in blocco il micro: questo bug è causato invece da un altro bug del compillatore che non gestisce correttamente i dati allocati oltre i 64 kB,.

Thanks

@Leo però non ho capito la risposta alla domanda di Testato, anche se sfori di un bit occupi tutta una word successiva?
Nei cluster degli hdd non ci sono il "mezzo cluster alto" e il "mezzo cluster basso" ma ci sono comunque i settori, e un cluster può avere un occupazione parziale dei settori, e basta un settore scritto per far considerare al fs il cluster come occupato, è così anche per le memorie dei micro?.

BB: scusa se riprendo il discorso flash e tralascio volutamente la questione cluster, ma devo concludere urgentemente.
@ Leo riepilogando, ma mi servono i riferimenti sui compilatori 4.3.2 (originale IDE) ed il nuovo 4.5.1, abbiamo che:
4.3.2: ha il limite della compilazione fino a 64kword (128kb) ma un altro bug impedisce il funzionamento per file >32kword (64kb).
4.5.1: sposta il limite della compilazione a 128kword (256kb) [oppure va oltre?] e non dovrebbe avere bug per far funzionare i file >64kb.
E' corretto questo riepilogo?

Vediamo di fare chiarezza sulla questione word e byte.
Il byte, ovvero 8 bit, è l'unità di memoria minima indirizzabile, vale per tutte le mcu e i microprocessori, la word rappresenta la quantità di dati che l'unità di calcolo può trattare ad ogni ciclo macchina, quindi le dimensioni della word non sono un valore fisso perché dipendono dall'architettura hardware.
Sulle mcu AVR la word dati è un byte, sulle mcu con core ARM la word dati è quattro byte, su un processore X86 a seconda dei modelli e di come vengono utilizzati la word dati può essere sia di quattro byte che di otto byte (64 bit).
Quasi tutte le mcu esistenti sono di tipo risc e adottano l'architettura Harvard che prevede una distinzione tra memoria dati e memoria di programma con relativi bus separati.
Sugli AVR la memoria di programma è costituita da due byte quindi la relativa word è di 16 bit, il che ci porta a dover fare una distinzione tra word di programma e word dati, dato che il core degl avr è da 8 bit solitamente per i dati si fa semplicemente riferimento ai byte e non alle word mentre per la memoria di programma si può fare sia riferimento alle word che ai byte realmente impiegati.
Quando si compila un programma il risultato dell'occupazione di memoria viene sempre fornita in byte perché questa è l'unità di misura con la quale viene indicata la memoria totale disponibile nei vari micro, però l'occupazione di questa avviene di due byte in due byte per ogni istruzione assembly, alcune richiedono l'uso di due o tre word nel caso siano da specificare indirizzi estesi.
Per quanto riguarda l'occupazione della memoria di programma da parte dei dati anche in questo caso avviene per word di due byte sugli AVR, cioè se mettere un dato di un byte nella flash questo occupa lo stesso due byte, se inserite un vettore di tipo char composto da 8 elementi occupa quattro word, ovvero 8 byte, se ne mettete uno di 9 elementi occupa 5 word, ovvero 10 byte.
Potete facilmente verificare da voi come viene usata la flash dai dati creando un array con la progmem e controllate la dimensione del compilato ogni volta che aggiungete un carattere, noterete che o aumenta di due byte oppure rimane ferma al valore precedente a seconda se il nuovo carattere viene posto nel secondo byte della word oppure deve essere posto in una nuova word.

No, il limite è 64k word, ovvero 128kbyte di memoria, e i programmi funzionano perfettamente, però non è possibile introdurre dati nella flash oltre i primi 64k, se lo si fa i risultati sono imprevedibili, in linea di massima fino a che il software non tenta di accedere a questi dati funziona tutto, non appena cerca di farlo va in crash.

4.5.1: sposta il limite della compilazione a 128kword (256kb) [oppure va oltre?] e non dovrebbe avere bug per far funzionare i file >64kb.
E' corretto questo riepilogo?

La Toolchain Atmel, e non semplicemente avr-gcc 4.5.1 perché la versione Atmel è modificata rispetto all'originale, permette di compilare sicuramente fino a 256k, oltre non lo se ci va perché non esistono mcu AVR 8 bit con più di 256k, e i dati si possono mettere anche oltre il limite dei 64k, però farlo non è una cosa immediata e semplice perché è indispensabile creare una apposita data_section che deve essere gestita dal linker e per accedervi è necessario usare le relative funzioni di tipo "far" messe a disposizione dalla "progmem".
Detto in modo più semplice, da wiring è praticamente impossibile accedere ai dati in flash oltre i 64k, mentre è fattibile in C ANSI e ovviamente il relativo codice è inseribile in uno sketch di Arduino, però non è semplice da implementare.

Grazie astrobeed per il chiarimento.
quindi l'esempio di Tesato ,più o meno era calzante.

Astro, il primo intervento è chiarissimo; sul secondo mi pare di cominciare a capire (scusa ma è materia nuova per me) che ci sia una differenza tra programma (inteso come istruzioni) e dati, per cui realizzando ipoteticamente un programma da 100K senza dati esso funzionerebbe senza problemi.

Ma la tua affermazione

...e i dati si possono mettere anche oltre il limite dei 64k, però farlo non è una cosa immediata e semplice...

può significare che il famoso sketch del mio amico potrebbe ancora non funzionare, nonostante tutto il lavoro che hai fatto, perché magari non ha gestito correttamente la creazione di una data_section?

Funziona fino a che i dati introdotti nella flash, e rammento che per farlo è necessario usare la progmem, non superano il limite di 64k, un programma composto da 60k di dati, a patto che si trovino sotto il limite, e altri 60k di codice funziona anche con il vecchio compilatore.
Attenzione non è che se definisci dati per tot k < 64k sei certo che si trovano nella parte bassa della flash, in linea di massima è così però non vi è nessuna garanzia che il compilatore non ti mette n k sotto i 64k e altri n k sopra i 64k.
Il brutto è che non ti accorgi dove stanno realmente i dati fino a che non fai girare il programma e tenti di accedere a quelli che si trovano oltre il limite a meno che non vai ad analizzare l'eseguibile tramite emulatore e puoi verificare prima dove si trovano i dati.

Ma la tua affermazione può significare che il famoso sketch del mio amico potrebbe ancora non funzionare, nonostante tutto il lavoro che hai fatto, perché magari non ha gestito correttamente la creazione di una data_section?

Si è possibile, però senza vedere fisicamente il suo software non posso dirti se è incappato in questo problema e come risolverlo.

il secondo quote è un sì? :disappointed_relieved:

E' un si, però ritengo molto difficile che sia incappato in questa cosa a meno che non usa delle LUT di grandi dimensioni.

Ultima domanda: possiamo quindi tranquillamente affermare di aver risolto il problema generale, senza stare troppo ad approfondire la questione?
Concordi con me che se non riesco ad affermare questa cosa, il lavoro resta al livello sperimentale e non è più presentabile/proponibile come un upgrade che risolve un problema ormai noto?

Fra poco posto la tabella con i test che ho fatto con un tri-blink semplice.
EDIT: la sola compilazione (IDE 0022-4.5.1) per un 1284P 1MHz mi dà questo errore:

test_80k.cpp:126:41: error: 'ring_buffer' has not been declared
test_80k.cpp: In function 'void blinkLED(uint8_t, uint8_t, uint8_t)':
test_80k.cpp:256:7: error: 'LEDPIN_TOGGLE' was not declared in this scope
test_80k.cpp: In function 'void annexCode()':
test_80k.cpp:327:42: error: 'V_BATPIN' was not declared in this scope
test_80k.cpp:359:5: error: 'LEDPIN_TOGGLE' was not declared in this scope
test_80k.cpp:361:30: error: 'LEDPIN_OFF' was not declared in this scope
test_80k.cpp:362:17: error: 'LEDPIN_ON' was not declared in this scope
test_80k.cpp:369:7: error: 'LEDPIN_TOGGLE' was not declared in this scope
test_80k.cpp: In function 'void setup()':
test_80k.cpp:396:3: error: 'LEDPIN_PINMODE' was not declared in this scope
test_80k.cpp:397:3: error: 'POWERPIN_PINMODE' was not declared in this scope
test_80k.cpp:399:3: error: 'STABLEPIN_PINMODE' was not declared in this scope
test_80k.cpp:400:3: error: 'POWERPIN_OFF' was not declared in this scope
test_80k.cpp: In function 'void loop()':
test_80k.cpp:544:23: error: 'STABLEPIN_ON' was not declared in this scope
test_80k.cpp:544:36: error: expected ';' before 'else'
test_80k.cpp: At global scope:
test_80k.cpp:1722:23: error: 'MOTOR_ORDER' was not declared in this scope
test_80k.cpp:2129:35: error: 'ROLLPIN' was not declared in this scope
test_80k.cpp:2129:44: error: 'PITCHPIN' was not declared in this scope
test_80k.cpp:2129:54: error: 'YAWPIN' was not declared in this scope
test_80k.cpp:2129:62: error: 'THROTTLEPIN' was not declared in this scope
test_80k.cpp:2129:75: error: 'AUX1PIN' was not declared in this scope
test_80k.cpp:2129:83: error: 'AUX2PIN' was not declared in this scope
test_80k.cpp:2129:91: error: 'CAM1PIN' was not declared in this scope
test_80k.cpp:2129:99: error: 'CAM2PIN' was not declared in this scope
test_80k.cpp: In function 'void __vector_6()':
test_80k.cpp:2240:21: error: 'THROTTLEPIN' was not declared in this scope
test_80k.cpp: In function 'void i2c_init()':
test_80k.cpp:2488:3: error: 'I2C_PULLUPS_DISABLE' was not declared in this scope
test_80k.cpp: In function 'void Mag_getADC()':
test_80k.cpp:3187:7: error: 'LEDPIN_TOGGLE' was not declared in this scope
test_80k.cpp: In function 'void initSensors()':
test_80k.cpp:3316:3: error: 'POWERPIN_ON' was not declared in this scope
test_80k.cpp: At global scope:
test_80k.cpp:3342:1: error: 'ISR_UART' does not name a type

Si, ovviamente non posso garantire che saltano fuori nuovi problemi in condizioni particolari, il lavoro dei beta tester serve proprio per trovare i bug, però visto che mi funziona correttamente anche con sketch complessi penso di poter affermare che è tranquillamente utilizzabile considerandola una release 1.0 definitiva di questa patch.
Sicuramente ci saranno nuove release nel futuro legate sia a nuove versione della toolchain che dell'IDE o ad eventuali bug fix.

Fra poco posto la tabella con i test che ho fatto con un tri-blink semplice.
EDIT: la sola compilazione (IDE 0022-4.5.1) per un 1284P 1MHz mi dà questo errore:

Sono tutti errori di mancata definizione di nomi simbolici, non è certo colpa del compilatore :slight_smile:

astrobeed:

[quote author=Michele Menniti link=topic=96976.msg744088#msg744088 date=1333180762]
Ultima domanda: possiamo quindi tranquillamente affermare di aver risolto il problema generale, senza stare troppo ad approfondire la questione?

Si, ovviamente non posso garantire che saltano fuori nuovi problemi in condizioni particolari, il lavoro dei beta tester serve proprio per trovare i bug, però visto che mi funziona correttamente anche con sketch complessi penso di poter affermare che è tranquillamente utilizzabile considerandola una release 1.0 definitiva di questa patch.
Sicuramente ci saranno nuove release nel futuro legate sia a nuove versione della toolchain che dell'IDE o ad eventuali bug fix.
[/quote]
MI BASTA MOLTISSIMO, nuovi bug, nuove soluzioni, nuovi articoli :grin:

Fra poco posto la tabella con i test che ho fatto con un tri-blink semplice.
EDIT: la sola compilazione (IDE 0022-4.5.1) per un 1284P 1MHz mi dà questo errore:

Sono tutti errori di mancata definizione di nomi simbolici, non è certo colpa del compilatore :slight_smile:
[/quote]
quindi come risolvo per caricare lo sketch sul micro? può essere che mi manchi <avr/pgmspace.h>?

Ti manca un qualche include o delle dichiarazioni, sono tutti nomi simbolici che non hanno nulla a che vedere con il compilatore.

sembra che tu stia usando qualche libreria non dichiarata

Sì, ma io non ho fatto altro che scaricare il rar di Astro "toolchain_test", estrarre la cartella "test_80k", v. immagine contenuto, ed eseguirla, quindi mi manca qualche libreria che Astro ha ed io no, se non so qual'è lo sketch diventa inutilizzabile da chiunque :disappointed_relieved:
A proposito, ma tutta quella roba nella cartella serve o mi basta il solo test_80K.pde?

EDIT: allego anche il riepilogo dei test fatti con le varie versioni di compilatore (AVRDUDE.EXE e .CONF identici per tutt'e tre) e con le tre versioni di ISP a disposizione, il tutto su tre diverse MCU: a quanto pare non si riesce a programmare il 1284P con l'ISP1.0.1 mentre non ci sono problemi con l'ISP della 0022 e con la versione patchata di Leo.
A questo punto devo fare qualche test con TiDiGino, basato sul mega2560.
Il test è con uno sketch blink su tre diversi pin (per mia comodità), 1K;
Ho provato a ridurre a 9600 ISP1.0.1 ma l'errore diventa:
avrdude: stk500_getsync(): not in sync: resp=0x00
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0x66

test_80k.jpg

Quello sketch utilizza MultiWii 1.9, il software per i quadricotteri, come base e l'ho rimaneggiato per farlo diventare più grande inserendo degli arryay dati di grosse dimensioni, tutti i file allegati fanno parte del codice e servono, a me si compila senza problemi per l'Arduino MEGA2560 e MEGA1280.
Dato che il codice controlla quale micro è utilizzato tra 328, 1280 e 2560 è possibile che con il 1284 saltano fuori degli errori per via della mancata corrispondenza hardware.