non ho letto attentamente il posto, quidni forse l'avete già menzionata. ma nel playground non vi è una bella libreria per gli encoder? la visionavo giusto ieri, co sono pure tre metodi di applicazione, una iper precisa, una media e una un po imprecisa! dipende dall'uso!
se ho toppato il senso del post, scusate!
hai azzeccato in pieno, nella pagina c'è una piccola animazione dell'andamento dell'encoder e dei segnali generati... e il nostro caro niki77 sta sbagliando per quanto riguarda il rilevamento dell'andamento orario o antiorario.
In tutti i casi ti scusiamo z3us 
A parte il trovare la ruota tonda bella e che fatta (che spesso non dispiace), guarda quanto è bello ed interessante scambiarsi opinioni e studiare teoricamente le cose.
E' anche uno dei pochi, se non l'unico mio post, dove non si polemizza o si va OT !
Quasi non ci credo.
Comunque grazie mille della segnalazioni appena posso ci do un occhio per capire quanto è diverso come approccio da quello che stiamo utilizzando.
@lesto
Tornando a noi per ricavare i tempi avevo pensato di giocare a questo modo :
Interrupt 0 Rising e Falling su PD2 gestiti in questa maniera
le variabili che ricavano i timing sono volatile unsigned long
void interruptEncoderRising()
{
long currentmicros = micros();
// se capita durante l'overflow somma i microsecondi precedenti
if(currentmicros < tmp_micros)
{
pulse_intervall = ulongMaxVal - tmp_micros + currentmicros;
}
else
{
pulse_intervall = currentmicros - tmp_micros;
}
tmp_micros = currentmicros ;
if(PIND&3)
pulse++;
else
pulse--;
}
void interruptEncoderFalling()
{
long currentmicros = micros();
if(currentmicros < tmp_micros)
{
pulse_intervall = ulongMaxVal - tmp_micros + currentmicros;
}
else
{
pulse_duration = currentmicros - tmp_micros;
}
tmp_micros = 0;
}
Però come dicevi tu acquisire i dati cosi a muzzo, non serve a nulla, ci sarebbe da acquisire almento un migliaio di campioni e fare la media, ma soprattutto mi servirebbe di avere un motore che fà girare l'encoder ad un a velocità abbastanza costante, altrimenti serve a poco mi sà.
Quindi dovrei acquisire la media di mille campioni di una rotazione costante ad esempio di 1500rpm ?
Ma mi è venuto un dubbio ,na volta ricavati cosa ci faccio ?
lesto:
... e il nostro caro niki77 sta sbagliando per quanto riguarda il rilevamento dell'andamento orario o antiorario.
??? e perchè mai??
osserva ll'animazione nel link postato da z3us, cliccando sui due pulsanti e osserva l'andamento dell'impulso. ora sappi che una digitalRead (o sostituti) possono fare la loro lettura in una posizione a casto tra un "salto" e l'altro fatto dai pulsanti.
Il sistema di rilevazione deve basarsi sulla distanza temporale tra l'impulso 1 e l'impulso 2, per capire se avviene ----2--1----- opuure -----1---2------
No, non ho capito.
Io ho un interrupt quando 1 solo canale passa dallo 0 logico al 1 logico , pertanto se prendiamo in considerazione l'animazione del sito, puoi paragonare la generazione del mio interrupt NON alla singola pressione dei tasti dell'animazione, ma a QUATTRO, e se verifichi lo stato delle onde quadre quando quella del PIN1 (riferito all'animazione) passa dallo LOW ad HIGH vedrai che andando verso dx il segnale di PIN2 sarà sempre allo stato logico LOW, mentre invece andando verso sinistra, sarà sempre HIGH.
Questo significa che eventualmente gestisco CW e CCW all'esatto contrario di come stà illustrato li (ma vai anche a capire quale pin del mio rilevatore è A o B )che in questo momento mi interessa poco, ma la logica per capire la differenza di direzione è assolutamente corretta.
no. pariamo da 0 e dal codice encoder rotativo recuperato da mouse - #6 by niki77 - Generale - Arduino Forum
consideriamo pin1 come l'interrupt, ma RISING (al contrario del tuo codice che è a CHANGE)
giriamo in senso orario: quando hai una condizione di RISING (quindi il pin1 diventa da 0 a 1) se facessi una lettura istantanea dello stato pin leggeresti il pin2 SEMPRE a 0.
con una digitalRead, vedresti sempre 0 a basse velocità, e 1 ad alte velocità. ma non è questo che ci interessa (anzi costituisce un problema)
prendiamo il caso ideale (lettura istantanea o quasi), e quindi le due letture non saranno mai 1 e 1, e quindi non succede nulla
In senso antiorario avresti il contrario: leggeresti sempre 1 e 1.
ora, stessa situazione ma interrupt a CHANGE, lettura istantanea (o quasi)
in senso orario leggeresti 1,0 (quando sale) e 0,1 (quando scende) (quindi non viene fatta nessuna lettura valida)
in senso antiorario avresti 1,1 (quando sale) e 0,0 (quando scende) (lettura valida solo in salita)
...ma usare pulsein no? 
qui ci sono delle informazioni molto interessanti sui "tempi" di lettura dei pin e degli interrupt.
http://arduino-pinchangeint.googlecode.com/files/PinChangeInt%20Speed%20Test-1.3.pdf
se guardate qui, in fondo a tutto, ce n'è un riassunto:
http://arduino.cc/playground/Main/RotaryEncoders
lesto:
no. pariamo da 0 e dal codice encoder rotativo recuperato da mouse - #6 by niki77 - Generale - Arduino Forum
consideriamo pin1 come l'interrupt, ma RISING (al contrario del tuo codice che è a CHANGE)giriamo in senso orario: quando hai una condizione di RISING (quindi il pin1 diventa da 0 a 1) se facessi una lettura istantanea dello stato pin leggeresti il pin2 SEMPRE a 0.
con una digitalRead, vedresti sempre 0 a basse velocità, e 1 ad alte velocità. ma non è questo che ci interessa (anzi costituisce un problema)
prendiamo il caso ideale (lettura istantanea o quasi), e quindi le due letture non saranno mai 1 e 1, e quindi non succede nullaIn senso antiorario avresti il contrario: leggeresti sempre 1 e 1.
ora, stessa situazione ma interrupt a CHANGE, lettura istantanea (o quasi)
in senso orario leggeresti 1,0 (quando sale) e 0,1 (quando scende) (quindi non viene fatta nessuna lettura valida)
in senso antiorario avresti 1,1 (quando sale) e 0,0 (quando scende) (lettura valida solo in salita)
Mhh, non ne sono convinto... o non ho capito esattamente cosa intendi...
Adesso gioco un pò con quello che abbiamo visto oggi e poi vi faccio sapere.
Per ora grazie mille del supporto.
Ahhhh, ma tu lesto ti riferivi al primo codice postato, no ma quello era fallosissimo e piu o meno lo sapevamo.
Io sostenevo che le modifiche fatte in seguito, spostando l'evento sul rising e leggendo direttamente il registro del pin era corretto.
Infatti lo è, perlomeno per quanto l'ho potuto provare.
Infatti le ultime prove effettuate hanno visto il mio encoder leggere ben oltre 3000 rpm.
C'erano un po di problemini che ho dovuto sistemare, ma ora è perfettamente funzionante.
Il primo problema che ho scoperto e risolto era che le resistenze di pull down erano di valore troppo alto ed eviedentemente come hai detto tu ad alta velocità il fototransistor non riusciva a commutare perfettamente e arduino non rilevava più la transizione.
Il secondo problema rilevato una volta collegato l 'encoder al motore pare sia legato al fatto che l'encoder era fortemente disturbato dal motore. Per risolvere questo problema ho messo una cinghia e ho spostato l'encoder.
Ora impostata una velocità il controller tenta di tenere il motore alla velocità costante,ma ho notato che la regolazione inizialmente era abbastanza scontrosa, e giocando un po coi parametri del id ora èdiventata molto più fluida, ma mi piacerebbe approfondire l'argomento...
Il pdf e molto interessante, domani lo leggo per bene.
Per i pid e un po magia nera 
Se conosci derivate e integrali puoi capirci qualcosa
Per i pid sento il mio amico (google)
I documenti sono veramente interessanti,
Se non ho capito male testano il tempo che passa da quando viene variato lo stato della porta (in vari modi, diretti o tramite funzione) e quando viene generato l'interrupt ?
Nella migliore delle ipotesi (PinChangeInt-1.1) arrotondiamo a 25us avremmo un F max di
1000000us / 25us = 40000 circa cicli al secondo
Applicando il tutto al mio encoder messo in modalità che legga solo 44 transizioni a giro posso gestire
40000 / 44 = 909 c.a. rivoluzioni al secondo = 54545 RPM 
(sempre ammesso che a quella velocità l'encoder legga , ma soprattutto non si sciolga come neve al sole)
C'ho preso ?
esatto