Un delay che cambia tutto...

delay() = male

pablos:
Probabilmente interferisce con l'antirimbalzo, dato anche in quella libreria ci sono dei delay, la button aspetta un pochino e anche nel loop aspetta un pochino e non si mettono d'accordo. :slight_smile:

delay() = male

più probabile che la libreria usi i millis(), in ogni caso anche io sono della vostra stessa idea.

@dvluca: impara ad usare la millis() e non usare mai più la delay() :grin:
per capire come osserva lo sketch di esempio blinkWithoutDelay

dvluca, cosí non funziona.
Non puoi chiederci un aiuto dandoci un sketch che non é quello che Ti da i problemi.
Ciao Uwe

Ciao, forse non sono riuscito a spiegarmi;
Questo da problemi!

prendo l'arduino, senza collegamenti eccetto l'USB, (senza bottoni, led, sonde, nulla di nulla)

copi il codice che ho inserito sopra,

fai l'upload senza delay, apri la seriale e dice: menu= 0 Level =0 ...poi...
fai l'upload con il delay, april la seriale e dice: menu= 1 Level =1

Vi prego di verifcare, sono certo di queste condizioni,

Il delay è male, lo sò... ma il delay non manda tutto a pallino!
Se avessi chiesto: "perchè se metto un delay di 2 ore non funziona nulla?" la risposta sarebbe ovvia per tutti,
Invece, in questo caso, il delay, da solo, altera 2 variabili!

perchè quel delay va a interferire con i tempi di milli memorizzati dalla libreria button.h per calcolare lo stato dei pulsanti, mandando tutto a pallino.

lo stesso vale per il delay(500) che vedo più avanti, ma viene chiamato in rari casi e quindi è un bug latente.

apri la button.h / button.cpp e leggiti il codice, dovresti capire cosa succede

La libreria dovrebbe funzionare così:

if (bitRead(state,CURRENT) != bitRead(state,PREVIOUS)){
bitWrite(state,CHANGED,true);

Leggi il tasto, prima era o ed adesso è 1 ;
prima era 1 ed adesso è 0;
bene lo stato è cambiato!

La libreria non ha delay ne millis...

lo stato iniziale era dei pin ai quali (non) sono collegati i bottoni è dichiarato a 0, i bottoni non ci sono! (quindi il problema non è hardware)
Scusate ma proprio non capisco!

prova a spostare quel delay 1000 in fondo al loop, se non altro almeno prima vede i tasti premuti ed esegue le relative cose, poi aspetta 1 sec.

aspetta, se ai pin dei bottoni non è presente pull up o pull down allora è normale avere cose a random

pablos:
prova a spostare quel delay 1000 in fondo al loop, se non altro almeno prima vede i tasti premuti ed esegue le relative cose, poi aspetta 1 sec.

Un delay di 1 secondo è distruttivo ovunque tu lo metta.

tuxduino:

pablos:
prova a spostare quel delay 1000 in fondo al loop, se non altro almeno prima vede i tasti premuti ed esegue le relative cose, poi aspetta 1 sec.

Un delay di 1 secondo è distruttivo ovunque tu lo metta.

lol .. è distruttivo, catastrofico, una cosa disumana, da ergastolo :slight_smile: ... dipende sempre cosa devi fare, posso comprare un I7 e fargli fare solo un timer da 1 secondo, quello che faccio del m.controllore o microprocessore sono affari miei ... l'istruzione esiste e usarla o no è una mia scelta. Perchè non impicchiamo quello che ha creato l'istruzione delay()? :fearful:
Dai su non esageriamo. pls

Allora! :slight_smile: il deley non mi serve, ne prima ne dopo; non è questo il punto!
Il nodo della questione è: i dati son sono random puoi resettare 10 volte e avrai sempre le stesse letture:
Con deley: menu=1 level=1
Senza: menu=0 level=0
I tasti li posso collegare o scollegare ma non cambia nulla!

pablos:

tuxduino:

pablos:
prova a spostare quel delay 1000 in fondo al loop, se non altro almeno prima vede i tasti premuti ed esegue le relative cose, poi aspetta 1 sec.

Un delay di 1 secondo è distruttivo ovunque tu lo metta.

lol .. è distruttivo, catastrofico, una cosa disumana, da ergastolo :slight_smile: ... dipende sempre cosa devi fare, posso comprare un I7 e fargli fare solo un timer da 1 secondo, quello che faccio del m.controllore o microprocessore sono affari miei ... l'istruzione esiste e usarla o no è una mia scelta. Perchè non impicchiamo quello che ha creato l'istruzione delay()? :fearful:
Dai su non esageriamo. pls

Appunto, non esageriamo. E non generalizziamo. Leggi la mia battuta come risposta al tuo commento: spostare delay(1000) da un punto all'altro così "almeno primva vede i tasti premuti..." ecc. non cambia nulla. Il problema è che i segnali vengono campionati una volta al secodo, e ritardare prima o dopo la loro campionatura non modifica questo fatto.

(edit: nella fretta avevo dimenticato questo: :slight_smile: )

Qui il punto è rimane perchè!

:0

dvluca:
Qui il punto è rimane perchè!

:0

Che in italiano significa ?

tuxduino:

dvluca:
Qui il punto è rimane perchè!

:0

Che in italiano significa ?

da buon polemico, me lo stavo chiedendo anch'io :slight_smile: :slight_smile:

comunque si capisce dai ... togli "è" e metti "che", aggiungi "è il " prima di perchè :slight_smile:

Qui il punto è e rimane: perchè?
Non voglio polemizzare, mi trovo solo in una situazione nella quale non sono in grado di capire una cosa apparentemente semplice come questa. E con umiltà, chiedo cosa mi sfugge...

Giuro: non ci ero arrivato... :cold_sweat:

Allora tornando a bomba...

  • puoi postare il lnk alla libreria Button che usi ?
  • hai provato a far girare il codice togliendo la chiamata delay(1000) ?
  • perché c'è una delay(500) su menu==6 ?
  • togli i print() di debug quando togli delay(1000) perché verrebbero eseguiti a velocità folle :slight_smile:
  • c'è un errore:
        (menu=menu++);

Le parentesi sono inutili, ma l'errore vero lo trovi confrontando quella riga con il modo in cui incrementi level, un paio di righe più sotto...

Un consiglio: credo che il codice risulterebbe più leggibile se invece di una serie di if() usassi l'istruzione switch, tipo:

switch(menu) {
    case 1:
        // fai qualcosa
        break;

    case 2:
        // fai qualcosa
        break;

    // ecc.
}

Ora che ho scritto questa pappardella credo di avere capito qual è il problema: l'analisi della voce di menu dovresti farla solo quando rilevi la uniquePress.
Ovvero (ometto per chiarezza la gestione del livello):

// se è stata rilevata la pressione del tasto menu:
if(tastomenu.uniquePress()) {
    // incrementa il numero del menu
    (indovina :-P )
    // esegui il codice relativo al menu attuale
    switch(menu) {
        // ecc. come indicato più sopra
    }
}

In questo modo le funzioni del menu vengono eseguite solo quando si rileva la pressione del tasto ed il cambio di nuemero di menu.
Questo ti permette di eliminare i delay().

Spero di esserti stato d'aiuto.

Ti ringrazio, diciamo che questo approccio è quello che cercavo, posterò il link questa sera.