silly me i had the dir var as byte, it now works with this added change
' Encoder.0 = Ch_A
' Encoder.1 = Ch_B
encoder =(porta&48)>>4
reading the pins individually wont work for me @32mhz
silly me i had the dir var as byte, it now works with this added change
' Encoder.0 = Ch_A
' Encoder.1 = Ch_B
encoder =(porta&48)>>4
reading the pins individually wont work for me @32mhz
Warning I'm not a teacher
I made that exact mistake initially, hence the comment where the DIR variable is declared - yet I missed it when looking at you code...
I wonder why reading the pins individually doesn't work in your case. I only did it that way because CuriousOne wanted to be able to have the signals placed arbitrarily. I suspect though that reading them individually might be faster than masking and shifting.
I've been playing around with the math to go from encoder counts to actual frequency and I'm down to 110 cycles for calculating and stuffing the bits into the array. Had to resort to a tiny bit of ASM, getting the high word of a 16*16bit multiplication back from PBP without resorting to actually using LONGs.
encoder=0
![]()
Warning I'm not a teacher
Had to resort to a tiny bit of ASM, getting the high word of a 16*16bit multiplication back from PBP without resorting to actually using LONGs.
did you and dt make this ? , i use it if req
;32 bit multiply result
A32bitVar var word[2]
Dummy var word
ASM
GetMulResult macro Dword
MOVE?WW R2, Dword ; Low Word
MOVE?WW R0, Dword + 2 ; High Word
endm
ENDASM
Dummy = 1000
Dummy = Dummy * Dummy
@ GetMulResult _A32bitVar
Warning I'm not a teacher
Thanks, hadn't seen (or did not remember seeing, certainly can't take credit for it) that macro but that's pretty much what I did except I copied the value byte-by-byte instead of using the MOVE?WW macros.
Henrik,
I tested your last code with a mechanical quadrature encoder and works just fine with a couple of 100nF debouncing capacitors and internal pull ups of the PIC.
I noticed though, a jump on the position variable due to mechanical problem of the encoder. Say you are at the beginning with position at 0. One click on the right increments to 4 and one to left gets back to 0. Sometimes due to little more movement of the axis of the encoder you may get a 65535 then back to 0. This of course is not a software problem, rather a pure mechanical, but a user may perceive it as a program error.
Ioannis
Yes, it's because your particular encoder has 4 counts per detent and, as you say, sometimes it will "overshoot" the detent slightly causing the code register one count before it "springs back" into the detent position. The important thing is that the code DOES register it "springing back" so that it doesn't lose position.
These mechanical encoders exists with either 4 counts (one quadrature cycle) per detent or 1 count (1/4 quadrature cycle) per detent. Using 1x decoding with an encoder that has 1 count per detent means you'd have to turn it 4 clicks for each increment. However, with the type of encoder you have using 1x decoding might be better.
Absolutely agree. Code works as expected and is fast enough for manual rotation. Have not tested for faster resposne.
The encoder indeed has a detent that produces 4x pulses so yeah. It is not appropriate for that code.
Ioannis
Bookmarks