Leggere un encoder incrementale: meglio sw o hw?

[mach01]

Ciao a tutti,
mi presento, perché sono al primo post sul forum.

Mi diletto di elettronica e vi pongo un quesito che mi è venuto in mente mentre mi stavo occupando di leggere la velocità ed il senso di rotazione di un albero motore (cc 12V) collegato ad un encoder incrementale.

Stavo eseguendo lo studio per leggere l'encoder via sw con un PIC (18f4525 in C18), e la cosa
non è per niente banale essendo alla prima esperienza in tal senso: bisogna conoscere gli interrupt, preparare le routine di conteggio e di confronto; il tutto tenendo d'occhio i tempi.

Poi ho avuto una intuizione: e se convertissi la frequenza dell'onda quadra dell'encoder in tensione continua che posso leggere molto più agevolmente con l'ADC del PIC?
Il sw sarebbe molto più semplice e sarebbe così implementata una sorta di dinamo tachimetrica.

Sembra (e sottolineo sembra perché devo ancora passare dalla teoria alla pratica) che con un LM2917 non dovrebbero esserci grossi problemi nella conversione.

Premesso che bisognerebbe conoscere le caratteristiche dell'encoder (devo ancora sceglierlo), e che non ho bisogno di presazioni/precisioni elevate; la domanda è: il ragionamento, secondo voi, è valido oppure c'è qualche particolare che mi sfugge?

Grazie!

[DonJ]

Per funzionare funziona, ma è chiaro che la precisione non è quella digitale dell'encoder.
Io lo farei via software, è questione solo di spendere un po' di tempo per buttare giù il programma.
Gli altri componenti sono superflui. Io fossi in te mi sforzerei di usare la testa e trovare una soluzione software. Ne guadagni in affidabilità, precisione e compattezza.

[DirtyDeeds]

Convertire una frequenza in una tensione non è praticamente mai una buona idea! Resterei sulla soluzione software.

Piuttosto, se proprio vuoi alleggerire il compito del microcontrollore, puoi fare un circuito esterno che faccia la rivelazione del verso di rotazione.

[mach01]

Grazie per le risposte.

Ho deciso di iniziare a preparare il.... sw! Mi sono (avete) convinto
che è il caso di provare a sviluppare il programma, farà comunque bene
per migliorare il livello di programmazione del PIC... mi tengo il barbatrucco
se proprio non ne esco vivo.

Thx

[Candy]

Cerca di uscirne vivo, anzi, escine vivo, perché un convertitore F/V da leggere poi con un ADC dove ti porterebbe? Già immagino un posizionatore di qualunque specie fatto in un modo simile... Addio.

Per carità, quando si è "giovani" ed alle prima armi, tutto è difficile, ma leggere un encoder incrementale con un PIC ed i suoi interrupt è veramente semplice. Le cose si potrebbero complicare nel momento in cui l'encoder si ferma col foto-transistor di uno dei canali sul punto di commutazione e magari ci sono sempre un poco di vibrazioni sull'albero...

[TardoFreak]

mach01, gli encoder si gestiscono via firmware, la conversione di cui parli è un suicidio elettronico.
C' è un sistema migliore che utilizzare interrupt e menate varie facendole gestire dal micro che dovrà poi fare anche tutto il resto: usare un microcontrollore dedicato come ha suggerito DirtyDeeds.
Al tuo livello di conoscenza ed esperienza è la soluzione migliore: un micro che faccia solo quello e senza usare interrupt ma campionando continuamente gli ingressi. Il programma risulterà quasi banale ed otterrai un ottimo risultato.
Oppure ci spendi un po' di tempo e lo integri con il resto utilizzando le interrupt come ha giustamente osservato Candy.

[Candy]

Per carità, si possono gettare anche i soldi dalla finestra e, quindi, si può anche dedicare un PIC solo per la gestione encoder... Ma è tutto sprecato.
Comunque sì, come primo approccio può anche essere. Comincia a fare un programma che faccia solo ed esclusivamente quello, controllando e rimuovendo tutti gli errori del caso, vedrai che poi, poco alla volta, col PIC ci prendi anche dimestichezza e gusto.

[TardoFreak]

Per carità, si possono gettare anche i soldi dalla finestra e, quindi, si può anche dedicare un PIC solo per la gestione encoder... Ma è tutto sprecato...

Si, è vero, si sprecano potenzialità ... ma solo quelle.
Piccolo O.T.
Questo è un aspetto dell' elettronica odierna al quale mi sono dovuto adeguare. Un microcontrollore che gestisca un encoder costa meno di un euro. E' vero che è sprecato ma, sforzandosi un po' non lo è poi tanto.
A livello, diciamo filosofico lo è ma a livello pratico no.
Faccio un esempio pratico.
Mi è capitato di dover realizzare un semplice circuito che pilota 8 display a 7 segmenti che deve collegarsi ad un altro circuito tramite isolamento galvanico. Inizialmente ho pensato realizzare un qualcosa di hardware (il solito driver con interfaccia SPI) che si collega al micro principale tramite optoisolatori. Poi ho pensato di utilizzare un micro per far svolgere alcune funzioni al display, fosse anche solo il multiplexing.
La cosa singolare è che il micro che gestisce tutto l' abaradan costa quanto un solo display, uno solo e la scheda ne monta otto!
Ma non finisce qui. Spulciando le varie soluzioni sono approdato ad un micro a 32 bit perché costava meno di un PIC delle balle.
Mettiamola come vogliamo ma, per un' applicazione commerciale si guarda il prezzo.
Quello che è venuto fuori è un display intelligente, che fa molte cose che avrebbe dovuto fare il micro principale e che utilizza un mostro assolutamente sprecato per l' applicazione ma economicamente conveniente.
Capisci che per uno come me che ha sempre combattuto contro i limiti dei micro, trovarmi ad utilizzarne uno al 5% delle sue possibilità per fargli fare un lavoro da manovale è come utilizzare un motore di una ferrari in un tosaerba.
Confesso che mi sento colpevole di lesa maestà per aver fatto questo ma ... il portafoglio è contento, ho un risparmio e mi posso permettere il lusso di fare un multiplexing a 20 kHz.
Un altro esempio: mi sto organizzando per usare i notepad (o come diavolo si chiamano) android come periferiche di I/O.
Con 100 euro compro una periferica intelligente con un display della Madonna, grande, e con ottima risoluzione, touch screen, wi-fi, bluetooth sulla quale posso far girare un programma. E' di sicuro uno spreco di potenzialità ma è economicamente conveniente rispetto ad un semplice display nudo e crudo che mi costerebbe di più e che dovrei gestire i toto partendo da zero.
Comunque così facendo si fa solo quello che le case produttrici di micro cercano di far fare ai progettisti, in pratica ci stanno dicendo "quando dovete fare un circuito con più di un integrato usate un micro! Fate più cose e risparmiate denaro", e non hanno torto. E lo dimostra il fatto che tutte stanno spingendo verso i 32 bit, In effetti sono seducenti, strapotenti, a basso consumo ed al costo delle patate. Il ink al documento che ho segnalato nel thread Passare dai PIC al Cortex-M3 dice chiaramente "tu, pirla, smettila di usare quelle ciofeche ad 8 bit ed usa questi mostri che ti rendono la vita facile e ti fanno pure risparmiare".
Che ci vuoi fare? Il mondo è pieno di contraddizioni e questi sono solo due esempi fra le migliaia.
Poi, per carità, il buon sviluppatore integra tutto in un solo micro, risparmiando un euro che moltiplicato per le decine di migliaia fanno valore.
Fine O.T.

[stevetdr]

Ciao, io ci sto' lavorando su ma voglio usare solo software, pero' su una rivista di Nuova Elettronica di molti anni fa' avevo trovato lo schema di un "gestore" di encoder. Il numero del progetto e' il LX.1156 e permetteva di collegare un encoder ottico ad un altro dispositivo. Nel caso specifico un contatore up/down.
Il circuito e' utile perche' trasforma il segnale dell'encoder in due segnali su due pin.
Uno che fa' incrementare ed uno che fa' decrementare un contatore.
Ma se gestisci questi due pin con 2 pin di una porta "on change" secondo me con 2 righe semplici semplici ottieni il risultato.
Non so' come fare a postare un PDF e pertanto fammi sapere come posso informarti.
Un saluto
Stefano