Go Down

Topic: [Linux] Aggiornare la toolchain Avr (Read 17848 times) previous topic - next topic

leo72

Ma io ho compilato ed usato la toolchain senza problemi, se rileggi i miei post in questo thread ad un certo punto parlavo proprio del fatto che con i 328 ed i 644 compilavo senza problemi ma non con i Tiny e con la Mega.

MauroTec

Quote
Ma io ho compilato ed usato la toolchain senza problemi, se rileggi i miei post in questo thread ad un certo punto parlavo proprio del fatto che con i 328 ed i 644 compilavo senza problemi ma non con i Tiny e con la Mega.


Vero, ho riletto tutto (che fatica).

Allora il problema è che io non ho codice che possa compilare su Attiny, comunque quegli errori non sono della toolchain ma del core tiny o meglio non trova le cose nel posto giusto. Io però non ho capito come hai fatto a far vedere la nuova toolchain ad Arduino IDE, quale strada hai scelto, no perchè non basta sistemare il path con la variabile di ambiente, devi anche dire all'ide di usare la avr-libc compilata e dire anche da dove prendere gli header ecc, se hai provveduto a sistemare i file nei posti giusti potrebbe essere che qualcosa non è andata nel verso giusto.

Ora io ho qualche problema con le patch ufficiali di Atmel per avr-libc, o meglio ho risolto manualmente e la compilazione è andata a buon fine senza errori, ma ora devo trovare il modo di creare delle patch da inserire nel file .spec che facciano quello che ho fatto manualmente.

Manualmente è stato sufficiente creare le dir mancanti e prendere un makefile.am da ogni famiglia e metterlo dentro la dir mancante modificando due solo righe, bene ora questa cosa la devo automatizzare, ma non mi ricordo come si usa diff, anzi non mi ricordo il nome tools che usavo al post di diff che fa un lavoro eccellente.

Alla fine avrò la toolchain aggiornata in sincro con Atmel, ma mi mancano i sorgenti per eseguire i test così da verificare che i bug conosciuti sono stati risolti.

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

leo72

Non ho inserito la toolchain Atmel all'interno della cartella dell'IDE perché così non funzionava.

Ho compilato la toolchain con lo script di AvrFreaks e poi ho inserito nella path dei comandi l'indirizzo della cartella dove risiedevano i nuovi binari Avr.
Non capisco però perché compilando per 328 e 644 andava e per Tiny o Mega2560 no. Le librerie, se non le trovava per i secondi, non le avrebbe dovute trovare neanche per i primi.

MauroTec

Leo non so risponderti, ma scusa perchè non usi il tasto shift per vedere da dove prende le lib e tutto il resto, certo che se sul sistema l'unico compilatore avr-gcc e quella da te compilata non può che usare questa, stessa cosa per le binutils e le avr-libc.

Studiando le pacth di atmel in particolare quelle per avr-gcc ho notato il bug di cui parlavo proprio tempo fa per attiny, specie per tn85 almeno un registro non si chiama più allo stesso modo e quasi sicuramente tocca ricompilare tutto con la nuova toolchain e sperare che non esca qualche errore.

Buone nuove:
Mentre scrivo ha terminato di creare il pacchetto per le avr-libc:
Code: [Select]

+ cd /home/mauro/rpmbuild/BUILD
+ cd avr-libc-1.7.1
+ DOCDIR=/home/mauro/rpmbuild/BUILDROOT/avr-libc-1.7.1-2.fc12.i386/usr/share/doc/avr-libc-docs-1.7.1
+ export DOCDIR
+ rm -rf /home/mauro/rpmbuild/BUILDROOT/avr-libc-1.7.1-2.fc12.i386/usr/share/doc/avr-libc-docs-1.7.1
+ /bin/mkdir -p /home/mauro/rpmbuild/BUILDROOT/avr-libc-1.7.1-2.fc12.i386/usr/share/doc/avr-libc-docs-1.7.1
+ cp -pr avr-libc-user-manual-1.7.1 /home/mauro/rpmbuild/BUILDROOT/avr-libc-1.7.1-2.fc12.i386/usr/share/doc/avr-libc-docs-1.7.1
+ exit 0
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Controllo per file scompattato/i in corso: /usr/lib/rpm/check-files /home/mauro/rpmbuild/BUILDROOT/avr-libc-1.7.1-2.fc12.i386
Scritto: /home/mauro/rpmbuild/SRPMS/avr-libc-1.7.1-2.fc12.src.rpm
Scritto: /home/mauro/rpmbuild/RPMS/noarch/avr-libc-1.7.1-2.fc12.noarch.rpm
Scritto: /home/mauro/rpmbuild/RPMS/noarch/avr-libc-docs-1.7.1-2.fc12.noarch.rpm
Esecuzione(%clean) in corso: /bin/sh -e /var/tmp/rpm-tmp.72DD8s
+ umask 022
+ cd /home/mauro/rpmbuild/BUILD
+ cd avr-libc-1.7.1
+ rm -rf /home/mauro/rpmbuild/BUILDROOT/avr-libc-1.7.1-2.fc12.i386
+ exit 0
[mauro@localhost SPECS]$


Allego lo specfile e la pacth per risolvere la mancanza dei Makefile.am

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

MauroTec

Dopo aver installato/aggiornato la avr-libc provo a compilare un mio programma e quello che segue è il risultato:
Code: [Select]

make: Entering directory `/home/mauro/Sviluppo/WashingMachine/master-build-desktop'
avr-g++ -c -Wall -Os -fpack-struct -fshort-enums -fno-exceptions -mmcu=atmega328p -save-temps -ffunction-sections -fdata-sections -funsigned-char -funsigned-bitfields -DF_CPU=16000000 -D__AVR_ATmega328P__ -I../../../.avrspecs/mkspecs/linux-avr8-g++ -I../washing_machine_master -I../washing_machine_master -I/usr/avr/include -I../../../.avr/include/mhvlib-08112011 -I. -o main.o ../washing_machine_master/main.cpp
In file included from ../washing_machine_master/main.cpp:7:0:
/usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h: In function 'void _delay_ms(double)':
/usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:149:42: error: 'fabs' was not declared in this scope
/usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:149:43: error: 'ceil' was not declared in this scope
In file included from ../washing_machine_master/main.cpp:7:0:
/usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h: In function 'void _delay_us(double)':
/usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:226:42: error: 'fabs' was not declared in this scope
/usr/lib/gcc/avr/4.5.1/../../../../avr/include/util/delay.h:226:43: error: 'ceil' was not declared in this scope
../washing_machine_master/main.cpp: In function 'int main()':
../washing_machine_master/main.cpp:67:102: warning: only initialized variables can be placed into program memory area
make: *** [main.o] Error 1
make: Leaving directory `/home/mauro/Sviluppo/WashingMachine/master-build-desktop'
The process "/usr/bin/make" exited with code 2.
Error while building project master (target: Desktop)
When executing build step 'Make'


Quindi ora mi tocca capire se il bug è in avr-libc o gli altri.
Suggerimenti??

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

MauroTec

Da quello che leggo la avr-libc-1.7.1 ha un modo nuovo per fare i delay_ms e delay_us, questo nuovo modo però richiede che avr-gcc abbia internamente questa funzione builtin __builtin_avr_delay_cycles(unsigned long), se non c'è la qualcosa va storta, ma non è questo il caso, invece sembra che l'header file utils/delay usi "fabs" e "ceil" che sono funzioni matematiche che si trovano nell'header "math.h" e questo file non è incluso in delay.h, quindi è un bug di avr-libc.

Dal momento che non c'è retrocompatibilità si può ovviare definendo #define __DELAY_BACKWARD_COMPATIBLE__  per usare le vecchie versioni di delay_ms e _us, ma occhio che dovete definirla in ogni sorgente che usa delay prima dell'include, oppure definirla come constante a tempo di compilazione passandola nella riga di comando di avr-gcc.

Ora c'è da vedere se escono altre magagne/novità, sempre bene accette le seconde.

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

leo72

Se il problema è del delay, devi sostituire il file allegato alla toolchain con il file di Arduino. Cerca il post di Astrobeed in cui segnala proprio a me le righe di codice. Non mi ricordo se è in questo o nell'altro thread (quello riguardante l'aggiornamento della toolchain per Windows)

MauroTec

Mi chiedo, ma utenti Linux siamo solo noi due?

Comunque ho risolto il problema con una patch, ma non so se risolve il problema su Arduino core.

Code: [Select]
--- ./include/util/delay.h.in 2012-03-21 22:29:29.000000000 +0100
+++ ./include/util/delay.h.in 2012-03-21 22:30:24.000000000 +0100
@@ -94,6 +94,10 @@ static inline void _delay_ms(double __ms
# warning "Compiler optimizations disabled; functions from <util/delay.h> won't work as designed"
#endif

+#if __HAS_DELAY_CYCLES && defined(__OPTIMIZE__) && !defined(__DELAY_BACKWARD_COMPATIBLE__)
+#include <math.h>
+#endif
+
/**
    \ingroup util_delay


Se gcc ha delay cicle builin e se -OS è presente e non è stata definita __DELAY_BACKWARD_COMPATIBLE__ include math.h

Altra cosa, stavo guardando qui http://www.atmel.com/products/microcontrollers/avr/default.aspx?tab=documents AVR998 dove c'è PDF e codice che a quanto sembra esegue dei test della memoria, non sono sicuro perchè è da 10 minuti che ho letto rapidamente il PDF e c'è ne ho capito poco, ora vedo il sorgente cosa fà, magari si può usare per testare lettura e scrittura nella flash e ram oltre le 64kword o 128k, alla fine non ho micro per testarla.

Ma tu a che sei, hai risolto qualcosa, sei operativo con la nuova toolchain?

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

leo72

Parto dall'ultima domanda, al momento fra czz e mazzi sono diversi giorni che non riesco a fare prove concrete. Spippolo un po' qui sul PC di lavoro ma non posso fare molte cose, poi ho un po' lasciato perdere perché alla fine nell'attesa di poter studiare con calma il problema (devo terminare un paio di progetti che ho a mezzo).

Il PDF lo leggo con calma, poi ti faccio sapere.

Sul fatto degli utenti Linux, non so il motivo per cui non partecipano, magari per il semplice motivo che non interessa la questione.

leo72

Veloce occhiata al PDF. O io ne ho trovato un altro oppure quel documento non mi pare che riporti del codice per testare la flash. Ci sono solo indicazioni sui controlli da eseguire per la verifica del dispositivo. Però mi pare che si basi sul fatto che puoi accedere a prescindere a tutta la memoria del micro, non mi pare si ponga il problema se effettivamente hai codice che può accedervi o no.

dab77


Parto dall'ultima domanda, al momento fra czz e mazzi sono diversi giorni che non riesco a fare prove concrete. Spippolo un po' qui sul PC di lavoro ma non posso fare molte cose, poi ho un po' lasciato perdere perché alla fine nell'attesa di poter studiare con calma il problema (devo terminare un paio di progetti che ho a mezzo).

Il PDF lo leggo con calma, poi ti faccio sapere.

Sul fatto degli utenti Linux, non so il motivo per cui non partecipano, magari per il semplice motivo che non interessa la questione.

Eccolo un altro linuxaro, e vi sto seguendo ad ogni post, ma purtroppo non posso aiutarvi causa mancanza tempo per smanettare..
oltretutto per fare prove ho a disposizione oltre i 328P, solo attiny85 e un Mega1280. quindi non sarei molto d'aiuto.

MauroTec

Ciao dab77, anche io non ho solo 168,328 e 644, ci vorrebbe chi ha uno di questi micro per testare la toolchain:

avr35 attiny1634
avr4 atmega48pa
avr5 at90pwm161 atmega325pa atmega3250pa atmega3290pa
avrxmega2 atxmega21x1
avrxmega6 atxmega128b1 atxmega256a3bu

Dab77, tu su che distrò lavori?

Questi sono stati introdotti con le patch di Atmel, queste inoltre risolvono il problema del 2560 almeno in parte. Per il problema che si verifica scrivendo o leggendo su flash dopo i 128k le cose stanno come ha detto legacy, in quanto c'è già tanto codice nella 4.7.0 e si può pensare che riescano a sistemare le cose nella seguente release, anche perchè è dalla 4.6.3 che ci lavorano. Guardando il codice delle patch di atmel mi sembra di capire che in parte si sono mossi nella stessa direzione, ma non sono riuscito a trovare traccia del "registro a 24bit che invece si vede nella 4.7.0.

@Leo
Il codice c'è, basta andare a link e cliccare sul l'icona del compat disc che si trova accanto a quella del pdf, comunque mi sono arenato con quel codice perchè c'è un po asm inline e io non sono in grado di convertirlo da IAR ad asm gcc, lo metto qui tra code non si sa mai ci sia qualcuno che ne sa qualcosa.

Code: [Select]

char __low_level_init()
{
  /* RO to R31 stuck test
     Move data between register
     R31, R30, R29, R28 and R27 are tested before
     to be reuse after during the test  */
 
      //   R31 stuck test
__asm("R31_0x55_TST:                              \n"
      "               ldi  R31, $55               \n"
      "               cpi  R31, $55               \n"
      "               breq  R31_0xAA_TST          \n" 
      "               jmp  Failure                \n"
      "R31_0xAA_TST:  ldi  R31, $AA               \n"
      "               cpi  R31, $AA               \n"
      "               breq  R30_0x55_TST          \n" 
      "               jmp  Failure                \n"
);

      //   R30 stuck test
__asm("R30_0x55_TST:  ldi  R30, $55               \n"
      "               cpi  R30, $55               \n"
      "               breq  R30_0xAA_TST          \n" 
      "               jmp  Failure                \n"
      "R30_0xAA_TST:  ldi  R30, $AA               \n"
      "               cpi  R30, $AA               \n"
      "               breq  R28_0x55_TST          \n"
      "               jmp  Failure                \n"
);

      //   R29 stuck test
__asm("R29_0x55_TST:  mov R31, R29     ; save R29 \n"   
      "                ldi  R29, $55              \n"   
      "               cpi  R29, $55               \n"
      "               breq  R29_0xAA_TST          \n"
      "               jmp  Failure                \n"
      "R29_0xAA_TST:  ldi  R29, $AA               \n"
      "               cpi  R29, $AA               \n"
      "               breq  R29_END_TST           \n" 
      "               jmp  Failure                \n"
      "R29_END_TST:   mov R29, R31  ; restore R29 \n"
);

      //   R28 stuck test
__asm("R28_0x55_TST:  mov R31, R28     ; save R28 \n"
      "               ldi  R28, $55               \n"
      "               cpi  R28, $55               \n"
      "               breq  R28_0xAA_TST          \n" 
      "               jmp  Failure                \n"
      "R28_0xAA_TST:  ldi  R28, $AA               \n"
      "               cpi  R28, $AA               \n"
      "               breq  R28_END_TST           \n" 
      "               jmp  Failure                \n"
      "R28_END_TST:   mov R28, R31  ; restore R28 \n"   
);


      //   R27 stuck test
__asm("R27_0x55_TST:                              \n"
      "               ldi  R27, $55               \n"
      "               cpi  R27, $55               \n"
      "               breq  R27_0xAA_TST          \n" 
      "               jmp  Failure                \n"
      "R27_0xAA_TST:  ldi  R27, $AA               \n"
      "               cpi  R27, $AA               \n"
      "               breq  R27_END_TST           \n" 
      "               jmp  Failure                \n"
      "R27_END_TST:                               \n"   
);


      // R0 to R27 stuck test
__asm("RX_TST:        ldi  R30,$00                \n"
      "               ldi  R31,$00                \n"
      "RX_0x55_TST:   ldi  R27,$55                \n"
      "               st  Z,R27                   \n"
      "               ldi  R27,$00                \n"
      "               ld  R27,Z                   \n"
      "               cpi  R27,$55                \n"
      "               breq  RX_0xAA_TST           \n"
      "               jmp  Failure                \n"
      "RX_0xAA_TST:   ldi  R27,$AA                \n"
      "               ST  Z,R27                   \n"
      "               ldi  R27,$00                \n"
      "               ld  R27,Z+                  \n"
      "               cpi  R27, $AA               \n"
      "               breq  RX_TST_2              \n"
      "               jmp  Failure                \n"
      "RX_TST_2:      cpi  r30,27 ; test until R27 \n"
      "               brne  RX_0x55_TST           \n"
);

  // Stack pointer Stuck Test (16 bit Stack pointer)
  // Save SP values
__asm("SP_TST:        in    R23,$3E               \n"
      "               in    R22,$3D               \n"
      "SPL_0x55_TST:  ldi   R24,$55               \n"
      "               out   $3D,R24               \n"
      "               in    R24,$3D               \n"
      "               cpi   R24,$55               \n"
      "               breq  SPL_0xAA_TST          \n"
      "               jmp   Failure               \n"
      "SPL_0xAA_TST:  ldi   R24,$AA               \n"
      "               out   $3D,R24               \n"
      "               in    R24,$3D               \n"
      "               cpi   R24,$AA               \n"
      "               breq  SPH_0x55_TST          \n"
      "               jmp   Failure               \n"
      "SPH_0x55_TST:  ldi   R25,"SPH_MASK
      "               andi  R25,$55               \n"
      "               out   $3E,R25               \n"
      "               in    R24,$3E               \n"
      "               cp    R24,R25               \n"
      "               breq  SPH_0xAA_TST          \n"
      "               jmp   Failure               \n"
      "SPH_0xAA_TST:  ldi   R25,"SPH_MASK
      "               andi  R25,$AA               \n"
      "               out   $3E,R25               \n"
      "               in    R24,$3E               \n"
      "               cp    R24,R25               \n"
      "               breq  RESTORE_SP            \n"
      "               jmp   Failure               \n"
      "RESTORE_SP:    out   $3E,R23               \n"
      "               out   $3D,R22               \n"
      "               rjmp  ALL_TEST_OK           \n"
);


     // stop here on failure
     // replace by an exit if necessary
__asm("Failure:        jmp   Failure              \n"
      "ALL_TEST_OK:                               \n"
);

  return 1;
}


Ciao.


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

leo72

legacy ha spiegato bene. Aggiungo solo che, se non ricordo male ciò che ho letto su AvrFreaks, la questione dei puntamenti a zone di flash >128kB è stato risolto in avr-gcc usando 3 registri combinati insieme per avere i 24 bit necessari a poter "saltare" nelle zone alte della memoria.

MauroTec

Quote
Non c'e' un registro a 24 bit esplicito come nelle architetture a 32bit flat memory, in avr8-xmega si combinano 4 registri per formare un registri a 32bit, e si hanno due possibilita' di farlo, con registri "combinati" chiamati regV e regW


Esatto, si capisce che non c'è un registro lungo 24 bit infatti ho dimenticato di chidere apici (ma non sono riuscito a trovare traccia del "registro a 24bit). Dicevo che nel ramo 4.7.0 c'è codice e si vede la formazione di questo "registro" a 24 bit, mentre nelle patch di Atmel io non l'ho trovato, devo controllare se hanno toccato LPM o come si chiama insomma la builtin per scrivere e leggere in flash.

legacy le vuoi tutte le patch che ho applicato a avr-gcc & company, poi tu le applichi a manina e compili, ma anche se non compili già puoi dare una lettura a gcc con le patch applicate, poi per te creare un file scriverci dentro e montarlo in loop non è un problema, io mi incasino con le versioni e mi ritrovo sempre codice compilato con la versione sbagliata. Però hai scritto che passi a SDCC, io ci avevo provato ma la riga di comandi non mi piace, ho avuto difficolta con il generatore di makefile e ho lasciato perdere perchè mi scocciava trovare una soluzione.

Quel codice asm inline viene da mamma Atmel ed è scritto per IAR, per me adattarlo a gcc non è un problema ci si impiega 10 minuti, ma non mi sono mai trovato codice asm IAR e non so come funziona. Quel codice di test e standard e ci sono anche test per la ram la eeprom ecc, ecco io volevo provarlo. Per il discorso superamente dei 128k io non ho chip con flash così grande.

Per me la nuova toolchain lavora, ma anche la vecchia quindi io non posso apprezzare differenze se non quelle teoriche, cioè supporto per xmega e gli altri chip di cui al momento non me ne faccio nulla.

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

MauroTec

@Legacy
Concordo in pieno, comunque quel pezzo di asm come si intuisce dal nome della funzione serve solo come inizializzazione dei registri tutto il resto e C, compreso il test in flash e lo volevo usare perchè è standard e poi eventualmente aggiungerci altro se necessario.

Conosco la tecnica del mounting volume, tutte le liveCD ecc la usano, ma nel formato compresso es suse usa Cloop (kernel module) fedora usa squashfs, questa tecnica è alla base dell'avvio di ogni distro, prima si monta initrd in ram e questo poi monta in sola lettura root ecc, ovviamente ci sono un mare di varianti. Quindi io ho abbandonato quella tecnica che mi incasinava di più, forse però non sono stato capace di renderla automatica e chiara per questo.

Un momento però con quell'env tu stabbilisci che CC= avr-gcc e come fai se vuoi compilare usando anche gcc, cioè devi sempre switchare, io mi ritrovo spesso con due ide aperti uno con codice per avr e l'altro per 386, boh per ora mi scoccia trovare una soluzione vado avanti così. Però ora che ci penso posso montare un volume diverso secondo necessità con dentro installati i pacchetti binari generati in modo standard, non è male la soluzione, ma mi scoccia lo stesso.  :P

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

Go Up