[FEATURE REQUEST] Add support for ADXL345 accelerometer with USB C

[plandevida]

Hi,

I just acquired this board accelerometer module that has UBSC for easy usage with Klipper.

I wanted to connect octoprint with your plugin and this board, but seems that this module only talks with a board with your proxy firmware installed.

The board Documentation

[rubienr]

Hi @plandevida ,

you are completely right. The board you linked is not compatible with the plugin i try to establish with OctoPrint (OP). The reason i chose an STM32 back then is simple: when i started to tinker around it was weekend and the that micro controller was by hand. However i am not into RPI ARM MCUs (i.e. RP2) at all but the board you linked sounds reasonable! Probably the fastest way to achieve "some" progress is to implement a custom FW for the RP2 instead of using the Klipper FW.

Referring to Klipper + module: do you know which USB mode is used to establish the communication? The OP plugin i wrote requires a USB device in CDC (communication device class) mode. That is basically a serial device where the line-coding settings (baud etc) are completely indifferent.

I am going to order one module soon :smiley:. In the meanwhile i have to check the board schematics because i will want to assert the ADXL overrun and water-level interrupt lines are connected to the MCU. This is because the FW shall ensure the samples coming from the sensor are taken equidistant (always same time separation) and no sample was lost. This is essential for the FFT later on.

[plandevida]

Hi!

Thanks for the reply and your openness on my request.

Would like to help you but my knowledge programming micro controllers is none, I am still trying to understand how it does work mostly. Nevertheless I can help you testing until you have your board and/or for the release.

On the other hand, regarding klipper and the usb mode I have no idea, the only think I know its that the communication it’s made as a secondary MCU.

Doc here: RPi accelerometer klipper

[rubienr]

Hi,

I went through the high level RP2040 specs. It is a great MCU but has only USB 1.1. Let me explain my intention and the issues i faced:

• I wanted to measure the ringing apriori, then configure Marlin's input shaping parameters. Probably Klipper does it on the fly. I don't know :man_shrugging:
• While it is feasible to compute the FFT on the fly with most MCUs I assumed the data coming from the accelerometer might not be that simple to be interpreted (proved to be true) . This is because the MCU needs to know when the printer started to move and when it stopped so that it computes the main frequencies over a specific time interval. I also wanted to define specific patterns and run this mulitple times (series) etc. ... Hence i decided to only sample with the sensor + MCU and compute the rest on the host (similar to Klipper: compute the high level stuff on the host):
  • it brings more flexibility and
  • makes rapid prototyping simpler;
  • simpler to plot and makes it easier to get a feeling for the sensor data.
• To decompose the sensor data, for FFT it is essential that all samples have been taken with equal time separation in between. And that is roughly what the MCU firmware does:
  • takes data from the accelerometer's FiFo,
  • asserts the FiFo never overruns,
  • buffers data until it is interrogated by the USB host and
  • sends as much data possible to the host until the next portion needs to be taken off the FiFo.
  • If the FiFo overruns it informs the host.

Now here the trouble begins: even with High-Speed USB, depending on the host, the FiFo may still overflow. While this hardly happens with a regular PC, it does regularly happen with the RPI4 that hosts OctoPrint. During investigation if its caused by PySerial, Python's slowness, file IO or overloaded USB bus i got stuck but i believe its Python's slowness. I am thinking of a native binary to communicate with the controller (probably C++/app-image).

Side Info:

• The controller sends the data as binary (not ascii) via CDC serial in a very naive structure.
• The serial implementation does not consider retransmissions, timeouts or CRC (not required, data integrity is ensured).
• The controller receives trivial commands, to mention some: "start sampling N times", "abort sampling", "reboot".
• Once the controller starts sampling it delivers a data stream. To mention a few attributes: sample sequence number, total samples requested, sample rate and sensor settings, and EOS (and end of stream). If this occurs the stream can be seen as complete (no samples are missing).
• The python part is the host API to the controller. It decodes the stream. This could be also a native binary as mentioned afore.
• If the stream is not read in time from the serial device, the samples pile up in the controllers RAM (about 250kB) until the buffer capacity in RAM is exhausted and hence also the sensor's FiFo.

[plandevida]

Hey!

Nice investigation! Unfortunately without experience with microcontrollers I can help little in the technical side of the accelerometer.

Anyhow, not sure about the slowness of Python here, klipper is written in Python and runs on RPi’s 2-4, so I don’t think you need to go for a native binary program (python can be complied too anyway). Maybe you could actually check their code adxl345 klipper implementation

Processing the samples in the host so pulling all the samples from the accelerometer buffer seems the right choice. I guess if you can send a command a command to start samples when you pull the data you will know which samples are within the time frame of your pattern series.

I would love to me more helpful on the implementation side, but just send something when you need to test and I will give it a try.