Go Down

Topic: Un delay che cambia tutto... (Read 3053 times) previous topic - next topic

tuxduino


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.

pablos

#16
Jan 24, 2013, 02:29 pm Last Edit: Jan 24, 2013, 02:46 pm by pablos Reason: 1


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 :) ... 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()?  :smiley-eek-blue:
Dai su non esageriamo. pls
no comment

dvluca

Allora! :) 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!

tuxduino

#18
Jan 24, 2013, 03:22 pm Last Edit: Jan 24, 2013, 05:34 pm by tuxduino Reason: 1



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 :) ... 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()?  :smiley-eek-blue:
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: :) )

dvluca

#19
Jan 24, 2013, 05:04 pm Last Edit: Jan 24, 2013, 05:07 pm by dvluca Reason: 1
Qui il punto è rimane perchè!

:0

tuxduino


Qui il punto è rimane perchè!

:0


Che in italiano significa ?

pablos

#21
Jan 24, 2013, 07:15 pm Last Edit: Jan 24, 2013, 07:18 pm by pablos Reason: 1


Qui il punto è rimane perchè!

:0


Che in italiano significa ?

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

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

dvluca

#22
Jan 24, 2013, 08:06 pm Last Edit: Jan 24, 2013, 09:35 pm by dvluca Reason: 1
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...

tuxduino

Giuro: non ci ero arrivato...  :smiley-roll-sweat:

tuxduino

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 :)
- c'è un errore:
Code: [Select]

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

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

Code: [Select]

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

dvluca

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

Go Up
 


Please enter a valid email to subscribe

Confirm your email address

We need to confirm your email address.
To complete the subscription, please click the link in the email we just sent you.

Thank you for subscribing!

Arduino
via Egeo 16
Torino, 10131
Italy