Newsgroup: it.hobby.elettronica.digitale
Titolo: Debounce al rilascio (interrupt)

Ciao,
ho problema "strano", che non ho mai affrontato.
Ho un tastierino 4x4 collegato ad un PCF8574. Da li vado ad un micro ed 
utilizzo l'interrupt sul fronte di discesa per intercettare le 
variazioni sui tasti.
Via software ignoro gli interrupt successivi dovuti al bounce con un 
ritardo (100ms) e ripulendo il relativo registro prima di uscire dalla 
ISR (EIFR dell'ATmega).
Pero' accade che ... al rilascio del tasto vengono generati altri 
interrupt, di solito prima che il micro abbia elaborato il tasto 
premuto. Il valore letto risulta quindi invalido.
Facendo un po' di debug "live", mettendo una print all'interno della 
ISR, sull'LCD a regime vedo:
- 16  # errore di lettura dal tastierino, o nessun tasto premuto
(premo il tasto 1)
- 0
(mollo il tasto)
- 16
Se tengo il tasto premuto sufficientemente a lungo, cosi' che il micro 
arrivi alla IF/THEN giusta, succede quello che voglio, altrimenti nulla. 
Ma poi ai rilascio riappare il "16". In pratica e' impossibile ottenere 
il "lock" sul tasto premuto dopo il rilascio dello stesso.
Come la risolvo? In hardware o via software?
Grazie :)
Paolo

 Come la risolvo? In hardware o via software?
Di solito si disabilita l'interrupt fino a quando non viene gestito
Cosa intendi per lock?
Ciao
CG 

 Cosa intendi per lock?
Intendevo "il mantenimento del valore corrispondente al tasto premuto 
anche al rilascio dello stesso."
Mentre aspettavo qualche suggerimento ho cercato in rete, ho letto che 
"il software non costa nulla, l'HW invece si" e ho trovato una soluzione 
SW: ho aggiunto una variabile che indica la presenza di un tasto 
premuto, letto ma non ancora consumato. La valorizzo nella ISR, la 
resetto nel "main". Mi pare di ricordare si chiami "semaforo" nella 
programmazione ad alto livello, no? ;-)
Nota: io penso che il SW sia possibile causa bug, mentre l'HW e' "certo". :)
Ciao,
PaoloC

 Nota: io penso che il SW sia possibile causa bug, mentre l'HW e' "certo". :)
Tsk. Inguaribile ottimista. Diciamo che l'HW fatto da professionisti viene
debuggato a fondo prima di essere stampato su silicio, ma neppure loro sono
perfetti.
-- 
Saluti

 perfetti.
Speravo ci fosse una soluzione HW al rimbalzo sul rilascio, gia' 
debuggata da professionisti. ;)
Saluti hobbystici :)
Paolo

 - } loop
Mi sembra perfetto, a parte l'attesa per non sovraccaricare la blackbox che
andrebbe gestita in tutt'altro modo. Basta eliminare la disabilitazione
degli intreq di tastiera e sostituire l'abilitazione con una lettura dei
pin della tastiera.
100 ms sono un po' tantini per il debounce, ma vabbé.
Facciamoci un po' di domande sull'hardware: perché usare quel coso?
Un ATtiny24 costa meno, comunica in IIC e ti permetterebbe di gestire
correttamente la tastiera.
Dato per scontato che non hai altri 5 pin per gestire la tastiera con
Arduino e che pormai hai già cablato quel coso, ti suggerisco di rimuovere
l'interrupt (così guadagni un pin) del coso o comunque di ignorarlo.
Definisci 16 variabili da 2 bit ciascuna (oppure, se non lo sai fare o
Arduino non gestisce le strutture a bit, un intero byte). Ad ogni ciclo
leggi lo stato dei tasti e, se il tasto è premuto, incrementi la variabile
relativa, se non lo è la azzeri. Quando la variabile arriva a 2 segnali al
main la pressione del tasto. Quando arriva a 4 la decrementi, in modo che,
al prossimo giro, sarà di nuovo a 4 perché il tasto è ancora premuto o a
zero se è stato rilasciato.
Se poi ci dicessi a che velocità trasmetti sulla seriale e di quanto tempo
ha bisogno la blackbox per riprendersi dall'ultimo byte trasmessogli o,
meglio ancora, ci dicessi che roba è (sempre tu non ci debba poi uccidere
per preservare il segreto) sarebbe ancora meglio, dato che scommetto che
l'architettura del tuo SW è "subottimale".
-- 
Saluti

 Arduino
Ah, no non sei tu quello dell'Arduino. Quale AVR usi?
-- 
Saluti


:-D Parto da qui, poi digerisco il tuo messaggio precedente.
ATmega168 (o 88 o 328, insomma, quella serie li) perche' ho bisogno di:
- package DIP (tanto ho spazio sotto il tastierino e il display ;) )
- USART
- oscillatore con XTAL
In realta' ora che sono passato al tastierino interfacciato tramite i2c 
(PCF8574), forse potrei usare qualcosa di piu' piccolo, ma ormai ho i 
mega168 in casa. NB: tutto il problema dell'interrupt avviene con il 16 
tasti attaccato al PCF8574 e I2C+INT0.
L'oscillatore con XTAL mi serve per avere 0% di errore sul baudrate 
(4800, 9600 o 115k) *e* non avere armoniche in RF che cadano in banda 
radioamatoriale. Quindi 11,052 MHz.
Passo a leggere l'altro messaggio.
Paolo

 Passo a leggere l'altro messaggio.
Dove per "Arduino" si intende "ATmega168" e "coso" "PCF8574".
-- 
Saluti

 l'architettura del tuo SW è "subottimale".
Probabilissimo. Ma per ora funziona :) Poi, a progetto concluso, 
cogliero' la sfida di ottimizzare il codice. Il problema è che il 
mega168 ha talmente tanta flash (e RAM) per quello che devo fare, che 
posso anche scrivere codice sprecone :( Mica come sull'ATtiny2313! :)
Mentre che ci sono, ho due ATmega168P a cui ho disabilitato il RSTDISBL 
e non posso piu' programmarli. Serve un HVP, che non ho. Li scambio a 
[TO] con mega48/88/168 DIP sbloccati, o li regalo previo rimborso delle 
spese (francobollo+busta a bolle).
Paolo

 spese (francobollo+busta a bolle).
Personalmente non saprei che farci, nel senso che li posso comprare da
Farnell per meno di quanto costerebbe la spedizione.
Mi sembra strano che non ci sia in rete (o su AVRfreaks) un sistema per
cancellare i fusibili. in fondo basta mettere il reset a +12 e mandare un
paio di byte...
-- 
Saluti

 paio di byte...
Dovrei costruire un High-Voltage Programmer. Ma se basta mandare un paio 
di byte (... datasheet) posso anche tentare la strada AVR-to-AVR :)
Grazie di tutto. Mi stampo il codice scritto finora e vedo come 
raddrizzare l'architettura.
Paolo

 Grazie di tutto.
Figurati, è un piacere aiutare gente come te. Mi spiace solo di non averlo
fatto prima (nel frattempo ho dato un'occhiata ai tuoi precedenti post).
-- 
Saluti

 tagliare (e poi ricucire) un po' di piste (prima fra tutte quella di reset)
cut...
Forse si potrebbe tentare di sottoalimentare il micro in modo che
internamente il reset sia generato.
Sicuramente occorrerà iniettare un clock esterno visto che
l'oscillatore avrebbe qualche problemino a funzionare.
IMHO...
Piccio.

 tagliare (e poi ricucire) un po' di piste (prima fra tutte quella di reset)
Ecco perche' uso DIP, rigorosamente su zoccolo :-)
Paolo

 l'oscillatore avrebbe qualche problemino a funzionare.
Non sapendo come sono settati i fusibili relativi č senz'altro necessario.
-- 
Saluti

 non ha abbastanza uscite. Se ci riesco, pubblico circuito e sorgente.
Tienici informati e chiedi qualunque aiuto. :-)
-- 
Saluti