search

Architeuthis-Flux / IGV1-16-Compass

A compass using a Soviet plasma discharge display and a USFSMAX module
0 stars 0 forks source link

i2c handling #1

Closed abzman closed 10 months ago

abzman commented 1 year ago

This looks like a standard arduino program, but all the i2c handling uses a function called transfer that doesn't seem to be in the default wire library. What did you base your i2c code off of? I have my own interesting display that I'm planning to adopt your compass handling code for, but it'll probably be on an rp2040 for the base cpu.

Architeuthis-Flux commented 1 year ago

Oh yeah, sorry I should have mentioned that. The this code was written before the official Arduino STMduino core came out. So they're using this core here: https://github.com/GrumpyOldPizza/arduino-STM32L4/tree/master/cores/stm32l4

It has a few of it's own additions to the standard I2C library such as i2c->transfer which are great, but it's a total nightmare for compatibility.

Maybe try looking into this fork of the original USFSMAX example where they apparently added support for Raspberry Pi (which probably isn't referring to the RP2040,) but it might be using a standard I2C library which should be more likely to work.

Let me know if that other fork helps because I spent a ton of time messing with the Wire libraries for the same reason and I might be able to help with other workarounds.

abzman commented 1 year ago

It was my intent to patch your stuff until it runs on the default wire library, then mod it for my use once that's working. Are those changes you're interested in for portability reasons?

Architeuthis-Flux commented 1 year ago

Yeah totally, I would love that. I was considering doing the same thing but the compass was just a one-off thing for myself so portability wasn’t really an issue. But it seems like there’s some interest in this now. So yeah, that would be great!

abzman commented 10 months ago

can I get you to add the specific versions of all the libraries you use to compile this? I may have come up with a generic i2c implementation, but now I'm stuck trying to find which moving average library and which rotary encoder library have these specifically formatted functions

Architeuthis-Flux commented 10 months ago

Hey I just noticed that there are 2 repositories here, and this is the out of date one. The one that works well is here https://github.com/Architeuthis-Flux/IGV1-16_Driver_Backpack It also has support for a relay to provide clickiness when you turn the encoder.

To answer your question about the libraries, here's the moving average library I used lib_deps = pilotak/MovingAverage@^1.0.3

https://github.com/pilotak/MovingAverage

I honestly have no idea which rotary encoder library I used, they're all shitty so I just cycle through them until one works. The newer code I linked to does away with the library and used a PIO state machine instead.

abzman commented 10 months ago

huh, well, it's ported to the pico now so I guess that's all I really wanted. Looking at the i2c code those changes are almost verbatim what I came up with too. Thanks.

Architeuthis-Flux commented 10 months ago

@abzman Did you put one of these boards together? If you want, I have some extra populated PCBs for this project.

abzman commented 10 months ago

I have a breakout board for the sensor and I have my own module with a display that never worked well (the sensor, not the display). I'll probably just use that

Architeuthis-Flux commented 10 months ago

Yeah those sensors are a pain in the ass to get working.

The trick is that if they start up and they're in 2D calibration mode and don't have a previous calibration in EEPROM, they lock up. So you need to switch to 3D calibration, run it until it gets a calibration, then switch back to 2D and run the calibration again.

The code in the other repo has some things to address that bug.

If you run into any more issues, you can ask me because the guys that make them can be less-than-helpful sometimes, so I kinda had to figure it out on my own without the source code.