Ottimizziamo il codice del core di Arduino

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.

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

Confermo, quell'esempio in compilazione verbose mi compila e da warning sulla IPAddress

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

In teoria dovrebbe essere così ma per sbrigarsi e non chiamare un getThing si è preferito dichiarare alcune classi friend, tanto che nel codice originale c’è questo:

void EthernetClass::begin(uint8_t *mac, IPAddress local_ip, IPAddress dns_server, IPAddress gateway, IPAddress subnet)
{
  W5100.init();
  W5100.setMACAddress(mac);
  W5100.setIPAddress(local_ip._address);
  W5100.setGatewayIp(gateway._address);
  W5100.setSubnetMask(subnet._address);
  _dnsServerAddress = dns_server;
}

dove si vede accesso alla variabile _address fuori contensto se non ci fosse friend EthernetClass in IPAddress

Il codice dovrebbe essere così:

void EthernetClass::begin(uint8_t *mac, IPAddress local_ip, IPAddress dns_server, IPAddress gateway, IPAddress subnet)
{
  W5100.init();
  W5100.setMACAddress(mac);
  W5100.setIPAddress(local_ip.raw_address());
  W5100.setGatewayIp(gateway.raw_address());
  W5100.setSubnetMask(subnet.raw_address());
  _dnsServerAddress = dns_server;
}

dove si fa ricorso ad una funzione (metodo get) raw_address
Ok a me sembra funzionare mo allego lo zip, datemi un minuto.

PS: mi era scappata una z, se non l’avete vista non considerate per niente questo PS.

Nello zip c’è anche Ethernet.cpp
Rinominate gli originali in es IPAddress.h.orig
e poi estraete IPxx nel core ed Ethernet.cpp nella libreria.

Ciao.

IPAddress.cpp.zip (3.05 KB)

Vero ... bella porcata ...

... peccato perché, nel frattempo, avevo provato anche io a sistemare IPAddress.cpp e .h come avevi detto e ... il WiFiServer compilava senza warning (... per questa parte ... ci sono altre cose, ma a suo tempo).

Ovviamente invece ... l'esempio di WebServer della Ethernet ... va in errore ... =( =( =(

Guglielmo

Ovviamente invece … l’esempio di WebServer della Ethernet … va in errore … smiley-cry smiley-cry smiley-cry

Provato ora e funonzia.

In teoria si potrebbe evitare la union provando ad usare (reinterpret_cast<uint32_t>(_address)),
ma così mi sembra più leggibile.

Ciao.

Si Mauro, confermo che con la modifica non solo dei due moduli del core, ma anche del Ethernet.cpp nella libreria ... COMPILA senza più quei warning (... svariati altri legati ad altre cose, ma un passo alla volta si dovrebbero risolvere) :D

C'è un'anima pia che collauda il codice generato ... per essere sicuri che continua a funzionare ? :grin: :grin: :grin:

Guglielmo