Go Down

Topic: [RISOLTO] dichiarare variabili al momento che servono oppure no (Read 1 time) previous topic - next topic

maubarzi

... mmm ... non ne sono sicurissimo. Certo, occorrerebbe valutare quante variabli booleane ti servono, quali operazioni fai più spesso, ecc. ecc. e valutare caso per caso l'ottimizzazione migliore :)

Guglielmo
In effetti, stanotte, ragionando (leggi dormendo), è venuto il dubbio pure a me.
Bisognerebbe vedere esattamente come viene scritto in assembly questo test, se riesce a mettere tutto negli stessi byte perchè di fatto non serve un intero byte per indicare numeroBit (ne potrebbero bastano 3 o 4 a seconda se si accede a 1 byte o 2) dipende dai bit che servono per l'indirizzamento della variabile da testare...
Non è che dal cilindro tiri fuori un reference del linguaggio assembly? Sul datasheet dell'ATmega c'è solo la lista delle istruzioni con l'identificativo mnemonico, non con quella binaria, almeno se non ho visto male.
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

gpb01

In effetti, stanotte, ragionando (leggi dormendo), è venuto il dubbio pure a me .....
... moltissimo conta come ottimizza il compilatore e quale livello di ottimizzazione si sceglie (cosa che non fa nessuno, ma esiste sia un apposito #pragma che un __attribute per cambiare le ottmizzazioni del codice tra le varie possibili).

Ripeto, per avere indicazioni reali, occorrerbbe mettersi a scivere aluni test, compilarli e guardare, con l'aiuto del .elf, l'assemblato generato per la varie righe scritte ;)

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

maubarzi

Ho trovato un po' di doc e mi sa che alla fine il buon vecchio Guglielmo non aveva proprio tutti i torti.
Le istruzioni sono a 16 bit per cui c'è tutto lo spazio per gestire il numeroBit nell'istruzione principale per cui non dovrebbe richiedere il byte in più che avevo ipotizzato.

L'unica pecca è che alla sua risposta mancava il solito doc di specifica cui ci ha sempre abituati...  ;)  ad abituare bene le persone ...  :smiley-evil:  poi queste non sono mai contente ...  :P

Quindi mi sa che possiamo dire che anche accorpare i boolean come bit di byte ha il suo vantaggio.
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

gpb01

L'unica pecca è che alla sua risposta mancava il solito doc di specifica cui ci ha sempre abituati...  ;)  
:D :D :D ... eccone uno (piuttosto vecchio) che magari ti sarà utile (se non lo hai già trovato) ...

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

maubarzi

Non mi dire che questa volta riesco io ad aggiornare la tua immensa libreria ;)
Ne ho trovato uno del 2014.
Però il karma te lo metto lo stesso, anche se guadagnato in zona Cesarini ;)
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

gpb01

Non mi dire che questa volta riesco io ad aggiornare la tua immensa libreria ;)
:D :D :D ... grazie, dato lo scarso uso che ne faccio, non mi ero preoccupato molto di cercare un aggiornamento ;)

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

dr_vagus

Qualche consiglio:
incorpora fino alla morte le boolean in variabili di tipo byte (non so per che cosa le usi ma ne ho contate una quindicina soltanto tra le dichiarate globali)
Contrario, solo in apparenza, a quanto dissi: sei certo che tutta quella pappardella di variabili globali ti siano utili? Quelle che ti servono solo per momenti rendile locali, che poi spariscono.
Ho visto una cosa che non mi piace:un, ma forse sono di più, esemplare di String. Estinguili.
Rendi #define TUTTE le variabili il cui valore NON debba cambiare nel programma. Altro che "const unsigned long", e pin di pulsanti manco dichiarati const.
Sicuro che ti serva leggere lobstato di pulsanti e ricordarlo in variabile? Se tale variabile la usi una volta sola in lettura basta leggere lo stato del pulsante in quel punto.
Poi mi spieghi perché dichiari alcune bool come =!HIGH (5 caratteri) e non come =LOW (3 caratteri)? Il risultato é lo stesso, ma il secondo é più chiaro.

Non ho ancora attaccato oa loop()
come scritto a molte delle cose che indichi ci avevo già pensato. Altre si potrebbero fare, ma quanto shrinko? 10-20-50 byte? ormai sono fuori di 600 byte.

"!HIGH" capisco la perplessità, ma cio' che sembra chiaro a te non lo per me. Uso "!HIGH" semplicemente perchè i relè si eccitato con stato LOW, e mi rimane piu intuitivo scrivere !HIGH per capire quando sto eccitando il relè." 

I problemi non sono solo SW ma anche HW: questo progetto è stato inserito in una scatola elettrica di certe dimensioni, molto compatte... con Arduino Pro Micro è tutto compatto, se metto un mega2560 devo rifare tutto.

Eppoi considerazione conclusiva: è bello anche poter scrivere il codice con un minimo di libertà di scrittura, ottimizzando si, ma senza dover rinunciare al proprio "stile", e al modo in cui ciascuno è abituato a scriversi il codice e a leggerlo.
Inoltre c'è da distinguere due tipi di sketcher: ci sono gli smanettoni, di solito piu esperti e molto bravi, ma spesso troppo intrippati con il coding (è bello concordo), e poco pratici, ma poi ci sono anche altri che per vari motivi non hanno tempo o voglia di dedicarsi troppo ai problemi SW e HW e preferiscono realizzare il progetto in modo piu agevole (quindi evitando di dedicarsi troppoai problemi di cavilli SW). Io appartengo alla seconda specie.

L'idea di passare a STM32 è dovuta 1) al costo 2) alle dimensioni fisiche (mi consente di utilizzare lo chassis già in suo) 3) la memoria, 64K è il doppio di quello che mi serve 4) non da ultimo il clock 72Mhz invece di 16.

Almeno per questo progetto, in altri casi rimango fedele ad ATMEL. :-)

Grazie cmq delle osservazioni di cui faccio sicuramente tesoro.
----
don't be ...Vagus.

dr_vagus

Resta però valida la mia premessa iniziale, se con pochi euro riesci a passare a qualcosa di più "potente" non vale la pena spendere ore in ottimizzazioni perchè costerebbero di più del cambio MCU.

Eh già. Anche perchè ahimè di tempo ne ho veramente poco. Tra figli moglie lavoro.. alla fine mi restano dei ritagli... perdere ore per comprimere di 100byte mi pare poco costruttivo nel mio caso almeno.

Grazie molto per le osservazioni.
----
don't be ...Vagus.

gpb01

... non da ultimo il clock 72Mhz invece di 16.
... questo dato, buttato così, non è molto signifcativo ... ho visto blasolante MCU viaggiare a quelle frequenze e svolgere i loro compiti più lentamente degli AVR a 16 MHz ... occorre esaminare molte cose, il solo clock non basta ;)

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

maubarzi

Eh già. Anche perchè ahimè di tempo ne ho veramente poco. Tra figli moglie lavoro.. alla fine mi restano dei ritagli... perdere ore per comprimere di 100byte mi pare poco costruttivo nel mio caso almeno.
Ma si, dai... siamo sempre in ambito hobbistico!
Se lo si fa per lavoro sarebbe già diverso, altrimenti si rischia di fare come una nota azienda di software che con le sue pessimizzazioni riesce sempre a vanificare tutti i miglioramenti prestazionali dell'hardware ;)

:D :D :D ... grazie, dato lo scarso uso che ne faccio, non mi ero preoccupato molto di cercare un aggiornamento ;)
Io però la metto lo stesso nel mio curriculum ;)
Nessuna buona azione resterà impunita!

Preistoria -> medioevo -> rinascimento -> risorgimento -> rincoglionimento!

Go Up