Encoder library modifications

SteveA · May 4, 2023, 6:05pm

I am using a standard industrial rotary encoders, which I use with my RPI and Microchip project. I am slowly changing to use Pico W as I am finding it a remarkable unit.

I respectfully wonder if the UF2 library could be altered to match standard type encoder routines. I will try to explain having looked at the encoder source in uf2 1.20.1. The encoder setup is:

Encoder::Encoder(PIO pio, uint sm, const pin_pair &pins, uint common_pin, Direction direction,
float counts_per_rev, bool count_microsteps, uint16_t freq_divider)

The uint common_pin setup is not needed as the common pin of an encoder really ought go to 0v. This setup is wasting a valuable and precious GPIO pin on the pico for no purpose whatsoever.

Presumably that common pin setup is to be used to alter the polarity of the ‘common’ pin (changing the pin from 0v to Vcc) so as to effectively alter the direction of rotation. If so, this pin change is not needed as all that is needed is to swap over the ENC_A and ENC_B pin definitions, which alters the rotation direction from CW to ACW.

Then the ‘Direction direction’ setup is not needed as the direction will have been decided by the ENC_A/B pin definitions and in any event the direction init value cannot be re-entered and re-inited whilst running.
On a typical industrial encoder with multiple micro pulses per click, using the bool count_microsteps setup value of False you will get 2 steps counts per mechanical indent click and when using a value of True you will need to do 2 mechanical indent clicks to get a step count of 1.

This count_microsteps setting does not allow you to achieve 1 step count per 1 mechanical indent click, which is usually what the end user wants.

To easily achieve that with any make of encoder, the setup could to be changed to uint16_t microstep_divider (and you can enter eg 2 or whatever value to suit the model of encoder). The routine should read every micro step all of the time and divide those micro steps by this entered value, eg 2 (which will then give a step of 1 per click), so that any encoder (some have 1, 2, 4, 8, etc, micro steps per 1 mechanical click) can actually be setup to output 1 step count per 1 mechanical click.

I am not sure who supports these excellent encoder and other library routines and hope this feedback is taken as it is meant, to be constructive because the pico with the Pimoroni add-ons is a very powerful device, however it has precious GPIO which ought not to be wasted.

if this library was able to be changed a GPIO would be saved and any encoder with differing micro steps could be used in industrial projects.

Thanks for looking

SteveA · June 24, 2023, 12:36pm

Hello Support

I see that there has been no response to this post and so wondered if it had been seen.

In order for me to try and update/optimise the encoder code is there a tutorial on how to build UF2 files on a Windows PC? I have repeatedly tried following the documentation to get the pico SDKs installed under windows, but sadly my setup keeps failing. I think it may be because I already have Visual Studio and Visual Studio Code installed for use in other projects and the pico SDK installer changes/corrupts an existing installation.

If I could do that, I may be able to incorporate my encoder routines.
Thanks for any tips.

Tonygo2 · June 25, 2023, 7:55am

Have you seen this driver?

It uses GND so does not waste a pin.

SteveA · June 25, 2023, 9:44am

Thanks @Tony for the link. However, when I use this driver (which is good), it requires 2 additional files being stored on the Pico W, which, although small, uses up more precious storage space. I was hoping the Pimoroni UF2 could be altered accordingly because that UF2 is already loaded in without any more driver files needed to be added and use up space.

As I mention, every encoder common line goes to Gnd (or can go to +Vcc) hence no need to specify/waste a pin. The direction is simply altered by changing over the EncA/B lines or the pin definitions, so that setup part can be removed and saved. The final request was to always count the microsteps (without the need of the boolean flag to turn on/off) and in its place use a single divider parameter to enter a value such as 8 - so that when the encoder pulses out 8 microsteps per mechanical click (as some do, depending on their quality) the output count will then be 1 per 8 micosteps. This then allows any encoder (1, 2, 4, 5, 8, 10, etc microstep version) to be used so as to get an output count of 1 per mechancial click.

hel · June 26, 2023, 8:41am

You’re probably best opening an issue on Github (or, even better, a pull request…) if you have suggestions for how our encoder libraries can be improved.

I did a quick tutorial on how to compile / build for Pico using WSL here:

Another low effort way to compile/build is by forking our repo on Github and using Github Actions, as Iestyn did here:

SteveA · June 26, 2023, 3:18pm

Thanks @hel. I have just posted on Github as suggested. I have not tried that before and so will see what happens. It is at

github.com/pimoroni/pimoroni-pico

Encoder library modifications in UF2

opened 03:10PM - 26 Jun 23 UTC

steverpi

I use a standard and industrial rotary encoders in my RPI and Microchip projects… and I am now slowly changing everything over to using the Pico W from Pimoroni, which I am finding is a most remarkable device. Could the encoder library in the UF2 be modified to be similar to other encoder routines. I will try to explain the changes and the reasons for them. Having looked at the encoder header source in uf2 1.20 onwards, the current encoder setup is: Encoder::Encoder(PIO pio, uint sm, const pin_pair &pins, uint common_pin, Direction direction, float counts_per_rev, bool count_microsteps, uint16_t freq_divider) 1. The 'uint common_pin' setup is not needed as the common pin of an encoder really ought go to Gnd/0v. This setup is wasting a valuable and precious GPIO pin on the pico for no purpose whatsoever and also wastes a small amount of code space. Presumably that common pin setup wss to be used to alter the polarity of the ‘common’ pin (by changing the pin from 0v to Vcc) so as to effectively alter the direction of rotation. If so, this pin change is not really needed as all that is needed to change direction is to swap over the ENC_A and ENC_B pin definitions, which alters the rotation direction from CW to ACW. 2. The ‘Direction direction’ setup is then not needed as the direction will have been decided by the ENC_A/B pin definitions and in any event the direction initial value cannot be re-entered and re-inited whilst running, so it is not needed. Again remove it to save code. 3. Typical industrial encoders have many microstep pulses per mechanical click (usually the more costly the encoder the more the number of microstep pulses per click, eg some have 4, 6, 8) Remove the 'bool count_microsteps' setup and in its place change it to 'uint8_t microstep_divider' and in this setup you enter the number of microstep pulses which the particular encoder model produces per mechanical click (eg 4). The encoder routine should read every microstep all of the time as normal and divide those microsteps by this entered setup value, eg 4. Output the integer count and this will then give a an encoder output count of 1 per mechanical click, rather than 4 counts as is the case at the moment. This will allow any the encoders with 1 to 255 microsteps to be simply used. (and if you still wanted every microstep, irrespective of the mechanical clicks, just enter a value of 1 into this setup). 4. Keep an internal flag for rotation, CW or ACW. If the last rotation was say CW and the new rotation is also CW, output the counts as normal. However if the rotation was say CW and the new rotation changes to ACW, do not output any change, ignore it and just alter this flag to ACW, ready for the next movement , which will presumeably be ACW, ie the same as last and so now output a change as normal The reason for this change of direction trap to ignore the first instance of a change of direction is because in a critical application, if the encoder contacts encountered a glitch it could appear as a change of direction. This modification removes that happening and will only output when the last movement (whenever it occurred) was in the same direction. Conclusion: if this library was changed a GPIO would be saved, any encoder with differing micro steps could be used in industrial projects and a potential glitch could be prevented.

Also, thanks for the steps on how to use a Windows PC with pico SDK. I will try them again - especially the WSL option. The last time I went through the steps of using VS Code on a PC many months ago, I failed miserably. Better luck this time with WSL!