Go Down

Topic: Ottimizziamo il codice del core di Arduino (Read 28438 times) previous topic - next topic

PaoloP

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

gpb01

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
Search is Your friend ... or I am Your enemy !

PaoloP

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?

gpb01

#18
Dec 08, 2013, 03:41 pm Last Edit: Dec 08, 2013, 03:44 pm by gpb01 Reason: 1
Attento, NON ho parlato di errori (... non mi da alcun errore) ... ho parlato di una marea di WARNING ;)

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

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 ;)
Search is Your friend ... or I am Your enemy !

PaoloP

#19
Dec 08, 2013, 03:55 pm Last Edit: Dec 08, 2013, 04:02 pm by PaoloP Reason: 1
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. :(


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.  :smiley-mr-green: :smiley-mr-green:


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).

Maurotec

Code: [Select]
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:
Code: [Select]

union {
        uint8_t vector[4];
        uint32_t u32;
    } unionIpAddress;


Code: [Select]

// 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.

leo72

@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  :smiley-sweat:

Ma questo lo sai meglio di me, sei un bravo programmatore  ;)

PaoloP

Si, ma finche qualcuno non mette mano al codice del core vado di WorkAround.  :smiley-mr-green:

nid69ita

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.
my name is IGOR, not AIGOR

lestofante

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.
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

leo72

@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.

PaoloP

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.

gpb01


Io credo che prima o poi la aggiorneranno.


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

... a te completare  :smiley-mr-green: XD :smiley-mr-green: XD :smiley-mr-green:

Guglielmo
Search is Your friend ... or I am Your enemy !

leo72

...muore cantando??  :smiley-sweat:

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

lestofante

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)

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

le lib esterne, quelle interne restano come sono, credo aggiungeranno solo il descrittore
Guida per principianti http://playground.arduino.cc/Italiano/newbie
Unoffical Telegram group https://t.me/genuino

Go Up