TheBackShed.com

Forum Index : Microcontroller and PC projects : Rotary encoder interrupt issues

Page 2 of 2

Author

Message

Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 4222

Posted: 10:17am 05 Nov 2024

Copy link to clipboard

Print this post

PhenixRising said
Just thinking about this though; I run a program, stop it, make a code change, re-run the program and the encoder-count is preserved from the previous version.

Hi Phenix,

Don't count on that to work. It is not good practise to start a PIO program with registers in a unknown state. Therefore I am sure these will be reset to a known state, either by the SDK or by PM (Peter Mather), else by me.
If you want that you will have to pre-load a value through FIFO.

PicomiteVGA PETSCII ROBOTS

Andy-g0poy
Regular Member

Joined: 07/03/2023
Location: United Kingdom
Posts: 56

Posted: 10:26am 05 Nov 2024

Copy link to clipboard

Print this post

Volhout said @Andy,

I looked at your original code, and I think it could be optimized to work better.
In MMBasic you can set an interrupt on a pin. If you set that for interrupt going high on clock, you do not need to check the clock being high in your interrupt routine.

...

Regards,

Volhout

Yes, I have tried that same issue more or less.

That code is a hangover from yet another test where I was trying a polling system rather than interrupt. I even cranked up the clock speed. That made a slight difference but not enough. I think it's going to be PIO code that solves the problem. At least it's looking easier every time I run through the code.

I'll have a go at coding your examples in the explaining PIO series which should get me going.

Thanks again,

Andy

Andy-g0poy
Regular Member

Joined: 07/03/2023
Location: United Kingdom
Posts: 56

Posted: 10:38am 05 Nov 2024

Copy link to clipboard

Print this post

PhenixRising said

It might be that your 1000 pulse encoder has complementary outputs (A, -A, B, -B) for better noise immunity. I use the MC3486 line receiver to interface to the MCU.

The 1000 pulse encoder has the same outputs as the control knob version in the image A , B and the complimentary outputs as well. The control knob version mentions a AM26LS31 which is an RS422 driver, I can't 100% confirm that as I did not take the encoder apart that far and of course the electronics were on the reverse side of the main PCB :-)

It would not surprise me if the 1000 pulse shaft encoder used the same. There is no index pulse on either of the devices, so one less thing to worry about :-)
The intended use for these things is tuning controls for radio use. SI5351 VCO etc.

Andy

Volhout
Guru

Joined: 05/03/2018
Location: Netherlands
Posts: 4222

Posted: 11:07am 05 Nov 2024

Copy link to clipboard

Print this post

Andy,

Since the start of the PIO series training, there has been one change in MMBasic that is important to remember:

In this training

PIO(EXECCTRL 0,a,b)

is used. The 0 designated the GP0 pin, but that was inconsistent with the rest of MMBasic that use either pin numbers or GPx identification. To enforce the use of GP0 (or any other GP pin) with 5.08.00 and newer the "GP" is required.

The user manual states correctly that you should use

PIO(EXECCTRL GP0,a,b)

But the early examples in the training may still use the "0" without "GP".
This is only with PIO(EXECCTRL )

Volhout

PicomiteVGA PETSCII ROBOTS

PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 856

Posted: 11:11am 05 Nov 2024

Copy link to clipboard

Print this post

Quote AM26LS31

Some line receiver options:
AM26LS32
SN75175
MC3486

PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 856

Posted: 11:23am 05 Nov 2024

Copy link to clipboard

Print this post

Volhout said

Hi Phenix,

Don't count on that to work. It is not good practise to start a PIO program with registers in a unknown state. Therefore I am sure these will be reset to a known state, either by the SDK or by PM (Peter Mather), else by me.
If you want that you will have to pre-load a value through FIFO.

Yeah, not a good idea to take risks with axis positions

Just been testing though; I set an encoder position register (12345), load and run a completely different program (no PIO stuff), re-load the quadrature program and interrogate the position register and it still holds the same value.

I guess we could store the current value in a tempVar, load the other PIO code, read the position register and compare it with tempVar.

PhenixRising
Guru

Joined: 07/11/2023
Location: United Kingdom
Posts: 856

Posted: 10:43am 20 Nov 2024

Copy link to clipboard

Print this post

PhenixRising said @Volhout

Hi Harm. I don't know if this is feasible but; apart from the A & B signals, there can also be a third "Index" signal (can be "C" or "I" or "Z"). This pulse occurs once/revolution and is used for accurate referencing (homing).

Currently, I have this triggering an input-interrupt and just like most CNC machines, the homing routine has to turn the motor very slowly to register a consistent home position.

The reason that other controllers have to do this slowly is because they only read the encoder during a PID update which is typically a 1KHz loop. So as per Nyquist, it's typical to use something like 250 quad-counts/sec homing speed (painful when 360° = 10,000 counts)

My PicoMite uses an interrupt which responds fast enough that I don't need to be so slow BUT...

It would be super-cool if this could be handled by the PIO where the main counter is set to zero (or a preset value) due to an index pulse transition.

Enable_Index_Reset = True

Hey Harm. I have this figured. If I configure this input as CIN, I don't need to worry about interrupt latency. When CIN > 0, I just slowly reverse until the CIN value doubles

Page 2 of 2

Print this page

To reply to this topic, you need to log in.