jamesbowman / i2cdriver Goto Github PK

Start the GUI, then detach the I2CDriver. It hangs trying to talk to it.

It should cope properly with this, and return to the "detached" state. See #22

When device is I2CMini, which has no current or voltage sensing, those readouts should be disabled.

There should be no issue at all receiving echo responses. i2cdriver fails to respond.
I am not a MyForth expert nor will I ever be, but I don't see that the watchdog timer is used. I don't see any exception vectors handled either. This looks like it could be a 5 star product but it needs the basics covered!

openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY) = 3
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
write(3, "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"..., 64) = 64
write(3, "eA", 2) = 2
read(3,

6 releases and it does not work!
Windows 10 x64 LTSC. Two processes in Task manager do nothing.
Cmpatibility/Admin Rights not help.

CLI not better

Hi,
When I run make to compile the i2cdriver I get these warnings.

mkdir -p build/
cc -o build/i2ccl -I common linux/i2c.c common/i2cdriver.c
common/i2cdriver.c:269:36: warning: passing 'uint8_t [1]' to parameter of type
'char *' converts between pointers to integer types with different sign
[-Wpointer-sign]
if (readFromSerialPort(sd->port, a, 1) != 1)
^
common/i2cdriver.c:154:41: note: passing argument to parameter 'b' here
size_t readFromSerialPort(int fd, char *b, size_t s)
^
common/i2cdriver.c:304:38: warning: passing 'uint8_t *' (aka 'unsigned char *')
to parameter of type 'char *' converts between pointers to integer types
with different sign [-Wpointer-sign]
(void)readFromSerialPort(sd->port, devices + 8, 112);
^~~~~~~~~~~
common/i2cdriver.c:154:41: note: passing argument to parameter 'b' here
size_t readFromSerialPort(int fd, char *b, size_t s)
^
common/i2cdriver.c:310:31: warning: passing 'uint8_t [2]' to parameter of type
'const char *' converts between pointers to integer types with different
sign [-Wpointer-sign]
writeToSerialPort(sd->port, start, sizeof(start));
^~~~~
common/i2cdriver.c:173:44: note: passing argument to parameter 'b' here
void writeToSerialPort(int fd, const char *b, size_t s)
^
common/i2cdriver.c:328:33: warning: passing 'uint8_t [65]' to parameter of type
'const char *' converts between pointers to integer types with different
sign [-Wpointer-sign]
writeToSerialPort(sd->port, cmd, 1 + len);
^~~
common/i2cdriver.c:173:44: note: passing argument to parameter 'b' here
void writeToSerialPort(int fd, const char *b, size_t s)
^
common/i2cdriver.c:331:18: warning: passing 'const uint8_t *' (aka
'const unsigned char *') to parameter of type 'const char *' converts
between pointers to integer types with different sign [-Wpointer-sign]
crc_update(sd, bytes, nn);
^~~~~
common/i2cdriver.c:223:51: note: passing argument to parameter 'data' here
static void crc_update(I2CDriver *sd, const char *data, size_t data_len)
^
common/i2cdriver.c:332:1: warning: control reaches end of non-void function
[-Wreturn-type]
}
^
common/i2cdriver.c:341:33: warning: passing 'uint8_t [1]' to parameter of type
'const char *' converts between pointers to integer types with different
sign [-Wpointer-sign]
writeToSerialPort(sd->port, cmd, 1);
^~~
common/i2cdriver.c:173:44: note: passing argument to parameter 'b' here
void writeToSerialPort(int fd, const char *b, size_t s)
^
common/i2cdriver.c:342:34: warning: passing 'uint8_t *' (aka 'unsigned char *')
to parameter of type 'char *' converts between pointers to integer types
with different sign [-Wpointer-sign]
readFromSerialPort(sd->port, bytes + i, len);
^~~~~~~~~
common/i2cdriver.c:154:41: note: passing argument to parameter 'b' here
size_t readFromSerialPort(int fd, char *b, size_t s)
^
common/i2cdriver.c:343:20: warning: passing 'uint8_t *' (aka 'unsigned char *')
to parameter of type 'const char *' converts between pointers to integer
types with different sign [-Wpointer-sign]
crc_update(sd, bytes + i, len);
^~~~~~~~~
common/i2cdriver.c:223:51: note: passing argument to parameter 'data' here
static void crc_update(I2CDriver *sd, const char *data, size_t data_len)
^
common/i2cdriver.c:415:23: warning: passing 'char [8192]' to parameter of type
'const uint8_t *' (aka 'const unsigned char *') converts between pointers
to integer types with different sign [-Wpointer-sign]
i2c_write(sd, bytes, nn);
^~~~~
common/i2cdriver.c:319:44: note: passing argument to parameter 'bytes' here
int i2c_write(I2CDriver *sd, const uint8_t bytes[], size_t nn)
^
common/i2cdriver.c:429:22: warning: passing 'char [8192]' to parameter of type
'uint8_t *' (aka 'unsigned char *') converts between pointers to integer
types with different sign [-Wpointer-sign]
i2c_read(sd, bytes, nn);
^~~~~
common/i2cdriver.c:334:38: note: passing argument to parameter 'bytes' here
void i2c_read(I2CDriver *sd, uint8_t bytes[], size_t nn)
^
11 warnings generated.

>>> import i2cdriver
>>> i2c = i2cdriver.I2CDriver("/dev/ttyUSB0")
>>> i2c.setspeed(100)
>>> i2c.speed
400

Expect to see 100, but without getstatus() the variable is not updated.

I recently purchased this, and was really excited about using it for some of my embedded development. It took a bit to get wxPython installed property on Ubuntu (needed a bunch of additional packages that were in your instructions), but eventually I got it sorted.

Now that it's installed, I can run i2cgui.py, but I can't select a serial port from the drop down. I can see the /dev/ttyUSB0 being created when I connect it, and my user has 'dialout' permissions, but the GUI is almost entirely grayed out, and there is no output on the console.

I'd love to see this work. Any ideas for what might be causing the problems, or steps for further troubleshooting?

Thanks!

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.

It is not currently possible to do a regrd() to receive more than 255 bytes.

The regrd() implementation should handle this by expanding the request to:

self.start(dev, 0)
self.write([reg])
self.start(dev, 1)
r = self.read(256)
self.stop()

I had this working at one time, but it's been awhile.

At first it was only showing up as a "Composite Device" in System Information. I re-installed the FTDI drivers and now it shows up as "FT230X Basic UART" so I think I'm making some progress.

When I try to load the GUI no device shows in the drop-down area to select the I2CDriver com port.

What else am I missing? Keep in mind I'm a Linux/newb so if you have command line instructions for me please let me know what each command is doing so I can learn while I fix.

Thanks!

My understanding is that monitor mode allows us to monitor an i2c bus- which seems pretty cool.

I'm curious about wiring and voltages... and if I'm way off base on what I'm understanding so far. I thought I better ask a few questions before I start plugging things in!

For what I've used my board for so far- my computer has been the master and has been providing power to the attached devices.

Monitor mode sounds like there is and existing bus that we get to plug in to and listen in. That would mean another device is the master and power is coming from elsewhere. If true- does the i2cdriver draw power from the bus then? Can/should usb be connected without issue?

When connected to USB, i2cdriver produces 3.3v on the VDD pins. What if the bus to be monitored is using VDD=5v?

The documentation at

https://i2cdriver.com/i2cdriver.pdf

specifies that the '?' command returns a status string of the form

[i2cdriver1 DO01JUOO 000000061 4.971 000 23.8 I 1 1 100 24 ffff ]

However, if the I2C Mini gets into some sort of error state, it can return simply

1

I assume this is an error code? This needs to be documented.

This code is does not work for reads of > 64 bytes, because the read command NAKs the final byte.

Instead, it should use the 'a' command (read with ACK) to read the prefix, before a final read-with-NAK for the last 1-64 bytes.

Some users want it always to enter monitor mode, and currently have to use a tool to do it.
It would be good to have a "set default mode" operation that sets it into a particular mode at startup.

A booted i2cdriver in monitor/capture mode goes into mode 'D' as soon as the first character is received.

So a connecting PC's first transmitted character would put it back into driver ('D') mode.

The I2C Mini has a register read command, 'r':

Reads an I2C device register data. This command executes the following I2C operations:

• START, select address dev for writing
• write a single byte addr
• START, select address dev for reading
• read count bytes item STOP

However, it appears there is no corresponding register write command. This seems like a big omission, since many I2C devices that have register values that may be read are controlled by writing to registers.

I realize a similar sequence to the above could be constructed for writing to a register, however it would be great if a command 'w' could be provided so that this boilerplate could be avoided.

Also, there are no commands for 2-byte register devices in the I2C Mini's firmware. See the different I2C addressing modes and how they are handled on the Devantech USB-ISS device here: https://www.robot-electronics.co.uk/htm/usb_iss_i2c_tech.htm

src/i2cdriver/c/common/i2cdriver.c:326:28: note: insert an explicit cast to silence this issue
uint8_t start[2] = {'s', (dev << 1) | op};
^~~~~~~~~~~~~~~
static_cast<uint8_t>( )

This command works once and then i2ccl returns to prompt with no action (for all i2ccl commands, including "d", "i" etc.):

i2ccl \.\COM11 w 0x15 0x03 r 0x15 2 p

Only fix I've found is to unplug the i2cdriver hardware and reconnect.

This command results in continued operation of i2ccl and i2cdriver without issue:

i2ccl \.\COM11 w 0x15 0x03 r 0x15 2

i.e. no trailing "p" for stop. The user guide examples show a trailing "p", which doesn't work after first time.

Would also request adding Windows port naming info to User Guide as it took me a long time to figure out "\\.\COM11" !!!?!!

Hi!
THANK YOU for making this device! It's so useful!

While looking through the documentation, I noticed there's a stub header for "Capture Mode", but nothing below it. Are there any plans for a capture mode to be supported? If so, when? I'd like to contribute to your project where I can, so I'd be happy to write up the documentation for this feature once it's available.

Thanks!

Start the GUI, then attach the I2CDriver. It should show up in the devices list, either automatically or with a refresh button. Instead you have to restart the GUI.

Hi I've just received my i2cdriver.
I plug it in and it lights up with the default screen, but it doesn't 'do' anything. When running i2ccl with the correct device name, it just seems to hang, i don't get the status line like your example.
Any hints on troubleshooting ?
Sorry this is on OSX. The python gui also seems to have issues with

TypeError: GridSizer(): arguments did not match any overloaded call:
  overload 1: not enough arguments
  overload 2: argument 2 has unexpected type 'int'
  overload 3: not enough arguments
  overload 4: not enough arguments

And from my reading, it does need 3x parameters in the call.
Thanks

Hi
Please add a short description on how to compile the firmware.
Afaik you dont need a forth bootloader, but I am stuck with compiling the forth firmware for the device.

Cheers
Michael

The GUI is now so large it doesn't vertically fit on some laptop screens.
Maybe a two column layout, with the address map on the left?

Can you tell me about anything I need to do specifically to handle clock stretching? What is supported? I'm switching from the Raspberry Pi's internal I2c circuit to yours hoping to avoid issues with that- but will I? the RPI supports clock stretching during ACK but i keep getting the famous i2c lockouts.

// i2c_connect(&i2cDriver, "/dev/tty.usbserial-DO029HL5");
i2c_connect(&i2cDriver, "/dev/cu.usbserial-DO029HL5");

bombs out at the tcsetatttr call on my mac os Catalina machine
cfmakeraw(&Settings);
Settings.c_cc[VMIN] = 1;
if (tcsetattr(fd, TCSANOW, &Settings) != 0) {
perror("Serial settings");
return -1;
}

Right now my code runs and I can i2c_scan just fine, but my i2c_write's and read's are not working

Any ideas?

I have the device working, occasionally. When it doesn't work I get a few errors in terminal.

I'm still learning programming in general and new to Python, so any help would be appreciated. Thanks!

The first error only appears once:

Traceback (most recent call last): File "/usr/local/bin/i2cgui.py", line 342, in refresh devs = self.sd.scan(True) File "/Library/Python/2.7/site-packages/i2cdriver.py", line 180, in scan d = struct.unpack("112c", self.ser.read(112)) struct.error: unpack requires a string argument of length 112

The second error loops until I terminate it:
Traceback (most recent call last): File "/usr/local/bin/i2cgui.py", line 323, in refresh self.sd.getstatus() File "/Library/Python/2.7/site-packages/i2cdriver.py", line 449, in getstatus ccitt_crc) = body.split() ValueError: need more than 0 values to unpack

It seems that after doing a [0xc0 0x01] command to I2C driver, I sometimes have to read 2 status bytes before the next command processes. The following are 2 straces. The first command sometimes results in a hangup; the second always seems to not hang but seomtimes ends up with weird communication errors. The difference is in the second is that a read for 16 bytes commences after the write request

openat(AT_FDCWD, "\x2f\x64\x65\x76\x2f\x74\x74\x79\x55\x53\x42\x30", O_RDWR|O_NOCTTY) = 3
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
write(3, "\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40"..., 64) = 64
write(3, "\x65\x41", 2) = 2
read(3, "\x41", 1) = 1
write(3, "\x65\x0d", 2) = 2
read(3, "\x0d", 1) = 1
write(3, "\x65\x0a", 2) = 2
read(3, "\x0a", 1) = 1
write(3, "\x65\x00", 2) = 2
read(3, "\x00", 1) = 1
write(3, "\x3f", 1) = 1
read(3, "\x5b\x69\x32\x63\x64\x72\x69\x76\x65\x72\x31\x20\x44\x4f\x30\x31\x4a\x54\x35\x55\x20\x30\x30\x30\x30\x30\x30\x38\x30\x38\x20\x34"..., 80) = 80
write(3, "\x78", 1) = 1
write(3, "\x72", 1) = 1
write(3, "\x31", 1) = 1
write(3, "\x69", 1) = 1
write(3, "\x73\x62", 2) = 2
read(3, "\x33", 1) = 1

write(3, "\xc0\x01", 2) = 2
read(3, "\x31", 1) = 1
write(3, "\x70", 1) = 1

openat(AT_FDCWD, "\x2f\x64\x65\x76\x2f\x74\x74\x79\x55\x53\x42\x30", O_RDWR|O_NOCTTY) = 3
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or TCSETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
write(3, "\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40\x40"..., 64) = 64
write(3, "\x65\x41", 2) = 2
read(3, "\x41", 1) = 1
write(3, "\x65\x0d", 2) = 2
read(3, "\x0d", 1) = 1
write(3, "\x65\x0a", 2) = 2
read(3, "\x0a", 1) = 1
write(3, "\x65\x00", 2) = 2
read(3, "\x00", 1) = 1
write(3, "\x3f", 1) = 1
read(3, "\x5b\x69\x32\x63\x64\x72\x69\x76\x65\x72\x31\x20\x44\x4f\x30\x31\x4a\x54\x35\x55\x20\x30\x30\x30\x30\x30\x34\x32\x37\x35\x20\x34"..., 80) = 80
write(2, "\x5b\x69\x32\x63\x64\x72\x69\x76\x65\x72\x31\x20\x44\x4f\x30\x31\x4a\x54\x35\x55\x20\x30\x30\x30\x30\x30\x34\x32\x37\x35\x20\x34"..., 81[i2cdriver1 DO01JT5U 000004275 4.981 000 27.4 I 1 1 100 24 0168 ]
) = 81
write(3, "\x78", 1) = 1
write(3, "\x72", 1) = 1
write(3, "\x31", 1) = 1
write(3, "\x69", 1) = 1 = 4
write(3, "\x73\x62", 2) = 2
read(3, "\x33", 1) = 1
write(3, "\xc0\x01", 2) = 2
read(3, "\x31", 1) = 1
write(3, "\x70", 1) = 1

The following code fails to compile in Visual Studio 2019 with the error:

Severity	Code	Description	File	Line	Suppression State
Error	C2133	'mm': unknown size	..\i2cdriver.c	42	
Error	C2057	expected constant expression	..\i2cdriver.c	42	
Error	C2466	cannot allocate an array of constant size 0	..\i2cdriver.c	42	

my quick fix:

    char mm[256];
    sprintf(mm, "%s failed with error %lu:\n%s", func_name, dw, (char*)lpMsgBuf);

unsure if there is a better way, just wanted to open the issue.

Also, I would suggest placing #define NOMINMAX before including windows.h to prevent windows from defining the min and max macros and clashing with other code.

I have a raspberry pi and had attempted to inspect bus i2c-1 and i2c-6. When connected, device 0x22 on i2c-6 joined bus 1 and vice-versa, according to i2cdetect on my pi-host. Didn't seem to matter whether powered on or not/connected to my Macbook host I intended to inspect from.

Normal:
➜ ~ /usr/sbin/i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- --
70: -- -- -- -- -- -- -- 77
➜ ~ /usr/sbin/i2cdetect -y 6
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

When connected:
➜ ~ /usr/sbin/i2cdetect -y 6
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- --
20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- --
70: -- -- -- -- -- -- -- 77
➜ ~ /usr/sbin/i2cdetect -y 1
0 1 2 3 4 5 6 7 8 9 a b c d e f
00: -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- 1c -- -- --
20: -- -- 22 -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- 6a -- -- -- -- --
70: -- -- -- -- -- -- -- 77

The I2CDriver class currently asserts when it fails.
Change these to exceptions, and trap them all properly in the GUI.

For example if SCL is tied low, the GUI should handle it. Maybe pop up a warning dialog.

I'm test driving an INA219 I2C current sensor. The I2CDriver board sees the device at address x40, but the read and write buttons are initially disabled.

If I plug in a second device, Ic2 address = x60, select that one and then go back and select the 0x40 device, the buttons are then enabled.

I have fixed a couple obvious problems but I quickly realized that this is at best a stub and very little works. When will a tool that was advertised be available?
Issues: Wrong number of arguments creating the grid layout.
Can't handle non i2c usb-serial devices.

Randomly will not connect claiming bus is busy

Add the i2ccl.exe path to PATH in the Windows installer.

While creating a Node.js module for this device- I came across bitbang mode (commands b & i)... but I couldn't find any further details on it.

Can you share insights on how this works? Maybe it's still in development?

This is an FYI more than anything. I2CDriver.exe installs fine on Win 10, however execution of the installer does nothing on Windows Server 2016. SPIDriver did not have this issue. Does the source have to be rebuilt on/for the OS distro?

Russ

1. Need to add a note for users to edit the go.bat with their destination path for i2cdriver-installer.exe output, or have the path resolve for the user automatically
2. Need to mention that Nullsoft Scripting, NSIS is a dependency, user to download and install it
3. Need to reconcile line #63 in i2cdriver.nsi - file "i2ccl.exe" - commenting the line out allows i2cdriver-installer to build, but execution of I2CDriver GUI fails with "Failed to execute script"

I am reading the following data between a Pi and a microcontroller at address 0x31
TX -> 01
RX <- 0d 76 09 01 00 01 01 01 02 00 32 00 00

I shown capture output for 2 identical runs.
The Pi is correctly reading data over i2c.
The i2cdriver LCD display also shows correct data.
The capture mode shows correct data for the first run but not the second.

<START 0x31 WRITE ACK>
<WRITE 0x01 ACK>
<START 0x31 READ ACK>
<READ 0x0d ACK>
<READ 0x76 ACK>
<READ 0x09 ACK>
<READ 0x01 ACK>
<READ 0x00 ACK>
<READ 0x01 ACK>
<READ 0x01 ACK>
<READ 0x01 ACK>
<READ 0x02 ACK>
<READ 0x00 ACK>
<READ 0x32 ACK>
<READ 0x00 ACK>
<READ 0x00 ACK>
<READ 0x10 NACK>

<START 0x31 WRITE ACK>
<WRITE 0x01 ACK>
<START 0x31 READ ACK>
<READ 0x0d ACK>
<START 0x01 WRITE ACK>
<WRITE 0x80 ACK>
<WRITE 0x80 ACK>
<WRITE 0x00 ACK>
<WRITE 0x80 ACK>
<WRITE 0x80 ACK>
<WRITE 0x80 NACK>
<WRITE 0x00 ACK>
<WRITE 0x0c NACK>
<WRITE 0x00 ACK>
<WRITE 0x00 ACK>
<WRITE 0x04 ACK>

I noticed on Mac OS with Clang at least that size_t is not defined without <cstddef>. I have a wrapper that includes it and my compile is fine with that above the i2cdriver.h include. I don't know how multi-platform that is/any implications, but I think you might be missing a <cstddef> in the .h file that you get lucky on depending on how you include?

Let me know if PEBKAC/ID10T

Distribution: Ubuntu 20.04

When I plug in the i2cdriver on Linux, the screen lights up but no /dev/ttyUSB0 device is registered. If I tail dmesg, I do not see any changes when I plug in and unplug the device.

Using i2ccl on Pi Zero and i2cddriver connected by USB to try and monitor i2c traffic between Pi and device.
Invoking: strace ./build/i2ccl /dev/ttyUSB0 m

I see the I2C traffic picked up on the LCD but not passed back through USB.
This is not terribly helpful given the volume of traffic I have to look through.

strace output

execve("./build/i2ccl", ["./build/i2ccl", "/dev/ttyUSB0", "m"], [/* 17 vars */]) = 0
brk(0)                                  = 0xed4000
uname({sys="Linux", node="RAD-TESTER-000", ...}) = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fa2000
access("/etc/ld.so.preload", R_OK)      = 0
open("/etc/ld.so.preload", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=42, ...}) = 0
mmap2(NULL, 42, PROT_READ|PROT_WRITE, MAP_PRIVATE, 3, 0) = 0xb6fa1000
close(3)                                = 0
open("/usr/lib/arm-linux-gnueabihf/libarmmem.so", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0h\5\0\0004\0\0\0"..., 512) = 512
lseek(3, 17960, SEEK_SET)               = 17960
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 960) = 960
lseek(3, 17696, SEEK_SET)               = 17696
read(3, "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\3\f\1\22\4\24"..., 47) = 47
fstat64(3, {st_mode=S_IFREG|0644, st_size=18920, ...}) = 0
mmap2(NULL, 83236, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6f60000
mprotect(0xb6f65000, 61440, PROT_NONE)  = 0
mmap2(0xb6f74000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x4000) = 0xb6f74000
mprotect(0xbe841000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0
close(3)                                = 0
munmap(0xb6fa1000, 42)                  = 0
open("/usr/local/lib/mspdebug/tls/v6l/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/mspdebug/tls/v6l/vfp", 0xbe83fe00) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/mspdebug/tls/v6l/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/mspdebug/tls/v6l", 0xbe83fe00) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/mspdebug/tls/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/mspdebug/tls/vfp", 0xbe83fe00) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/mspdebug/tls/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/mspdebug/tls", 0xbe83fe00) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/mspdebug/v6l/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/mspdebug/v6l/vfp", 0xbe83fe00) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/mspdebug/v6l/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/mspdebug/v6l", 0xbe83fe00) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/mspdebug/vfp/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/mspdebug/vfp", 0xbe83fe00) = -1 ENOENT (No such file or directory)
open("/usr/local/lib/mspdebug/libc.so.6", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat64("/usr/local/lib/mspdebug", {st_mode=S_IFDIR|S_ISGID|0755, st_size=4096, ...}) = 0
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=42459, ...}) = 0
mmap2(NULL, 42459, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb6f97000
close(3)                                = 0
access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)
open("/lib/arm-linux-gnueabihf/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0L\204\1\0004\0\0\0"..., 512) = 512
lseek(3, 1239936, SEEK_SET)             = 1239936
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 2840) = 2840
lseek(3, 1236500, SEEK_SET)             = 1236500
read(3, "A.\0\0\0aeabi\0\1$\0\0\0\0056\0\6\6\10\1\t\1\n\2\22\4\23\1\24"..., 47) = 47
fstat64(3, {st_mode=S_IFREG|0755, st_size=1242776, ...}) = 0
mmap2(NULL, 1312152, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb6e1f000
mprotect(0xb6f4a000, 65536, PROT_NONE)  = 0
mmap2(0xb6f5a000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x12b000) = 0xb6f5a000
mmap2(0xb6f5d000, 9624, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6f5d000
close(3)                                = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f96000
set_tls(0xb6f964c0, 0xb6f96ba8, 0xb6fa5058, 0xb6f964c0, 0xb6fa5058) = 0
mprotect(0xb6f5a000, 8192, PROT_READ)   = 0
mprotect(0xb6f60000, 20480, PROT_READ|PROT_WRITE) = 0
mprotect(0xb6f60000, 20480, PROT_READ|PROT_EXEC) = 0
cacheflush(0xb6f60000, 0xb6f65000, 0, 0x15, 0xbe8402e8) = 0
mprotect(0xb6fa4000, 4096, PROT_READ)   = 0
munmap(0xb6f97000, 42459)               = 0
open("/dev/ttyUSB0", O_RDWR|O_NOCTTY)   = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B1000000 -opost -isig -icanon -echo ...}) = 0
write(3, "@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@"..., 64) = 64
write(3, "eA", 2)                       = 2
read(3, "A", 1)                         = 1
write(3, "e\r", 2)                      = 2
read(3, "\r", 1)                        = 1
write(3, "e\n", 2)                      = 2
read(3, "\n", 1)                        = 1
write(3, "e\0", 2)                      = 2
read(3, "\0", 1)                        = 1
write(3, "?", 1)                        = 1
read(3, "[i2cdriver1 DO01JT5U 000000017 5"..., 80) = 80
write(3, "m", 1)                        = 1
fstat64(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fa1000
write(1, "[Hit return to exit monitor mode"..., 34[Hit return to exit monitor mode]
) = 34
fstat64(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fa0000
read(0,

The register read command 'r' in the serial API does not seem to have any way of returning success/error status (it is missing a return byte similar to the ARB|TO|ACK bits returned by the other commands).

Hi,

Just read about this project on an email from Cool Components - looks great!

I just clicked on 'The serial protocol is very simple, and there are included drivers for' and got a 404. Where can I find out about the protocol?

Thanks,

nick.

Such a handy tool, thanks a million.
It helped me to debug a situation where the I2C device documentation was incorrect. Saved me from a lot of aggravation and frustration.

When running the python gui I get

Traceback (most recent call last): File "./i2cgui.py", line 215, in <module> f = Frame() File "./i2cgui.py", line 99, in __init__ devgrid = wx.GridSizer(14, 8) TypeError: GridSizer(): arguments did not match any overloaded call: overload 1: not enough arguments overload 2: argument 2 has unexpected type 'int' overload 3: not enough arguments overload 4: not enough arguments

Has GridSizer in wxPython changed ?

According to table 10 of the I2C specification, for 100 kHz operation, SCL has a minimum low period of 4.7 us and a minimum high period of 4.0 us.

Checking the signals generated by the I²CDriver board, SCL is low for roughly 3.5 us and high for the remaining time of the 10 us clock cycle.

The I2C devices I am trying to control specify a 4.7 us clock low time and I suspect that this timing issue may be the reason I am unable to control them.

I installed the application using the installer. Unfortunately I have issues using it.

Either the application window does not appear, but the app remains running in the process list.

Or the application window does show up but I can't actually select any COM ports.

I tried running the git version of i2cgui.py from the command line, it launches the window, but does not let me select any COM port, it's empty as per screenshot above.

connecting with i2ccl.exe works.

perhaps the radio buttons can be vertically pushed closer together a bit, or add a scrollbar for those that have lower resolution screens? I would have submitted PR for this, but could not find the GUI version source code.

Need to:

• document the bit-field
• add to GUI
• make a new release