 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Rotary encoder interrupt issues
  Page 2 of 2 |
|||||
| Author | Message | ||||
| Volhout Guru  Joined: 05/03/2018 Location: NetherlandsPosts: 4923 |
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 KingdomPosts: 73 |
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 KingdomPosts: 73 |
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: NetherlandsPosts: 4923 |
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 KingdomPosts: 1193 |
 Some line receiver options: AM26LS32 SN75175 MC3486 |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1193 |
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 KingdomPosts: 1193 |
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 |
||||
| Andy-g0poy Regular Member Joined: 07/03/2023 Location: United KingdomPosts: 73 |
Many, many, thanks for this, I've now tried it on the large encoder I have and it works very nicely. The only "problem" is that it's giving 400 counts per rev rather than 100 That should be fixable. The jump table seems to be giving 4 increments per cycle so maybe a tweak there will do the job, but that's for later. What I have found which is probably working as designed, is that the PIO assembler does not accept variables or pin numbers, it seems to only use the GPxx format. I found this out when I changed the pin assignments from GP0 and GP1 to GP14 and GP15 which the breadboard was already wired to. I ended up having to find and replace the GP0's and GP1's with 14 and 15, which makes the code slightly awkward to move to different pins. Is this the expected behavior? I'm using: PicoMiteRP2040V6.00.00RC1.uf2 Andy |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4923 |
Pio only knows gp numbers, not pin numbers. The actual gp numbers are in the pio Pinctrl configuration. The pio state machines use offsets from the gp number in the config. PicomiteVGA PETSCII ROBOTS |
||||
| Andy-g0poy Regular Member Joined: 07/03/2023 Location: United KingdomPosts: 73 |
Thanks, I'll stick to GP numbers then. Andy |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1193 |
That's what quadrature is. |
||||
| Andy-g0poy Regular Member Joined: 07/03/2023 Location: United KingdomPosts: 73 |
It's sold as a 100 pulse per rev, but I suspect that you are correct and what they actually mean is 100 "clicks" per rev. Multiple choices really, either divide the output by 4 or knock out three of the increments etc. Another option is to not treat it as a quad. encoder and just look at the state of the two lines when A is positive then B gives you the direction. As there is no bounce with these things that should be more than good enough for a simple tuning control. Whatever it will be good PIO practice to have a play with. Andy |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 1193 |
Yes, there are physically 100 pulses per channel and the 2 channels are 90 deg out of phase. Quad-decode counts the rising and falling edges to provide direction and X4 multiplication. This is a wonderful development for the PicoMite as I now have a product that has no equal. High performance, closed-loop servo motion control with user-programmable sequencing. Modern motion control has, IMO, taken a retrograde step in that; axis feedback is as far away from "the action" as it can get....on the back of the motor. I don't care about the rotor angle, I care about the true position of the axis and so I always install two encoders/axis. I have the motor encoder for primary feedback and a load encoder for true position. It used to be that the motor was fitted with a tach-generator for velocity control and the position feedback came directly from the load. On a typical modern machine, the motor can be decoupled and left to spin freely and the control system would still believe that the machine is actually moving  With the PicoMite, we can handle 4 encoders which not only facilitates dual-loop feedback but one could also tap-off the encoder feedback from other axes (other PicoMites) for perfectly synchronized electronic gearing (which I use all the time) Exciting times  Edited 2024-11-27 16:56 by PhenixRising |
||||
| Page 2 of 2 |
|||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
