Ottimizziamo il codice del core di Arduino

Io ho risolto gli errori di compilazione dovuti al pgmspace ripescando i metodi deprecati dalla nuova toolchain senza necessità di mettere mano al core --> http://forum.arduino.cc/index.php?topic=96976.msg1498857#msg1498857

Mmm ... palliativo che funzionerà ancora per una o due ... tre release e poi, essendo comunque i metodi deprecati, prima o poi non verrà più supportato.

Se le cose si devono fare, si devono fare bene, proponendo a chi di dovere le correzioni da fare sul codice per renderlo conforme alle ultime releases del compilatore.

E comunque ... non ci sono solo warning (... che oltretutto abbiamo visto essere ininfluenti) sul PGMSPACE ... ci sono valanghe di altri warning compilando applicazioni per ATtiny =( Quanto questi warning (... con il core del tiny) siano gravi ... ancora non l'ho determinato ... ma sono veramente tanti :(

Guglielmo

A me su Windows con 1.5.5 + TC 3.4.3 + AVRdude 6.0.1 + core Tiny modificato (vedi post mio e di Leo: http://forum.arduino.cc/index.php?topic=197790.0) non da nessun errore di compilazione. Mi passi lo sketch che stai testando tu?

Attento, NON ho parlato di errori (… non mi da alcun errore) … ho parlato di una marea di WARNING :wink:

Ti allego la lista che esce … magari molti escono anche con la vecchia Toolchain … c’è solo da verificarli e capire quanto sono importanti … o quanto sono trascurabili :smiley:

Guglielmo

P.S. : Finché non è stabile, mi RIFIUTO di usare la 1.5.x … quindi tutte le prove sono con la STABILE 1.0.5.
Altrimenti, se devo fare qualche cosa che questa proprio non supporta … uso Atmel Studio 6.1 :wink:

Warning_Tiny.txt (29.8 KB)

La cosa è veramente curiosa perché ho messo anche il verbose sulla compilazione e, con la mia configurazione (1.55 ecc..), non esce neanche mezzo warnigs. :(

gpb01: P.S. : Finché non è stabile, mi RIFIUTO di usare la 1.5.x ... quindi tutte le prove sono con la STABILE 1.0.5.

Mi sembra di sentire Michele. :grin: :grin:

EDIT: E' stata aperta una richiesta per la soluzione del problema --> https://github.com/arduino/Arduino/pull/1695 E' in elenco per la versione 1.5.6 (la prossima).

IPAddress.h:51:55: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     operator uint32_t() { return *((uint32_t*)_address); };[code]

[/code] Questo warning si risolve con una union. La union sarà qualcosa di simile a:

union {
        uint8_t vector[4];
        uint32_t u32;
    } unionIpAddress;
// operator uint32_t() { return *((uint32_t*)_address); }; // this is old
operator uint32_t() { return unionIpAddress.u32; }; // this is new

Ovviamente anche le altre parti della classe IPAddress devono essere modificate.

Ciao.

@Paolo:
proprio perché “deprecati”, quei metodi non dovrebbero essere più usati. Altrimenti rischi di dover mettere le mani al codice due volte: ora, per usare i metodi deprecati ma ancora presenti; e poi, per togliere nuovamente i metodi deprecati quando il loro supporto verrà definitivamente tolto :sweat_smile:

Ma questo lo sai meglio di me, sei un bravo programmatore :wink:

Si, ma finche qualcuno non mette mano al codice del core vado di WorkAround. :grin:

Però non ho capito una cosa. Se qualcuno riesce a correggere i vari warning/errori modificando il core, poi queste modifiche verranno applicate al 1.0.5 e 1.5.5 dal Team di Arduino (e quindi l'adozione della toolchain 3.4.3) ? Oppure sono tutte operazioni che ci appuntiamo e poi chi vuole fare l'aggiornamento alla 3.4.3 si dovrà fare quelle modifiche? Non ho capito bene il "traguardo" rispetto al Team Arduino.

in teoria la cosa migliore è che siano retrocompatibili. In tal caso uno si aggiorna la tool-chain a gratis, e quando ci saranno abbastanza test positivi FORSE si passerà alla nuova tool-chain.

@Nid: non so proprio se il team ha intenzione di aggiornare la toolchain. Se avessero voglia di aggiornare la toolchain, dovrebbero modificare tutte le librerie correggendo il codice affinché sia compatibile con i nuovi tool. Ma ne varrebbe la pena, per una scheda che non ha una grossa diffusione? Alla fine, è l'unica afflitta dal bug.

Io credo che prima o poi la aggiorneranno. Stanno rivedendo tutte le librerie per la nuova versione dell'IDE (formato che non hanno ancora deciso in modo definitivo), quindi cambiare qualche file del core per la nuova toolchain non dovrebbe essere difficile.

PaoloP: Io credo che prima o poi la aggiorneranno.

Chi vive sperando .............

... a te completare :grin: XD :grin: XD :grin:

Guglielmo

…muore cantando?? :sweat_smile:

Cmq non credo neanch’io che lo aggiorneranno. Troppi problemi col codice ancora in circolazione potrebbero venir fuori. Perché rischiare?

per questo loro non spingono, anzi rallentano.. ma se noi portiamo tutte le lib già sistemate, e con una buoni test esaustivi (quindi non semplicemente compilare, ma anche TESTARE)

Stanno rivedendo tutte le librerie per la nuova versione dell'IDE

le lib esterne, quelle interne restano come sono, credo aggiungeranno solo il descrittore

Dalle mie parti si dice: Un uomo solo manco (nemmeno) buono per pisciare (fare la pipi) :grin:

Quindi non lasciatemi solo.
Se qualcuno è in grado di applicare la modifica alla classe IPAddress lo faccia, se non c’è nessuno, datemi almeno un pezzo di codice per testare, c’è nell’ide un esempio semplice che usa la classe IPAddress?

La modifica costa 5 minuti, nelle condizioni migliori.

Ciao.

Presumo venga usata negli sketch della ethernet shield.

Nel core la IPAddress.h viene richiamata da Client.h, Ethernet.h e da Udp.h Tra gli esempi UdpNtpClient.ino chiama EthernetUdp.h che a sua volta richiama Udp.h

MauroTec: Dalle mie parti si dice: Un uomo solo manco (nemmeno) buono per pisciare (fare la pipi) :grin:

:grin: :grin: :grin: ... moralmente siamo tutti con te !!! ;)

MauroTec: Quindi non lasciatemi solo. Se qualcuno è in grado di applicare la modifica alla classe IPAddress lo faccia, se non c'è nessuno, datemi almeno un pezzo di codice per testare, c'è nell'ide un esempio semplice che usa la classe IPAddress? La modifica costa 5 minuti, nelle condizioni migliori.

Qualunque esempio che è nell'IDE e che riguarda, ad esempio il WiFi, usa la classe IPaddress ... prova con il WebServer ...

Il sorgente IPaddress. cpp e IPaddress.h immagino li avrai già visti nella cartellina del core di Arduino ... ;)

Guglielmo

Esaminando bene il codice di IPAddress.h, vedo che" uint8_t _address[4]; // IPv4 address" è nella private della classe IPAddress ... questo immagino debba far ben sperare che quel _address[] non sia usato al di fuori ... e che quindi ci sia solo da modificare la classe ... giusto ???

Guglielmo

esatto. Facciamo una bella lista dei warning, così vediamo di smazzarceli a vicenda.