next topic »

[Reply #45 on:]

Seconda prova.
NON funziona neanche con i Tiny. Ecco il BlinkWithoutDelay Vs. un Tiny84:

Code:

In file included from /home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/wiring_pulse.c:26:0:
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/pins_arduino.h:60:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'port_to_mode_PGM'
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/pins_arduino.h:61:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'port_to_input_PGM'
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/pins_arduino.h:62:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'port_to_output_PGM'
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/pins_arduino.h:63:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'port_to_pcmask_PGM'
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/pins_arduino.h:65:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'digital_pin_to_port_PGM'
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/pins_arduino.h:67:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'digital_pin_to_bit_mask_PGM'
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/pins_arduino.h:68:27: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'digital_pin_to_timer_PGM'
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/wiring_pulse.c: In function 'pulseIn':
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/wiring_pulse.c:37:16: error: 'digital_pin_to_bit_mask_PGM' undeclared (first use in this function)
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/wiring_pulse.c:37:16: note: each undeclared identifier is reported only once for each function it appears in
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/wiring_pulse.c:38:17: error: 'digital_pin_to_port_PGM' undeclared (first use in this function)
/home/geuropa/Documenti/Arduino/arduino-tiny-0022/hardware/tiny/cores/tiny/wiring_pulse.c:48:11: error: 'port_to_input_PGM' undeclared (first use in this function)

[Reply #46 on:]

Terza prova.
Lo sketch BlinkWithoutDelay compila per 644 e 1284.

[Reply #47 on:]

Come ti ho scritto dovrai aspettare avr-gcc-4.7.1, tutte le attuali non ne sono capaci come ti ho raccontato.

Mi spieghi come mai la toolchain Atmel non ha questo limite ?

Se parli dei binari io ti rispondo che non stiamo parlando della stessa cosa, io sto parlando del ramo ufficiale avr-gcc, tu di quanto una azienda ci fa, e a me non mi interessa quello che dicono in Atmel, non solo loro che si occupano del compilaotre gcc, io su macchine x86 uso avr-studio per lavoro, linux solitamente lo uso sul portatile powerc, e dato che leo mi ha chiesto un parere, e dato che la cosa potrebbe interessarmi in forma hobbistica per avere un compilatore avr8 anche la dove windows fisicamente non ci puo' girare (il portatile ha cpu non x86 ma powerpc, per cui non esistono toolchain binarie gia' fatte), ho parlato con i mainteiners di avr-gcc e con diversi utenti e devs che si trovano su freenode (irc), e tutti mi hanno confermato la stessa cosa: c'e' un gran casino perche' ci sono divergenze sul da farsi, pero' le modifiche ufficiali, vere, testate, e approvate, ma sopratutto che si possono capire, che hanno senso e che non sono rattoppate tanto per tener su la baracca, sono previste e riguarderanno la 4.7.1, come e' chiaramente scritto anche sul forum avr.

Nel ramo 4.7 vera' rifatto tutto e a partire dal 4.7.1 non servira' piu' alcuna patch. La proposta di modifica riguarda una revisione totale della machine layer.

Atmel non ha rilasciato nulla nei sorgenti per avr8, fornisce delle patch per avr32, che non centra una pizza, e per avr8 fornisce solo dei binari che io personalmente non ho nemmeno interesse a provare.

Se poi tu i binari della toolchain fornita da Atmel li hai provati e ci dici che quella toolchain e' esente dai difetti che riguardano i far-pointers (ma li hai provati sul serio ?) significa che in Atmel hanno patchato avr-gcc senza aver minimamente documentato la cosa il che annichilisce tutto il discorso con un "embe, e chi se ne frega, come me li compilo io su powerpc ?"

Morale astro, se la cosa sta in piedi tu stai consigliando di usare i binari, mentre io sto parlando dei sorgenti di cui sono stra certo che il difetto non ha trovato che pagliativi.

[Reply #48 on:]

'sta cosa comincia a farmi venire il mal di testa...
Sul PC "cavia" ho rimesso tutto com'era prima. Oggi a casa vedrò se mi viene qualche altra idea.

[Reply #49 on:]

Se parli dei binari io ti rispondo che non stiamo parlando della stessa cosa, io sto parlando del ramo ufficiale avr-gcc, tu di quanto una azienda ci fa, e a me non mi interessa quello che dicono in Atmel

Ok, chiarissimo.
Infatti io sto parlando degli eseguibili già compilati di Atmel, che sicuramente includono delle patch non ufficiali, e non del compilatore che scarichi dal repository.
Concordo col discorso che non è compito di Atmel fare manutenzione ad avr-gcc, però non sputiamo sul piatto dove mangiamo se loro ci offrono una soluzione funzionante al problema.
Non ho ne tempo, e nemmeno la voglia, di mettermi a verificare se le patch di Atmel a gcc sono fornite in sorgente o solo sotto forma di eseguibili, e tutto sommato non mi interessa, a me interessano solo i risultati finali.
Il compilatore è uno strumento di lavoro e non devo perderci tempo per capire come funziona o come posso modificarlo/correggerlo, se non va bene ne uso uno diverso o una nuova release che risolve i problemi.

[Reply #50 on:]

Le patch sono sotto forma di codice sorgente.

[Reply #51 on:]

'sta cosa comincia a farmi venire il mal di testa...

Tu non hai idea di quello che ho passato io per farla funzionare sotto Windows, aggiusti una cosa e subito dopo ne trovi altre cinque che non vanno  
Però alla fine si tratta solo di correggere/modificare alcune righe nelle varie librerie, non ho tenuto il conto, ma in totale dovrebbero essere meno di 20 righe di codice, almeno questo per la versione Windows utilizzando in toto tutti i file, e gli eseguibili, della toolchain.
Con Linux se non fai la stessa cosa la situazione potrebbe risultare molto più complicata, vedi errore seriali sulla Mega2560.
Per quanto riguarda la seriale della Mega2560 ho provato ad aggiunge le altre tre, e usarle, allo sketch che stampa la tabella ASCII, non ho nessun errore di compilazione, adesso non posso verificare se poi funzionano sul serio, però più tardi lo faccio.
Per gli ATtiny non ho fatto nessuna prova, in questa prima fase mi interessava far funzionare il tutto con i processori standard di Arduino, quindi 328 e 2560,  ti anticipo che ora sembra essere tutto ok solo con la 0023, con la 1.0 ho ancora dei problemi residui.

[Reply #52 on:]

Seconda prova.
NON funziona neanche con i Tiny. Ecco il BlinkWithoutDelay Vs. un Tiny84:

Provato adesso con il 4313, compila senza problemi.

[Reply #53 on:]

Le patch sono sotto forma di codice sorgente.

Le patch messe online da Atmel riguardano avr32, che ha una machine layer completamente diversa da quella in avr8, non centra nulla con il problema in oggetto, che non la riguarda, e che quindi non puo' nemmeno lontanamente aiutare, anzi fa solo casino.

Ho scritto ad Atmel segnalando l'errore, perche' di errore si tratta. Vedremo che rispondono, se rispondono o se danno chiarimenti in merito, allo stato attuale ignoro qualsiasi patch che non provenga dal ramo ufficiale di avr-gcc, per altro mi hanno risposto sl forum avr suggerendo la stessa identica cosa.

[Reply #54 on:]

Le patch messe online da Atmel riguardano avr32, che ha una machine layer completamente diversa da quella in avr8, non centra nulla con il problema in oggetto, che non la riguarda, e che quindi non puo' nemmeno lontanamente aiutare, anzi fa solo casino.

Avevamo già stabilito che le patch scaricabili attualmente dalla pagina della toolchain sono solo un update per gli AVR32 relativo all'ultima release della toolchain, ovvero è solo una parte di tutte le patch.

Edit: questo è il link postato da MauroTec dove dovrebbe esserci tutto.

Edit2: e qui si parla in dettaglio del mega2560 e del pc a 3 byte, ovvero una patch specifica anche se tocca andare a vedere le varie dipendenze per capirci qualcosa sul serio.

[Reply #55 on:]

Provato adesso con il 4313, compila senza problemi.

Però non abbiamo usato la stessa cosa. Tu hai fatto le prove con la toolchain Atmel, io con la toolchain precompilata del sito linkato, che è costruita partendo dagli script di Bingo600 di Avrfreaks. A casa proverò con la toolchain Atmel.

[Reply #56 on:]

Se parli dei binari io ti rispondo che non stiamo parlando della stessa cosa, io sto parlando del ramo ufficiale avr-gcc, tu di quanto una azienda ci fa, e a me non mi interessa quello che dicono in Atmel

Ok, chiarissimo.
Infatti io sto parlando degli eseguibili già compilati di Atmel, che sicuramente includono delle patch non ufficiali, e non del compilatore che scarichi dal repository.
Concordo col discorso che non è compito di Atmel fare manutenzione ad avr-gcc, però non sputiamo sul piatto dove mangiamo se loro ci offrono una soluzione funzionante al problema.
Non ho ne tempo, e nemmeno la voglia, di mettermi a verificare se le patch di Atmel a gcc sono fornite in sorgente o solo sotto forma di eseguibili, e tutto sommato non mi interessa, a me interessano solo i risultati finali.
Il compilatore è uno strumento di lavoro e non devo perderci tempo per capire come funziona o come posso modificarlo/correggerlo, se non va bene ne uso uno diverso o una nuova release che risolve i problemi.

Chiaro, e daccordissimo in tutto.

Il mio discorso praticamente vale la candela soltanto per chi ha un pc con processore non x86, tipo il mio powerbook apple con cpu G4, perche' usare emulatori PC e' lenterrimo oltre il sopportabile.

Per me e' fisicamente impossibile usare le toolchain binarie-x86 di Atmel su quel portatile, dovrei necessariamente ricompilarle per la mia cpu, quindi seguo il consiglio che mi hanno dato a maggioranza ed aspetto il avr-gcc-4.7.1, anzi avr-gcc-4.7.3 seguendo le timeline dei changes promessi.

Domani notte voglio sentire i ragazzi di SDCC perche' potrebbe essere una alternativa.

[Reply #57 on:]

Per me e' fisicamente impossibile usare le toolchain binarie-x86 di Atmel su quel portatile, dovrei necessariamente ricompilarle per la mia cpu, quindi seguo il consiglio che mi hanno dato a maggioranza ed aspetto il avr-gcc-4.7.1, anzi avr-gcc-4.7.3 seguendo le timeline dei changes promessi.

Indubbiamente sul tuo notebook sei obbligato a ricompilare tutto, tra parentesi lo stesso problema dovrebbe esistere per gli utenti MAC a meno che non sia possibile far girare un eseguibile Linux, senza ricompilarlo, sotto MAC OS, ma forse loro fanno prima ad usare BootCamp e caricare direttamente Windows 

[Reply #58 on:]

Edit2: e qui si parla in dettaglio del mega2560 e del pc a 3 byte, ovvero una patch specifica anche se tocca andare a vedere le varie dipendenze per capirci qualcosa sul serio.

Code:

{ "avr6",                 ARCH_AVR6, NULL,                        0, 0x0200, "m2561" },
-  { "atmega2560",           ARCH_AVR6, "__AVR_ATmega2560__",        0, 0x0200, "m2561" },
+  { "atmega2560",           ARCH_AVR6, "__AVR_ATmega2560__",        0, 0x0200, "m2560" },
   { "atmega2561",           ARCH_AVR6, "__AVR_ATmega2561__",        0, 0x0200, "m2561" },
     /* Enhanced, == 256K.  */
     /* Xmega, <= 8K FLASH.  */

Questa patch corregge un'errore di copia incolla in pratica hanno dimenticato a corregere l'ultimo campo m2561 in m2560. La patch più corposa è questa: 30-gcc-4.5.1-fixedpoint-3-4-2010.patch che contiene codice che coinvolge tutti i micro. Mentre per attiny la patch più corposa è questa: 32-gcc-4.5.1-avrtiny10.patch

Capisco perfettamente quello che vuoi dire, però in questo caso invece di complicarsi la vita per capire come deve essere compilato gcc per la toolchain Atmel mi pare logico utilizzare gli eseguibili già pronti, e sicuramente funzionanti, almeno in prima battuta per verificare se il tutto funziona, poi nulla vieta, con calma e tranquillità, di ricompilarsi il tutto partendo dai sorgenti e dalle patch.

E siamo sempre li, il problema è che devi mettere i file nel posto giusto per provare con l'ide arduino, perchè a quello che ricordo la versione per linux non ha il compilatore incluso nel suo tree. Comunque ti assicuro che pasticciare con gli eseguibili non è la strada più semplice anche perchè su linux in fase di configurazione devi specificare il PREFIX e poi installare i file nei posti che rispecchiano il prefix, altrimenti potrebbe non funzionare e allora non trova un file e tu cominci a sporcare il sistema con link simbolici per far stare impiedi la baracca il tutto agendo alla cieca.

Comunque ognuno e libero di trovare e provare la sua strada, io le ho sperimentate tutte e quella della creazione dei pacchetti tramite i tools di sistema è la via più diretta e comoda, anche se prima sarebbe opportuno installare tutto manualmente in /usr/local ma in questo caso bisogna risolvere il problema di far vedere i tools ad arduino, il modo più semplice è quello di disinstallare i pacchetti avr-gcc & company allora scaricare i sorgenti, patchare manualmente, compilare ed installare, allora l'ide userà avr-g++ che trova nel path ed essendocene solo uno userà quello appena installato.

Io continuo a studiare un po le patch e a documentarmi poi passo alla vie di fatto.

Ciao.

[Reply #59 on:]

Aggiornamento:
Sono passato dal repo di fedora 15 e mi sono preso il pacchetto sorgente di avr-gcc-4.5.3 e ho provato la compilazione, come prima cosa ho notato un'errore di riferimento in libmpc.so allora ho scaricato la versione 0.9 e ho provato a ricompilare e tutto è andato a buon fine, ma ancora non ho provato ad installare ed usare avr-gcc, per questo ancora è presto, prima devo introdurre ad una ad una le patch di Atmel e tentare la compilazione, in più l'applicazione della patch può portare ad errore e bloccare il processo di creazione del pacchetto. Al momento ho introdotto solo la patch Atmel 50-gcc-4.5.1-new-devices.patch, ora aggiungo le altre poco per volta.

Chi volesse tentare dico che deve avere libmpc-devel, libmpfr-devel, gmp-devel, per le versioni io ho:
gmp-devel-5.0.4-4.fc12.i686
libmpc-devel-0.9-1.fc12.i686
mpfr-devel-3.0.0-4.fc12.i686

Ciao.