[MAC] Aggiornamento IDE 1.0x all'ultima versione Atmel Toolchain

Qualche novità ?

nid69ita:
Qualche novità ?

Purtroppo NO ... quell'errore per me è piuttosto oscuro e ... non ho visto nessuno proporre un tentativo di soluzione ... :frowning:

Guglielmo

Cerca con google "unable to find a register to spill in class 'POINTER_REGS'", siamo in buona compagnia.

Il bug è noto ed è stato risolto nella 4.0, ma ora è ritornato. Quindi se di bug del compilatore si tratta c'è poco da fare al momento se non trovare un workaround, per aggirare il problema. Alcuni dicono di ottimizzare con O1, anziché Os, ma con arduino style si è vicolati ad usare Os, quindi....

Ciao.

Se è un bug del compilatore.... bella fregatura. Tappano una falla e se ne apre un'altra a 10 cm di distanza! :zipper_mouth_face:

Domanda forse stupida, e forse avete già risposto.
Ma qualcuno ha installato e usato Avr Studio? L'ultima versione dovrebbe usare la toolchain nuova. Anche li usando il codice in esame escono questi errori?

Scusa Nid ma come vedi dal titolo del thread qui si parla di MAC (opzionalmente *nix, quindi Linux).
AvrStudio va solo su Windows. :wink:

@Nid
C'è la discussione apposita per Windows --> [WIN] Aggiornam. compilatore IDE 0022-0023-1.0 all'ULTIMA VERSIONE ATMEL - Megatopic - Arduino Forum

leo72:
Scusa Nid ma come vedi dal titolo del thread qui si parla di MAC (opzionalmente *nix, quindi Linux).
AvrStudio va solo su Windows. :wink:

Ho anche Linux Ubuntu e lì ho aspettato a mettere la toolchain nuova, su Win l'ho aggiornata (ho mantenuto però un IDE non aggiornato).
Lo sò, ma mi sono un pò perso, portate pazienza. Il problema non viene dato in qualsiasi versione di S.O. si usi?

Ricordo che stiamo parlando di codice C++ e che quindi il compilatore è g++.
Quelle librerie io non le conosco e non ho voglia o interesse a studiarle, sicuramente c'è un workaround, ma finche non si trova qualcuno che si mette li a scrivere codice isolato per replicare il problema, non si va da nessuna parte.

Potrei dire scrivete un programmino di 5 righe senza usare librerie esterne che una volta compilato dia lo stesso errore e poi proviamo a togliere Os ecc, o altre prove che vengono in mente solo dopo aver visionato il codice isolato. Ma ci sono grosse limitazioni usando l'ide Arduino, dovreste compilare a manina.

Da quello che ho letto sembra che l'errore si presenti quando ci sono puntatori a puntatori che puntano ad un puntatore, ma ho letto tanto rapidamente che la devo considerare solo una vaga idea.

Ciao.

nid69ita:
...
Lo sò, ma mi sono un pò perso, portate pazienza. Il problema non viene dato in qualsiasi versione di S.O. si usi?
...

Io ho un Win7 in una Virtual Mchine su OS X ed ho provato ad inserire, come descrive il link indicato da Leo, la nuova ToolChain precompilata da Atmel, sotto IDE 1.05 in Windows e ... mi sembra si comporti esattamente allo stesso modo. Se tu ce l'hai, basta che prendi quel piccolo esempio che ho messo e provi a compilare ...

Facci sapere :wink:

Guglielmo

P.S. : Anche su Linux mi sembra che Leo riscontri lo stesso problema ...

gpb01:
Io ho un Win7 in una Virtual Mchine su OS X ed ho provato ad inserire, come descrive il link indicato da Leo, la nuova ToolChain precompilata da Atmel, sotto IDE 1.05 in Windows e ... mi sembra si comporti esattamente allo stesso modo. Se tu ce l'hai, basta che prendi quel piccolo esempio che ho messo e provi a compilare ...
Facci sapere :wink:
Guglielmo
P.S. : Anche su Linux mi sembra che Leo riscontri lo stesso problema ...

Si, nei post precedenti di questo thread sono intervenuto e ho riscontrato gli stessi errori, ma io provavo su Windows (scusate ma davo per scontato che il S.O. c'entrasse ben poco).
In questo thread a differenza di quello per Windows mi sembrava @guglielmo e @leo stessero affrontando meglio il problema, in maniera più sistematica. Sorry

P.S. ma siete sicuri abbia senso fare differenze tra S.O. per questi problemi di compilazione?

MauroTec:
Cerca con google "unable to find a register to spill in class 'POINTER_REGS'", siamo in buona compagnia.
Il bug è noto ed è stato risolto nella 4.0, ma ora è ritornato. Quindi se di bug del compilatore si tratta c'è poco da fare al momento se non trovare un workaround, per aggirare il problema. Alcuni dicono di ottimizzare con O1, anziché Os, ma con arduino style si è vicolati ad usare Os, quindi....

Secondo te l'IDE richiama il compilatore con parametri scritti nel codice java compilato?
Non risulta la possibilità di avere un file txt tra i tanti sotto l'IDE per personalizzare questi parametri ?

@Leo72 che usi la nightybuild e te la compili, non è che si riesce a trovare nei sorgenti dell'IDE dove passa i parametri e provare a cambiare questo parametro?
E' solo una idea.

nid69ita:
...
P.S. ma siete sicuri abbia senso fare differenze tra S.O. per questi problemi di compilazione?

NO, l'unica differenza poteva essere magari una cattiva compilazione della Toolchain su Mac ... per questo volevo un riscontro che anche le loro pre-compilate (Win, Linux) dessero lo stesso problema ... e l'ho avuto :wink:

Guglielmo

Se dipende da un bug nei sorgenti, la stessa versione compilata per Win, Linux o Mac dovrebbe portare a generare lo stesso errore, a meno che non ci siano direttive specifiche per i vari SO. Ma non credo perché sia su Lin che su Mac, prelevando l'ultima toolchain, arriviamo allo stesso errore.

Che poi credo proprio che dipenda dal compilatore. Leggendo un pò di documentazione in rete, ho appreso che il compilatore ottimizzando il codice può portare anche all'uso di registri della CPU per alcune variabili, in modo da velocizzare l'esecuzione del programma, evitando di depositare dati in RAM a cui poi deve accedere. La RAM è memoria esterna alla CPU, i registri sono invece interni.

Lì pare che ci sia un problema di assegnazione di qualche dato ad un registro.

Guardando ai sorgenti dell'IDE Arduino, la compilazione viene fatta dal Compiler.java
Dentro ci sono 2 funzioni getCommandCompilerCPP() e getCommandCompilerC() (riga 600)

List baseCommandCompilerCPP = new ArrayList(Arrays.asList(new String[] {
      avrBasePath + "avr-g++",
      "-c", // compile, don't link
      "-g", // include debugging info (so errors include line numbers)
      "-Os", // optimize for size
      Preferences.getBoolean("build.verbose") ? "-Wall" : "-w", // show warnings if verbose
      "-fno-exceptions",
      "-ffunction-sections", // place each function in its own section
      "-fdata-sections",
      "-mmcu=" + boardPreferences.get("build.mcu"),
      "-DF_CPU=" + boardPreferences.get("build.f_cpu"),
      "-MMD", // output dependancy info
      "-DUSB_VID=" + boardPreferences.get("build.vid"),
      "-DUSB_PID=" + boardPreferences.get("build.pid"),      
      "-DARDUINO=" + Base.REVISION,
    }));

Alcuni parametri sono fissi mentre altri sono letti dal file boards.txt , naturalmente a seconda della board.

Si il parametro optimize è fisso a s (size), quindi se sei in grado di modificarlo e fare le prove con -O2 o -O1 fai e riporta qui. Tempo addietro ho proposto a chi è in grado di programmare in java di modificare il preprocessore di arduino al fine di fargli interpretare delle #define APP_OPT size, o APP_OPT 02 e altre macro dummy, al fine di poter acquistare flessibilità. Il preprocessore di arduino legge i sorgenti prima di avviare la compilazione e quindi interpreta le macro dummy speciali, che iniziano con APP (arduino Pre Processor) e in base a queste, modifica i flags.

Se tu nid sei in grado di programmare java potresti provarci, per ciò che riguarda la logica io posso dedicarci tempo ma non potrei passare alle vie di fatto perchè allergico a java. :stuck_out_tongue:

"-Os", // optimize for size

In questo documento Atmel Redirect Notice

nella sezione "Issues Fixed" c'è questo bug risolto: PR513: An "unable to find a register to spill" issue has been fixed for Tiny architecture

Questo conferma che il bug è noto e che questi alle volte ritornano 8)
C'è da vedere se con tiny quel bug si verifica, sempre che gpb01 non stia proprio compilando per tiny.

Ciao.

Il problema è che la lib ethernet non è compatibile con i Tiny per cui non si può fare la prova che dici usando il codice arduinico.

leo72:
Il problema è che la lib ethernet non è compatibile con i Tiny per cui non si può fare la prova che dici usando il codice arduinico.

Vero non ci avevo pensato, anzi a dire il vero non conosceo tutti i tiny di atmel e non sapevo fosse totalmente impossibile. Ecco un buon motivo per dare seguito alla mia di isolare il codice che comporta il bug in modo da replicarlo potenzialmente con tutte le varianti possibili, quindi diverse MCU e diversi flags di ottimizazione.

Bisogna conoscere nel dettaglio cosa fanno tutte le librerie coinvolte.

[OT] ho dato uno sguardo a gcc 4.8 e ci sono interessanti novità:
Ora il compilatore può usare RTEMS RTEMS Project o la avr-libc.

http://gcc.gnu.org/gcc-4.8/changes.html

Ciao.

MauroTec:
Se tu nid sei in grado di programmare java potresti provarci, per ciò che riguarda la logica io posso dedicarci tempo ma non potrei passare alle vie di fatto perchè allergico a java. :stuck_out_tongue:

Conosco un poco java ma non saprei come ricompilare l'IDE, sorry.
Secondo me si potrebbe provare a ricompilare con quel parametro i sorgenti che l'IDE mette nella cartella build e vedere se il compilatore ancora si arrabbia.
Però se funziona, non credo averebbe senso avere un ulteriore IDE non ufficiale.
Dovrebbe essere una possibilità da inserire nell'IDE ufficiale quella di fargli leggere dei parametri maggiori dal file boards.txt come ad esempio quale ottimizzazione attivare.

EDIT:
Ho provato a prendere lo sketch che da errori in verbose, controllato che da warning su progmem ingorato dentro a Print.cpp
Allora ho creato file bat con stessi parametri ma con -O1 e ho ricompilato solo la Print.cpp
Mi da lo stesso errore, "line 44 warning: progmem attribute ignored"

@Mauro:
oltre al problema compatibilità codice, c'è da vedere la compatibilità hardware, parlo di memoria ad esempio.
Tornando al bug, come hai ben capito esso viene fuori per come è stato scritto il codice, non perché usa l'Ethernet. Quindi andrebbe trovato il modo di replicarlo, ma bisognerebbe analizzare non solo tutta la catena di include della libreria che gestisce l'Ethernet ma anche i changelog del compilatore. Ho avuto un problema simile quando ho provato a compilare un RTOS scritto da un utente: con la toolchain integrata nell'IDE nessun problema, quando l'ho compilato con la nuova toolchain, ho avuto diversi problemi relativi al modo in cui vengono gestite le ISR. E non ho capito da dove l'errore viene fuori.