How to send float32 to MCU

If I want to send a 32 bit floating point numbers to the MCU, what would be the recommendation?

  1. implement support for %f floats in the command protocol (I would limit this to c_float, not Pythons internal double)
  2. Split them into to 2 integers and recombine on the MCU
  3. Send them as byte arrays and unpack with memcpy
  4. Something else?

Looks like I wouldn’t need ctypes for #1:

import struct, binascii
value = 3.2
b = bytearray(struct.pack("f", value))
print("Length: ", len(b), ", Hex:", binascii.hexlify(b))
f = struct.unpack('f', b)
print("value: %s" % (f))


Length:  4 , Hex: b'cdcc4c40'
value: 3.200000047683716

I wouldn’t get any benefits of VLQ, it would always end up being 4 bytes long.

In the meantime I can try #3 because it should be the same wire format in the end.

The klipper host/mcu message protocol does not support floating point numbers ( Protocol - Klipper documentation ). Indeed, most of the micro-controllers that Klipper supports do not have hardware support for floating point numbers (and those that do are not compiled for that support).

A typical alternative to floating point numbers would be to use a fixed point number and send it as an integer.


1 Like

I had not thought about turning off the FPU in the compile options. That really puts a steak :skull_and_crossbones: :dagger: through the idea of doing this on the MCU. Oh well I learned some new things about the protocol handling.

The next alternative would be running the filter in Python and sending an updated threshold intermittently while homing. There will be some latency there (buffering + transit + filter execution + transit back). The low frequency drift should be slow enough that this works ok. I guess thats a bit more “klipperesque”.

On second through, maybe I should fight for this a bit more. If we are stuck with a 10Hz update rate, that limits the lowest frequency we can reject to being 1/2 that, so 5Hz. That works for my Voron. But the low frequency cutoff on the XL is 11.2Hz.

Also all high frequency rejection would be ruled out. I don’t know why Prusa did high frequency cutoffs, but its in their source. Maybe its unnecessary, maybe its something we will run into via testing. Maybe I wont find out until I klipperize an XL. But I wanted to leave the option open just in case I needed it.

I’ll look into fixed point, seems like it might be viable. A lot of these boards do have FPUs through, hardware has changed in the last ~3 years.