search

jamesbowman / i2cdriver

I2CDriver open source tools
https://i2cdriver.com/
BSD 3-Clause "New" or "Revised" License
187 stars 57 forks source link

Enumerate as a Linux device #35

Open kornpow opened 4 years ago

kornpow commented 4 years ago

Is it possible to use the i2cdriver like a native I2C port, enumerated in /dev/i2c-*?

On my Raspberry Pi, I use the Python smbus2 library to control I2C devices. I would love to be able to plug the I2CDriver into my computer and ran the same exact code as on the Raspberry Pi.

codehero commented 4 years ago

You could take a stab at writing a CUSE driver

jamesbowman commented 4 years ago

Looking around, it seems that CUSE is not very actively developed.

kornpow commented 4 years ago

Thanks, I also briefly looked into CUSE to see what it would take. I'm a little ways off before I can devote some time to this, but I'm definitely very interested so I hope to get a chance to take a stab at it.

mickeyl commented 2 years ago

Any update on that? Just stumbled over the same "limitation".

mbenkmann commented 2 years ago

Maybe a firmware for i2cdriver could be developed that is compatible with the simple device supported by this Linux driver:

/usr/src/linux/drivers/i2c/busses/i2c-tiny-usb.c

which is for this device

https://github.com/harbaum/I2C-Tiny-USB

mickeyl commented 2 years ago

Indeed, that would be pretty cool. While I can work around the difference of talking to the I2CDriver vs. the I2C character device with an additional abstraction layer in my programs, it would be much nicer if that wasn't necessary.

mbenkmann commented 2 years ago

Unfortunately my idea does not seem possible because the USB frontend of the i2cdriver is provided by an FTDI chip and is therefore hardwired to be a USB serial device, so the USB protocol can't be changed. But I have a different idea. One could take the kernel driver ftdi_sio which handles the FTDI chip and add support for the I2C-related ioctls. The first time an I2C ioctl is used, the driver engages a translation layer that translates read()/write() data blocks from/to the i2cdriver's protocol. Finally you write a udev-rule that creates a symlink from /dev/i2c-... to /dev/ttyUSB...

The result would be that programs that use /dev/i2c-... would just work on the i2c-driver's device even though it's not a real i2c-bus from the Linux kernel's perspective because every i2c program always has an i2c-related ioctl before the first read()/write(), thereby activating the translation layer. Since the translation layer is active on a per-file descriptor basis, you can mix and match programs that use i2cdriver's native interface and those that use the i2c interface as you wish. E.g. you could use stm32flash to program an STM32 MCU via the i2cdriver and then without having to unplug/reset/whatever start the I2C driver's python helper program to debug the I2C bus functionality of your STM32.

mbenkmann commented 2 years ago

I'm seriously looking into working on this. Has anyone else started on this? I'm still looking for the best option. I think I will try a CUSE solution first. @kornpow You said you looked into CUSE. How far did you get? I'm at the point where I've googled it and am looking at the top search results. Did you get further into the topic?

mickeyl commented 2 years ago

This would be frickin' awesome. Crossing fingers that you can make it happen!

kornpow commented 2 years ago

No I didn’t get too far, and haven’t been doing to much embedded systems lately but would love anything that makes using I2C on normal laptops easier!

mbenkmann commented 2 years ago

Okay. I've implemented the CUSE-based solution. You can find it here:

https://github.com/mbenkmann/i2cdriver/tree/master/c/linux

The program also includes a more powerful command line interface to all other features of the i2cdriver, so if you're on Linux this should be an all around better replacement for the bare bones i2ccl utility.

So far I've only implemented the pure i2c ioctls that are used e.g. by i2ctransfer(8) and stm32flash(1) but it's easy to add the SMBus-related stuff, too, so if you have a concrete need for it, open an issue.

kornpow commented 2 years ago

Not that I am going to use this any time soon, but IMO since you are already in there, why not add SMBus related stuff? Save someone the realization that what theyre trying to do is unimplemented.

codehero commented 2 years ago

This is really cool, thanks! If I weren't so busy with other projects I would make a different i2cdriver device that wasn't written in (colorforth?)

Does this have a configurable clock stretch timeout?

(also issues don't seem to be enabled on your fork)

mbenkmann commented 2 years ago

Thanks for pointing that out. I wasn't aware that Issues weren't enabled by default. I enabled them now. As for clock stretching, I'm not seeing a command to configure this in the i2cdriver manual.

jamesbowman commented 2 years ago

@codehero @mbenkmann is correct, there is no clock stretch timeout configuration value. iirc it's set to something like 250 ms.

@codehero is written in myForth, a machineForth-flavored Forth for 8051s. http://www.kiblerelectronics.com/myf/myf.shtml