[Linux] Aggiornare la toolchain Avr

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?

@astro:
ma la MEGA2560 è in vendita da 1 anno, scusa... :wink:

@brain:
è il link da cui si scarica la toolchain ufficiale Avr8, quella che legacy dice sia un potpourri fra codice della Avr8 e patch della Avr32. Quella che mi sta dando problemi di funzionamento.

avevo visto che astrobeed cercava quella roba lì...

BrainBooster:
@astro hai guardato qui?
http://www.atmel.com/tools/ATMELAVRTOOLCHAIN3_2_3FORLINUX.aspx

Il file dei sorgenti è lo stesso di quello della versione Windows, ovvero contiene solo gli update e non tutti i sorgenti della toolchain.

leo72:
@astro:
ma la MEGA2560 è in vendita da 1 anno, scusa... :wink:

Vallo a dire all'Arduino Team che stanno vendendo una scheda non utilizzabile al 100% con gli strumenti di serie, ovvero indicassero loro una procedura di patch ufficiale per i vari S.O. :slight_smile:
Io nel mio piccolo sto risolvendo la questione per Windows, voi cercate di risolverla per Linux, forse dovrebbe andare bene anche per MAC con i dovuti ritocchi, dopo di che chiediamo all'Arduino Team un adesivo omaggio e un caffè pagato per il lavoro svolto :smiley:

Nelle release notes della toolchain di atmel a 8bit c'è scritto che il atmega2560 è supportato.

Su Linux la toolchain non è inclusa, la scarichi dai repo della tua distro. Molte distro hanno versioni aggiornate ed il problema non si pone. Casomai sorgono altri problemi, quindi è il classico cane che si morde la coda: risolto il problema A spunta il problema B, risolto questo spunta il problema C ecc... E' la fregatura di avere un sistema aggiornato: usando una versione freezata sai i suoi limiti ma anche le sue potenzialità.

Il problema è che al momento non pare esistere una versione di avr-gcc che sia esente del tutto da problemi. E di distro nell'ultimo anno ne ho provate un sacco. Quindi va trovata la giusta combinazione che permetta di risolvere almeno i problemi più grossi se che ne vengano fuori altri (vedi ad esempio il bug della funzione delay).

BrainBooster:
Nelle release notes della toolchain di atmel a 8bit c'è scritto che il atmega2560 è supportato.
http://www.atmel.com/Images/avr8-gnu-toolchain-3.2.3.314-readme.pdf

Guardavo questa pagina:

Leggo:

avr6
“Enhanced” devices with 3-byte PC, i.e. with at least 256 KiB of program memory.
mcu = atmega2560, atmega2561.

Non è che forse allora basta l'aggiunta di questa opzione specificare il tipo di MCU per far sì che il codice compilato da gcc-avr venga correttamente elaborato anche per micro con 256 kB di Flash?

EDIT:
se però è un bug... sono un po' fava stamani... :roll_eyes: