[Linux] Aggiornare la toolchain Avr

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.

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)

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

@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. :stuck_out_tongue:

Ciao.

Ecco come lo hai fatto tu è meglio, per sbagliare si deve essere morti dal sonno. Però sei costretto a lavorare con le shell aperte e io che uso L'ide dovrei avviarlo da li, si può fare non è male come idea, poi l'avvio dal menù di gnome usa gcc nativo. Appena ho un po di tempo vediamo che riesco a combinare.

Ma non volevi testare se il codiche che esce dalla toolchain procuce un eseguibile in cui la flash e' indirizzata nel modo corretto e se i salti funzionano nel modo corretto ? Secondo me basta un address-in-address test piu' un far-jump per dirlo, e senza fare altro, lo provi cosi' come e' e vedi come si comporta la toolchain, se inizia a toppare si "indaggina" meglio e si prendono provvedimenti.

Io non lo posso fare perche' non ho hw sottomano ne mi interessa averlo nell'immediato: ho solo 644 in produzione, ho solo quei chip qui.

Si notte :D...., non leggi, io sono nelle stesse condizioni non ho hardware per testare, cioè ho solo 168, 328, 644 e solo chi ha il 2560 può verificare, magari io posso compilare per questo ma altri devono verificare. Quel doc e codice mi è capitato davanti per caso e gli ho dato uno sguardo e lo messo dentro anche perchè quel test ripeto è standard ed è da eseguire in produzione, quindi, si basta fare come dici tu.

Ciao.

legacy:
non ho idea se quello che ha riportato leo sia gia' stato applicato al ramo 4.5.1, io so che verra' applicato al 4.7.x,

Di default, solo avr-gcc ramo 4.7.x implementerà questa cosa.

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?
........
Ciao.

Ho una ubuntu 10.04, kernel pae.e non mi stacco neanche morto da gnome 2. quindi ho un ambiente standard su cui testare, mi manca il tempo per adesso, ma tra un pò mi metterò a testare volentieri.

Ho una ubuntu 10.04, kernel pae.e non mi stacco neanche morto da gnome 2. quindi ho un ambiente standard su cui testare, mi manca il tempo per adesso, ma tra un pò mi metterò a testare volentieri.

Io se legacy è disposto a condividere farei quello che ha fatto lui, cioè in pratica si applicano le path si compila e si installa su file system ext, poi questo file si monta in loop device e da shell si avvia arduino, così L'ide vede un /usr/avr e /usr/bin che sono quelli presenti nel file montato.

Purtroppo neanche tu hai hardware per fare il test, perchè anche la mega con il 1280 ha solo 128K, ma che fine hanno fatto quelli che hanno la Mega?

Ciao.

mmmmmmmmmm.... mi fate una cortesia, mi controllate se nel file avr/io c'è definito AVR_ATmega168PA, perchè nella 1.7.1 con patch Atmel non c'è, nel caso l'aveste mi postate qui le righe del 168, così visto che ci sono faccio la patch, avr-libc-1.7.1-missin_168pa.patch.

Ciao.

Visto che ci siete a me manca anche il 164PA. Il AVR_ATmega1284P c'è ma manca AVR_ATmega1284 senza la P.

FYI:
http://gcc.gnu.org/gcc-4.7/
:slight_smile:
queste le modifiche della nuova versione:
http://gcc.gnu.org/gcc-4.7/changes.html

MauroTec:
mmmmmmmmmm.... mi fate una cortesia, mi controllate se nel file avr/io c'è definito AVR_ATmega168PA, perchè nella 1.7.1 con patch Atmel non c'è, nel caso l'aveste mi postate qui le righe del 168, così visto che ci sono faccio la patch, avr-libc-1.7.1-missin_168pa.patch.

Se per avr/io intendi /avr/include/avr/io.h no, non c'è.

Ciao.

Visto che ci siete a me manca anche il 164PA. Il AVR_ATmega1284P c'è ma manca AVR_ATmega1284 senza la P.

Manca.

PS:
parlo della toolchain AVR.

BrainBooster:
FYI:
GCC 4.7 Release Series - GNU Project
:slight_smile:
queste le modifiche della nuova versione:
GCC 4.7 Release Series — Changes, New Features, and Fixes - GNU Project

Finalmente!!! Uscita proprio ieri.
Allora in questi giorni formatto tutto e torno ad Arch :wink:

Io per adesso vado avanti con questa, ma poi più in là voglio fare quello che ha fatto legacy per le toolchain, così da avere più toolchain in un colpo solo a scelta e ovviamente proverò questa versione. Però non so se è il caso di aspettare la 4.7.2.

Ciao.

:slight_smile: @Mauro poi ci sarà la 4.7.3, poi la 4.7.4 ecc....
la cosa migliore quando si fanno esperimenti è quella di avere sempre l'ultima versione (quando si lavora seriamente, magari la penultima :smiley: )