[Linux] Aggiornare la toolchain Avr

Leo per 2,3 e 4 la risposta è no, non ho provato, però so che il compilatore lavora perchè viene compilato in due fasi, e c'è una fase di test durante la compilazione che produce codice per tutti i micro, infatti questa fase veniva condotta con successo per tutti i micro tranne per xmega dal momento che binutils nel mio sistema non conosce come linkare per questi micro. Dopo aver applicato le patch a binutils compilato ed aggiornato la versione presente nel sistema il test per xmega è andato a buon fine ed i pacchetti sono stati creati.

Le risposte 2,3,4 potrei averle ma mi devi dire o dare il tuo ide che di sicuro funziona, ma anche così avrò sicuramente qualche problema con jre, allora dovrei installare quella originale ecc, solo per dire che funziona con arduino. Certamente compilerò i mie programmi con questa toolchain per testarla, ma non prevede il core arduino, uso altre lib.

Nota che ancora devo compilare avr-libc con le pacth di Atmel, ora se mi passa il mal di capa e riesco a concentrarmi ci provo.

Come ci sono arrivato:
I link su avrfreaks, gli script uno in particolare get-pacthes.sh guardandolo all'interno si vede che usa wget per scaricare le pacth allora con il browser sono andato li, anche il file che scarica i pacchetti è stato utile per prendere le binutils 2.20.1 che non trovavo. Ora penso che tu potresti facilmente fare la stessa cosa su ubuntu tranne che li tu hai i .deb ed io non ricordo come si fa ad applicare le pacth, o meglio ricordo che si mettono tutte le pacth in un file con estensione .diff e se questo file e presente quando avvia dpkg questo le applica tutte in toto e poi fa più o meno quello che ha fatto rpmbuild per fedora, cioè applica le pacth avvia la configurazione, compila, ed installa su un percorso di comodo provvisorio e poic mette tutto nel .deb.

Nel mio caso ho preso dal repo di fedora 15 avr-gcc-4.5.3 ed ho provato con questo, ma avevo sempre un problema con le pacth, allora ho trovato sempre in fedora il pacchetto sorgente .src.rpm di avr-gcc-4.5.1 e con questo ho incontrato le stesse difficoltà ad applicare le patch, ho capito il motivo e ho corretto due pacth originali di ATMEL ma solo per portare a termine l'applicazione delle pacth, cioè non ho toccato codice compilabile.
Comunque il pacchetto src.rpm va installato (ma devi avere home rpmbuild inizializata) con rpm -i nomepac, poi cd homerpmbuild/SPEC
e avvio il processo di costruzione del pacchetto così: rpmbuild -ba --target=i686 avr-gcc.spec che crea dei pacchetti binari per arch i686, rpmbuild parsa il file avr-gcc e in base a questo avviengono tutte le fasi necessarie per passare da un sorgente ad uno o più pacchetti binari.

Nel tuo caso tu hai di bisogno di due file, il .dsc e il tar.gz dal repo di ubuntu e provi da questi a creare il pacchetto .deb, se va a buon fine poi sostituisci il tar.gz con la versione del pacchetto sorgente originale di avr-gcc sempre in tar-gz e modifichi leggermente il file .dsc (la modifica e intuitiva) e riavvia la creazione del pacchetto, poi trovi la procedura per pacthare il sorgente prima che si avvia la fase di configure e se va a buon fine allora installi e provi a compilare con Arduino IDE.

Ciao.
Se tu dovessi avere un progetto scritto in C/C++ che posso compilare per testare il problema dei 64k, passamelo che dopo aver compilato avr-libc provo.

Ma una domanda. Rispetto ad usare lo script di Avrfreaks, che vantaggi hai avuto? Io con lo script ho compilato correttamente la toolchain però poi non sono riuscito all'atto pratico ad usarla con l'IDE 0022. Ora volevo riprovare con l'IDE 1.0.1RC visto che questa prima cerca di usare la toolchain incorporata.

Leo, anche tu puoi installare il tutto in automatico, ti basta entrare nella dir dove si trova avr-gcc (nota che viene compilato in sottodirectory, di solito chiamata build) e scrivere make install, il makefile installerà di default in /usr/local e se nel sistema non hai un pacchetto .deb di avr-gcc installato, l'ide richiamerà quello nel path di esecuzione che nel tuo caso si troverà in /usr/local/bin.

Il vantaggio è quello che hai quando trovi nei repo della distrò una pacchetto di aggiornamento, lo installi e provi se non sei contento ritorni alla versione precedente, poi puoi anche installare ad esempio avr-gcc 4.5.1 e avr-libc-1.8.0 al posto della 1.7.1 e provare se non va torni indietro e così via.

Ho provato a creare il pacchetto per avr-libc-1.7.1 con su le pacth di Amel, ma non ha funzionato, il problema è che mancano i makefile.am per le nuove MCU introdotte. Sotto si vede che cerca il makefile.in e non lo trova, anzi non trova proprio la directory con il nome della MCU, ora riprovo a creare delle cartelle con quel nome e vediamo se automake è in grado di creare i makefile.

 cd . && /bin/sh /home/mauro/rpmbuild/BUILD/avr-libc-1.7.1/missing --run automake-1.11 --foreign
configure.ac:1151: required file `avr/lib/avr35/attiny1634/Makefile.in' not found
configure.ac:1163: required file `avr/lib/avr4/atmega48pa/Makefile.in' not found
configure.ac:1186: required file `avr/lib/avr5/at90pwm161/Makefile.in' not found
configure.ac:1186: required file `avr/lib/avr5/atmega325pa/Makefile.in' not found
configure.ac:1186: required file `avr/lib/avr5/atmega3250pa/Makefile.in' not found
configure.ac:1186: required file `avr/lib/avr5/atmega3290pa/Makefile.in' not found
configure.ac:1303: required file `avr/lib/avrxmega2/atxmega32x1/Makefile.in' not found
configure.ac:1327: required file `avr/lib/avrxmega6/atxmega128b1/Makefile.in' not found
configure.ac:1327: required file `avr/lib/avrxmega6/atxmega256a3bu/Makefile.in' not found
make: *** [Makefile.in] Error 1
[mauro@localhost avr-libc-1.7.1]$ make

ah, dimenticavo, ho compilato con avr-gcc-4.5.1, binutils-2.20.1 e avr-libc-1.6.7 (no atmel patch) e per il 328 ha funzionato senza errori o warning, ma questo me lo aspettavo, c'è da fare la prova con un 1284 o uno di quelle MCU che vedi sotto, questo appena risolvo il problema di avr-libc.

Ciao.

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.

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.

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.

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:

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

avr-libc.spec (6.27 KB)

avr-libc-1.7.1-new-devices-makefile.am.patch (25.6 KB)

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

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.

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.