Ik heb een rotary encoder hier. Deze geeft op 2 aansluitingen pulsjes af welke op 90 graden van elkaar zijn verschoven:


A     ---     ---     ---
     |   |   |   |   |   |
  ---     ---     ---     ---

B -     ---     ---     ---
   |   |   |   |   |   |   |
    ---     ---     ---     ---

Deze pulsjes komen met een frequentie van maximaal 400.000 Hz binnen. Ik heb uitgerekend dat ik een 3 bytes getal nodig heb het aantal bij te kunnen houden.

Als ik een verandering zie, moet ik eerst kijken of er 1 op-of afgeteld moet worden. Zodra ik dat weet moet er dus een rekenbewerking voor 24 bits gedaan worden.

Eerst dacht ik dat met een PIC te doen. Maar gezien de snelheid waarmee de pulsjes binnenkomen, kan een PIC op 40 of 48 MHz dat nauwelijks aan.

Mijn vraag is dan ook of het (zonder al te veel componenten ) mogelijk is om zo'n tellerschakeling met de 4000, 74HC of 74F serie op te bouwen.

Dat is niet het zelfde onderwerp, maar ik heb wel dat onderwerp gevolgt.
Daarin heb ik niet geantwoord omdat ik niet wist welke kant de TS heen wilde.

Zijn oplossing is ook wel te doen in een uC omdat hij met 10.000 pulsjes per seconde heeft.
Bij mij is dit ruim een factor 10 hoger.

Ik wil mijn encoder alleen als teller gebruiken. Het heeft geen terugkoppelende functie voor de motoraansturing zelf.

Klein PLC'tje? Er zijn ook speciale IC'tjes voor. Free_electron had er in een ander topic enkele opgesomt.

[Bericht gewijzigd door GJ_ op ]

die encoder chip van agilent bijvoorbeeld kan dat perfect aan. en anders een hardware counter bouwen. ene fase is de clock de andere fase geeft aan of het up down is. met ene paar up-down counters kom je er wel. dit is nu echt eens iets om in een kleine goedkope altera te prammen. ( eentje met 44 pootjes ) beetje prul logica , de teller en een readout circuitje. je kan het tekenen met ttl ictjes in quartus ( de ganse 74xx reeks zit erin als macrocellen. open de schema editor teken het simuleer het en vlam het in de altera. klaar is kees. als ik 2 seconden heb vandaag teken ik het wel even. )

Een kleine CPLD van Xilinx of Altera is hier perfect voor als tellertje, hoe breed wil je hem laten tellen?

Een kleintje kun je zo bij futurlec bestellen voor een paar dollar.

Op 11 december 2005 15:23:30 schreef Onbekend:
Eerst dacht ik dat met een PIC te doen. Maar gezien de snelheid waarmee de pulsjes binnenkomen, kan een PIC op 40 of 48 MHz dat nauwelijks aan.

Lijkt me echt iets voor een SX op 75 MHz.

klaar : hier staat ie

http://expand.xs4all.nl/uploadarchief/download.do?file=updown.zip

synthetiseerbaar in een altera 7064 zonder problemen.

in 2 uitvoeringen ( 24 bit en 32 bit . de 32 bit moet in een 7128 )

hoe werkt ie:

PHASE A en PHASE B komen van je encoder. niks speciaal dus
RST : als je die laag maakt dan zet je de tellerstand op nul
D0..D7 dit is de databus
A0 en A1 zijn een adress bus
RDn en WRn zijn actief lage read en write strobe

bijvoorbeeld


A0 A1 RST RDn  WRn  output
0  0  1   1    1    tri-state
0  0  1   0    0    tri-state ( er gebeurt niks )
0  0  1   0    1    lezen laagste 8 bit
1  0  1   0    1    lezen middenste 8 bit
0  1  1   0    1    lezen hoogste 8 bit
1  1  1   0    1    allemaal 0 ( bij 24 bit ) of 
                    allerhoogste 8 bit (bij 32 bit
                    uitvoering)
0  0  1   1    0    zet hier de data voor laagste 8 bit
enzovoort

je kan dus een tellerstand laden in de counter via de WRn en de databus.

kheb hem niet gesimuleerd maar volgens mij werkt ie wel.
Het enige wat je rest is de pin assignment en de fusemap synthetiseren. Quartus kan je downloaden op www.altera.com

Zo, dat is snel.
Ik zal dus toch een beetje de FPGA, SPLD en CPLD kant in moeten duiken.

@free_electron: Ik de komende dagen de code bekijken. Misschien moet ik toch eens gaan stoeien met een paar Altera chips.

Met een CPLD kan natuurlijk, net zoals met wat up-down counter TTL of CMOS chippies. Heb je trouwens 400.000 flanken of pulsen per seconde? (100.000 pulsen is 400.000 flanken).
Volgens mij moet je dat kunnen halen met een 18F PIC. Met een 16F pic haal ik al 100.000 ints/sec bij het decoderen en in mijn ervaring is het 5* zo snel op een 18F.

24 bit berekenen , 400k ints per seconden.

ik denk dat voor je 3 byte te processen ( je moet carry en borrow etc doen je toch een 80 tal instructies zult nodig hebben ..
das 24 mips ... ik denk niet dat die pic dat haalt ( vooral niet als ie ondertussen nog iets anders moet doen ook .. en wat als je int handler een puls mist ? ik zou voor de hardware oplossing gaan

Op 13 december 2005 00:13:02 schreef free_electron:
24 bit berekenen , 400k ints per seconden.

ik denk dat voor je 3 byte te processen ( je moet carry en borrow etc doen je toch een 80 tal instructies zult nodig hebben ..

Ja, meneer electron, als jij je nu met de hardware bezighoud doe ik dat wel met de software :)
Ik doe een 24bit increment/decrement in 4 cycles, niet in 80.

Ik heb even mijn decoder code van de 16F naar de 18F gehaald en bij gebruik van een 7474 (D-flipflop) om up- en down pulsjes te genereren is de hele interruptroutine 14 cycles, met een 10MHz kristal dus 1.4 microseconde. Bij 100k pulsjes/sec dus peanuts en zelfs met 400k pulsjes heb je nog bijna de helft van je cpu cycles over voor je user programma. Daarom vroeg ik ook over het om 400.000 pulsen of flanken per seconde ging.....

hehehe . ik ben geen software guru. dit is ongeveer wat ik er van zou bakken


   ; PROCEDURE ROTENC_INT (START)
          CLR   0A8H.7
          MOV   C,P10
          CPL   C
          JC    DECR
          INC   X
          MOV   A,X
          JNZ   DONE
          INC   Y
          MOV   A,Y
          JNZ   DONE
          INC   Z
        DECR:
           DEC   X
           MOV   A,X
           CJNE  A,#0FFH,DONE
           DEC   Y
           MOV   A,Y
           CJNE  A,#0FFH,DONE
           DEC   Z
        DONE:
           SETB  0A8H.7
           RET  

das toch 20 instructies. machinecycles zal rond de 30 zijn ( sommige instructies gebruiken 2 cycles ) en we hebben ook nog niet de interrupt overhead bekeken ( de cpu heeft ook tijd nodig om te springen )

x,y en z zijn bytes. ik moet dus alle berekeningen zelf doen vor multibyte incrmeent decrement ( ik gebruik een 'domme' 8 bit processor.

Op 13 december 2005 11:45:03 schreef JoWi:
[...]
Ja, meneer electron, als jij je nu met de hardware bezighoud doe ik dat wel met de software :)
Ik doe een 24bit increment/decrement in 4 cycles, niet in 80.

Dan doe je iets fout denk ik. Je hebt 2 signalen en daar moet je hoe dan ook rekening mee houden. En een 24bit inc/dec in 4 cycles mag je mij even uitleggen, zeker met een A/B signaal, alhoewel 80cycles mij ook wel wat aan de ruige kant lijkt.

----edit------------------------
hr. _electron was me voor.

Op 13 december 2005 18:57:42 schreef GJ_:
Dan doe je iets fout denk ik.

Vooruit dan, de complete interrupt handler voor een 18F PIC bij gebruik van een 74LS74 (dan krijg je op de ene uitgang een puls "stap omhoog" en op de andere een puls bij "stap omlaag". Zoek de Microchip Appnote maar op in die andere thread over rotary encoders. Ik hang de uitgangen van die flipflops aan RB1 en RB2, die genereren een INT1 en INT2 interrupt.

	ORG	ISRH_V			; Interrupt vector location
INTERRUPT	btfsc	INTCON3,INT1IF	; Rotary encoder,  increment value
		 bra	_iIncFreq

		btfsc	INTCON3,INT2IF
		 bra	_iDecFreq	; Rotary encoder,  decrement value

					; other int.


_iIncFreq	movlw	.0
		incf	Freq,F
		addwfc	Freq+1,F
		addwfc	Freq+2,F
		bsf	E_FreqChanged	; Notify MAIN code that the frequency has changed
		bra	_iDone

_iDecFreq	movlw	.0
		decf	Freq,F
		subwfb	Freq+1,F
		subwfb	Freq+2,F
		bsf	E_FreqChanged	; Notify MAIN code that the frequency has changed

_iDone		retfie	FAST		; return from interrupt

Als je hem uittelt kom je op 12 cycles + 2 voor de interrupt overhead, dat is dus 14 cycles.
En dan heb ik nog een cycle over omdat ik de main code signal met een status vlag.

Voor een ruimhartige vergoeding wil ik wel cursussen "advanced assembly" organiseren :).

Ik programmeer trouwens bijna 30 jaar en ben gewend om de laatste cycle uit een 2 MHz 6800 of weet-ik-wat te trekken. Dat soort stunts leer je als je image processing probeert te doen op micros/minis uit de jaren 70 en 80. Iedereen is gewoon verwend door die 1 Gig+ PC's en heeft geen flauw idee wat er achter die toetsen en beeldscherm gebeurt, maar het blijft leuk om een stuk code van een collega 10* zo snel te maken door het juiste algoritme en optimale codering te gebruiken.

Aha, 14 cycles, ik dacht 4.
En die 6800 ken ik ook nog wel. Wij gebruikten in die dagen de eurocom1 van Manudax. Daar zat een 6802 in en moest je programmeren via het "opgebouwde" hex keyboardje: mnemonics waren toen nog ongehoorde luxe.

[Bericht gewijzigd door GJ_ op ]

Op 13 december 2005 20:31:39 schreef GJ_:Aha, 14 cycles, ik dacht 4.

De in- en decrement gaan in 4 cycles, maar dat had ik ook beweerd, lees het postje anders nog maar eens door.

Ja, nu zie ik het, niet goed begrepen.
Maar het programma mag dan verder toch niet al te groot zijn. Die PIC gaat echt niks harder dan 10MIPS.

Voor een ruimhartige vergoeding wil ik wel cursussen "advanced assembly" organiseren :).

maar dan wel op een deftige processor ( Geen RISC prullen en geen Von Neumann krengen zoals motorolie's.) :)

alle gekheid op een stokje. jij kan direct registers manipuleren, ik moet door de accumulator.
dus dan is de code ongeveer gelijk, op 1 ding na: ik sampel een input in mijn int handler , jij gebruikt 2 interrupts.

tis ook een manier om het op te lossen. andere cpu andere instructieset.

Die cursus sla ik liever af. Ik stop die encoder net zo lief in een low-budget PLC'tje.

Op 13 december 2005 20:52:58 schreef free_electron:
maar dan wel op een deftige processor ( Geen RISC prullen en geen Von Neumann krengen zoals motorolie's.) :)

Die dingen moet je niet in assembly meer willen optimaliseren. Hebben bijv. 3 integer en een 2 f.p pipes parallel, cache hits/misses, aligned/unaligned fetches, stallen van de pipes en weet ik niet wat. Laat ik fijn aan een compiler over :-)

Op 13 december 2005 22:03:48 schreef JoWi:
[...]Die dingen moet je niet in assembly meer willen optimaliseren. Hebben bijv. 3 integer en een 2 f.p pipes parallel, cache hits/misses, aligned/unaligned fetches, stallen van de pipes en weet ik niet wat. Laat ik fijn aan een compiler over :-)

hahaha ja die zeker niet . tegen dat je itgevlooid hebt hoe je de cahce controleert en wat je in welke pipe stopt moest het ontwerp al in productie zijn

ik had het natuurlijk over de goede 'oude' intel 8051 :p cpu.