Closed UweBonnes closed 4 years ago
Nothing leaps to mind I'm afraid.
I'd certainly have to concede that the -f1 code is more heavily used than the -f4 code (IIRC I only ever did the -f4 port because I was having trouble with early versions of the code which wouldn't scan properly and I wanted to try on a different micro).
However even with the -f1 code base I've mostly used userspace drivers (not because I dislike the kernel drivers but because I've mostly used i2c-star for protocol experiments before writing a driver for a uC).
I just tested with a bluepill and I can see a BME280 connected via tiny-usb/bluepill and IIO. So there is something wrong with the F4. I will try to have a look.
Updating libopencm3 fixed the issue! Please use PR #12.
Thanks for following up with that! It is all merged.
I have compiled i2c-star for f4 and run it on a F4-Disco. Linux kernel sees the tiny-usb device and i2cdetect -l reports the tiny. I have tried to run Industrial IO (IIO) with BME280 and SI7020. The devices are detected on the tiny i2c bus. When IIO talks to the device, all I2C data is 0, while the device expects valid commands. I can see with a logic analyzer (LA) that the command sent to the device is NULL. Spying in usb_i2c_io() I also see that buf data is 0. Wireshark on the USB line however tells me that the USB transaction sends valid data, not 0. The address from req->wValue ist transferred right and seen in with the LA. I could not test with a Bluepill yet.
Anybody an idea what is going wrong?