Thank you. I would appreciate that, but I think that will work only if there is no complete cycle between two reads, so it is potentially a possibility to get wrong position.
I will try experiment more with timer counter interrupts to see if 0 -> 0xFFFF and 0xFFFF -> 0 situations. I will appreciate if you can share your code so I can take it as a reference. Best regards, Petro On Thu, Jan 13, 2022, 4:26 PM Nathan Hartman <hartman.nat...@gmail.com> wrote: > On Thu, Jan 13, 2022 at 8:19 AM Petro Karashchenko < > petro.karashche...@gmail.com> wrote: > > > Hi, > > > > I've been working to add SAMv7 Qencoder interface and see that Qencoder > > driver expects QEIOC_POSITION to be int32_t value. The issue is that > SAMv7 > > has 16 bit timer counter interface and the SW extension to 32 bits (by > > adding adding or subtracting UINT16_MAX+1 when counter matches 0xffff) > does > > not seems to work reliably because sometimes pulses are incremented / > > decremented not by 1 by the HW. > > > > The question that I have is whether the Qencder position is expected to > > count to negative values "INT16_MIN, ..., -2, -1, 0, 1, 2, .. INT16_MAX" > or > > position can be in range "0 ... UINT16_MAX" or there are not strict > > requirements? > > > > Best regards, > > Petro > > > > Correct; you can't rely on that. > > > > I don't know at the moment whether the position is expected to be signed or > unsigned, but I have code somewhere to extend precision from 16 bit to 32 > bit. If I remember correctly it always saves the previous reading. Each > time it samples the encoder it subtracts the old from the new. If > 0x7fff > it subtracts the complement, otherwise it adds the value, to a 32-bit > variable, which is used as the counter. Let me know if you need me to find > the code. > > Hope this helps, > Nathan >
