Pages: 1 ... 4 5 [6] 7 8 ... 12   Go Down
Author Topic: [Linux] Aggiornare la toolchain Avr  (Read 11659 times)
0 Members and 1 Guest are viewing this topic.
Rome
Offline Offline
God Member
*****
Karma: 1
Posts: 636
La mia prima bromografata!!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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

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


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

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.

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

regV = r27:r26:r25:r24
regW = r31:r30:r29:r28

C'e' ancora casino nel push/pop di questi registri perche' qualche sprovveduto li sta ancora usando come registri ad uso generale quando sono abbastanza delicati da usare e io non li userei altro se non per le load/store, ivi compresi r27 ed r31 che attualmente vengono ignorati ma che non lo saranno affatto appena si passera' ad indirizzi a 32bit ... e col senno di poi diranno "ah, se ci avessimo pensato ... quando ancora eravamo in tempo".

Nella revisione dei core Xmega-compliant per ogni operazione di load e store si fa riferimento, in effetti, a questi registri a 32bit (attualmente a 24bit, r27 ed r31 sono ignorati), in molto semplicato per fare queste cose:

V_load Rd, regV           Rd=memory [ regV ]
V_store regV, Rr           memory [ regV ] = Rr

per la flash si usa
W_Ipm Rd, regW         Rd = flash [ regW ]


C'e' attualmente un gran casino anche per i salti oltre i 128Kbyte perche' la cosa non passa da un "Load xxxx, Pc" (metti nel program counter l'indirizzo a cui saltare), non e' cosi' banale e richiede di toccare un registro speciale mettendolo ad 1 se xxxx > 128K, cosa che gcc non intende fare e che nelle avr-libc non l'ho vista gestita, e morale per questi salti lunghi se ne occupa il linker (e' stata una delle soluzioni, e riguarda le binutils, non gcc) con la controindicazione di NON fare assolutamente salti con "non-symbolic address perche' non sono supportati, mentre il consiglio e' di fare salti ad indirizzo simbolico, e tutto questo perche' gcc davanti ad un salto se ne lava le mani e passa la palla al linker che puo' intervenire soltanto se l'indirizzo del salto e' espresso in modo simbolico e non numerico.


Io mi sto occupando di SDCC per la semplice ragione che ha una machine layer immensamente piu' semplice per cose ad 8 bit, SDCC nasce proprio per core piccoli, gcc e' nato gia' per cose a 32bit, adattarlo ad 8 bit e' per molti versi una "forzatura".

Abbandono un attimo avr-gcc fino a che non uscira' la versione gcc-4.7.1, voglio dare tempo alle cose di assestarsi.


p.s. lo scrivo come idea alternativa alla questione "e la toolchain e dove la metto ?"

io non uso i packet builder delle distro, compilo a mano con una accortezza secondo me comoda: dire a chiunque ne faccia richiesta che la toolchain la trova in /usr/avr8 e non in /usr/local, in questo modo non scoccio eventuali altre utility presenti in /usr/local e posso fare uso delle tecnica del toolchain-mounted volume per "montarci sopra" un filesystem in loopback con dentro la toolchain che piu' mi piace, e i n questo modo mi semplifico immensamente la vita e posso anche sceglire la toolchain che piu' mi piace. Ho uno scriptino che le elenca, banalmente si fa un file list, e mi chiede quale voglio, io scelgo e viene fatto un mount in loopback sul path /usr/avr8 in (readonly).

# > avr8-toolchain -l

[1] avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.7.1--atmel-patched-rev1
[2] avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.7.1
[3] avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.8.0
[4] avr8-gcc-4.5.1-binutils-1.20-my-bsp-libc.0.0.0.1--atmel-patched-rev1
[5] avr8-sdcc---very-proof-rev0--not-currently-working

# > avr8-toolchain 1
Code:
mounting avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.7.1--atmel-patched-rev1 in /usr/avr8 .... done
[!] export does not work, you have to manually set the profile

# > source /usr/avr8/profile
Code:
profile updating about avr8-c-compiler .... done
env[]={CC=avr-gcc, AS=avr-as, LD=avr-ld}

# > avr-gcc --version
Code:
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/avr/libexec/gcc/avr/4.5.1/lto-wrapper
Target: avr
Configured with: ../configure --prefix=/usr/avr --target=avr --enable-languages=c --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 4.5.1-atmel-patched, realeased not for production

Code:
# lspretty /usr/devs/avr8/mountable-toolchain
180Mbyte    avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.7.1--atmel-patched-rev1.ext2
180Mbyte    avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.7.1.ext2
180Mbyte    avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.8.0.ext2
180Mbyte    avr8-gcc-4.5.1-binutils-1.20-my-bsp-libc.0.0.0.1--atmel-patched-rev1.ext2
 50Mbyte    avr8-sdcc---very-proof-rev0--not-currently-working.ext2

« Last Edit: March 22, 2012, 07:39:00 am by legacy » Logged

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

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


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

@leo
quello e' il modo giusto di fare le cose, mi auguro che venga accettato da tutti e applicato alla toolchain ufficiale di gcc.

@mauro
la questione si spacca in 2: leggere dati, e fare salti.

per la questione dati io non passerei dall'asm, io metterei dei valori noti in flash per vedere se la app me li legge correttamente per tutti gli indirizzi che va a testare, e il test lo farei address-in-address, cioe'  
flash [ address ] = address (+offset)

e vedrei se arriva fino in fondo senza che quanto leggi dalla flash sia sbagliato.


per la questione salti
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, in ogni caso per vedere come stanno le cose facendo test ... io metterei in fondo alla flash una semplicissima function che saluta il mondo e vedrei se facendoci un salto il micro ci saluta oppure no.

Si puo' fare scripino che crea un enorme array di boh, xxKbyte pieno di address (+offeset), da mettere poi dentro un file.c del progetto.

In sostanza cercherei di riempire la flash con qualcosa di questo tipo

- app=main+libc&C
- mega-array per il test address (+offset) in address
- function hello_word
« Last Edit: March 22, 2012, 08:02:43 am by legacy » Logged

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

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

legacy le vuoi tutte le patch che ho applicato a avr-gcc & company

le scarico direttamente da Atmel
http://distribute.atmel.no/tools/opensource/avr-gcc
(c'e' gente che e' stata cazziata per questo url, usiamolo)

come vedi dall'output di prima ho gia' buildato la toolchain patchata atmel, usiamo io e te gia' le stesse patch, ho cambiato in piu', credo, soltanto il file version.c di gcc, di as e ld, in modo che lo dicano espressamente quanto glielo si chiede con "gcc --version". Idem as, ed ld, con 'as --version".

io mi incasino con le versioni e mi ritrovo sempre codice compilato con la versione sbagliata

la tecnica del toolchain-mount-volume e' stata pensata proprio per questo e non ti incasini affatto perche' tutta la toolchain sta dentro un file .ext2 montato in loopback e in readonly, in piu' lo scritp che lo monta fa controllo di consistenza, di env, e ti dice che cosa e' attivo, in piu' ti da il vantaggio di poter cambiare la toolchain in meno di 0.5 secondi senza dover ricompilare nulla, e con l'uteriore vantaggio di poterla avere gia' backuppata.

Serve soltanto kernel support per il loopback, che si paga n termini di prestazioni con un maggiore carico di lavoro del kernel perche' dovra' gestirsi il meccanismo, pero' la cosa era stata pensata per i volumi criptati, io uso banali raw ext2, e il tutto gira tranquillamente su un portatile catorcio del 2001, consumando nemmeno troppa ram. Sono forse uno dei pochi che sta usando avr8-toolchain su host powerpc con meno di 1Gbyte di ram a disposizione.

Quote
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

Gcc e' troppo complicato, e poi c'e' gente che se ne sta occupando, mi hanno espressamente consigliato di attendere la 4.7.1 e io li lascio lavorare tranquilli  smiley-mr-green

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.

Il punto non e' testare l'hw del micro ma il compilatore, e quel test non va bene perche' non testa il compilatore per quello che serve a noi, io farei il test che ti ho raccontato poco fa, e lo farei per l'appunto in C.

buh, torno ad SDCC perche' non funziona ancora una pizza  smiley-mr-green
ciao.

« Last Edit: March 22, 2012, 08:28:34 am by legacy » Logged

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

@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.  smiley-razz

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

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

Ma non volevi testare se il codiche che esce dalla toolchain procude 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. Quel pezzo di codice che hai scritto, o una parte di esso spero che venga messo nella crt0 di gcc-4.7.1, cioe' nel posto giusto.

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.

Quindi io ho abbandonato quella tecnica che mi incasinava di più, forse però non sono stato capace di renderla automatica e chiara per questo.

Nel mio caso basta un banale mount con opzione loopback, questo al lato utilizzo, al lato creazione ti fai un folder, ci butti dentro quello che vuoi, quando hai finito ti fai un file ext2 (dimensioni opportune per farci stare tutto), te lo formatti ext2, te lo monti in scrittura, ci butti dentro il contenuto del folder (con attenzione ai permessi e agli attributi), lo smonti, e di li in poi hai la tua mountable-toolchain-volume. Quello a cui stai facendo riferimento tu ha la stessa procedura dietro, solo che e' usata nell'early boot e quindi viene montata in ramdisk (solitamente) e ha dentro un bel po' di cose piu' complesse ed incasinate e che non servono in questo caso.

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

Ogni toolchain nella sua finestra, il giochino funziona se ti appoggi a bash con l'assunto che gli cambi env solo limitatamente alla sessione che fai.

Ci sono dei trucchi come Screen che ti potrebbero dare una mano, ma io per non fare confusione non metto che una ed una soltanto toolchain in ogni finestra, e di finestre ne ho 12, ne uso al massimo 4 per volta.

Una delle cose che ho aggiunto allo scriptino e' un cambio di PS1 in modo che mi dica espressamente (a colori) che sono sulla console di sviluppo avr8-tal-dei-tali. In effetti e' la sola confusione che uno puo' avere a colpo d'occhio quando hai tante shell aperte, sia in grafica sia come me in textconsole switchando da una all'altra con ALT+Fn.

Prima di inserire il colored-PS1, cosa che ho fatto in tuo onore (path e prompt diventano rossi se e' un crosscompiler), per sapere "in quale toolchain sono" usavo chiederlo espressamente all'env

(lo scriptino usa 2 variabiline, espressamente create per lo scopo, e allo scopo di rendere tutto comodo)

shell di sviluppo avr8
#> echo $WHOSECCAMI
avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.7.1--atmel-patched-rev1
# > echo $WHOSECCAMI_IS_NATIVE
no

shell di sviluppo pc, macchina remota, accesso via ssh, dal suo punto di vista e' nativo avere gcc-x86
# > echo $WHOCCAMI
i686-pc-linux-gnu-4.5.3-binutils-2.10-glibc
# > echo $WHOSECCAMI_IS_NATIVE
yes

shell di sviluppo pc, macchina locale, sono in console
# > echo $WHOSECCAMI
powerpc-apple-linux-gnu-4.1.2-binutils-2.18-glibc
# > echo $WHOSECCAMI_IS_NATIVE
yes

la cosa va bene anche negli script, cosi' sanno l'env in cui lavorano, ed evenutalmente e' sbagliato si piantano prima di fare danni.

Code:
if [ "$WHOSECCAMI_IS_NATIVE" != "no" ]
   then
         echo "[!] you are working in the wrong env"
         echo "     the currently env is $$WHOCCAMI, which is not the native one"
         exit
   fi
e posso anche chiederlo a

# > avr8-toolchain
Code:
[1] avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.7.1--atmel-patched-rev1 <-------  it is in currently in use
[2] avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.7.1
[3] avr8-gcc-4.5.1-binutils-1.20-avrlibc-1.8.0
[4] avr8-gcc-4.5.1-binutils-1.20-my-bsp-libc.0.0.0.1--atmel-patched-rev1
[5] avr8-sdcc---very-proof-rev0--not-currently-working

« Last Edit: March 22, 2012, 10:07:10 am by legacy » Logged

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

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.

Quote
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 smiley-grin...., 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.

Logged

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

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

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


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

@leo ok, ora mi torna

@mauro, questo portatile apple e' cosi' miserrimo e scarso in cpu e ram che non posso permettermi ne gnome ne kde, mi tocca usare "e16.9999" (non chiamatelo e17, gli manca quel 0.00001 di classi in piu') che non mi da alcun menu alcun supporto per nulla, non ho nemmeno un file browser grafico tipo nautilus, niente icone sul desktop, tutto in console, e per X11 avevo il tuo stesso sbigottimento, poi ho trovato la soluzione nella shell multi tab come gnome multi-term, che e' uguale a gnome-terminal ma al posto di aprire una finestra nuova per darti una nuova shell ti apre un tab accanto e tu puoi anche volendo cambiarne il titolo del tab cosi' a colpo d'occhio sai subito dove sei.

Prima la mia shell preferita era Aterm, ora e' gnome-multi-term per quella questione dei tab: secondo me la cosa piu' comoda in assoluto e mi sono complimentato per email con tutte le persone nella voce AUTHORS dei sorgenti !!!


Su macOSX lion del portatile serio che ho al lavoro  (serio si fa per dire, pero' e' un intel core i3 con 4 giga di ram, rispetto al mio macinino fa molta differenza) mi sono trovato la stessa features di default, e meno male che anche in Apple ci hanno pensato perche' hanno fatto proprio bene: stra comoda!

« Last Edit: March 22, 2012, 12:35:00 pm by legacy » Logged

Rome
Offline Offline
God Member
*****
Karma: 1
Posts: 636
La mia prima bromografata!!
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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

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

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

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

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

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.
« Last Edit: March 22, 2012, 06:38:05 pm by MauroTec » Logged

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

Pages: 1 ... 4 5 [6] 7 8 ... 12   Go Up
Jump to: