On 04/25/2020 06:11 AM, andy pugh wrote:
On Sat, 25 Apr 2020 at 04:21, Jon Elson <[email protected]> wrote:
I immediately saw there were problems handling conversion to
scaled position.
I expected problems with the sign-extend/rollover of the
24-bit hardware encoder
I might have already fixed the encoder rollover.
git checkout git checkout origin/andypugh/ppmc_fix
OK, so there's two parts. One is to handle the sign
extension/rollover of the 24-bit hardware encoder
to 32-bits. What I'm seeing so far (on 2.7.14) is that that
IS working. But, then the 32-bit value
is placed into a presumably 64-bit signed integer, while the
upper 32-bits are allowed to
stay at zero. So, minus numbers don't work.
There are two ways to go. One is to make the extended
32-bit value explicitly 32-bits, as in
int32_t. And, the existing code would just work fine,
within its limits, incrementing and decrementing the
uppermost byte. The other way is to handle it fully as a
64-bit signed value, and incrementing and
decrementing the upper 40 bits. This would allow encoder
counts up to 64-bits, although they could only be converted
to float up to 55 bits, I think, before losing precision.
One issue is the driver ecports
a signed 32-bit raw encoder count. That would have to be
changed to export a 64-bit count, and that's a change that
could affect anyone using this hal pin. I have no way to
know if anyone actually uses it, but I suspect it is a rare
case.
Now, if we go the 2nd way, with the signed 64-bit extended
count, we need to be sure it compiles and
runs correctly on both 32- and 64-bit systems. I'm kind of
unfamiliar with handing 64-bit integers in the 32-bit C
environment. But, I guess it is just supposed to work.
Changing the count to a 64-bit integer will require a
documentation change.
Jon
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
