Bootloader

Sto lavorando ad una mia idea (una di quelle tipo l'SRAM, per intenderci... uan di quelle diaboliche ]:D) e devo capire un po' di più sul bootloader.

Perché aprendo la cartella /arduino/hardware/arduino-00xx/bootloaders/optiboot il file optiboot_atmega328.hex è grande 1,4 KB? Non dovrebbe essere 512 byte? Forse il file binario si porta dietro altri dati? Che dati? E dove vengono messi?

Per modificare il bootloader, su quale file devo agire? Su bootloader.c? Ed a cosa serve il file optiboot_atimega328.lst che, a prima vista, sembra anch'esso un file di codice?

I file .hex non sono in formato binario, sono in formato ASCII e contengono i vari codici esadecimali, scritti sotto forma di due caratteri ASCII, che compongono il vero formato binario, i dati contenuti possono essere organizzati in vari modi a seconda dello standard usato inoltre il file hex può contenere anche dati per precaricare la EEPROM e i fuse. I file .lst sono un sottoprodotto del compilatore, vengono generati solo se espressamente richiesto, e contengono le informazioni sull'allocazione della memoria, il listato assembler ottenuto dal sorgente c e altre informazioni a seconda dei parametri di compilazione.

Quindi il file .lst è un "prodotto" della compilazione, non un file necessario ad essa. Ok. Perciò dovrei lavorare solo sul bootloader.c, giusto? Ma come faccio a sapere la dimensione finale della memoria occupata, se il file HEX si porta dietro tutte queste info aggiuntive? Non posso cioè basarmi sulla sua dimensione, perché essa è "falsata".

Si devi lavorare solo sul file .c, la dimensione reale del programma te la dice il compilatore alla fine del processo. Che ambiente di lavoro stai usando per ricompilare il bootloader ?

Ancora non ho mosso un passo, ma essendo su Linux userò qualche strumento open. A tal proposito, tu hai qualche consiglio? Non ho mai programmato in C finché non ho iniziato ad usare Arduino, quindi non so cosa possa essere meglio.

Il mio ambiente di lavoro primario è Windows e per gli AVR uso AVR Studio abbinato al compilatore IccAVR, tieni presente che il mio è un uso professionale anche se gli AVR non sono la famiglia principale di micro 8 bit che uso.

Sto lavorando ad una mia idea (una di quelle tipo l'SRAM, per intenderci... uan di quelle diaboliche smiley-twist) e devo capire un po' di più sul bootloader.

Quelle del tipo, ma no non si può fare, non conviene, ma usa altro ecc. Mi piacciono queste idee anche se non so cosa hai in mente.

Se sotto linux nella shell scrivi avr- e dai un paio di tasto tab noterai molti eseguibili che iniziano appunto con avr- uno di questi è avr-size, che dovrebbe mostrarti la dimensione effettiva. Nota che puoi usare degli argomenti ma il manuale se ricordo bene dice che riconosce il formato automaticamente, quindi dovrebbe bastare avr-size file.hex.

Quindi il file .lst è un "prodotto" della compilazione, non un file necessario ad essa.

Esatto, si devono specificare alcuni argomenti sulla riga di comando durante la compilazione e durante il linker, per ottenere dei file supplementari, ad esempio è possibile produre di ogni sorgente compilato il corrispondente file in assembley, oppure puoi chiedere al preprocessore di mostrarti il suo lavoro.

Il processo di compilazione di base è composto dalle seguenti fasi preprocessore c o c++ avr-gcc o avr-g++ compilatore c o c++, sempre gcc o avr-g++. il linker lo stesso.

Questa fase produce un file in formato .elf, che tramite avr-objcopy viene trasformato in formato ihex (intel hex).

Leo72 chiedi pure sul compilatore perchè anche se non so risponderti mi vado a spulciare la doc perchè mi interessa avere più info possibili sul processo di compilazione.

Attendo info sulla tua idea. Ok ciao.

Allora, l'idea è questa. Stavo studiando la possibilità di riscrivere il bootloader in modo che possa caricare in flash uno sketch trovato su una SD esterna ;)

Perché questa cosa? L'idea è alla base della progettazione di un Arduino/Atmega in condizioni difficili da programmare, ad esempio in un progetto standalone a cui l'accesso con un programmatore e/o computer sia difficile, e l'asportazione dell'Atmega per la programmazione non sia possibile. Immaginate, ad esempio, un Arduino chiuso nella sua bella scatoletta, che per toglierlo da lì dovete moccolare mezz'ora. Oppure un Atmega che, per motivi economici o di altezze, avete saldato direttamente sulla PCB. Avete magari la scatoletta contenente il vostro dispositivo nella soffitta di casa oppure inserita in una centralina ecc... a cui l'accesso con un PC non è pratico. Però avete dotato il vostro dispositivo di una piccola schedina esterna con un lettore SD/MMC.

Vi preparate lo schema a casa, salvate il file sulla SD e poi arrivate sul posto ed infilate la schedina nel lettore, premete un tastino et voilà! Senza nessuno strumento extra l'Atmega legge il nuovo sketch e si riprogramma in automatico XD

Non è fantastico?? Sembra una cosa improbabile? No! L'hanno già fatto: http://www.mikrocontroller.net/articles/MMC/SD_Bootloader_f%C3%BCr_AT_Mega (traducete con Google)

Ecco, io vorrei però fare un'integrazione fra quel codice ed il bootloader dell'Arduino, così che se decidete comunque di portarvi dietro un PC, potete programmare l'Atmega senza smontarlo dalla sua scheda o dall'Arduino. Perché quel codice, da quel che ho capito, fa solo l'upload da una SD ma non credo gestisca la comunicazione col PC (perché è scritto per un Atmega, non per un Arduino).

Non è male, no? ;) Il bootloader parte; controlla se c'è una SD; se c'è, controlla che ci sia un file "adatto"; lo carica e lo controlla; se è a posto, lo scrive nella Flash e poi lo esegue; altrimenti esegue lo sketch memorizzato.

tutto Ok ma devi sostiture il Bootloader Arduino con il Bootloader SD. Non vedo possibilitá di avere tutte due le cose ecetto che riscrivi il Bootloader Arduino e aggiungi anche la funzionalitá SD. Ciao Uwe

Infatti io voglio/vorrei riscrivere il bootloader integrando le funzionalità SD in modo da avere sia l'una che l'altra cosa ;)

In bocca al Lupo Stai imparando assembler? Ciao Uwe

Non conosco ancora l'assembly degli Atmega perché non ho mai avuto la necessità di usarlo però conosco l'assembly in generale dato che (tanti) anni fa ho programmato in assembly (7501 del Commodore 16 e i8086 del PC XT).

Il comodore 16 aveva un 7501? non avevano la serie 6500? Il vic20 aveva un 6504 e il C64 un 6510; di questo sono sicuro. Ricordarsi queste cose dopo 30 anni...

Correzione: Il vic20 aveva un 6502.

Ciao Uwe

Ti correggo, il VIC20 aveva un 6502 ;) Il C64 aveva un 6510, derivato direttamente dal 6502, da cui differiva per alcune piccolezze. Il C16 e Plus4 avevano un 7501, che derivava a sua volta dal 6510. Erano comunque tutte CPU della famiglia 65xx, come hai giustamente precisato

Ho queste cose fresche nella memoria perché negli ultimi mesi ho riscritto tutte le voci della Wikipedia sullo Z80, il 6502/6510/7501, il 6800 di Motorola ecc... XD

ufff vi invidio ad aver giocato con quelle macchinette. io sono molto più giovane e mi devo accontentare dei simulatori per il 6800 di Motorola (se non erro) e per scopi didattici...

edit: vi romperò le balle quando avro qualche problema con gli esercizi :)

leo72 secondo me non è troppo difficile, basta modificare il codice attuale che "legge" la seriale per "leggere" la sd, certo che il boot loader divente un bel pò più tosto.. forse puoi sfruttare le libreria SD FAT già fatte, ma non vorrei dire castronate, altrimenti ti tocca scrivere il driver per scrivere l'SD in formato raw usato sull'arduino

L'idea dell' sd non la capisco. Costa di meno e funziona meglio con meno fatica mettere un ftdi con la porta usb e collegarci un portatile per riprogrammare il tuo oggetto...

ps: Ci fai sentire dei vecchi? Io ho 31anni e c'erano ancora un po' dappertutto questi oggetti... Io programmavo il basic sul c64 a 13 anni mi pare, anche se ora non ricorderei neanche la giusta sintassi per il "load"...

ciao leo72

mi sembra un bel progetto

La discussione su mikrocontroller.net continua per decine di post finché non arrivano ad una versione limata (e google translate getta la spugna a metà discussione...) questa è l'ultima versione http://www.mikrocontroller.net/attachment/30080/MMC_Bootloader_ATMega88.rar

Gli strumenti di sviluppo sono già compresi in arduino, basta andare nella directory Bootloader e scrivere "make"

ho cambiato Makefile mettendo questi valori BOOTLOADERSTARTADR = 0x7800 BOOTLDRSIZE = 0x800 F_CPU = 16000000 MCU = atmega328p

e compila

Ora sarebbe da provare su un'arduino con shield ethernet

Nella discussione si parla di ottimizzazioni varie ma dubito che tu riesca a mettere entrambi i bootloader dentro i 2 k... il tuo miglio candidato è optiboot che usa solo 512byte di flash.

Link al thread http://translate.googleusercontent.com/translate_c?hl=en&ie=UTF-8&langpair=auto|en&u=http://www.mikrocontroller.net/topic/66690&tbb=1&rurl=translate.google.com&usg=ALkJrhjb7yJsg86WdYpSwqWZTkzhyoj0Hg#new

Userò sicuramente la libreria già fatta, perché di scriverla ex-novo non ne vedo la necessità (perché reinventare la ruota?). Se poi il bootloader cresce, questo non è un problema dato che ho già preventivato la cosa.

Mi manca solo... lo slot SD, ora :cold_sweat:

ho trovato questa discussione molto interessante, non se ne e' fatto piu' nulla ? mi piacerebbe collaborare alla cosa magari su AtmelStudio

Ho portato l'optiboot ultima versione, 5.0a su AtmelStudio, non compilava perche' uno dei comandi per l'ottimizzazione e' diventato obsoleto : mshort -calls

La cosa interessante e' che cercando info su questo punto ho trovato due flag di ottimizzazione ed override che oltre ad essere compatibili con ultima toolchain riducono ancora di piu' la dimensione, su 328 siamo a 482, rispetto ai passati 504B

Questa la porzione di makefile che ho modificato, ho commentato e lasciato vecchi e nuovi flags per testare facilmente

OBJ        = $(PROGRAM).o
# Modificato: -mshort-calls obsoleto, usare -mrelax
# OPTIMIZE = -Os -fno-inline-small-functions -fno-split-wide-types -mshort-calls
# OPTIMIZE = -Os -fno-inline-small-functions -fno-split-wide-types -mrelax
# Riduce ulteriormente dimensioni, da usare insieme a override LDFLAGS
OPTIMIZE   = -Os -ffunction-sections -fno-move-loop-invariants

DEFS       = 
LIBS       =

CC         = $(GCCROOT)avr-gcc

# Override is only needed by avr-lib build system.

override CFLAGS        = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) -DF_CPU=$(AVR_FREQ) $(DEFS)
# override LDFLAGS       = $(LDSECTIONS) -Wl,--relax -nostartfiles -nostdlib
#-Wl,--gc-sections (disabilitato in origine)
# Riduce ulteriormente dimensioni, da usare insieme a OPTIMIZE
override LDFLAGS = $(LDSECTIONS) -Wl,--relax -nostartfiles -nostdlib -Wl,--gc-sections