When I put the serial number into a calculator, I can see 2 and 1F16
... but how do I get the lo word into the mix?
When I take 139030 and subtract the 0x1f16 (7958) I get 131072. Then divide it by 2 and get 65536. which is 1 more than the value of 0xffff.
Meaning, playing with these numbers shows me some relationship.
But I do not get the logic of it.
Well, I know what the serial number is.
It is stored as two unsigned ints.
Adding the number by concatenating does not seem to be the solution to the problem.
When I look at the calculator in the O.P. I see the 2nd byte from the bottom to be a 2.
This means 2 x something.
Like 2 x 65536.
If I add this to hi_word being 7958 I get 139030.
There is something I need to do with the 2 or get to the 2. Bit shifting, OR-ing... something, I am not familiar with.
[Worst case, either one or both of the two ints I am reading are incorrect. But I do not believe this to be the case, given the commercial product I am interfacing with.)
Thanks for hanging in there...
I just checked...
I am pulling the right addresses, but the documentation seems out.
There is a value before the lo word, which should belong to the previous word.
Well case closed! I am not getting the right value from this address (lo_word).
Didn't see the post... yes, these are the two words I should be seeing.
I did some further digging, based on my assumption that a commercial product should not have this problem (can, but unlikely)... I reviewed my code.
I have grouped the 106 registers into lots that belong together... these words being in a group of 13 registers. I only had 12 in there! After adding the missing one, the serial number appears correctly.