next topic »

[Reply #15 on:]

Allora ti faccio una domanda forse stupida, quindi significa che atmel ha un campionamento del segnale troppo lento?

Non è un problema di campionamento lento, è un problema di rimbalzi, un contatto meccanico quando chiude crea una serie di impulsi rapidissimi, anche molte decine, che creano una serie di conteggi fasulli.
Si può gestire anche solamente da software, magari con l'accortezza di utilizzare almeno un filtro passa basso (RC) sul pin collegato al canale, però dato che è indispensabile introdurre dei ritardi di molti ms, anche diverse decine, questo si traduce in forti ritardi nella gestione dell'encoder con la conseguenza che se non lo giri lentamente, dipende da quanti impulsi giro fornisce, rischi di perderti dei conteggi.
Adesso non ho tempo per farlo però domani ti posto uno schema di base, solo con rete RC, e un minimo di codice per gestire l'encoder tramite interrupt e debounce software.

perfetto grazie per la gentilezza, cosi per avere qualche altro sistema di gestione, proverò anche quello di flz47655 poi valuterò quello più conveniente, ma con arduino due leggevo che la gestione degli encoder diventa più semplice o sbaglio?

[Reply #16 on:]

perfetto grazie per la gentilezza, cosi per avere qualche altro sistema di gestione, proverò anche quello di flz47655 poi valuterò quello più conveniente, ma con arduino due leggevo che la gestione degli encoder diventa più semplice o sbaglio?

Arduino DUE ha la gestione degli encoder in hardware, però mi pare non sia supportata da wiring 1.5, ma non ti è di molto aiuto perché il problema del debouncing rimane, anzi è ancora peggio perché sei obbligato ad usare gli appositi IC antidebouncing perché non è possibile gestirlo a software se usi il decodificatore hardware.
La decodifica degli encoder in hardware ti semplifica la vita dal punto di vista software perché hai un registro che incrementa/decrementa in automatico ogni volta che l'encoder gira, hai anche un flag che ti dice in che verso ruota, può gestire elevate velocità di cambio degli impulsi, centinaia di kHz, tipiche negli encoder ottici ad alta risoluzione utilizzati su i motori per misurare la velocità e lo spazio percorso, cosa inutile nel caso di encoder meccanici visto il loro utilizzo come manopole.

[Reply #17 on:]

perfetto grazie per la gentilezza, cosi per avere qualche altro sistema di gestione, proverò anche quello di flz47655 poi valuterò quello più conveniente, ma con arduino due leggevo che la gestione degli encoder diventa più semplice o sbaglio?

Arduino DUE ha la gestione degli encoder in hardware, però mi pare non sia supportata da wiring 1.5, ma non ti è di molto aiuto perché il problema del debouncing rimane, anzi è ancora peggio perché sei obbligato ad usare gli appositi IC antidebouncing perché non è possibile gestirlo a software se usi il decodificatore hardware.
La decodifica degli encoder in hardware ti semplifica la vita dal punto di vista software perché hai un registro che incrementa/decrementa in automatico ogni volta che l'encoder gira, hai anche un flag che ti dice in che verso ruota, può gestire elevate velocità di cambio degli impulsi, centinaia di kHz, tipiche negli encoder ottici ad alta risoluzione utilizzati su i motori per misurare la velocità e lo spazio percorso, cosa inutile nel caso di encoder meccanici visto il loro utilizzo come manopole.

Credevo si sarebbe passati a una semplificazione del tutto, va bene lo stesso

[Reply #18 on:]

Dai un'occhiata qui, c'è il codice pronto all'uso per un encoder meccanico.

[Reply #19 on:]

http://bildr.org/2012/08/rotary-encoder-arduino/ risolto con questo grazie a tutti