Pages: [1] 2 3 ... 12   Go Down
Author Topic: [Linux] Aggiornare la toolchain Avr  (Read 11823 times)
0 Members and 1 Guest are viewing this topic.
Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 313
Posts: 21650
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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??
http://www.atmel.com/tools/ATMELAVRTOOLCHAIN3_2_3FORLINUX.aspx
Logged


0
Offline Offline
Faraday Member
**
Karma: 24
Posts: 2814
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Quote
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.37 KB - downloaded 16 times.)
Logged

AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

Deep south of Italy
Offline Offline
Faraday Member
**
Karma: 7
Posts: 2961
The quieter you become, the more you can hear
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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?
Logged

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 313
Posts: 21650
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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?
Logged


Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 313
Posts: 21650
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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...
Logged


Rome (Italy)
Offline Offline
Tesla Member
***
Karma: 120
Posts: 9185
"Il Vero Programmatore ha imparato il C sul K&R, qualunque altro testo è inutile e deviante."
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Logged

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 313
Posts: 21650
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged


0
Offline Offline
Faraday Member
**
Karma: 24
Posts: 2814
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
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.

Quote
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
Quote
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.

Logged

AvrDudeQui front end per avrdude https://gitorious.org/avrdudequi/pages/Home

Offline Offline
God Member
*****
Karma: 5
Posts: 873
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

@leo
come ti ho scritto in privato, e come mi hai chiesto di intervenire, butto giu' due righe.

Ho dato di persona (ho finito ora) un occhio approfondito alla machine layer di gcc-4.5.1 e ti confermo che e' un gran casino, la questione non e' per nulla banale e c'e' pure una divisione netta di pensiero fra i coders perche' in molti vedono il limite dei 64Kbyte del supporto gcc per avr8 come il limite che dovrebbe far scegliere un avr32, c'e' davvero un grosso polverone dietro questa storia, anche in casa Atmel sono divisi, ma sopratutto senza che la cosa porti alcuna soluzione per quanto riguarda il problema del "far pointers", cioe' dei puntatori ad oggetti oltre i primi 64Kbyte indirizzabili.

In poche parole non hanno toccato minimamente la machine layer, ci sono state un paio di proposte pagliative ma di fatto non hanno introdotto alcun built-in tricks per gestire i far pointers e gcc-4.5.1 continuera' a non tradurli nel modo corretto e a non dare nemmeno warning perche' syntatticamente e samanticamente un far pointer dal punto di vista del C e' corretto.

Da quanto dicono i manteiner gcc del ramo avr8 solo a partire da avr-gcc 4.7.1 verra' cambiata la machine layer in modo che nativamente gcc faccia uso di indirizzamenti indiretti per consentire all'utenza di poter accedere tranquillamente ad indirizzi di memoria (ram o flash) che sono fisicamente maggiori dei primi 64Kbyte indirizzabili raggiungibili da registri a 16bit.

Insomma per i far pointers servono piu' bit dei 16 attualmente in uso "nativamente"-a-costo-zero-senza fatica, ne servono di piu' e avremo 24 (16Mbyte gente, notevole), serve una sottile e pregiata tecnica chiamata "named address spaces", e la versione 4.7.1 la introdurra' senza pero' backporting, anche perche' richiede parecchio lavoro ed e' una gran rottura gia' farlo sui rami nuovi di gcc, riportarlo all'indietro sarebbe un bagno di sanue.

Cio' significa niente patch ufficiali per i rami 4.5 e ancor meno per il ramo 4.6, anche avr-gcc-4.7.0 saltera' il giro e le novita' verranno inserite dal 4.7.1 in poi.

Morale ad oggi con gcc-4.5.*, ma addirittura fino a avr-gcc-4.7.0, non si risolve nulla, le patch che ci sono in giro non sono ufficiali ed e' altamente improbabile che funzionino dato che per funzionare richiedono modifiche molto invasive che sono quasi impossibili sui rami pre 4.7, quindi direi che di fatto per i rami attuali serve ancora calcolarsi a mano gli indirizzi dei far pointers con metodi poco simpatici, e fare inline assembler,.

Raga, fatevi due conti, perche' aggiornare ora, per quanto riguarda questo limite, e' inutile, io vi consiglio di lasciare lavorare lo staff e quando la situazione si stabilizza ed assesta, cioe' almeno un paio di settimane dopo il 4.7.1, se ne riparla.
« Last Edit: March 18, 2012, 08:55:28 pm by legacy » Logged

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 313
Posts: 21650
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@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.
Logged


Rome (Italy)
Offline Offline
Tesla Member
***
Karma: 120
Posts: 9185
"Il Vero Programmatore ha imparato il C sul K&R, qualunque altro testo è inutile e deviante."
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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:

Code:
#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

Logged

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 313
Posts: 21650
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged


Rome (Italy)
Offline Offline
Tesla Member
***
Karma: 120
Posts: 9185
"Il Vero Programmatore ha imparato il C sul K&R, qualunque altro testo è inutile e deviante."
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

@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.
Logged

Global Moderator
Italy
Offline Offline
Brattain Member
*****
Karma: 313
Posts: 21650
Logic is my way
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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à.
Logged


Rome (Italy)
Offline Offline
Tesla Member
***
Karma: 120
Posts: 9185
"Il Vero Programmatore ha imparato il C sul K&R, qualunque altro testo è inutile e deviante."
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.

Logged

Pages: [1] 2 3 ... 12   Go Up
Jump to: