TLE5012B: validate the safety word the driver already reads

[jajmangold]

Summary

readBytes() already requests len + 2 bytes, so the SSC safety word is clocked off the wire on every read and then discarded. This PR validates it instead.

Because the bytes are already being read, this costs no extra transaction and no extra bus time.

Why

Every 15-bit value the TLE5012B returns is a legal angle, so the data word alone can never reveal that a read was corrupted — only the safety word can. At present a corrupted angle is passed straight to the control loop, which matters once the sensor is closing a position loop and a bad reading commands real current.

What it does

Opt-in, and disabled by default so existing behaviour is unchanged:

sensor.checkSafetyWord(true);

With it enabled, a read whose CRC fails or whose status bits report a fault is rejected and the previous good angle returned. Two accessors expose what happened:

sensor.safetyErrorCount();   // reads rejected since init
sensor.lastSafetyWord();     // raw safety word from the most recent read

The CRC, determined by measurement

The algorithm is CRC-8, polynomial 0x1D, seed 0xFF, over the transmitted command word followed by the returned data word, inverted.

Rather than take one reading of the datasheet on trust, four plausible interpretations were implemented and scored simultaneously against a real TLE5012B over 200 reads:

Variant	Matches
command + data, inverted	200 / 200
command + data, not inverted	0 / 200
data only, inverted	0 / 200
data only, not inverted	0 / 200

Status bits read healthy 200/200 in the same run.

Testing

• CRC algorithm verified on hardware as above, on a TLE5012B in 3-wire SSC mode on a BIGTREETECH S57B V2.0 (STM32F103)
• The command word reconstruction matches how readBytes() builds it (0x0020 | 0x8000 | 1 = 0x8021)
• Patched driver compile-tested for genericSTM32F103CB with all three new methods exercised; builds clean with no warnings

Scope note, stated plainly: the CRC algorithm and the sensor behaviour were verified on hardware, but this exact driver was not run end to end on my board — my own firmware uses a separate SPI implementation. The integration is small and was checked against readBytes() by inspection, but I would rather flag that than overstate it.