Go Down

Topic: Un delay che cambia tutto... (Read 2673 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