Dimensioni sketch 328P vs 32u4

Blink su 328P

Lo sketch usa 1.116 byte (3%) dello spazio disponibile per i programmi. Il massimo è 32.256 byte.
Le variabili globali usano 11 byte (0%) di memoria dinamica, lasciando 2.037 byte liberi per le variabili locali. Il massimo è 2.048 byte.

Blink su 32u4

Lo sketch usa 5.138 byte (17%) dello spazio disponibile per i programmi. Il massimo è 28.672 byte.
Le variabili globali usano 153 byte (5%) di memoria dinamica, lasciando 2.407 byte liberi per le variabili locali. Il massimo è 2.560 byte.

Mi aspettavo differenze ma non il 400% in piu' :fearful:

Credo sia dovuto alla parte Seriale/Usb che l'IDE si tira dietro comunque.
Stanotte faccio le prove anche con la mia configurazione: IDE 1.5.5 + Toolchain 3.4.3.

Come ti ha detto Paolo è causato dal blocco seriale, cioè dal fatto di avere intanto 2 seriali, e poi di gestirsele da sé senza demandare nulla ad un convertitore USB/seriale come sulla Uno (con il 16U2) per la comunicazione verso il computer.

Comunque tu hai compilato con la 1.5.5, vero?
Con la 1.0.5, lo spazio è di 4826 byte. Pensa un pò quanto incide il core, cioè tutte quelle librerie che, anche se non usate, l'Arduino si trascina dietro e si compila lo stesso.

ma nel blink la seriale non e' impostata, perche' le usa lo stesso ?
Il compilatore non si accorge che non viene usata sta roba ? non e' compito suo ?
oppure e' colpa del core arduinico che potrebbe essere migliorato ?

anche perche' questo 32u4 alla fine diventa piccolissimo, perche' parte lo ruba il bootloader, poi sta bubbazza la rubano le due seriali, in pratica si ha meno spazio a disposizione per gli sketch rispetto al 328

Il core, se mai ti venisse voglia di dargli un’occhiata, è un’articolazione di #include che ti viene il mal di testa a seguire tutte le diramazioni :sweat_smile:
Tante cose sono scartate, è vero, ma tante sono incluse nel codice finale anche se non usate direttamente solo perché usate da file inclusi da altri file… :sweat_smile:

L’esempio più semplice è lo sketch seguente:

void setup(){}
void loop(){}

Compilato per Uno, da 466 byte. Compilato per la Leonardo sono 4.242 byte! Ecco il peso del core, cioè semplificare all’utente appesantendo il codice.

Sempre geniale leo! Questo esempio è eccelso.
E secondo te non ? migliorabile la situazione ? Intendo in futuro dal team ?
Ad oggi possiamo dire che gli Arduino con 32u4 hanno 26kB di flash utile.

Arduino è nato per semplificare le cose agli utenti. Fornisce tanta pappa pronta, esempio banale: il PWM. L'utente fa analogWrite(pin, valore) e stop. Ma dietro le quinte il core ha prima inizializzato i timer, poi quando il programma trova la funzione analogWrite va a recuperare il piedino fisico dal valore di "pin" passato, dopo scrive "valore" nel registro del timer. Eventualmente prima stacca un eventuale segnale presente su quel pin. Insomma fa un sacco di cose ma tutte trasparenti all'utente. Se poi prendiamo funzioni un pò più complesse come la gestione della seriale o dell'I2C, allora lì sono dolori...

Vuoi semplificare? Non usare l'IDE. Scrivi un programma in C/C++ con Atmel Studio.
Però ti devi sbattere a rifare a mano tutto quello che il core di Arduino fa lui. In compenso mettendo solo quello che ti serve lo sketch è enormemente più leggero.

PaoloP:
Stanotte faccio le prove anche con la mia configurazione: IDE 1.5.5 + Toolchain 3.4.3.

UNO con 1.5.5 + TC 3.4.3

Lo sketch usa 1.062 byte (3%) dello spazio disponibile per i programmi. Il massimo è 32.256 byte.
Le variabili globali usano 11 byte (0%) di memoria dinamica, lasciando 2.037 byte liberi per le variabili locali. Il massimo è 2.048 byte.

Leonardo con 1.5.5 + TC 3.4.3

Lo sketch usa 4.858 byte (16%) dello spazio disponibile per i programmi. Il massimo è 28.672 byte.
Le variabili globali usano 153 byte (5%) di memoria dinamica, lasciando 2.407 byte liberi per le variabili locali. Il massimo è 2.560 byte.

UNO con Nightly Build (1.5.6 beta)

Lo sketch usa 1.116 byte (3%) dello spazio disponibile per i programmi. Il massimo è 32.256 byte.
Le variabili globali usano 11 byte (0%) di memoria dinamica, lasciando 2.037 byte liberi per le variabili locali. Il massimo è 2.048 byte.

Leonardo con Nightly Build (1.5.6 beta)

Lo sketch usa 5.138 byte (17%) dello spazio disponibile per i programmi. Il massimo è 28.672 byte.
Le variabili globali usano 153 byte (5%) di memoria dinamica, lasciando 2.407 byte liberi per le variabili locali. Il massimo è 2.560 byte.

Quindi un eventuale inserimento della nuova Toolchain nelle versioni future può migliorare ma sono briciole.
Leo tutto quello che dici lo capisco, ma anche il 328P si porta dietro sta roba.
Vuol dire che il 32u4 è molto più complicato da gestire a basso livello, ma del 400% ?
Io dico che c'è qualcosa che non va, un bug che si fa tirare dietro roba che non serve.
Ma io oltre a fare un ipotesi non posso, si potrebbe aprire una segnalazione di bug e vedere se vuene chiusa con una spiegazione ? Se il team dice che il 400% in piu dipende da questo e quello, impaeiamo e ci mettiamo l'anima in pace :slight_smile:

Allora, esaminiamo bene la cosa …

Codice usato come esempio :

void loop() {};

void setup() {};

ed in allegato abbiamo sia i listati della compilazione (ottenuti con il “verbose” attivo), sia (… purtroppo in jpg) le immagini del contenuto della directory temporanea usata per la compilazione.

Se confrontate le cose … salta bene all’occhio che :

CDC.cpp.o sulla UNO è di 2.2K … sulla Leonardo 26.8K
HID.cpp.o sulla UNO è di 2.2K … sulla Leonardo 26.9K
USBCore.cpp.o sulla UNO è 2.2K … sulla leonardo 38.3K

… devo aggiungere altro ???

Guglielmo

Edit : Arduino IDE 1.0.5 standard

Arduino_UNO.txt (20.4 KB)

Arduino_Leonardo.txt (21.6 KB)

interessante, grazie

ma questi file sono tutti pezzi di codice dai quali estrarre solo cio' che serve, non e' che vengono nella totalita' inclusi nel .hex finale, altrimenti altro che 4kB, sarebbe 1MB :slight_smile:

Quindi secondo me sottolineare che HID sia di 25kB piu' grande che sulla UNO (ed e' giustificato in quanto sulla UNO l'HID e' gestito dall'8u2), non significa poi spiegare o essere sicuri che non ci sia un bug, in quanto sullo sketch testato non serve niente dell'HID, quindi mi aspetto che da quel file HID venga tirato fuori un qualche striminzito define utile alla compilazione e basta.

Forse punterei piu' l'occhio sul core che e' di quasi 100kB piu' grande, ma anche li' vale la stessa obiezione, non e' che dentro al codice macchina va a finire tutto il core del 328P e quindi nemmeno del 32u4

la risposta in pratica non l'abbiamo :slight_smile:

La risposta c'era già, te l'avevo data all'inizio. I dati di Guglielmo te lo dimostrano. Tutta la parte di gestione della USB (CDC, HID, USB) pesa come un macigno sul firmware perché è vero che le periferiche sono integrate ma le devi anche gestire, e per gestirle ci vuole il software.

se volete che vi dica di si io lo faccio, ma la risposta, per come io intendo una risposta fatta di dati da analizzare, non c'e', perche' io parto dal presupposto che e' vero che ad esempio dentro al micro ho la periferica HID, ma se non chiamo nessuna funzione dell'HID, cioe' niente mouse e niente tastiera, l'HID non occupa nulla nel .hex finale.

E’ vero quel che dici ma ti ho spiegato che i file del core si autoincludono tra di loro e porzioni di questo o quello sono comunque incluse.
Ricordati che lo sketch dell’Arduino NON è il vero programma principale, il vero programma principale è il main.cpp. Questo è questo:

#include <Arduino.h>

int main(void)
{
	init();

#if defined(USBCON)
	USBDevice.attach();
#endif
	
	setup();
    
	for (;;) {
		loop();
		if (serialEventRun) serialEventRun();
	}
        
	return 0;
}

Come vedi, c’è un if con un controllo sugli eventi della seriale, per cui la seriale viene sempre inclusa anche se tu non la usi nel tuo sketch.

E non solo. Se decommenti l'include e quell'if, viene fuori un sacco di errori da IPAddress.cpp relativi alla funzione Print, alla struct Print ed al file Printable.h! Pensa te che caos c'è nel core di Arduino :cold_sweat:

Grazie, è sempre un piacere leggerti, ti meriti un ennesimo karma.

Che fosse L'Open Source il problema ? :slight_smile:
Tutti ci mettono mano, si aggiunge, si aggiunge, e dopo un tot di anni nessuno conosce a fondo il progetto ma solo piccoli pezzi.

Non credo.
Considera che il progetto è sì opensource, nel senso che vengono rilasciati i sorgenti, ma lo sviluppo è portato avanti da un ristretto numero di persone. Tu puoi prendere quei sorgenti e modificarli ma se vuoi che le tue modifiche siano inserite nel progetto originale devi sottoporle al gruppo che ne cura lo sviluppo.

Ma con questo non li stai aiutando perché rimane l'ultima opzione, l'incompetenza :slight_smile: ?

Test, se leggi il forum degli sviluppatori su Google Group (non è necessario avere un account Google+) vedrai che ogni tanto esce qualcuno con una proposta "bizzarra" ma che viene comunque discussa e nel caso accantonata.
Lo stesso avviene per le pull-request su GitHub e le Issue.

Non è che tutte le "minchiatine" richieste o le correzioni proposte vengono in automatico messe nel core... :fearful:

Esatto, c'è comunque la discrezionalità del gruppo di sviluppo dietro alle proposte presentate.

Ma il bello dell'opensource è che se a te (generico, non te personalmente) non piace come viene portato avanti il progetto, puoi forkarlo e crearti una toolchain tutta tua :wink: