Ciao a tutti!
Vi vorrei sottoporre un piccolo problema che non riesco a risolvere in maniera efficace:
su un circuito che sto progettando, ho un solo pulsante normalmente aperto, che tramite un fotoaccoppiatore (4N35) va ad un microcontroller (ATTINY13). Il pulsante funziona a 24 V, mentre la logica del uC a 5V. Ho bisogno di creare un circuito antirimbalzo, ma essendo a 24 V, non posso utilizzare i classici circuiti CMOS per il buffer con schmitt trigger. che mi consigliate di fare? Vorrei evitare come la peste l'antirimbalzo software.
Avevo pensato di mettere il circuito dopo il transistor del fotoaccoppiatore, ma non so se è una soluzione ottimale o meno. Che ne dite?
Grazie a chi mi può aiutare.
Ciao!
Antirimbalzo 24 V
Moderatori:
carloc,
g.schgor,
BrunoValente,
IsidoroKZ
6 messaggi
• Pagina 1 di 1
0
voti
1
voti
Mah. Io invece ti invito calorosamente a pensare all'antirimbalzo software. Con poche righe di codice, pochissime, risolvi tutti i problemi senza toccare la circuiteria ed in tempi quasi nulli.
Diverso sarebbe il caso se la logica non fosse programmata o se la circuiteria fosse veramente fatta male.
Un anti-rimbalzo esterno potresti farlo con una rete RC oppure un flip flop ed un deviatore invece del pulsante. Come dire, in tutti i casi circuiti complessi: sostenere una corrente di antirimbalzo ad un fotoaccoppiatore non è scherzo di poco conto.
Diverso sarebbe il caso se la logica non fosse programmata o se la circuiteria fosse veramente fatta male.
Un anti-rimbalzo esterno potresti farlo con una rete RC oppure un flip flop ed un deviatore invece del pulsante. Come dire, in tutti i casi circuiti complessi: sostenere una corrente di antirimbalzo ad un fotoaccoppiatore non è scherzo di poco conto.
-

Candy
32,5k 7 10 13 - CRU - Account cancellato su Richiesta utente
- Messaggi: 10123
- Iscritto il: 14 giu 2010, 22:54
0
voti
Prima di tutto grazie per la risposta Candy!
Il problema dell'antirimbalzo lo escludevo per un fatto di "pigrizia", nel senso che il software gestisce eventi molto vicini, e, visto che non posso prevedere il tipo di pulsante che verrà usato, perché viene collegato dall'utente finale (che non sono io), mi tocca usare dei delay abbastanza lunghi per evitare rimbalzi con contatti di scarsa qualità.
Ci studio sopra un attimo...
Grazie ancora!
Ciao!
Il problema dell'antirimbalzo lo escludevo per un fatto di "pigrizia", nel senso che il software gestisce eventi molto vicini, e, visto che non posso prevedere il tipo di pulsante che verrà usato, perché viene collegato dall'utente finale (che non sono io), mi tocca usare dei delay abbastanza lunghi per evitare rimbalzi con contatti di scarsa qualità.
Ci studio sopra un attimo...
Grazie ancora!
Ciao!
0
voti
Per antirimbalzo devi rimuovere variazioni 0/1 inferiori a circa 20 ms / 30 ms. Non penso proprio che un pulsante ad azione manuale possa dare segnali a frequenza più elevata.
Le tecniche per arrivarci sono innumerevoli. Dipende anche dalla complessità o meno del programma.
Le tecniche per arrivarci sono innumerevoli. Dipende anche dalla complessità o meno del programma.
-

Candy
32,5k 7 10 13 - CRU - Account cancellato su Richiesta utente
- Messaggi: 10123
- Iscritto il: 14 giu 2010, 22:54
0
voti
Ciao
Lemming,
aggiungo il mio commento a quello di @Candy che, di fatto, ti ha già scritto quasi tutto quello che ci sarebbe da considerare.
Lo faccio per rafforzare ulteriormente l'indicazione che ti è stata fornita.
Davvero non mi sembra ci siano validi motivi per ricorrere ad un hardware esterno quando con un dispositivo programmabile te la puoi cavare con poche righe di codice: proprio non c'è paragone nell'impegno.
L'unico dubbio è che tu non abbia la possibilità di scriverle ma, non credo si ricada in questa evenienza.
Molto dipende da quello che deve fare il pulsante: per quanto mi riguarda, per esempio, mi è capitato di inserire ritardi anche di mezzo secondo.
Per esasperare il principio è palese il fatto che se gestisci un "antirimbalzo" di tre secondi quando con la pressione del pulsate(ino) devi fare uno "scroll" di informazioni su un display, l'utente non se la cava più.
Se hai il "contorno" del microcontrollore consolidato dal punto di vista funzionale, completi il firmware, fai le tue prove e ... finito.
Saluti
aggiungo il mio commento a quello di @Candy che, di fatto, ti ha già scritto quasi tutto quello che ci sarebbe da considerare.
Lo faccio per rafforzare ulteriormente l'indicazione che ti è stata fornita.
Davvero non mi sembra ci siano validi motivi per ricorrere ad un hardware esterno quando con un dispositivo programmabile te la puoi cavare con poche righe di codice: proprio non c'è paragone nell'impegno.
L'unico dubbio è che tu non abbia la possibilità di scriverle ma, non credo si ricada in questa evenienza.
Molto dipende da quello che deve fare il pulsante: per quanto mi riguarda, per esempio, mi è capitato di inserire ritardi anche di mezzo secondo.
Per esasperare il principio è palese il fatto che se gestisci un "antirimbalzo" di tre secondi quando con la pressione del pulsate(ino) devi fare uno "scroll" di informazioni su un display, l'utente non se la cava più.
Se hai il "contorno" del microcontrollore consolidato dal punto di vista funzionale, completi il firmware, fai le tue prove e ... finito.
Saluti
W - U.H.F.
-

WALTERmwp
30,2k 4 8 13 - G.Master EY

- Messaggi: 8982
- Iscritto il: 17 lug 2010, 18:42
- Località: le 4 del mattino
0
voti
Grazie sia a Candy che ad WALTERmwp,
alla fine ho fatto la modifica al software del uC, ho dovuto studiarci su un attimo, visto che ancora non ho molta confidenza con l'assembly, ma pare che ce l'abbia fatta.
Appena ultimato il tutto vi faccio sapere se è uscito qualcosa di valido o meno.
Grazie ancora!
alla fine ho fatto la modifica al software del uC, ho dovuto studiarci su un attimo, visto che ancora non ho molta confidenza con l'assembly, ma pare che ce l'abbia fatta.
Appena ultimato il tutto vi faccio sapere se è uscito qualcosa di valido o meno.
Grazie ancora!
6 messaggi
• Pagina 1 di 1
Chi c’è in linea
Visitano il forum: Google [Bot] e 53 ospiti

Elettrotecnica e non solo (admin)
Un gatto tra gli elettroni (IsidoroKZ)
Esperienza e simulazioni (g.schgor)
Moleskine di un idraulico (RenzoDF)
Il Blog di ElectroYou (webmaster)
Idee microcontrollate (TardoFreak)
PICcoli grandi PICMicro (Paolino)
Il blog elettrico di carloc (carloc)
DirtEYblooog (dirtydeeds)
Di tutto... un po' (jordan20)
AK47 (lillo)
Esperienze elettroniche (marco438)
Telecomunicazioni musicali (clavicordo)
Automazione ed Elettronica (gustavo)
Direttive per la sicurezza (ErnestoCappelletti)
EYnfo dall'Alaska (mir)
Apriamo il quadro! (attilio)
H7-25 (asdf)
Passione Elettrica (massimob)
Elettroni a spasso (guidob)
Bloguerra (guerra)