adxl345: Add I2C support to the ADXL345 accelerometer implementation

[enduity]

Hello,

The purpose of this pull request is to allow others with the same issues as me to use their accelerometers without hardware modding. Namely the issue I had was that my board from Seeed Studio, the Grove - ADXL345 - 3-Axis Digital Accelerometer(±16g), was hardwired to use I2C with a trace below the ADXL345 chip itself (between CS and Vin). As I do not own a hot air station, I wanted to avoid desoldering this chip as much as possible. Turns out what I wanted was possible, as the ADXL345 chip supports 400 kHz I2C communication, which is already supported by Klipper in the MPU series.

I changed the ADXL345 Klippy Python code to detect I2C or SPI bus usage from the config, modifying the communication behaviour accordingly. I also implemented a new sensor_adxl345_i2c.c driver, because the code changes were much larger in this case and it is easier to configure the Makefile this way (to include only if I2C is supported on a given MCU).

I have tested this on my own printer and both I2C and SPI (on another board) work properly. I do not think there is a big risk in breaking any existing functionality, because the added Python code uses basic if statements, where the SPI cases include previously existing code.

I admit the documentation of this addition could be vastly improved, but I think it is currently usable for someone already tinkering with accelerometers using a manual setup (vs a KUSBA or something). I sadly currently lack the time to improve it. Still, I felt it's important to get this change out there so nobody ends up buying another board unnecessarily or maybe breaking one trying to get SPI to work (or maybe even wasting their time trying to do this).

[KevinOConnor]

Thanks. I guess the main question is - does the adxl345 actually work well in i2c mode? When that chip is in i2c mode it is severely limited in the sample rate it can achieve (without losing samples).

So, I'd be curious to understand the testing results you obtained. I think @dmbutyugin may also be interested.

-Kevin

[enduity]

Thanks for replying.

Would running a different ADXL345 on the same bed/extruder be sufficient? I can probably manage to run them simultaneously if necessary. I already own the other one, which has SPI wiring available.

[Sineos]

I'd propose two measurements:

• TEST_RESONANCES AXIS=X OUTPUT=raw_data
• Same location
• One with SPI connection and one with I2C
• Compare the two raw measurements in terms of how many samples have been taken
• Generate the graphs and compare if there are noteworthy / unexplained differences
• MEASURE_AXES_NOISE with both and compare if there are noteworthy differences

[github-actions]

It looks like this GitHub Pull Request has become inactive. If there are any further updates, you can add a comment here or open a new ticket.

Best regards,
~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.