My rotary encoder adventures

[Demon]

Very good, then there's plenty of margin.
Next challenge: Velocity sensing, ie a way to detect that the user wants the value to change by a lot and not have to turn the knob 600 turns. Getting that just right seems to be tricky, even the big boys don't always... (I've never tried). ...

That's exactly why I started looking up Elapsed Timer last night. I already have an idea in mind; rotate the encoder at 3 speeds, record the time elapsed between pulses, and then use that to determine if I increment/decrement by ones, fives or tens. I figure with some tweaking I can generate a decent compromise.

I've already adjusted my logic this morning to fall down to 359 when it goes below 0; to better simulate a heading gauge in flight sim, and inverse, flip up to 0 after moving up past 359.

... How will you transfer the count from one PIC to the other? ...

HSEROUT, that's why I had it in my early tests. It compares somewhat with LCDOUT timewise, maybe a tad slower.

I have a lot of R&D to go on that subject (like protocol and such).

... If needed, divide the LCDOutput routine in two (or more) parts if needed.

Nah, I have a LOT of controls to manage. I'm putting encoders as priority on a PIC, then switches and pots separately (ADC probably takes forever in comparison), and 4 LCDs wherever I have room and time available.

This is a preliminary layout; 3 enclosures: left, center and right . The right side has the most encoders with:

- 4 dual encoders
- 7 single encoders
- 1 mouse wheel (essentially a single encoder)

Those Custom Keys in the middle are just a reminder for a 4th optional enclosure at far left.





The thin red stripes are LED stripes; shielded towards the controls to simulate a red glow, like this: