Arduino Forum

International => Italiano => Generale => Topic started by: Maurotec on Dec 06, 2013, 10:12 am

Title: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 06, 2013, 10:12 am
In risposta a @gpb01 http://forum.arduino.cc/index.php?topic=186435.msg1496469#msg1496469 (http://forum.arduino.cc/index.php?topic=186435.msg1496469#msg1496469)
Si ci si è preoccupati per niente, anche se la 3.4.2 non si comportava bene come la 3.4.3. Guardiamo il lato positivo, abbiamo imparato qualcosa. Se vogliamo creare una nostra classe con metodi che prendono un puntatore in flash, nella lista dei parametri scriviamo:
Code: [Select]
myFnc(PGM_P ptrf);

Che però non ci permette di usare il polimorfismo di cui è capace il C++.
Risolviamo come nel core Arduino:

Code: [Select]

myFnc(const __FlashStringHelper *ifsh)
{
    PGM_P p =  (PGM_P)ifsh;
    ...
}


Tra l'altro __FlashStringHelper dovrebbe essere visibile negli sketch e quindi conviene usarla.
Se non è visibile allora si dovrà includere WString e se questo crea problemi dovrebbe anche bastare una semplice
class __FlashStringHelper; dopo gli include.

Io ci provo, arruolo lesto. Clona il repositor di arduino, sia in locale che in remoto, così noi possiamo vedere che lesto a un suo repo arduino su github, e poco per volta sistemi il core e tutto il quello che ti viene in mente.
Sai bene che di java io non ci capisco, mentre tu ci lavori tutti i giorni.

Ciao.
Title: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 06, 2013, 10:34 am
io posso falro, ma non ho capito bene cosa dovrei cambiare nel java. Fate attenzione che ho già arduino clonato, ma una versione vecchissimissima.

Quello che dovremmo fare di sicuro è una serie di test per verificare che tutto funzioni con la nuova toolchain
Title: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 06, 2013, 10:53 am
Intanto ripulire tutti i warning è cosa buona e giusta no.

Comparare un int e un unsigned int può portare facilmente a risultati inaspettati e allora perché non vedere di sistemare il core in modo che il compilatore non emetta warning.

Posso dirti con certezza che il mio codice viene compilato senza warning, sia lato PC che lato embedded, c'è anche il modo per evitare che gcc emetta unused warning, usando proprio l'attributo unused che al momento non ricodo come si fa.

Per le modifiche al IDE, nelle preferenze ci vorrebbero due line edit CXX_FLAGS e LFLAGS, così da poter modificare i flags di compilazione e linking. Potrebbero anche bastare alcune checkBox per limitare il numero di flags, una potrebbe essere quella che abilita i float nella printf. Poi se hai tempo e voglia, di modifiche profonde c'è n'è a iosa.

ciao.
Title: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 06, 2013, 11:05 am
Quote
Intanto ripulire tutti i warning è cosa buona e giusta no.

Approvo, ma parliamo di modificare le lib, qui8ndi lato c++. Allora, tu hai modificato le lib per eliminare i warning?

io ad aggiungere una di textbox per passare degli argomenti al compilatore/linker/uploader credo di metterci un attimo.
Title: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 06, 2013, 11:16 am
Mauro, Lesto ... molto interessanti le Vs. discussioni, ma questo thread è dedicato a "[MAC] Aggiornamento IDE 1.0x all'ultima versione Atmel Toolchain" ... quindi ...
... cortesemente aprite un altro thread dedicato a chi si vorrà dedicare alle modifiche del "core" (così questo resta dedicato al tuo titolo) e ... a convincere poi le alte sfere ad accettarle ed inserirle nelle distibuzioni.

@Leo : Poi ci pensi tu a spostare questi ultimi post di Mauro e Lesto nel giusto thread così il loro rimane un bel discorso pulito e logico ... e si riesce a seguirlo bene ?

Grazie ;)

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: leo72 on Dec 06, 2013, 11:28 am
Ho messo la discussione in questo nuovo thread, mi pare appropriato come titolo.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 06, 2013, 11:56 am

Quote
Intanto ripulire tutti i warning è cosa buona e giusta no.

Approvo, ma parliamo di modificare le lib, qui8ndi lato c++. Allora, tu hai modificato le lib per eliminare i warning?

io ad aggiungere una di textbox per passare degli argomenti al compilatore/linker/uploader credo di metterci un attimo.


Lo so, lo so, potrei ripeterlo mille volte, ma non lo ricordereste comunque. Io non uso il core Arduino, non uso L'ide Arduino, ho le mie routine C, il mio IDE QtCreator, il mio flasher AvrDudeQui, con questi ho la massima flessibilità e con il mio codice gcc non emette warning e non ho disabilitato i warning. Questo vuol dire che durante lo sviluppo i warning ci sono, se stabilizzi un API devi provvedere a ripulire i warning, cosa che ho fatto nelle mie routine, quindi è fattibile ripulire il core come lo è stato per il mio codice.

Quote
io ad aggiungere una di textbox per passare degli argomenti al compilatore/linker/uploader credo di metterci un attimo.


Ok non correre, parliamone, dammi il tempo di visionare il codice java dove vengono lanciati i processi di build.
Comunque ci sono delle flags vitali per arduino e quindi non dovrebbe essere possibile modificarle o se si da la possibilità bisogna mettere un button che resetti le flags a quelle originali considerate vitali per arduino.

@gpb01
Hai ragione, ho fatto una escursione fuori pista.
@Grande leo, sei sempre più reattivo.

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 06, 2013, 12:02 pm
Consiglierei di revisionare il codice delle versioni 1.5.x e non quello delle 1.0.x in quanto prima o poi verrà abbandonato.
E' anche vero però che il codice della 1.0.5 è stabile mentre la 1.5.x (oggi arrivato alla 1.5.5) è in continua evoluzione.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 06, 2013, 12:11 pm

Code: [Select]

myFnc(const __FlashStringHelper *ifsh)
{  PGM_P p =  (PGM_P)ifsh;
    ...
}

Tra l'altro __FlashStringHelper dovrebbe essere visibile negli sketch e quindi conviene usarla.
Se non è visibile allora si dovrà includere WString e se questo crea problemi dovrebbe anche bastare una semplice
class __FlashStringHelper; dopo gli include.


In questo thread:
http://forum.arduino.cc/index.php?topic=202262.msg1492087#msg1492087 (http://forum.arduino.cc/index.php?topic=202262.msg1492087#msg1492087)
un utente chiese come rendere la UTFT compatibile con F(); ho suggerito questo codice scopiazzando da print.cpp del core e mixando con la print della UTFT, non testato, ma scrissi correttamente?
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 06, 2013, 12:20 pm
Quote
dammi il tempo di visionare il codice java dove vengono lanciati i processi di build.


https://github.com/arduino/Arduino/blob/ide-1.5.x/app/src/processing/app/debug/Compiler.java
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 06, 2013, 12:53 pm
@lesto
Code: [Select]
List baseCommandLinker = new ArrayList(Arrays.asList(new String[] {
      avrBasePath + "avr-gcc",
      "-Os",
      "-Wl,--gc-sections"+optRelax,
      "-mmcu=" + boardPreferences.get("build.mcu"),
      "-o",
      buildPath + File.separator + primaryClassName + ".elf"
    }));

    for (File file : objectFiles) {
      baseCommandLinker.add(file.getAbsolutePath());
    }

    baseCommandLinker.add(runtimeLibraryName);
    baseCommandLinker.add("-L" + buildPath);
    baseCommandLinker.add("-lm");


Questo dovrebbe essere il codice per il linker, dove si vede che alla fine viene aggiunto -lm per la libreria math che deve essere sempre presente. L'ideale sarebbe che il campo editabile permetta di fare questo:
-(Os) + (O2). Il significato è: rimuovo il flag Os e aggiungo O2, ma è troppo complicato, rendiamolo semplice.
Per cui una edit line con un buddy button così: Optimize flags: -Os    [reset default flags]
dove [text] è un pulsante, cliccandoci il campo edit viene impostato a 0s.

Il codice dovrebbe diventare così:
Code: [Select]
List baseCommandLinker = new ArrayList(Arrays.asList(new String[] {
      avrBasePath + "avr-gcc",
      optimizeFlags,    // oppure Preference.get("compiler.optFlags)
      "-Wl,--gc-sections"+optRelax,
      "-mmcu=" + boardPreferences.get("build.mcu"),
      "-o",
      buildPath + File.separator + primaryClassName + ".elf"
    }));

    for (File file : objectFiles) {
      baseCommandLinker.add(file.getAbsolutePath());
    }

    baseCommandLinker.add(runtimeLibraryName);
    baseCommandLinker.add("-L" + buildPath);
    baseCommandLinker.add("-lm");


A scelta se usare una line edit o più check box exclusive dove solo una check box può essere marcata.
Le ottimizzazione di gcc sono:
-O0, -O1, -O2, -O3, -Os.

@nid69ita
strlen non funziona, ma c'è una funzione specifica, ma non ricordo pgm_strlen o simile.
Che poi pgm_strlen conta i caratteri fino ad arrivare a NULL e quindi non è molto rapida come la strlen.

Ciao.

Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 06, 2013, 01:29 pm
io invece farei una textbox con i valori di default (e piccolo pulsantino "reset"), così che uno possa modificare il comportamento del compilatore, però sarebbe da decidere cosa può essere utile modificare (e qui chiedo a te, io non gioco mai con i compilatori)

edit: per le ottimizzazioni una combobox (per intenderci i menù a tendina) è ottima
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 06, 2013, 03:10 pm
Quote
edit: per le ottimizzazioni una combobox (per intenderci i menù a tendina) è ottima


Ottimo tanto sono solo 4, quella di default sarà sempre -Os e il pulsante reset to default selezionerà questo valore.

La optimize e già un flag, se fai una text box si corre il rischio di poter modificare tutto a piacere con potenziali effetti disastrosi, teniamo sempre in conto il fatto che l'utente medio non è in grado di rimettere le flags correttamente, perché gli esiti della modifica delle flags può facilmente comportare una mancata compilazione. Il flag O0 è utile per il debug. Nota che l'optimize viene usato nel linker e nel compilatore vero e proprio, ancora devo isolare il codice e postarlo.

Un altro flag da inserire sarebbe "-save-temps" ma questo va in CXX_FLAGS cioè quando il sorgente viene trasformato in codice ".o", che poi è il processo di compilazione vero e proprio. -save-temps crea dei file ".i" già espansi dal preprocessore C/C++, così se abilitiamo questo flag possiamo vedere il lavoro svolto dal preprocessore ed è utile quando pasticciamo con le macro. Inoltre vengono creati dei file ".s" contenenti sorgente asm corrispondente ai singoli moduli "cpp". Tradotto in modo commestibile save-temps conserva i file temporaneamente creati durante il build.
Per questo basta una comune check box.

Alcune considerazioni:
Ogni progetto dovrebbe avere le proprie impostazioni, ma con arduino IDE non abbiamo file che descrivono il progetto e quindi cambiando impostazioni queste influiranno su qualunque progetto. Cosa utile allora sarebbe quella di documentare il progetto specificando quali flags si devono usare. In genere Os è la scelta primaria e le altre serviranno solo per debug e sperimentazione e test.

La stringa da inserire per fare in modo che printf accetti float è la seguente:
Code: [Select]
-Wl,-u,vfprintf -lprintf_flt
da inserire in baseCommandLinker.
Che verra inserita o meno in base ad una check box del tipo enable prinf float, con magari una tooltip del tipo: "La dimensione finale del firmware saranno maggiori ecc". Questo facilmente potrebbe portare l'utente a pensare di usare il core arduino con string & e in più abilitare print float e questo non è cosa senzata.

PS: con tooltip intendo quei messagi che compaiono se sosti con il mouse su un "widget" o components.

Ciao.



Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 07, 2013, 10:23 am
Code: [Select]
static private List getCommandCompilerS(String avrBasePath, List includePaths,
   String sourceName, String objectName, Map<String, String> boardPreferences)


Restituisce una lista di argomenti che saranno usati solo quando l'ide incontra un file sorgente ".S"
Qui non serve intervenire al momento, perché l'argomento -Ox non è previsto.

Code: [Select]

static private List getCommandCompilerC(String avrBasePath, List includePaths,
   String sourceName, String objectName, Map<String, String> boardPreferences)


Restituisce una lista di argomenti che saranno usati solo quando l'ide incontra un file sorgente ".c"
qui -Ox deve essere presente e -save-temps può essere presente o meno in base alla check box.

Code: [Select]
static private List getCommandCompilerCPP(String avrBasePath,
   List includePaths, String sourceName, String objectName,
   Map<String, String> boardPreferences)


Stessa cosa di sopra ma con i sorgenti ".cpp"

Quote
Consiglierei di revisionare il codice delle versioni 1.5.x e non quello delle 1.0.x in quanto prima o poi verrà abbandonato.
E' anche vero però che il codice della 1.0.5 è stabile mentre la 1.5.x (oggi arrivato alla 1.5.5) è in continua evoluzione.


Vero, peccato che il codice della 1.5 io non l'ho clonato e non so nemmeno cosa è cambiato, se non pesa molto ora clono il repo 1.5, ma quasi sicuramente in tempi umani non ne ricaverò informazioni necessarie per metterci mani, forse lesto può dire qualcosa di più che mi aiuti a studiare il codice più velocemente o quanto meno a farmi una idea. Il tree di progetto dell'ide io non l'ho comprendo, es perché Compiler.java si trova dentro la dir debug? Qual'è il codice dell'IDE e quello delle librerie di terze parti? ecc. Io ogni volta che navigo il tree mi perdo.

161Mb e ancora sta scaricando, troppo pesante...ma che si porta dietro java, il compilatore avr8, quello per arm ecc, ma che sono matto.

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 08, 2013, 01:27 am
la struttura non è molto user frindly, ma i java sono tutti assieme, i programmi esterni sono richiamati da terminale.

per la dimensione, si porta dietro tutta la storia, clona solo il ramo 1.5.x con una depth di 1 (solo ultima versione) e va più che bene.

il codice fondamentalmente CREDO sia lo stesso.

spero di avere tempo domani (aka non dormo fino a tardi, la sera mangio fuori), ah, potessi avere del tempo libero!!

edit: credo siano in debug perchè testavano la doppa copilazione multipiattafroma.

per il preferencies:
https://github.com/arduino/Arduino/blob/ide-1.5.x/app/src/processing/app/Preferences.java

mamma mia che casino, usano un sistema loro di preferencies quando basterebbe usare il sitema standar di java.. vabbè, in pratica devi far finire l'opne nella hashmap "table", dopo di che con un Preferencies.getBoolean(nome) o getTipoDato(nome) hai il dato dove vuoi (vedi linea 85 del Compile.java, usa Preferences.getBoolean("build.verbose"))
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 08, 2013, 02:46 pm
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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 08, 2013, 02:55 pm
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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 08, 2013, 03:13 pm
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 (http://forum.arduino.cc/index.php?topic=197790.0)) non da nessun errore di compilazione.
Mi passi lo sketch che stai testando tu?
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 08, 2013, 03:41 pm
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 ;)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 08, 2013, 03:55 pm
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).
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 08, 2013, 08:40 pm
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.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: leo72 on Dec 09, 2013, 08:16 am
@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  ;)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 09, 2013, 09:25 am
Si, ma finche qualcuno non mette mano al codice del core vado di WorkAround.  :smiley-mr-green:
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 09, 2013, 10:18 am
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.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 09, 2013, 10:25 am
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.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: leo72 on Dec 09, 2013, 11:04 am
@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.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 09, 2013, 11:20 am
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.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 11:26 am

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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: leo72 on Dec 09, 2013, 11:33 am
...muore cantando??  :smiley-sweat:

Cmq non credo neanch'io che lo aggiorneranno. Troppi problemi col codice ancora in circolazione potrebbero venir fuori. Perché rischiare?
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 09, 2013, 11:54 am
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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 09, 2013, 04:15 pm
Dalle mie parti si dice: Un uomo solo manco (nemmeno) buono per pisciare (fare la pipi) :smiley-mr-green:

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.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 09, 2013, 04:16 pm
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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 04:19 pm

Dalle mie parti si dice: Un uomo solo manco (nemmeno) buono per pisciare (fare la pipi) :smiley-mr-green:


:smiley-mr-green: :smiley-mr-green: :smiley-mr-green: ... moralmente siamo tutti con te !!! ;)



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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 04:24 pm
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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 09, 2013, 04:38 pm
esatto. Facciamo una bella lista dei warning, così vediamo di smazzarceli a vicenda.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 09, 2013, 04:40 pm

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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 09, 2013, 05:08 pm
Quote
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:

Code: [Select]

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

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.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 05:15 pm
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
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 09, 2013, 05:21 pm
Quote
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.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 05:28 pm
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 ?  :smiley-mr-green: :smiley-mr-green: :smiley-mr-green:

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 05:32 pm
Per chiarezza ... in allegato i moduli che, ad oggi, occorre sostituire (grazie Mauro ;) )...
... ora occorrerebbe fare qualche prova di "funzionamento" del codice generato e non solo di compilazione andata a buon fine ;)

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 09, 2013, 05:34 pm
Io ho compilato con la toolchain standard o meglio con L'ide1.05 ma io sul sistema ho la vecchia toolchain 4.5.1 atmel patched.

Vediamo come va e se c'è altro si sistema in un modo o nell'altro.

Ok, ora mi merito un caffe e purtroppo me lo devo pure fare io. :~
Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 05:38 pm
No, io ho compilato con l'ultima toolchain, la 3.4.3 ... quindi, almeno per la compilazione, la cosa è OK ! :)

Ripeto ... ora qualcuno che ha le board WiFi ed Ethernet installate ... dovrebbe provare se, ricompilando con la nuova toolchain e quelle modifiche ... l'eseguibile funziona ancora come dovrebbe ...  :smiley-mr-green: XD :smiley-mr-green: XD

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 09, 2013, 06:24 pm
Andiamo avanti con :
Quote

/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.0.5 TL 3.4.3.app/Contents/Resources/Java/libraries/WiFi/utility/wifi_drv.cpp: In static member function 'static uint8_t WiFiDrv::getEncTypeNetowrks(uint8_t)':
/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.0.5 TL 3.4.3.app/Contents/Resources/Java/libraries/WiFi/utility/wifi_drv.cpp:432:10: warning: converting to non-pointer type 'uint8_t {aka unsigned char}' from NULL [-Wconversion-null]
   return NULL;
          ^
/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.0.5 TL 3.4.3.app/Contents/Resources/Java/libraries/WiFi/utility/wifi_drv.cpp: In static member function 'static int32_t WiFiDrv::getRSSINetoworks(uint8_t)':
/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.0.5 TL 3.4.3.app/Contents/Resources/Java/libraries/WiFi/utility/wifi_drv.cpp:457:10: warning: converting to non-pointer type 'int32_t {aka long int}' from NULL [-Wconversion-null]
   return NULL;
          ^


NULL è un tipo particolare che si applica ai puntatori, come si vede dal codice viene ritornato NULL ma il tipo da ritornare non è un puntatore ma un intero. Per correggere questo ingenuo errore, ho bisogno di aiuto, perché tutto dipende dal codice esistente che usa wifi_drv.
Una possibile e semplice modifica potrebbe essere:
Code: [Select]

int32_t WiFiDrv::getRSSINetoworks(uint8_t networkItem)
{
if (networkItem >= WL_NETWORKS_LIST_MAXNUM)
return 0;// no NULL is NULL pointer return NULL;


return 0 oppure return -1 o altro codice.
Stessa cosa vale per uint8_t WiFiDrv::getEncTypeNetowrks(uint8_t networkItem)

Ciao.

Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 09, 2013, 10:15 pm

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


Sulla 1.5.5 + TC 3.4.3 nessun errore e nessun warnings durante la compilazione.
Non è che statecorreggendo cose già corrette nel passaggio tra la 1.0.5 e la 1.5.5.
Mi pare un lavoro inutile. Non è meglio lavorare sul codice più recente e migliorarlo invece di inseguire codice più datato?

Ripeto che l'unica modifica che ho fatto è quella del #define per il workaround delle definizione deprecate in pgmspace.



Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 09, 2013, 10:42 pm
Io ho scaricato la 1.5.x ma non riesco a trovare dentro il tree dei sorgenti la verisone precisa di ciò che ho scaricato.
Comunque, il core di ciò che ho scaricato non contiene queste modifiche.

Se a te non da questi warning abilitando da preference vuol dire che hanno disabilitato i warning (forse).

Riguardo a questo:

Quote
l'esempio di WebServer della Ethernet ... va in errore ...  smiley-cry smiley-cry smiley-cry


gpb01 aveva iniziato ad apportare la modifica a IPAddress in base al mio suggerimento iniziale ma non avevo
modificato Ethernet.cpp per cui riceveva errori.

Ciao.

Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 11:06 pm
Paolo ... ho idea che stai sbagliando da qualche parte la verifica ...
... IPAddress per AVR è identico sulla 1.5.5 e sulla 1.0.5 ... e se da problemi da una parte, deve dare problemi anche dall'altra !!!

Quindi ...
... ricontrolla che effettivamente stai usando la toolchain 3.4.3 e che non l'hai messa nel posto sbagliato (e quindi continua a usare la vecchia), controlla di aver messo verbose nella compilazione, ecc. ecc.

Essendo il compilatore lo stesso .. ti rendi conto che NON può in un caso segnalare un problema ed in un altro no ... visto che i due sorgenti sono gli stessi ! ;)

Guglielmo

Edit : Su Mac ( ma su Win è simile) il percorso per il core AVR è :
Code: [Select]
/Applications/Arduino 1.5.5.app/Contents/Resources/Java/hardware/arduino/avr/cores/arduino
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 09, 2013, 11:16 pm
Confermo che sono quasi identici tra 1.0.5 e.1.5.5
C'e' solo una differenza, nella 1.5.5 c'e' all'inizio questo include che manca nella 1.0.5
Code: [Select]
#include <stdint.h>
Uso il programma BeyondCompare per trovare le differenze di codice tra stessi file in due cartelle.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 11:27 pm
Ok Paolo, effettivamente ho sostituito la toolchain nella 1.5.5 ed ho provato a compilare il WiFiServer e ... chiedo scusa,  HAI RAGIONE !!!  XD XD XD

Ma, controllando la compilazione ... mi sembra di NON vedere più usato IPAddress.cpp  :smiley-eek: :smiley-eek: :smiley-eek:

Ecco perché non ti da errore !!!  Probabilmente hanno cambiato la libreria WiFi e la Ethernet per non includerlo più ...  :smiley-roll: :smiley-roll: :smiley-roll:

Occorre una verifica delle lib ...

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 11:33 pm
Mi correggo di nuovo LO USA, ma con la seguente stringa di compilazione :

Code: [Select]

/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.5.5 TL 3.4.3.app/Contents/Resources/Java/hardware/tools/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=155 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -I/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.5.5 TL 3.4.3.app/Contents/Resources/Java/hardware/arduino/avr/cores/arduino -I/Users/gpb01/Desktop/Prove Toolchain/Arduino 1.5.5 TL 3.4.3.app/Contents/Resources/Java/hardware/arduino/avr/variants/standard /Users/gpb01/Desktop/Prove Toolchain/Arduino 1.5.5 TL 3.4.3.app/Contents/Resources/Java/hardware/arduino/avr/cores/arduino/IPAddress.cpp -o /var/folders/td/xjbgg2n97rl9wsy40_rsj90h0000gn/T/build6874946970987828386.tmp/IPAddress.cpp.o


... Mauro .. ti dicono qualche cosa tutte quelle direttive ????  :smiley-eek: :smiley-eek: :smiley-eek:

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 09, 2013, 11:34 pm
@Guglielmo, nelle 2 cartelle del core 1.0.5 e 1.5.5 i file che mi risultano diversi sono:
Arduino.h     (aggiunta funzione void yield(void) come dichiarazione)
CDC.cpp
HardwareSerial.cpp e .h
IPAddress.h
USBAPI.h
USBCore.cpp
wiring.c             (nella delay() richiama la yield() !?!)
wiring_analog.c
WString.cpp e .h    (hanno aggiunto un pò di metodi per le stringhe in flash ram)
(Eliminato malloc.c e aggiunto hooks.c)
Tutto il resto è identico.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 11:41 pm
Si nid, ma ho fatto adesso la comparazione dei due IPAddress.h (utilizzando DeltaWalker, e non ad occhio) e, l'unica differenza, è appunto l'include :

Code: [Select]
#include <stdint.h>

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 09, 2013, 11:41 pm
IPAddress è usata, e si è "spostata" nelle librerie core (o forse è sempre stata lì?)
ora controllo...


BALORDI!!! -w è di default, ora nascondono tutti i warning!! MALOOO!!!! apro subito un bug

edit: nid prossima volta controlla bene, se metti su verbose vedesisubito il maledetto -w
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 09, 2013, 11:45 pm
Code: [Select]

/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=155 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -I/...

\avr\bin\avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L  -DARDUINO=105 -DUSB_VID=null -DUSB_PID=null  -I/...


@Guglielmo ho messo anche la compilazione da me della 1.0.5  e la tua, togliendo dagli include in poi
Han solo tolto "all" da -W
Le altre define che fanno? I vari -D qualcosa ?
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 11:47 pm

...
BALORDI!!! -w è di default, ora nascondono tutti i warning!! MALOOO!!!! apro subito un bug
...


Ma sono matti ??? E' vero, guarda la riga di copilazione che ho messo QUI (http://forum.arduino.cc/index.php?topic=203097.msg1500923#msg1500923) ... nonostante il verbose ... c'è proprio il -w ... che Dio li fulmini !!!

@Paolo : ecco perché non vedi warning  :smiley-mr-green: :smiley-mr-green: :smiley-mr-green:

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 09, 2013, 11:50 pm

BALORDI!!! -w è di default, ora nascondono tutti i warning!! MALOOO!!!! apro subito un bug

:smiley-eek-blue:

Si risolve facilmente editando nel file platform.txt la riga
Code: [Select]
compiler.c.flags=-c -g -Os -w -ffunction-sections -fdata-sections -MMD
parlo sempre della versione 1.5.5
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 09, 2013, 11:53 pm
Quote
BALORDI!!! -w è di default, ora nascondono tutti i warning!! MALOOO!!!! apro subito un bug

:smiley-mr-green:

@PaoloP
Si risolve facilmente editando nel file platform.txt la riga
Ottimo, la 1.55 allora permette di modificare i flags, prova ad aggiungere -save-temps, ti tornerà utile in molte occasioni.

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 09, 2013, 11:57 pm
C'è comunque un problema ... anche se metti verbose, non mette la -Wall ...  =( =( =(

Tocca metterla a mano ...

Guglielmo

P.S. : Ovviamente, mettendola, saltano fuori TUTTI i warning che Mauro ha risolto ;)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 09, 2013, 11:57 pm
Si Mauro.
E' altamente customizzabile e ci sono flag per tutti i gusti e tutte le situazioni
Code: [Select]
compiler.c.cmd=avr-gcc
compiler.c.flags=-c -g -Os -w -ffunction-sections -fdata-sections -MMD
compiler.c.elf.flags=-Os -Wl,--gc-sections
compiler.c.elf.cmd=avr-gcc
compiler.S.flags=-c -g -assembler-with-cpp
compiler.cpp.cmd=avr-g++
compiler.cpp.flags=-c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD
compiler.ar.cmd=avr-ar
compiler.ar.flags=rcs
compiler.objcopy.cmd=avr-objcopy
compiler.objcopy.eep.flags=-O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0
compiler.elf2hex.flags=-O ihex -R .eeprom
compiler.elf2hex.cmd=avr-objcopy
compiler.ldflags=
compiler.size.cmd=avr-size
# this can be overriden in boards.txt
build.extra_flags=


Guglielmo hai fatto la modifica anche per il compilatore cpp?
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 09, 2013, 11:59 pm
grazie paolo, provvedo subito.
In tatnochi ha account dia mano forte a far apparire il bug: https://github.com/arduino/Arduino/issues/1728

Quote
quanto tempo che perdete con la roba GNU!

con roba ARDUINO vorrai dire...
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Dec 10, 2013, 12:00 am

...
Guglielmo hai fatto la modifica anche per il compilatore cpp?


Si, ho tolto la -w ad entrambi e ... ora ho aggiunto la -Wall al entrambi ;)

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 10, 2013, 12:04 am
-Wall abilita tutte le warning.
Le -Dxx sono macro utente visibili in ogni unit compile, come appunto la versione dell'ide -DARDUINO=155

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 12:05 am
clonato il repo: https://github.com/lestofante/Arduino/blob/ide-1.5.x

già rimossa l'infame -w, se mi fate un riassunto delle modifiche le carico, graaaazie :)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 12:07 am
partiamo dalla toolchain originale, arduino 1.5.4 (la 1.0.x lasciamola perdere per favore)

con -Wall ecco i warning di un codice base:
Code: [Select]
void setup() {
  // put your setup code here, to run once:

}

void loop() {
  // put your main code here, to run repeatedly:
 
}



Code: [Select]

/home/mauro/arduino-1.5.4/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp: In function 'void __vector_18()':
/home/mauro/arduino-1.5.4/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp:89: warning: unused variable 'c'
/home/mauro/arduino-1.5.4/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp: In member function 'void HardwareSerial::begin(long unsigned int, byte)':
/home/mauro/arduino-1.5.4/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp:329: warning: unused variable 'current_config'


Code: [Select]
/home/mauro/arduino-1.5.4/hardware/arduino/avr/cores/arduino/Tone.cpp:119: warning: only initialized variables can be placed into program memory area

Code: [Select]
/home/mauro/arduino-1.5.4/hardware/arduino/avr/cores/arduino/Print.cpp: In member function 'size_t Print::print(const __FlashStringHelper*)':
/home/mauro/arduino-1.5.4/hardware/arduino/avr/cores/arduino/Print.cpp:44: warning: '__progmem__' attribute ignored
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 10, 2013, 12:16 am
Non c'è l'ho operativa la 1.5.4, anzi se mi sai dire quella che ho scaricato dal repo chiamata 1.5.x che versione è?
In allegato trovi tutti i file, devi metterli tu nel posto giusto.

Comunque le modifiche sono poche, quindi ti basta fare un diff e in 10 minuti risolvi anche con la 1.5.4.

Aggiornamento zip:
Incluso HardwareSerial.cpp

Note: Il codice proviene da arduino-1.0.5 quindi, non copiare direttamente nel ramo 1.5x ma usa un programma diff e applica le modifiche.

Perché 1.0.5? Io operativa ho solo la 1.0.5, non sono in grado di fare il build della 1.5x, se avete info precise postate pure.

ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 10, 2013, 12:22 am
Le versioni attualmente in download (http://arduino.cc/en/Main/Software (http://arduino.cc/en/Main/Software)) sono la 1.0.5 e la 1.5.5.

Questa --> https://github.com/arduino/Arduino/tree/ide-1.5.x
è la 1.5.5 con 1 o 2 modifiche effettuate dopo la pubblicazione.
In pratica è la versione 1.5.6 in sviluppo.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 12:26 am
per la prima parte di warning: rimosse le 3 variabili.

UDR0 e UDR mi hannolasciato un po perplesso, essndo registrinon vorrei che la loro lettura scatenasse qualcosa. Credo di no, anzi c'è il riscio che l'istruzione sia rimossa dal compilatore, vedendo che è inutile, come un ciclo for finito ma vuoto,  no?

per la parte 2 di tone, non so, c'è la progmem di mezzo e un array di un valore.. e tra l'altro mi sembra errata lal ibreria pèerchè fa
Code: [Select]
tone_pin_to_timer_PGM + i
invece io mi aspetterei fosse un
Code: [Select]
tone_pin_to_timer_PGM[i] ovvero che legge il prossimo

ma poi in realtà l'uso di più timer cozza con le definizioni multiple ehh. bho è una schifezza di codice, scritto metà per supportare più timer e metà per funzionare con un timer solo. Meriterebbe una riscrittura.

MauroTec opinioni sul da farsi?

per la 3° parte se ho capito bene avete già risolto, giusto? mi posti il codice corretto? graaazie :)

per chi volesse clonare, giusto per testare e senza portarsi appresso tutto il mondo, ecco il comando git:

Code: [Select]
git clone --depth 1 -b ide-1.5.x https://github.com/lestofante/Arduino.git

git: comando e ci siamo
clone: crea un clone del repo
--depth 1: non impora la storia, ma soloilmomento attuale
-b ide-1.5.x: clona solo il branch ide-1.5.x
https://github.com/lestofante/Arduino.git: da dove pescare il codice

ps. nei preferencies.txt ho tolto il -w, ma NON ho messo il -Wall. Anche quì, sono aperto a suggerimenti
pps. e ai SAM nessuno ci pensa? mi aspeto avvenga di conseguenza,ma essendo parti del codice diverse...bhe vedremo poi

edit: la mia versione si basa sull'attuale 1.5.x, questo per evitareun pò di casini eventuali quando faremo la pull-request :)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 10, 2013, 12:39 am
Per Tone.cpp non ho risolto, io credevo si trattasse di un bug del compilatore risolto con la 4.7.2, almeno così ho letto in rete.

Per UDR ecc, non ti seguo non vedo warning, comunque i warning unused lasciamoli stare al momento.
Code: [Select]

#if defined(UDR0)
   if (bit_is_clear(UCSR0A, UPE0)) {
     unsigned char c = UDR0;
     store_char(c, &rx_buffer);
   } [color=brown]else {
     unsigned char c = UDR0;[/color]
   };

Che senso ha questo codice in HardwareSerial?
Il ; dopo chiusura blocco. Il codice in brown color si deve eliminare, in quanto non ha senso creare c se poi nella funzione ISR non viene usata. Ho modificato anche altre cose in HardwareSerial che non ho incluso nello zipfile, l'ho dimenticato.

Rivalutazione
Il codice in brown color deve essere mantenuto, in quanto ha la funzione di scartare il carattere, nel caso in cui PE0 in UCSRnA is set, però io non vedo abilitato (UPMn1 = 1) in UCSRnC. Comunque mi sembra di aver risolto l'unused di c così:
Code: [Select]

#if defined(UDR0)
    unsigned char c;   
    if (bit_is_clear(UCSR0A, UPE0)) {
      c = UDR0;
      store_char(c, &rx_buffer);
    } else {
      c = UDR0;
    }
  #elif defined(UDR)
    unsigned char c;
    if (bit_is_clear(UCSRA, PE)) {
      c = UDR;
      store_char(c, &rx_buffer);
    } else {
      c = UDR;
    }
  #else
    #error UDR not defined


Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: leo72 on Dec 10, 2013, 06:38 am

wiring.c             (nella delay() richiama la yield() !?!)

La Due ha un proto-scheduler di tipo cooperativo basato sul SysTick, un timer interno, e sull'uso della funzione yeld per passare il controllo da un task all'altro. Non so però il motivo per cui la trovi nel core Avr, dovrebbe essere solo nel core Arm.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: leo72 on Dec 10, 2013, 06:43 am
Ah, ho capito. Nel wiring.c del core Avr la funzione yield è una macro che serve ad attendere esattamente 1 microsecondo eseguendo una particolare istruzione assembly, ed è usata nella funzione delay per contare il tempo non usando più millis. In teoria quindi delay dovrebbe funzionare anche dentro una ISR.

Invece in wiring.c del core Sam la funzione di yield è proprio quella di eseguire altri task mentre il core è in un delay.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 10, 2013, 08:50 am

Le -Dxx sono macro utente visibili in ogni unit compile, come appunto la versione dell'ide -DARDUINO=155


Si @Mauro è chiaro. Trovo strano però che nelle 2 versioni IDE vengano poi dichiarate altre -D diverse tra i due. A che serviranno?  Influenzano qualche lib? Magari causano compilazioni diverse? Non credo sia importante però un ma, mi sovviene.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 10, 2013, 09:24 am
@Lesto
Per i SAM si usa la toolchian ARM che mi pare sia l'ultima.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 10, 2013, 09:46 am
Quote
Si @Mauro è chiaro. Trovo strano però che nelle 2 versioni IDE vengano poi dichiarate altre -D diverse tra i due. A che serviranno?  Influenzano qualche lib? Magari causano compilazioni diverse? Non credo sia importante però un ma, mi sovviene.


Non ho avuto il tempo per indagare, sarebbe todo, se puoi cerca quelle macro in tutto il codice con find e vedi cosa fanno.

Quote
Per Tone.cpp non ho risolto, io credevo si trattasse di un bug del compilatore risolto con la 4.7.2, almeno così ho letto in rete.

Mi autoquoto. Il problema è stato risolto come pensavo a partire dalla 4.7.2 infatti nel file degli errori allegato da gpb01 non c'è quel warning.

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 10:45 am

Per Tone.cpp non ho risolto, io credevo si trattasse di un bug del compilatore risolto con la 4.7.2, almeno così ho letto in rete.

io ho letto il codice della tone e mi pare una porcheria per i motivi cui sopra. Che poi un array dia warning starni sul progmem che cmq da warning anche sulle variabili ci sta.


Rivalutazione
Il codice in brown color deve essere mantenuto, in quanto ha la funzione di scartare il carattere, nel caso in cui PE0 in UCSRnA is set, però io non vedo abilitato (UPMn1 = 1) in UCSRnC.


immaginavo, in oltre è obbligatorio leggere PRIMA UCSRA e poi UDR, però vedo che la cosa un pò varia, in oltre non è tenuto conte l'errore FE (Frame Error, bit 4) e DOR (Data OverRun, bit 3)

ora mi studio un pò il datasheet, vediamo che salta fuori
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 11:00 am
da datasheet:

Code: [Select]

unsigned int USART_Receive( void )
{
unsigned char status, resh, resl;
/* Wait for data to be received */
while ( !(UCSRnA & (1<<RXCn)) )
;
/* Get status and 9th bit, then data */
/* from buffer */
status = UCSRnA;
resh = UCSRnB;
resl = UDRn;
/* If error, return -1 */
if ( status & (1<<FEn)|(1<<DORn)|(1<<UPEn) )
return -1;
/* Filter the 9th bit, then return */
resh = (resh >> 1) & 0x01;
return ((resh << 8) | resl);
}
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 10, 2013, 11:16 am

Code: [Select]

/avr/bin/avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L -DARDUINO=155 -DARDUINO_AVR_UNO -DARDUINO_ARCH_AVR -I/...
-------
\avr\bin\avr-g++ -c -g -Os -Wall -fno-exceptions -ffunction-sections -fdata-sections -MMD -mmcu=atmega328p -DF_CPU=16000000L  -DARDUINO=105 -DUSB_VID=null -DUSB_PID=null  -I/...

Le altre define che fanno? I vari -D qualcosa ?

Dalla versione 1.5.3 sono cambiate le define passate al compilatore per definire l'hardware per cui si compila.
https://github.com/arduino/Arduino/issues/308
Dalla 1.5.3 si usa -DARDUINO_{board}     e poi     -DARDUINO_ARCH_AVR oppure ARDUINO_ARCH_SAM
Mentre nella 1.0.x venivano usate USB_VID=xxx -DUSB_PID=xxx
Secondo me non è poi così banale, ma forse poco importante. Nel core e nelle librerie distribuite dal Team si saranno adeguati.
Chissà nelle librerie di terze parti se il tutto funziona ancora (se si basano su quelle define USB qualcosa).

Esempio nella libreria fornita dal Team TFT, c'era:
Code: [Select]
#if (USB_VID == 0x2341) && (USB_PID == 0x803C) // are we building for Esplora?
ora c'e':
Code: [Select]
#if ARDUINO_AVR_ESPLORA // are we building for Esplora?
Stranamente in 1.5.5 è poco presente questo ARDUINO_xxx e di fisso han messo USB_VID = 0x2341 in Arduino.h se SAM (usata questa macro in USBcore.cpp)
Code: [Select]
#define USB_VID            0x2341 // arduino LLC vid
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 11:52 am
esatto, così facendo invece che compilare per atmega328 o atmega328p, visto che la atmel (e/o gcc?) ha fatto il favore che i nomi dei registri sono gli stessi per gli stessi hardware, non serve più verificare il TIPO di MCU ma se SUPPORTA quell'hardware, aka se possiete quei registri.

In questo modo, se la atmel rialscia una nuova MCU i cui HW sono gli stessi di altre MCU già scritte, il suo supporto è automagico!!
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: astrobeed on Dec 10, 2013, 12:02 pm

esatto, così facendo invece che compilare per atmega328 o atmega328p, visto che la atmel (e/o gcc?) ha fatto il favore che i nomi dei registri sono gli stessi per gli stessi hardware, non serve più verificare il TIPO di MCU


Non diciamo cavolate :)
Il core del 328 è diverso da quello del 328p, il compilatore DEVE sapere per quale compila, solo per il 1284 e il 1284p è possibile fare una cosa unificata perché i due core sono identici.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 12:16 pm
il compilatore deve saperlo, ma non gli #IFDEF che scelgono se e quali registri usare.

Quote
se la atmel rialscia una nuova MCU i cui HW sono gli stessi di altre MCU già scritte

rettifico aggiungendo: e che sia supportata da GCC

edit: esempio: io posso scrivere HardwareSerial per atmega238p, ma siamo d'accordo che il codice è uguale per atmgea8 e varie altre. Quindi o faccio uina bella #ifdef con millemila cpu, oppure una bella #ifdef nomeRegistroUsart
poi ri-edito quando trovo l'issue che spiega bene
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 10, 2013, 12:27 pm
Quote
Secondo me non è poi così banale, ma forse poco importante. Nel core e nelle librerie distribuite dal Team si saranno adeguati.


Non è né banale né poco importante e solo che in questa fase non serve sapere cosa sono quelle #define.
Non vorrei ci si lanciassi in modifiche pesanti al core per almeno un motivo:
Il core bene o male fa il proprio lavoro, sistemiamo quello che si può senza stravolgere il funzionamento, ottenuta una compilazione senza warning o con solo unused è l'obiettivo e mi sembra che ci siamo arrivati o quasi, quasi perché io non ho la toolchain 3.4.3, quindi chi l'ha è pregato di apportare le modifiche e postare il risultato della compilazione con i warning abilitati.

Stasera vedo di postare la HardwareSerial modificata per compilare senza warning.

Riguardo alla gestione della HardwareSerial c'è da fare delle considerazioni e in base a queste prendere delle decisioni. Al momento non ho ben chiaro come si debbano gestire gli errori quando di mezzo c'è il buffer rx, scartare il carattere non è risolutivo ma fa comprendere che qualcosa non funziona. Se spedisco alimortacci e ricevo alimortaci il significato si perde no. :smiley-mr-green:

Comunque gli interventi sul core o lib che aggiungono caratteristiche o migliorano il funzionamento lo si deve fare in seconda istanza, al momento ne possiamo solo parlare, perché mettere mano pesantemente al codice lo può portare facilmente al non funzionamento per cui ogni intervento deve essere testato con un codice di test.

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: nid69ita on Dec 10, 2013, 01:35 pm

Non è né banale né poco importante e solo che in questa fase non serve sapere cosa sono quelle #define.
Non vorrei ci si lanciassi in modifiche pesanti al core per almeno un motivo:

Perfettamente d'accordo. La preoccupazione era solo che quelle define facessero compilare in maniera diversa parte del core e perciò tra i due IDE ci potessero essere parti diverse da modificare.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Dec 10, 2013, 02:08 pm
Le definizioni delle variabili per la compilazione nella 1.5.x sono in platform.txt e board.txt, che a tutti gli effetti fanno parte del core. Ci sono definiti anche PID e VID.
Questi due file non possono essere ignorati per capire il funzionamento dell'IDE.
(ci ho sbattuto un po' la testa quando ho integrato il core tiny per la 1.5.x)

Esempio per la UNO
Code: (boartd.txt) [Select]

uno.name=Arduino Uno

uno.vid.0=0x2341
uno.pid.0=0x0043
uno.vid.1=0x2341
uno.pid.1=0x0001

uno.upload.tool=avrdude
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.maximum_data_size=2048
uno.upload.speed=115200

uno.bootloader.tool=avrdude
uno.bootloader.low_fuses=0xFF
uno.bootloader.high_fuses=0xDE
uno.bootloader.extended_fuses=0x05
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.bootloader.file=optiboot/optiboot_atmega328.hex

uno.build.mcu=atmega328p
uno.build.f_cpu=16000000L
uno.build.board=AVR_UNO
uno.build.core=arduino
uno.build.variant=standard


Ad esempio se uno volesse potrebbe aggiungere le righe per l'AVR Dragon in programmers.txt e usarlo con l'IDE.

EDIT:
In platform.txt ci sono anche i flag per l'USB che rimanda alle variabili definite in board.txt
Code: [Select]
build.usb_flags=-DUSB_VID={build.vid} -DUSB_PID={build.pid} '-DUSB_MANUFACTURER={build.usb_manufacturer}' '-DUSB_PRODUCT={build.usb_product}'
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 02:38 pm
è stato fatto apposta per permettere una facile integrazione di piattaforme esterne, anche custom; questo, unito al fatto di poter compilare e uppare da riga di comando, trasforma arduino da semplice ide a toolchain "appendibile" a valle di un ide custom con board custom; ciò evita il proliferare di arduino IDE cloni, e la conseguente entropia
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 10, 2013, 06:02 pm
HardwareSerial è stata scritta molto tempo fà, prima di toccarla bisogna decidere come intervenire.

HardwareSerial dovrebbe essere visto come il driver per accedere all'hardware, la gestione del parity error ecc, dovrebbe essere di competenza del protocollo. Se il protocollo prevede la gestione degli errori allora in caso di errori deciderà molto probabilmente di richiedere nuovamente il dato o il frame a seconda della interfaccia.

Qui occorre qualcuno che si sprema le meningi per organizzare una HardwareSerial che permetta di abilitare o meno la gestione degli errori e chiami delle funzioni utente a seconda dell'errore. A complicare un poco le cose c'è il fatto che HardwareSerial viene "pre-instanziata" e quindi bisogna usare metodi set e get per abilitare la gestione degli errori. Se c'è qualcuno che sa come nel codice reale si deve comportare un protocollo in cui il dispositivo dati rileva un errore, parli ora o taccia per sempre. :P

Quote
Perfettamente d'accordo. La preoccupazione era solo che quelle define facessero compilare in maniera diversa parte del core e perciò tra i due IDE ci potessero essere parti diverse da modificare.


Ok, non avevo capito che l'obbiettivo era questo. Comunque quelle -Dxxx si usano spesso e addirittura partono dal file di progetto C++, come es APPLICATION_NAME "chichi", APPLICATION_VENDOR = Mtec, APPLICATION_VERSION ecc e bene che siano visibili in tutte le unit, poi queste possono anche non usarle.
Io ne faccio uso per abilitare o neno i messaggi di debug dal file di progetto, come anche avrlibc li usa per abilitare o meno i messaggi di "assert".

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 06:26 pm
io userai una funzione handler che passa l'utente, stile attachInterrupt per intenderci. Non modifica nulla "nel passato", ma aggiunge potenza nel futuro :)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 10, 2013, 06:43 pm
Qualcosa del tipo:
Code: [Select]

void myErrorHandler(int err);

Serial.setErrorHandler(myErrorHandler)


Dici che può bastare, oppure ci facciamo anche passare il puntatore a Serial?
Oppure (const HardwareSerial &serial, int err)

PS: ho aggiornato arduinochanged.zip

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Dec 10, 2013, 08:33 pm
ci stavo pensando anche io, si crea una dipendenza ciclica, un pò brutta come cosa, e poi serial è statica...

diciamo che per le classi NON statiche avrei fatto col puntatore, ma in questi casi no. Ovvio che avrai 3 hadler nel caso di 3 seriali.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Dec 10, 2013, 10:10 pm
Penso che se si vogliono gestire gli errori c'è necessità di un comportamento flessibile.
Una funzione predefinita potrebbe essere fornita internamente e se si vuole maggiore flessibilità, si può usare Serial.setErrorHandler(). La funzione utente verrebbe fornita solo per l'instanza di HardwareSerial che si ha intenzione di usare. Cioè la HardwareSerial deve essere pensata in modo che lavori di default nel modo attuale o simile, poi se l'utente vuole maggiore flessibilità si fa ricorso al metodo.

Lasciamo decantare la cosa un poco, vediamo se ci sono altri interventi, poi isolo la HardwareSerial creo codice di test e vediamo cosa ne esce fuori.

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 08, 2014, 04:15 am
facciamo il punto, che io sto preparando il repo remoto, la toolchain è pronta.

Devoassolutamente togliere il flag anti-warning, poi?

dobbiamo risolvere il PROGMEM

Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Feb 08, 2014, 11:44 am
Il flag anti-warning nella 1.5.x si elimina modificando il file platform.txt
Mi pare di averlo già scritto qualche post indietro.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 08, 2014, 01:44 pm
sì, trovato il flag c e c++, grazie
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Feb 08, 2014, 01:53 pm

dobbiamo risolvere il PROGMEM


Dove ???   In Print.cpp era gié stato risolto ... verso l'inizio di questo thread ... comunque :

Code: [Select]

size_t Print::print(const __FlashStringHelper *ifsh)
{
 PGM_P p =  (PGM_P)ifsh;
 size_t n = 0;
 while (1) {
   unsigned char c = pgm_read_byte(p++);
   if (c == 0) break;
   n += write(c);
 }
 return n;
}


Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 08, 2014, 02:07 pm
edit: sto cercando di partire da capo, per fare il punto dove siamo arrivati. Il primo errore in assoluto è:
Code: [Select]
WString.cpp:189:26: error: ISO C++ forbids declaration of 'type name' with no type [-fpermissive]
  strcpy_P(buffer, (const prog_char *)pstr);


1. in WString.cpp sostituire le 2 occerrenze di prog_char con char (a verede il core attuale arduino x la nuova toolchain, hanno anche cambiato strcpy_P in strcpy)

2. In Print.cpp
Code: [Select]
const char PROGMEM *p = (const char PROGMEM *)ifsh
diventa
Code: [Select]
const char *p PROGMEM = (const char *)ifsh;

et voilà, compilato senza warning e/o errori!


edit: per il punto 2 la branch di arduino non sembra avere la modifica. Quindi ora sto clonando il loro branch per vedere se sono riusciti a risolvere magari mettendo la define in una ifdef
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 08, 2014, 03:11 pm
ok, loro hanno fixato in aplro modo, probabilmente alla diefine di PROGMEM o qualcosa del genere.

I warning ci sono, non avevo attivato -Wall, però sono molto differenti:

versione branch arduino;
Code: [Select]
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/HardwareSerial.cpp: In function 'void store_char(unsigned char, ring_buffer*)':
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/HardwareSerial.cpp:98: warning: comparison between signed and unsigned integer expressions
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/HardwareSerial.cpp: In function 'void __vector_18()':
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/HardwareSerial.cpp:127: warning: unused variable 'c'
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/HardwareSerial.cpp: In member function 'void HardwareSerial::begin(long unsigned int, byte)':
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/HardwareSerial.cpp:368: warning: unused variable 'current_config'
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/HardwareSerial.cpp: In member function 'virtual size_t HardwareSerial::write(uint8_t)':
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/HardwareSerial.cpp:467: warning: comparison between signed and unsigned integer expressions

/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/Tone.cpp:119: warning: only initialized variables can be placed into program memory area

/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/Print.cpp: In member function 'size_t Print::print(const __FlashStringHelper*)':
/home/mauro/git/ArduinoMod/Arduino/build/linux/work/hardware/arduino/cores/arduino/Print.cpp:44: warning: '__progmem__' attribute ignored



1.5.5 cvon toolchain e mnodifiche di cuisopra:

Code: [Select]

In file included from /home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/IPAddress.cpp:3:0:
/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/IPAddress.h: In member function 'IPAddress::operator uint32_t()':
/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/IPAddress.h:52:55: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     operator uint32_t() { return *((uint32_t*)_address); };
                                                       ^
/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/IPAddress.h: In member function 'bool IPAddress::operator==(const IPAddress&)':
/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/IPAddress.h:53: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)); };
                                                                           ^
/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/IPAddress.h:53:108: 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)); };

/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp: In function 'void __vector_18()':
/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp:89:21: warning: unused variable 'c' [-Wunused-variable]
       unsigned char c = UDR0;
                     ^
/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp: In member function 'void HardwareSerial::begin(long unsigned int, byte)':
/home/mauro/arduino-1.5.5-MOD toolchain/hardware/arduino/avr/cores/arduino/HardwareSerial.cpp:329:11: warning: unused variable 'current_config' [-Wunused-variable]
   uint8_t current_config;

Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Feb 08, 2014, 03:15 pm
Se vai un po' indietro Mauro aveva analizzato il problema di HardwareSerial ... era un po' un casino se ricordo ... ma alla fine aveva proposto una soluzione ...  :smiley-roll:

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 08, 2014, 03:18 pm
non è questo ilpunto. NOn capisco perchè la versione 1.5.5 liscia (solo la toolchian modoficata) NON da quell'errore!!
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: gpb01 on Feb 08, 2014, 04:06 pm
Scusa ... quale errore ? A che riga ?

Perché su HardwareSerial da dei warning più o meno simili, mentre vedo altre cose relative però alla Tone.cpp ed alla Print.cpp ...  :smiley-roll:

Guglielmo
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Feb 08, 2014, 09:51 pm
Purtroppo sono poco attivo di recente, me ne capita una al giorno, pazienza.

Dunque io ancora non ho funzionante la 1.5.x, ora provo a compilare, se riuscissi poi dovrei anche fare in modo che L'IDE usi la toolchain installata nel sistema. Uso avr-gcc-4.7.2 ufficiale di fedora, che di base è come la 4.3.4 di atmel.
C'è da notare che nella doc c'è la builtin di avr-gcc __flashN dove N è un numero, dalla doc mi sembra di capire che usando __flash non è più necessario il supporto avr-libc, cioè non serve più pgm_read_byte() ecc, tuttavia ci sono delle limitazioni che ancora non ho approfondito.

La nuova caratteristica "potrebbe" anche portare grande vantaggio in termini di velocità e spazio occupato, ma questo è ancora da verificare in dettaglio.

@lesto
Code: [Select]
const char *p PROGMEM = (const char *)ifsh;
Dovrebbe invece diventare
Code: [Select]
PGM_P p =  (PGM_P)ifsh;

In avr-libc PGM_P è così definita:
Code: [Select]

#ifndef PGM_P
#define PGM_P const char *
#endif


PROGMEM si espande in un attributo __attribute__((progmem)) che ha senso usare quando vogliamo che un dato venga posizionato in progrmem. Dichiarare un puntatore const char *p PROGMEM non ha senso, perché manca il dato da posizionare in progmem. Ha senso invece const PROGMEM myString[] ="mystring", nota che il puntatore è in ram e contiene un indirizzo di memoria flash. Quindi PROGMEM è riferito al dato "myString" è non al tipo di variabile.

Stessa cosa per const void * definito in avr-libc così:
Code: [Select]
#ifndef PGM_VOID_P
#define PGM_VOID_P const void *
#endif


Ripeto, usa PROGMEM quando vuoi che un dato venga salvato in area flash, questo significa che tutte le dichiarazioni in cui compare PROGMEM deve comparire anche il dato da salvare in flash, se non c'è il dato non usare PROGMEM, ma solo PGM_P o PGM_VOID.

Qui sotto, p è un puntatore che vive in RAM e il contenuto di questo indirizzo RAM punta ad un indirizzo in flash, visto che non c'è il dato da spostare in flash PROGMEM è superfluo. Se p lo salvassimo in flash dovremmo avere anche un puntatore in ram che contiene l'indirizzo flasg in cui si trova p.
Code: [Select]
const char *p PROGMEM = (const char *)ifsh;

Ho capito che questo non è ancora chiaro e ho ribadito il concetto.

Ora provo a compilare la 1.5.x

ciao.





Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 08, 2014, 10:16 pm
Quote
Scusa ... quale errore ? A che riga ?

scusa warinig, non errori.

@MauroTec me lo leggo con più calma
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Feb 08, 2014, 11:59 pm
Ok, compilato e avviato con successo L'ide 1.5.x.
In pratica è bastato:
cd build
ant
ant run

....e dopo aver macinato qualche minuto è comparsa l'interfaccia dell'IDE arduino, con su caricato uno sketch
di default. Compilato con 4.7.2 (di fedora) in effetti dava proprio l'errore, aggirabile con la macro di compatibilità.
Quindi dalla 4.7.2 prog_char e compagni sono già deprecati.

Ora vedo nei post precedenti come si abilita -wall.

Ciao.

Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 09, 2014, 01:05 am
cerca il file platform.txt, lì trovi le flag che arduino da in pasto al C e al C++

Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Feb 09, 2014, 01:45 am
Si grazie lesto, fatto.

Ho provveduto a sistemare il core, solo che ora non so come sia meglio procedere, facciamo finta che il
tuo clone sia la release e se mi dici come clonare il repo remoto applico le patch tu e gli altri le valutano e se tutto ok le applichi nel ramo release.

Solo che mi devi guidare su git remote, o meglio sarebbe il caso di postare i comandi di git da eseguire per casi di uso comune, in questo modo ne rimane traccia anche per tutti gli altri. Come clonare il tuo repo lo visto in un post precedente, ma poi che si procede.

Avevo in mente di stravolgere il core, ora che sono operativo con la 1.5.5 e per questo ci vorrebbe un altro clone remoto chiamato newfeatures o simile, altri tipo experiment ecc.

Che ne pensi?

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 09, 2014, 02:52 am
dunque, un repo al suo interno ha varie "branch", ovvero ad un certo punto tu crei una branch con un dato nome (la principale è master) ed esso sarà come avere un repo a parte. Con la differenzache è all'interno del repo stesso, quindi puoi facilmente passare da uno all'altro, e ache mergiarli assieme. Si soliuto si tiene il master allineato che funziona sempre, e i vari branch di test.


1. crea la cartella ed entraci
2. git clone https://github.com/lestofante/Arduino.git
3. git checkout -b modItaVostroNick  (se si lamenta che esiste togliete il -b, il nick evitate caratteri strani e niente spazi)
4. modificare i vari file
5. git commit -a -m 'piccola descizione'


git checkout serve per spostarsi nei branch, e con -b si crea un nuovo branch, con -D lo si elimina.

ricordarsi di fare sempre una git pull prima di branchare o in generale prima di lavorare, così si resta il più allineati possibile.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Feb 09, 2014, 12:27 pm
Dunque, non sono proprio a digiuno ma ho bisogno di conferme.
Mi serve creare un account su github? Si giusto?
Clono in locale il repo remoto così:
Code: [Select]
git clone --depth 1 -b ide-1.5.x https://github.com/lestofante/Arduino.git
Oppure senza --depth 1? io l'ho clonato con depth 1 va bene comunque?

Cosa ho clonato ?
Ci sono le tue modifiche?
C'è solo un branch.
Come faccio a vedere i log, con git log me ne compare solo una.

Sul tablet ho un libro su git vediamo se posso leggerlo nel pomeriggio, ma ora volevo comunque fare qualcosa.

Altra domanda:
Le modifiche che coinvolgono IPAddress comportano modifiche anche a Ethernet e wifi e potenzialmente a tutte le librerie di terze parti che ereditano IPAddress. Come risolvere?

La soluzione più pulita e quella di stabilizzare l'api di IPAddress così che modifiche interne non si ripercuotono su altre classi in futuro. La dipendenza di IPAddress Ethernet e wifi è legata ad un membro private _address presente nella classe IPAddress che deve essere trasformato in una union, membro a cui Ethernet e wifi accedono grazie al fatto che sono friends. Potrei limitarmi a modificare questo membro in union per tutte le classi oppure togliere le dipendenze da friends su questo membro privato, in questo caso Ethernet e wifi devono accedere alla union address tramite metodi get e set che mi pare siano già presenti.

Forse per adesso mi limito a modificare solo _address in union e poi creo un branch su cui sperimento l'eliminazione di questa dipendenza da friends.

lesto che ne pensi?

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 09, 2014, 02:40 pm
Code: [Select]
git nome del programma
Code: [Select]
clone crea un clone (dato che lavorerailocalmente, non ti serve avere accesso al remoto)
Code: [Select]
--depth 1 non importare tutto lo storico, ma solo la versione attuale.
Quote
-b ide-1.5.x
clona solo il branch ide-1.5.x, ma non è corretto, dovresti aver clonato il master o uno con un nome più lungo.  se nonmetti -b clona tutto il che è meglio. In effetti i warning sono diversi tra il master e il branch dal nome lungo su cui cmaglie ha suggerito di lavorare x la uova toolchain

Code: [Select]
https://github.com/lestofante/Arduino.git è da dove clonare il repo


per il resto: entraimo nel vivo della discussione. A mio avviso le friend dovrebbero sparire per sempre, però dobbiamo assicurare che all'esterno della classe tutto resti ESATTAMENTE come prima. O meglio, si possonoAGGIUNGERE metodi, ma non cancellarli.

Però essendo una modifica tosta conviene che crei un branch solo per quetsa modifica col comando

Quote
git checkout -b modItaVostroNick


ah ecco, checkout serve per muoversi tra i branch.

la commit salva i dati in locale, quindi puoi farlo, quando vuoi uppare le modifice devi fare un
Code: [Select]
git push, il che richiede un account e che sia abilitato a scrivere nel repo, se mi passi la tua utenza ti aggiungo.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Feb 09, 2014, 06:37 pm
Ora è più chiaro, devo per forza clonare tutto il repo, peccato che ho già clonato con quel comando, c'è un modo per usare già ciò che ho clonato con il comando : git clone --depth 1 -b ide-1.5.x https://github.com/lestofante/Arduino.git

Se avvio la clonazione da dentro il repo locale senza -b ide-1.5.x che succede?
Mi dovrebbe fare in automatico il pull di ide-1.5.x, o mi conviene farlo io manualmente?

L'account su github fresco fresco è: https://github.com/maurotec
Ti basta questo?

L'indirizzo email fornito da github mi conviene lasciarlo privato?

Come devo configurare git in locale?
git config --global user.name "Your Name Here"
Al posto di user.name che ci devo scrivere?
Al posto di yournamehere qui ci arrivo da solo :smiley-mr-green:

Quindi mi aggiungi come contribuitore?

Se si, appena aggiunto creo in locale un nuovo branch freewarning e poi? posso fare push?
Se si dovrebbe comparire in remoto il nuovo branch.

Lo so troppe domande, porta pazienza.

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 09, 2014, 08:59 pm
allora, puoi partire tranquillamente anche solo da quel branch, in realtà io direi di partire da quello suggerito che è quello consigliato
Code: [Select]
ide-1.5.x-avr-toolchain-gcc-4.8.1

e da li creare il nostro branch. occhio x la ethernet che per la 1.5.6 è stata modificata, quindi tienila ferma per ora.
per git fregatene di conf in più, tanto scrivere user e pass ogni volta che vuoi CARICARE codice io lo considero una feature, non uno sbattimento :P

la mail tienila privata va :)

ps. aggiunto come collaboratore sul progetto :)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Feb 11, 2014, 02:21 am
Praticamente, il branch ide-1.5.x-avr-toolchain-gcc-4.8.1 è già warning free, ciò che manca è mettere mano a IPAddress che provoca tutti quei type puned strict alias, che se si sa realmente cosa si sta facendo potrebbero anche essere ignorati del tutto, tuttavia risolvendo il compilatore potrebbe essere in grado di applicare una migliore ottimizzazione, e quindi minore flash e minore tempo CPU impiegato.

Non posso usare __restrict__ perché non ci sono parametri a cui applicarla e applicarla al volo non fa capire a gcc quello che voglio fare, in sostanza gli dovrei dire in riferimento ad ogni codice di warning: all'indirizzo _address e al puntatore ricavato uint32_t* non ci sono alias in questo contesto, cioè in locale.

Gcc solleva il warning perché non ha sufficienti informazioni per ottimizzare il codice, ma sa che potrebbe.

Quindi non mi rimane che mettere mano ad IPAddress e a tutto il resto stando attento a eliminare la dipendenza.

Ciao.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 11, 2014, 11:29 am
occhio che la ethernet è stata modificata nella versione in sviluppo aggiungendo l'operatore == su Client e non so che altro. Quindi vedi tu, io sisnceramente renderei le classi friend free, ma forse per questo conviene prima mergiarsi al master, se il branch non ha le modifiche.

poi vedo che anche la HardwareSerial solleva dei warinig!

il

Code: [Select]
unsigned char c = UDR0;
è da ignorare in quanto il registro DEVE essere letto per avviare la prossima lettura

Code: [Select]
uint8_t current_config;
credo si possa rimuovere
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Feb 11, 2014, 11:31 am
Anche la HardwareSerial è stata modificata di recente.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 11, 2014, 01:56 pm
qualcuno può fare una git diff tra master e ide-1.5.x-avr-toolchain-gcc-4.8.1?

se no ci penso io stasera
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Feb 11, 2014, 02:08 pm
Cos'è?  :~
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 11, 2014, 03:23 pm
è una diff (ovvero trova le differenze) tra i due branch, in tal modo sappiamo esattamente quali file e cose sono stte modificate
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: matthijskooijman on Feb 18, 2014, 09:41 pm
Hi folks! Apologies for talking in English, but you'd rather have that than me trying Italian :-)

I'm also interested in getting the core cleaned of warnings I saw a few recent fixes from IIRC lestofante being merged, which I think originated from this topic. Good work!
Today, I've been working on a few more fixes, which should make the AVR core completely warning-free and the SAM core for thoe most part. My commits are here, if you want to do some testing with them: https://github.com/arduino/Arduino/pull/1877

Now, trying to read back your thread (without any mentionable knowledge of Italian, though), it seems that you've been (also?) working on the 1.0 Arduino version, while I've been focusing on the 1.5.x version. Not sure if the 1.0 version is worth investing much more time into, even though it is still the current stable version. At the least, if you want to work on 1.0, be sure to check how things were solved in 1.5, if the same code is still present there.

I think you've  been discussing the IPAddress strict pointer aliasing thing - My pullrequest contains a proper fix for this issue (using unions).
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 18, 2014, 11:04 pm
hi matthijskooijman, i'm sorry but i'm not who started this thread or who produced the fix, i'm just reporting it to github, where applicable.

we are actually working on 1.5.x, official branch "ide-1.5.x-avr-toolchain-gcc-4.8.1" witch actually fixed a lot of warning.

murotec (i think) also proposed a union "fix" BUT in our opinion the "friend" class are the actual problem to fix.

if you want to try to pull your fix to https://github.com/lestofante/Arduino/tree/ide-1.5.x-avr-toolchain-gcc-4.8.1 (it is exactly the arduino's one, but we was going to work a bit on it), so we can see what is different and what has the same solution, and choose the best
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: matthijskooijman on Feb 18, 2014, 11:22 pm

murotec (i think) also proposed a union "fix" BUT in our opinion the "friend" class are the actual problem to fix.

Ah, indeed, totally missed those friend classes. Thanks, I'll have a
closer look there tomorrow.


if you want to try to pull your fix to
https://github.com/lestofante/Arduino/tree/ide-1.5.x-avr-toolchain-gcc-4.8.1
(it is exactly the arduino's one, but we was going to work a bit on it),
so we can see what is different and what has the same solution, and
choose the best

Ok. It looked like this branch was mostly the ide-1.5.x branch with the
updated toolchain added by ffisore (IIRC), but perhaps there was more
than that. I'll fetch it tomorrow and see what's in there :-)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: lestofante on Feb 18, 2014, 11:27 pm
there is more, you will still find warning, but they are only in the IP union, i think (i'm actually re-cloning the repo, had some problem)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: matthijskooijman on Feb 19, 2014, 04:05 pm
Ok, I looked at the IPAddress friend classes and found only one that caused a problem, which I fixed in my pullrequest.

I looked at the ide-1.5.x-avr-toolchain-gcc-4.8.1 and it indeed looks like the one from Federico. Compared to ide-1.5.x it only updates the toolchain, but I was already using a locally compiled gcc 4.8.2, so I'll just stick to ide-1.5.x. But you probably already knew all this :-)
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Feb 21, 2014, 10:03 am
@matthijskooijman

Congratulations, you have found all warning.  :P

I remember, that other friend class require changes, but if you have build all examples that use IPAddress with succesfull, then there is not other to do. 

Strict alias warning can to be solved using union or local pointer support:
ie.
Code: [Select]

uint16_t *dummy_p = (uint16_t*)_address;
return *dummy_p;


There is a need check if firmware code size is greater than with the union.

I have noticed other possible optimizations, but target is de-warning, should focus on this.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: matthijskooijman on Feb 21, 2014, 10:27 am
I have not built all examples, but any example that includes Ethernet should cause all Ethernet code to be compiled, so that should test all code AFAICS.

I'm not sure what your code example is supposed to show. We should be converting uint8_t[4] to uint32_t, so you probablyl meant uint32_t instead of uint16_t? Also, I suppose you mean (uint32_t*)&address (so with an & added)? Does putting the result in a local variable before dereferencing actually change the strict aliasing requirements? Looks weird to me, but I'll give it a spin as an alternative.

As for firmware code size, IIRC the union approach produced an identical .hex file as the old code, so that should be ok.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: Maurotec on Feb 21, 2014, 01:02 pm
Ok, il codice mostrato è solo un esempio ricavato da mio codice eseguibile sul Computer.

La classe IPAddress non è dipendente dall'hardware, quindi con poche modifiche
l'ho resa compatibile con la toolchain per x86_64.
Questo mi da la possibilità di scrivere codice di test ed eseguirlo sul Computer,
in questo modo il risultato del test è immediato.

Il codice originale da IPAddress.h è questo:
Code: [Select]
operator uint32_t() const { return *((uint32_t*)_address); };

Intanto il ";" dopo } si deve togliere, cioè deve diventare:
Code: [Select]
operator uint32_t() const { return *((uint32_t*)_address); }

Con il codice sopra avr-gcc si lamenta, come pure gcc sul mio computer.
La soluzione alternativa alla union è la seguente:

Code: [Select]
operator uint32_t() const { uint32_t *dummy_p = (uint32_t*)_address);
                            return *dummy_p; }


Quote

Mettere il risultato in una variabile locale prima di "dereferenziare" modifica effettivamente la richieste
di restringere l'alias?


Non sono in grado di darti una spiegazione del perché funziona, ma funziona, inoltre
io non sono in grado di analizzare il codice asm prodotto e quindi non so qual'è la  soluzione più efficiente.
Questo è un punto su cui ritornare quando l'obbiettivo sarà l'ottimizzazione

English translation:

Ok, the code shown is just an example based on my code executable on the my computer.

The IPAddress class is not hardware dependent, so with a few changes
I made it compatible with the toolchain for x86_64.
This gives me the ability to write test code and run it on the computer,
in this way the test result is immediate.

The original code from IPAddress.h is this:
Code: [Select]
operator uint32_t() const { return *((uint32_t*)_address); };

Meanwhile, the ";" after} must be removed, ie it must be:
Code: [Select]
operator uint32_t() const { return *((uint32_t*)_address); }

With the above code avr-gcc complains, as well as gcc on my computer.
The alternative solution to the union is the following:

Code: [Select]
operator uint32_t() const { uint32_t *dummy_p = (uint32_t*)_address);
                            return *dummy_p; }


Quote
Does putting the result in a local variable before dereferencing actually change the strict aliasing requirements?


I am not able to give an explanation of why it works, but it works, also
I am not able to analyze the asm code product and so do not know what is the most efficient solution.
This is a point on which to return when the goal is the optimization.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: matthijskooijman on Mar 16, 2014, 01:15 pm
I had a closer look at this, and I think that your proposed code still violates the strict aliasing rules in C99, but that the compiler is not smart enough to warn about this (or perhaps only with more warnings enabled). AFAIU strict aliasing rules, the union approach _does_ satisfy strict aliasing requirements, so I'll stick with that solution.
Title: Re: Ottimizziamo il codice del core di Arduino
Post by: PaoloP on Apr 04, 2014, 09:16 am
Ho clonato il repository Arduino/master e Arduino/ide-1.5.x-avr-toolchain-gcc-4.8.1
Compilando su Windows con CygWin e creando la distribuzione con
Code: [Select]
ant dist (quella ide-1.5.x-avr-toolchain-gcc-4.8.1)  rimane nell'eseguibile un warning riguardante le directory di tipo MS-DOS.

Ho incluso nel file .bat che carica CigWin la riga
Code: [Select]
set CIGWIN=nodosfilewarning
e se lancio il comando
Code: [Select]
ant run
dentro la directory Arduino/build l'IDE parte e se compilo non da nessun messaggio di errore.
Per contro nella distribuzione (file .zip) se lancio l'eseguibile Arduino.exe e compilo mi appaiono i warning relativi a CygWin nella finestra console dell'IDE.
Perchè?

Qualcuno sa come risolvere?