I've implemented a straightforward fix in our FW and am hoping it can be incorporated:
#define SIGN_EXTEND_SGT(sgt) int8_t(sgt | ((sgt << 1) & 0x80))
template<typename TMC>
static void tmc_get_sgt(TMC &st, const char name[]) {
SERIAL_ECHO(name);
SERIAL_ECHOPGM(" driver homing sensitivity set to ");
MYSERIAL.println(SIGN_EXTEND_SGT(st.sgt()), DEC);
}
Hummm, actually, looking back on this code I wrote long ago, I have no idea what the bit-shift is doing. I think it does nothing and all that matters is the int8_t ...
UPDATE: Oh, I see. The SGT is a 7-bit signed quantity. This copies the 7th bit to the eighth position.
This really is something that should be done at the library level. I can't have the sgt() reporting values that aren't correct and I believe I've already fixed this once already.
Either way, I'm getting a very different output and that led me to this oversight.
@teemuatlut: I'm not sure why you would consider sign-extending a 7-bit value into an 8-bit value to be incorrect. I agree that this would be better done in the library, but no matter where you do it it is not incorrect.
"I can't have it report values that aren't correct"
As in if the current implementation is bugged and reporting bad values. It was not a comment on your suggestion!
@teemuatlut : Ah, gotcha :)
After fixing the argument data type:
SENDING:M914 X-1
X driver homing sensitivity set to -1
>>> M914 X-60
SENDING:M914 X-60
X driver homing sensitivity set to -60
>>> M914
SENDING:M914
X driver homing sensitivity set to -60
>>> M914 X10
SENDING:M914 X10
X driver homing sensitivity set to 10
Edit: PRs https://github.com/MarlinFirmware/Marlin/pull/9650 https://github.com/MarlinFirmware/Marlin/pull/9651
Most helpful comment
After fixing the argument data type:
Edit: PRs https://github.com/MarlinFirmware/Marlin/pull/9650 https://github.com/MarlinFirmware/Marlin/pull/9651