harbaum/i2c-tiny-usb

Cheap and simple I²C to USB interface

i2c-tiny-usb's Issues

No precompiled binaries present

Hello,

The readme mentions "If in doubt use the pre-compiled firmware.hex file distributed with the source code". However, I cannot find it. Is it not there or am I overlooking something? If it is not there, would it be possible to include it?

Kind regards,
Roy

/dev/i2c-* disappears after one access

Hi.
i got it working after about 2 hours of googleing around the world.
module i2c-dev have to be loaded!!!

now i can execute i2cdetect -y 8
it read all adresses.. find my BME280 at 0x76 and after that, the bus is disappeared in /dev.

why?

can you help me?

EDIT: the usb device isn't listed any more at lsusb after read.

Adafruit Trinket M0 supported?

On the Adafruit Trinket home is a deprecation warning, advising users to change to the Adafruit Trinket M0. Is this also supported by this firmware?

What changes would be necessary to support the Trinket M0?

README.md / Henning Pauls i2c-tiny-usb

The "Henning Pauls i2c-tiny-usb" link in "README.md" now points into digital nirwana.

...but archive.org still has that page.

USB_CFG_LONG_TRANSFERS?

Hello.
I am trtying i2c-tiny-usb + digispark for my project.
This is a linux host.

I am now trying CFG_USB_LONG_TRANSFERS in usbconfig.h with 1 since I am seeing my I2C read() fails with 205 bytes or larger data.

Though I have not succeeded yet with the larger data transfers, at least I think following changes are needed in order to build this configuration properly.
(At least, passing compilation.)

I wonder if anyone already tried CFG_USB_LONG_TRANSFER configuration.
Or possible clue to solve my issue of not able to read() 205 bytes or more?

====
diff --git a/digispark/main.c b/digispark/main.c
index 472595c..1b7b76e 100644
--- a/digispark/main.c
+++ b/digispark/main.c
@@ -359,7 +359,8 @@ struct i2c_cmd {
static uchar status = STATUS_IDLE;

-static uchar i2c_do(struct i2c_cmd *cmd) {
+//static uchar i2c_do(struct i2c_cmd *cmd) {
+static usbMsgLen_t i2c_do(struct i2c_cmd *cmd) {
uchar addr;

LED_PORT |= LED_BV
@@ -398,7 +399,8 @@ static uchar i2c_do(struct i2c_cmd *cmd) {

LED_PORT &= ~LED_BV;

• return(cmd->len?0xff:0x00);

• //return(cmd->len?0xff:0x00);
• return(cmd->len?USB_NO_MSG:0x00);
  }

@@ -484,7 +486,8 @@ uchar usbFunctionWrite(uchar data, uchar len)
/ ------------------------------------------------------------------------- /
/ ------------------------ interface to USB driver ------------------------ /
/ ------------------------------------------------------------------------- */
-uchar usbFunctionSetup(uchar data[8])
+//uchar usbFunctionSetup(uchar data[8])
+usbMsgLen_t usbFunctionSetup(uchar data[8])
{
static uchar replyBuf[4];
usbMsgPtr = replyBuf;

Linux GPIOs with I2C-GPIO expanders (PCF8574)

Hi,

I have flashed a Digispark with the i2c-tiny-usb firmware, connected a PCF8574, and under linux, it seems you can obtain those 8 GPIOs exported in /sys/class/gpio.

However, I cannot manage to see them there.

Do I need those 10K resistors somewhere? I have the impression the PCF does not receive 5V on its VCC pin, so I suspect this might be the reason. Do you have a better picture or a schema where to place those 10K resistors?

That would be great to document the usage of those, as GPIOs over USB are pretty hard to get (out-of-tree driver, etc...):

http://www.zoobab.com/ch341-usb-spi-i2c-uart-isp-dongle#toc15

Driver hangs on i2cdetect if nothing connected (digispark)

I downloaded the firmware for the Digispark variant and it works fine, at least on initial testing - for example I can plug the Digispark into my Linux laptop, connect to an MCP23017 and ensure it has pullup 10K resistors, and it can detect the device (i2cdetect -y 6 in my case works fine)

However if I just plug in the digispark and let it initialise, then run i2cdetect -y the driver stops working altogether. Now, to be fair, I'm not expecting a meaningful result here. If you are running open collector, connecting to nothing, not even terminators, it's unreasonable to expect any data. But it seems bad to let the USB driver crash, because the only way to recover seems to be to power cycle the digispark by removing it from the USB and reinserting it.

Is this expected behaviour and is there any way to make the device at least self-heal without requiring manual power cycling? Maybe for example having a watchdog timer to force a reset if the usb polling loop breaks?

"Failed to read functionality" after program

After programming my ATTiny85 with the included main.hex I am getting the following messages in dmesg.

[ 1829.201263] usb 3-1.3: new low-speed USB device number 10 using xhci_hcd
[ 1829.291719] usb 3-1.3: New USB device found, idVendor=16d0, idProduct=0753
[ 1829.291726] usb 3-1.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 1831.328892] usb 3-1.3: USB disconnect, device number 10
[ 1831.558550] usb 3-1.3: new low-speed USB device number 11 using xhci_hcd
[ 1831.639708] usb 3-1.3: New USB device found, idVendor=0403, idProduct=c631
[ 1831.639716] usb 3-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1831.639720] usb 3-1.3: Product: i2c-tiny-usb
[ 1831.639724] usb 3-1.3: Manufacturer: Till Harbaum
[ 1831.639728] usb 3-1.3: SerialNumber: 0215
[ 1831.640173] i2c-tiny-usb 3-1.3:1.0: version 2.01 found at bus 003 address 011
[ 1831.641538]  (null): failure reading functionality
[ 1831.641575] i2c i2c-4: failure reading functionality
[ 1831.641678] i2c i2c-4: connected i2c-tiny-usb device

The device shows up as a "dummy bus"

i2c-4	dummy     	i2c-tiny-usb at bus 003 device 011	Dummy bus

I tried it both with 10K resisters and internal resisters. Same error.

Writing a device tree overlay for a i2c device attached to i2c-tiny-usb

Has anybody managed to write a device tree overlay to use a i2c device kernel driver?

I'm trying to connect a touch screen via a i2c-tiny-usb adapter on a raspberry pi (the normal i2c bus is disabled because I'm using a DPI screen).

I've managed to get the interrupt details setup but it looks like the overlay is getting attached to the disabled built in i2c bus and I need to work out how to write an overlay to add the extra i2c bus.

/dts-v1/;
/plugin/;

/ {
	compatible = "brcm,bcm2837", "brcm,bcm2835", "brcm,bcm2708", "brcm,bcm2709";

	fragment@0 {
		target = <&i2c>;

		__overlay__ {
			status = "okay";
		};
	};

	fragment@1 {
               target = <&gpio>;
                __overlay__ {
                        st16xx_pins: st16xx_pins {
                                brcm,pins = <27>; /* GPIO */
                                brcm,function = <0>; /* in */
                                brcm,pull = <2>; /* up */
                        };
                };
	};

	fragment@2 {
		target = <&i2c>;
		__overlay__ {
			#address-cells = <1>;
			#size-cells = <0>;
			st16xx: st16xx@38 {
				compatible = "sitronix,st16xx-ts", "sitronix,st16xx";
				reg = <0x38>;
				pinctrl-names = "default";
				interupt-parent = <&gpio>;
				interrupts = <27 0x8>;
			};
		};
	};

	__overrides__ {
                addr = <&st16xx>, "reg:0";
        };

};

If I've understood the problem is with the target = <&i2c> lines which point to the existing bus. I think I need to create a overlay named i2c3 to match the new bus.

(also asked on rPi Stack Overflow site here: https://raspberrypi.stackexchange.com/q/101823/37180)

submodule update

you need to add to the description what must be done after the clone to update the submodule.
git submodule update --init --recursive

Atmega8 firmware variant doesn't work

Checked USBTiny and AVRUSB variants with custom pcb and noname prototype board, both failed. Besides, other projects (like https://github.com/gblargg/vusb-joystick) works nice with my HW.
I connected D+ and D- to D2 and D3 accordingly:

#define	USB_CFG_IOPORTNAME		D
#define	USB_CFG_DMINUS_BIT		3
#define	USB_CFG_DPLUS_BIT		2

but after programming everything I can see in dmesg is

[413259.524068] usb 1-1.3: new low-speed USB device number 32 using ehci-pci
[413259.608062] usb 1-1.3: device descriptor read/64, error -32

Installing with Ardruino IDE?

I tried now 5 hours long to flash this firmware now, asked for help but did not success.

https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=267383
https://community.openhab.org/t/how-to-install-micronucleus-to-openhabian/94270

Is it possible to install this Firmware using THIS method:
https://digistump.com/wiki/digispark/tutorials/connecting
?

Thank you very much in forward for any help!

Multiple digispark USB

How do I change the I2C bus address of a ATTiny85 Digispark dongle, if I would like to use multiple of them on the same Raspberry Pi4? (Or with a USB HUB.)

I guess I have to re-compile the firmware it again for each one?
Checked both digital.h & main.c files, but did not find any "I2C_BASE_BUS_ADDRESS" or anything similar.

Raspberry Pi4 has 4 I2C buses by default, so this should start from 8+

... or ...
if the BUS address is given by Debian OS, how /where should I change the name or unique identifier of the flashed device so I can distinguish one from the others?

Sorry if my question is wrong, I'm a newbee to this. Trying to drive more than 64 IO pins:
https://community.openhab.org/t/compatible-usb-i2c-adapter-for-rpi4/93690/6

Read errors with large size data

Hello.
I am seeing read errors (121 EREMOTEIO) with i2c-tiny-usb + digispark.
Host is Linux, and I am doing something like read(fd, buf, 210) on
/dev/i2c-7 (where my i2c-tiny-usb appears).

I am reading from an I2C device, which can respond relatevely large
size data, say, upto 1,000 bytes.
But I am beginning to see 121 errors around 204 bytes.
(Smaller number of bytes are OK. read() call fails with larger than this.)

1. If I read one byte at a time like below, I do not get this 121 error.
   (But it is very very slow.)

i2c_smbus_read_byte_data(addr, reg)
i2c_smbus_read_byte(addr) x 210 times.

2. I debugged for a while, and I can see if I modify a line in
   main.c:usbFunctionRead() like this, I no longer see this error, even
   if I do read(fd, buf, 210).

*data = i2c_get_u08(expected == 0)
->
//*data = i2c_get_u08(expected == 0)
*data = 0;

i.e. if I do not call i2c_get_u08() in usbFunctinoRead(), I do not get
this 121 error.

I think if I take long time in usbFunctionRead(), it may cause
something wrong and the read request fails.
(Timeout somewhere related to USB polling loop?)

For 204 bytes, usbFunctionRead() is getting called 26 times
(i2c_get_u08 is called 204 times)

I wonder if there is a way to avoid this within i2c-tiny-usb layer.

Will I2C-Tiny-USB work with LilyPads based on the ATTiny85

I want to try to replicate this project. However, I have a hard time obtaining a ATTiny85 chip with a MicroUSB-Port (like the blue one here: https://www.aliexpress.com/item/32432747996.html). I tried to order it twice but the order got cancelled each time as it doesn't seem to be available atm.

However, there are plenty of offers for a LilyPad with the ATTiny85 (e.g. here: https://www.aliexpress.com/item/4000943968380.html).

Is there any reason the project would not work with this board?

Side note: I also found offers for the digispark, however I would prefer a solution with a MicroUSB cable.

Tiny-USB hangs on host reboot

Hi,
i2c-tiny-usb (main.hex on digispark) is fine with debian host.

But if the host is rebooting, the tiny doesn´t respond to the usb registering process. After a system reboot just pulling and replugging the hardware module re-enables the module again.

Any advice for fixing? I am not familiar with the USB state machines...