JamesNewton
commented
5 years ago StartSpeed in the FPGA defaults to 500. E.g. putting in 0 makes the speed 500. So reversing those bits, putting in 500, makes the speed 0. Any actual speed must be XOR'd with 500 before being sent to the FPGA. This XOR with 1 was a hold over from a time when the default speed was 1. The FPGA default was changed to 500 and the matching change was not made in DexRun. This has been corrected in: https://github.com/HaddingtonDynamics/Dexter/compare/SpeedsUpdate#diff-691272021fae98368efb598f8e089c16R3632 on the SpeedsUpdate branch, along with other improvements / corrections to the speed system.
Anyone experiencing that problem should try that branch.
Current code in DexRun.c is XORing the StartSpeed with 1.
mapped[START_SPEED]=1 ^ a2;The
^operator in C is XOR. so if a 1 is sent as the parameter, the result will be 0. And a 0 will become a 1. Larger values will simple transition to the nearest value. E.g. 5 will become 4 and 4 will be 5. 1000 will become 1001. With larger values the LSB change quickly becomes negligible.If I understand correctly, StartSpeed can not be 0 because then the counter in the FPGA will never overflow and the joints won't move.
My expectation is that the operator used should be
lthe OR operator so that 1 will become 1 and 0 will become 1. Larger values will only be changed if they are even, and will always become the next higher value.The other option is to simply check for zero and always change 0 to 1 without making any other changes.
But before any change is made, we should verify the intent of the current code. Is it just there to try to ensure the value is never zero?