[Linux] Aggiornare la toolchain Avr

In questo thread parleremo di come aggiornare la toolchain Avr sul sistema operativo Linux.
Il materiale di partenza è lo script presente a questa pagina:
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42631

Con questo script si scarica e si compila (patchata) la toolchain Avr con avr-gcc alla versione 4.5.1
Il problema è che poi si ha una cartella contenente l'albero della toolchain completa e.... come usarla per sostituirla a quella della propria distribuzione?

Altro quesito: qualcuno ha compilato ed installato la toolchain ufficiale Atmel??

Allora, facciamo le cose con ordine.

Il link su avrfreaks porta nel primo post 3 file da scaricare, il primo di questi permette la creazione della toolchain con avrgcc 4.5.1 ecc.

Ma qui http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=115567 c'è anche un'altro file che colpisce la mia attenzione specie per il nome "buildavr-gcc-4.5.1-atmel-3.3.1-avrtools-v2.zip", cosa vorrà dire atmel-3.3.1?

Aprendo il primo file compresso si scopre che ci sono degli script che scaricano delle patch da freebsd, quindi sono delle patch sviluppate da freebsd.
Ora queste patch io non ho avuto ancora modo di studiarle, non applico pacth se non controllo per principio e non per malafede in freebsd.

Il file che scarica le pacth è get-patches.sh che compie questa operazione con wget. Io sto pensando di installare una versione di Fedora su una partizione e fare delle prove, perchè al momento la situazione del sistema in uso attuale mi sta più che bene e non voglio compromettere la stabilità. Per ubuntu o altre distro che usano il formato di pacchetti .deb mi devo documentare ma credo che basti fare un "cat" per concatenare tutte le patch in un unico file .diff e modificare ogni file .desc per fargli applicare le patch prima della compilazione e seguente creazione del pacchetto binario .deb.

Ora riuscendo a pacthare il tutto e ad installare tutto correttamente nei posti giusti rimane sempre il problema dell'ide, cioè come fare in modo che l'ide usi avr-g++ installato in /usr/local/bin anziche quello presente in /usr/bin. Si potrebbe risolvere rimuovendo i pacchetti avr-gcc installati in /usr e inserire i file manualmente, presi dalla directory di cui parla Leo, ma questo lavoro bisogna farlo manualmente.

Allora la soluzione di eccelenza per me è quella di ricreare i pacchetti binari .deb prendendo gli originali modificarli e avviare la costruzione del pacchetto. Se tu Leo vuoi tentare questa strada posso provare a guidarti, qualcosa di debian me la ricordo ancora. Dimmi la distro che usi ed eventualmente se lo sai il repo da cui prendere i pacchetti originali.

Altro quesito: qualcuno ha compilato ed installato la toolchain ufficiale Atmel??
http://www.atmel.com/tools/ATMELAVRTOOLCHAIN3_2_3FORLINUX.aspx

Allego solo il penultimo file nella lista presente a quel link per motivi di spazio, come vedi sono solo patch e se guardi in ogni file vedi sono modifiche inerenti avr32. Non ti nascondo che quei link mi lasciano un pò smarrito.

Mo vado a magna, ciao.

avr32-gnu-toolchain-3.2.3.261-source.zip (475 KB)

Ora riuscendo a pacthare il tutto e ad installare tutto correttamente nei posti giusti rimane sempre il problema dell'ide, cioè come fare in modo che l'ide usi avr-g++ installato in /usr/local/bin anziche quello presente in /usr/bin. Si potrebbe risolvere rimuovendo i pacchetti avr-gcc installati in /usr e inserire i file manualmente, presi dalla directory di cui parla Leo, ma questo lavoro bisogna farlo manualmente.

perchè non provi a sostituire con un hardlink che punta a quelli appena compilati?

Vediamo se riesco a riassumere alcuni punti ed alcune prove che ho fatto.

Premessa: Kubuntu 11.04 con avr-gcc/binutils/avr-libs presenti nei repo ufficiali Ubuntu

Ho scaricato il 1° script del thread di avr-freaks, quello denominato
build-avr-gcc-4.5.1-binutils-2.20.1-libc-1.8.0-gdb-7.3.1-dude-5.11.1-avarice-2.12-aw.zip

Scompattandolo, si hanno alcuni file .sh. Eseguendoli secondo il readme, essi prelevano prima i sorgenti, poi le patch ed infine compilano tutto. Non ho installato nulla sul sistema perché non so esattamente come dividere tutti i file perché sono 97.300!!!! 917 MB di eseguibili, file oggetto, librerie ecc... Una cosa impossibile da gestire a mano! Quindi ho provato l'approccio dell'IDE di Windows: ho copiato la cartella /avr che si è creata all'interno della cartella contenuta in /arduino-0022/hardware/tools, andando praticamente a sovrascrivere la cartella /avr lì presente, che alla fine non contiene nient'altro che una lib per gestire la EEPROM.

Poi ho disinstallato avr-gcc/binutils/avr-libs dal mio sistema ed ho provato a compilare uno sketch. Risultato: l'IDE non trova il compilatore. Come faccio a dire all'IDE di usare il compilatore che ha al suo interno? Qual'è il settaggio che sulla versione di Windows dice all'IDE di usare avr-gcc contenuto in /hardware/tools/avr/ecc... al posto di quello presente nel sistema?

PS:
non mi ricordo da dove l'ho tirato fuori, ma ho anche questo link:
http://www.wrightflyer.co.uk/avr-gcc/

In fondo vedete dei pacchetti .deb che si chiamano
avr-gcc-4.5.1-avrfreaks-2011-dec-29-u10.04.i386.deb

C'è anche un .txt che riporta (cito):
Description: Ubuntu 10.04 i386 avr-gcc toolchain based on the below script from AvrFreaks.
build-avr-gcc-4.5.1-binutils-2.20.1-libc-1.8.0-gdb-7.3.1-dude-5.11.1-insight-2.12

Quindi pare che quel .deb sia un mega-archivio di tutti i file che dovrebbero comporre la toolchain che sono creati con lo script di Bingo600. Son curioso di provare quella toolchain, ma lo farò domani perché ora non posso mettermi a fare delle prove per verificare se lo sketch ArduinoISP compila per bene, se non ci sono i problemi del delay, se gli sketch di dimensioni maggiori di 64K lavorano correttamente, se non c'è il bug del progmem delle ultime versioni di binutils ecc...

leo72:
Qual'è il settaggio che sulla versione di Windows dice all'IDE di usare avr-gcc contenuto in /hardware/tools/avr/ecc... al posto di quello presente nel sistema?

E' solo una questione di path, l'IDE di Arduino si aspetta di trovare il compilatore nella cartella "..\arduinoxx\hardware\tools\avr", quando va costruire la riga di comando vi inserisce questo percorso in aggiunta a quello dove si trova, idem per tutti i seguenti comandi.

No, questa cosa funziona solo su Windows. Su Linux non va.

Ho provato il pacchetto .deb che ho menzionato qui sopra ma ho ricevuto un errore di mancanza di eseguibile appena avviata la compilazione. Questa cosa della toolchain è più ostica di quanto sembrasse. L'unico modo per compilare è stato quello di creare manualmente la toolchain con lo scritp di Bingo, poi esportare nella variabile PATH il percorso dell'albero della toolchain e lanciare l'IDE di Arduino. Ma ho ricevuto un errore su un file delay.h. File che vedo è stato inserito a mano insieme all'elenco dei pacchetti .deb. Ora non ho voglia di fare altre prove. Domani ci rimetto le mani.

Qual'è il settaggio che sulla versione di Windows dice all'IDE di usare avr-gcc contenuto in /hardware/tools/avr/ecc... al posto di quello presente nel sistema?

Magari puoi provare a creare un link simbolico nella cartella /hardware/tools che si chiama avr e che punta alla cartella con dentro tutta la tolchain, oppure copiare il tutto in avr, ma non credo che sia questo il problema perchè avrai sicuramente provato.

In merito al delay.h questo deve trovarsi in /avr/include/utils/delay.h insieme ad altre utility, il core invece lo cerca in avr/include e a me compare un errore ed al tempo ho risolto modificando il core arduino.

Quei file deb li ho visti e ci sei arrivato dal link di avrfreaks.

Scompattandolo, si hanno alcuni file .sh. Eseguendoli secondo il readme, essi prelevano prima i sorgenti, poi le patch ed infine compilano tutto.

Se mi fai un elenco parziale delle directory che trovi all'interno della director build ti posso fare un'esempio sensato. Se scarichi i sorgenti di avr-gcc o avr-libc o altro software GNU questi usano tutti gli autotools ed in genere si deve eseguire ./configure && make && make install. Lo script avvia sicuramente la compilazione in questo modo su tutti i sorgenti. Nel link di avrfreaks è spiegato che di default il percorso di installazione è /usr/local ma se vuoi lo puoi personalizzare e mostra il prefix=/path e poi l'export:

PREFIX=/usr/local/avr
export PREFIX

Questo ha lo stesso effetto di avviare la configurazione del pacchetto sorgente in questo modo:
./configure PREFIX=/usr e poi make e make install

Quindi io dico che se hai le directory dei pacchetti sorgente entri in ognuno e fai make install da utente semplice e se vedi il tentativo di scrivere in /usr/local/ capisci che sta tentando di installare e pure dove. Se non vuoi sporcare /usr/local puoi provvisoriamente usare il comando make DESTDIR=tua_dir install e all'interno dovresti trovare l'albero di directory tipico di linux es bin etc share share/man ecc. Però il pacchetto così non può funzionare perche crede di essere eseguito a partire dalla variabile data in PREFIX ma torna utile per fare dei pacchetti deb o rpm tramite tools anche grafico.

@Brain

perchè non provi a sostituire con un hardlink che punta a quelli appena compilati?

Si si può tentare io però sono alla frutta perchè non uso ide e core arduino ma solo le schede, da tempo ormai ho trovato il modo di sviluppare classico tipico di avrstudio ma senza facility per i registri. A me serve aggiornare la toolchain ma non la posso testare con arduino IDE.

Piccola digressione:
di recente ho scoperto che questa riga di codice non lavora del tutto
vsnprintf_P(onerow, sizeof(onerow), PSTR("temperatura: %2.2f\0"), &th_data);

Per far si che lavori bisogna aggiungere a LFLAGS questa riga:
LFLAGS += -Wl,-u,vfprintf -lprintf_flt -lm

Io risolvo scrivendo questo nel file di progetto:
CONFIG += printfloat

Chi usa Arduino non ha questa flessibilità e io mi sento incatenato.

Ciao.

Ciao.

@legacy:
se almeno con la versione 4.5.x siamo in grado di indirizzare il codice all'interno di uno spazio indirizzi di 128 KB (ossia 64K word) a me è più che sufficiente. L'intento è quello di usare gli Atmega1284, che sono i chip DIP attualmente più capienti.

leo72:
Ma ho ricevuto un errore su un file delay.h. File che vedo è stato inserito a mano insieme all'elenco dei pacchetti .deb.

Questa te la risolvo io, è il primo problema in cui mi sono imbattuto nella versione per Windows, la soluzione è editare il file delay.h che si trova in "..\Arduino-xx\hardware\tools\avr\avr\include\avr" nel seguente modo:

#ifndef _AVR_DELAY_H_
#define _AVR_DELAY_H_

#warning "This file has been moved to <util/delay.h>."
// #include <util/delay.h>

#endif /* _AVR_DELAY_H_ */

Questo delay.h non ha nulla a che vedere con il delay di Arduino, infatti se lo usi viene regolarmente compilato, è per la "_delay_ms()" e " _delay_us()" delle avrlibc che Arduino non usa, se le vuoi utilizzare devi mettere "#include <math.h>" seguito da "#include <util/delay.h>" nello sketch, questo perché la delay usa due istruzioni, fabs e ceil, definite in math.h

Oggi riproverò con più calma.
Ieri sera avevo provato ad inserire il file delay.h che fornisce il creatore del pacchetto .deb nel percorso in cui andava a sbirciare il compilatore ma non era cambiato nulla.

leo72:
@legacy:
se almeno con la versione 4.5.x siamo in grado di indirizzare il codice all'interno di uno spazio indirizzi di 128 KB (ossia 64K word) a me è più che sufficiente. L'intento è quello di usare gli Atmega1284, che sono i chip DIP attualmente più capienti.

La versione di gcc 4.5.1, allegata alla toolchain di Atmel, probabilmente è stata modificata da loro rispetto all'originale, compila senza problemi fino a 256k di flash del Mega2560, verificato personalmente sia sotto AvrStudio 4, dove ho un paio di applicativi per Mega2560 che tra programma e tabelle dati arrivano quasi al limite della flash, e con Arduino 0023 e 1.0 dopo il trapianto, ancora sperimentale, della toolchain.

E la versione allegata all'IDE per Windows? Da quel che capisco, essendo la 4.3.5, dovrebbe avere il limite a 64K di word, giusto? Se è così, chi compra la MEGA non può usare il chip in tutta la sua funzionalità.

leo72:
E la versione allegata all'IDE per Windows? Da quel che capisco, essendo la 4.3.5, dovrebbe avere il limite a 64K di word, giusto? Se è così, chi compra la MEGA non può usare il chip in tutta la sua funzionalità.

Con l'IDE, 22/23 che 1.0, è allegata la versione 4.3.2 che oltre al limite delle 64 kword ha il bug dei dati posti oltre 64k nella flash, e tutta la discussione relativa a Windows è partita dopo una segnalazione di Menniti di questo problema.
Sostituendo WinAvr fornito di serie con Arduino con l'ultima release, e non capisco perché non è stato fatto dall'Arduino team con la versione 1.0 dell'IDE, il compilatore è la versione 4.3.3 dove è ancora presente il limite delle 64 kword e il bug dei 64k, però permette di compilare per più modelli di micro rispetto alla precedente versione, p.e. il famigerato Attiny4313.
In tutti i casi anche con la 4.3.5 puoi compilare per il 1284 senza nessun problema, il bug dei dati oltre 64k è stato risolto a partire dalla 4.3.4.

Beh allora io sono apposto con la mia versione di avr-gcc

$ rpm -q avr-gcc
avr-gcc-4.4.2-2.fc12.i686

La versione di gcc 4.5.1, allegata alla toolchain di Atmel, probabilmente è stata modificata da loro rispetto all'originale, compila senza problemi fino a 256k di flash del Mega2560, verificato personalmente sia sotto AvrStudio 4, dove ho un paio di applicativi per Mega2560 che tra programma e tabelle dati arrivano quasi al limite della flash, e con Arduino 0023 e 1.0 dopo il trapianto, ancora sperimentale, della toolchain.

Mi sembra strano che abbiano apportato delle modifiche a codice GPL e le hanno chiuse, perchè ancora io di patch Atmel ufficiali per avr-gcc & company non ne ho trovato. Ora sentendo ciò che dice legacy devo dire che sono confuso e perplesso, vedremo cosa esce fuori.

Ciao.

MauroTec:
Mi sembra strano che abbiano apportato delle modifiche a codice GPL e le hanno chiuse, perchè ancora io di patch Atmel ufficiali per avr-gcc & company non ne ho trovato.

L'eventuale modifica al compilatore, parliamo di gcc, è una mia ipotesi se è vero quello che dice Legacy, è tutto da verificare.
Mi pare che Atmel da anche i sorgenti del tutto, non li ho scaricati perché non mi interessa guardarli, quindi dovrebbe essere facile capire se il gcc è stato modificato oppure no.
In tutti i casi quello che contano sono i fatti, con AvrStudio 4 e la toolchain Atmel compilo per l'ATmega2560 senza problemi arrivando quasi al limite della flash, idem con la stessa toolchain montata sull'IDE di Arduino, quindi la questione è molto semplice visto che quello che conta sono i fatti e non le ipotesi :slight_smile:

MauroTec:
perchè ancora io di patch Atmel ufficiali per avr-gcc & company non ne ho trovato. Ora sentendo ciò che dice legacy devo dire che sono confuso e perplesso, vedremo cosa esce fuori.

Ho scaricato adesso i sorgenti e gli ho dato un'occhiata veloce, in effetti contiene solo roba riguardante gli AVR32 però si tratta sicuramente solo di un update dei sorgenti della toolchain e non di tutti quanti.
Tocca rovistare sul sito Atmel per trovare gli altri update, sopratutto quelli per gli 8 bit, che saranno stati allegati alle precedenti release della toolchain ed eventualmente il sorgente globale del tutto.

Però viene fuori una situazione un po' ai limiti del paradosso. L'IDE per Windows di Arduino contiene un compilatore che non è in grado di compilare correttamente codice più grande di 64K però viene venduta una scheda con un chip che ne contiene 256K.

Non voglio additare nessuno prima di sapere esattamente come stanno le cose ma a questo punto sarebbe gradito un chiarimento da parte del team.

leo72:
Non voglio additare nessuno prima di sapere esattamente come stanno le cose ma a questo punto sarebbe gradito un chiarimento da parte del team.

Il limite è 128 kbyte se ragioniamo con questi e non con le word, due byte ciascuna, ho l'impressione che il team Arduino non si sia ancora reso conto dell'esistenza di questo problema, il Mega 2560 è un micro relativamente recente e ha sostituito il Mega 1280 presente sulla precedente versione di Arduino Mega, non credo ci siano applicazioni Arduino che richiedono più di 128k, almeno io non ne ho viste.
C'e sempre la questione del bug dei dati posti oltre 64k, credo sia molto difficile che una normale applicazione Arduino incappi in questo errore, però dato che è un problema noto sarebbe stata cosa gradita inserire nella 1.0 di Arduino un compilatore aggiornato ad una release esente da questo problema.
Per quanto riguarda Windows il problema lo sto risolvendo io in modo definitivo, tra oggi e domani rilascio una prima release, da considerarsi sperimentale, della toolchain Atmel per l'IDE 1.0, così grazie alla collaborazione di qualche volenteroso beta tester vediamo se ci sono ulteriori problemi da risolvere oltre a quelli che ho trovato io.

@astro hai guardato qui?