[WIN] Aggiornam. compilatore IDE 0022-0023-1.0 all'ULTIMA VERSIONE ATMEL

Risolto.

Ho aggiunto in WString.h nel core di Arduino per avr

#define __PROG_TYPES_COMPAT__

prima di

#include <avr/pgmspace.h>

in modo che risulti

#define __PROG_TYPES_COMPAT__
#include <avr/pgmspace.h>

In questo modo vengono ripescati i metodi deprecati e non bisogna modificare tutto il core di Arduino. :grin:

in teoria se metti la define prima di tutto nel tuo .ino non funziona lo stesso?

void setup() {
  Serial.begin(9600);
}

void loop() {
  Serial.println(F("Test"));
  delay(1000);
}

Compilato su IDE 1.0.5 originale per Arduino UNO

Dimensione del file binario dello sketch: 2.126 bytes (su un massimo di 32.256 bytes)

Compilato su IDE 1.5.5 originale

Lo sketch usa 2.050 byte (6%) dello spazio disponibile per i programmi. Il massimo è 32.256 byte.
Le variabili globali usano 187 byte (9%) di memoria dinamica, lasciando 1.861 byte liberi per le variabili locali. Il massimo è 2.048 byte.

Compilato su IDE 1.5.5 con TC 3.4.3 per Arduino UNO

Lo sketch usa 1.866 byte (5%) dello spazio disponibile per i programmi. Il massimo è 32.256 byte.
Le variabili globali usano 187 byte (9%) di memoria dinamica, lasciando 1.861 byte liberi per le variabili locali. Il massimo è 2.048 byte.

Interessante... no!! :grin: :grin:

EDIT: provato anche 1.5.5 originale.

lesto:
in teoria se metti la define prima di tutto nel tuo .ino non funziona lo stesso?

C'è scritto di metterlo prima dell'include... e così ho fatto

/**
\ingroup avr_pgmspace
\typedef prog_char
\note DEPRECATED

This typedef is now deprecated because the usage of the progmem
attribute on a type is not supported in GCC. However, the use of the
progmem attribute on a variable declaration is supported, and this is
now the recommended usage.

The typedef is only visible if the macro PROG_TYPES_COMPAT
has been defined before including <avr/pgmspace.h> (either by a
#define directive, or by a -D compiler option.)

Type of a "char" object located in flash ROM.
*/
typedef char PROGMEM prog_char;

Paolo, ciò che scrivi significa che hai trovato la sequenza esatta di operazioni per l'aggiornamento alla nuova toolchain?
Se è così ti spiacerebbe, basandoti sul primo post, implementare la procedura, in modo che sia chiara e fattibile da chiunque, perfino da me? :grin:

Domani testo qualche codice più lungo e complesso e ti aggiorno.

Paolo, uno sketch vuoto è un test ma non è IL test. Hai provato con l'esempio WiFiWebServer della libreria WiFi? Quella dà un sacco di problemi, se compili quella sei a posto. :wink:

leo72:
Paolo, uno sketch vuoto è un test ma non è IL test. Hai provato con l'esempio WiFiWebServer della libreria WiFi? Quella dà un sacco di problemi, se compili quella sei a posto. :wink:

Leo, con la 3.4.3, a parte un po' di warning del tipo :

/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.0.5 TL 3.4.3.app/Contents/Resources/Java/hardware/arduino/cores/arduino/IPAddress.h: In member function 'bool IPAddress::operator==(const IPAddress&)':
/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.0.5 TL 3.4.3.app/Contents/Resources/Java/hardware/arduino/cores/arduino/IPAddress.h:52:75: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     bool operator==(const IPAddress& addr) { return (*((uint32_t*)_address)) == (*((uint32_t*)addr._address)); };
                                                                           ^

... compila, come già ho avuto modo di dire nel thread del MAC, WiFiWebServer senza problemi :wink:

Per risolvere questo tipo di warning su IPaddress, ho visto che Mauro, nell'apposito thread, a proposto una possibile soluzione ... certo che tocca mettere le mai in vari punti del core relativo alla parte TCP/IP.

Guglielmo

Sì ma difatti io mi riallacciavo a QUELLA modifica. Io l'ho apportata e compila anche il WiFiWebServer SENZA errori. :smiley:
Solo un paio di alert su qualcos che trova incongruente (confronti fra tipi, se non ricordo male). Ma con quel fix, fatto in Print.cpp e non in WString come ha fatto Paolo, l'errore scompare. Su Mac, su altri SO non so. :*

Certo, c'è da dire che una cosa è la modifica per il problema di PGMSPACE da fare in Print.cpp, modifica che è abbastanza semplice ed indolore, un'altra è quella proposta QUI per il problema dei warning su IPaddress ... mi sembra piuttosto più complessa da gestire e credo richieda una serie di modifiche a vari files ... :roll_eyes:

Guglielmo

leo72:
Su Mac, su altri SO non so. :*

non capisco perchè pensate che la stessa tool-chian, su differenti arch abbia comportamenti diversi.
Avreste regione se usaste risorse fornite dal SO come socket o driver vari, ma invece sono scollegati se non per la gestione delle risorse ram e cpu per l'esecuzione del compilatore

lesto:
non capisco perchè pensate che la stessa tool-chian, su differenti arch abbia comportamenti diversi.

SI, infatti, mi sembra ormai provato che, a parità di modifiche, il comportamento è esattamente lo stesso (... e sarebbe grave il contrario ... stiamo parlando di uguali sorgenti semplicemente compilati su diverse piattaforme) :wink:

Guglielmo

Lesto, hai ragione. La toolchain è la stessa versione per i 3 SO, mi scordo sempre di questa cosa. sorry sorry :sweat_smile:

lock:
...
e con la roba GNU non ti deve affatto stupire, non hai idea di quante volte mi sia successo, stesso identico codice comportamento del compilato diverso, e ai fatti in prima istanza cosa era cambiato ?

  • l'environment
  • un sacco di macro nel codice attivato dall'environment con possibili sviste/bachi e mal configure, inside
  • altri casini legati alle lib linkate (a volte banali casini di endian, tipico nei casi x86 vs ppc, a volte cose peggiori)
    ...

Mmmm ... effettivamente ...

Comunque, al momento, per quello che abbiamo verificato, fortunatamente il comportamento è uguale su tutte e tre le piattafome :wink:

Guglielmo

PaoloP:
Domani testo qualche codice più lungo e complesso e ti aggiorno.

Ok, ho provato a compilare diversi esempi allegati alle librerie dell'IDE 1.5.5 con la TC 3.4.3.
A parte qualche warnigs nascosto dalle impostazioni di default, la compilazione avviene sempre con successo.
Non ho fatto l'upload del codice su Arduino, non ho la WiFi shield.
Se riesco, recupero la Ethernet shield che ho nel cassetto la monto sulla UNO R3 e faccio qualche prova.

La cosa che mi rallegra è che, finalmente, la dimensione del codice decresce invece di aumentare. :wink:

PaoloP:
La cosa che mi rallegra è che, finalmente, la dimensione del codice decresce invece di aumentare. :wink:

Io uso quella Atmel da 1 anno buono e di questo "beneficio" me ne sono accorto anche con le toolchain precedenti (3.4.1 e 3.4.2).

Federico Fissore, sta sperimentando la creazione di una toolchain unica targata Arduino.
--> Redirecting to Google Groups
--> GitHub - arduino/toolchain-avr: The AVR toolchain used by the Arduino IDE
--> https://github.com/arduino/Arduino/tree/ide-1.5.x-avr-toolchain

La modifica riguarda quindi tutti e tre i sistemi operativi supportati, anche la NEWS la metto qui nel topic di Windows.

Leggendo nei sorgenti, pare che stia usando avr-gcc 4.3.x, o mi sbaglio?
Se così fosse, dov'è il vantaggio rispetto alla toochain attualmente utilizzata? Oppure non ho capito io che sta usando?

Adesso unifica... poi, spero, aggiornerà.
Anche perché cosi si può accorgere se qualcosa va storto per colpa della toolchain o del processo id unificazione, visto che quella toolchain al momento è ultratestata.

leggendo il messaggio originale di federico si capiscono due obiettivi

  1. unificare la toolchain rendendola propria, e quindi decidendo poi personalmente quali aggiornamenti inserire e quali no
  2. aggiornare se possibile

quindi quella di portare all'ultima versione gcc verra' in secondo momento, forse perche' attualmente la 4.3 e' l'unica testata su tutti e 3 i so ?

(p.s. Paolo abbiamo risposto contemporaneamente :))