Trying to specify anything other than the default (I've tried Restart and the pictured Restart No Stop) results in an unhelpful error (5000, unknown), as are just about any error conditions in Linx. It would appear as if the Linx low level library doesn't support this behavior or has some bug in its implementation.
Has anyone successfully used the repeated start behavior in Linx? Anyone know if the source for the lower level shared libraries are available somewhere that I could dive into?
Yep, the implementation for Linux platforms like Raspberry Pi and BeagleBone Black do not support anything but the first method only. There is no easy way to support the meaning of this flag with the Linux I2C driver in the current Linx API even when accessing the low level driver directly through ioctl() calls. There would need to be a combined "I2C Read Write" method that allows to configure multiple frames witch each frame indicating what length it should have and if it is a read or write bus transfer.
Ahh. I missed the Pi and BBB stuff in there, I had only noticed the Arduino/ChipKIT stuff. Time to dig!
In fact, the error with restarting in the Raspberry Pi hardware has been known for a long time. I found this problem when connecting the MAX31785 chip to the RaspberryPi. This is due to the fact that BCM2835 does not work correctly with i2c devices using Clock Stretching of SCL line.
Check out the last post on this thread: https://www.raspberrypi.org/forums/viewtopic.php?p=855345#p855345 and this thread: https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=13771&start=50
But fortunately, the RaspberryPi developers have provided a software implementation of the i2c bus (i2c-gpio).
To switch to software i2c mode you need to add the following lines to config.txt: dtoverlay=i2c-gpio,bus=1,i2c_gpio_delay_us=2,i2c_gpio_sda=2,i2c_gpio_scl=3 (or you can use another gpio lines for SCL and SDA)
And also disable hardware i2c by commenting out the following lines: #dtparam=i2c1=on and #dtparam=i2c_arm=on (you can keep hardware i2c working, if you use another lines for SCL and SDA)
So in the software implementation of the i2c bus, Repeated Start works great on Raspberry Pi! The i2ctransfer utility from the i2ctools package was used for testing.
The next step is to add a new function to the liblinxdevice_rpi2.so library and rebuild it from the source code. And then, you need to add support for this feature to the LabviewLINX library.
All this has been successfully implemented. The new function currently support: Write 1 frame to slave - do Repeated Start - Recieve 1 frame (not 1 byte) from slave. But the I2C_RDWR mode in the ioctl () call is much more complicated, and you can implement writing and reading more than just 1 data frame per transaction.
Necessary changes in the LINX source code in the attached files (many thanks to Sam Kristoff and the other guys who made this awesome library for us):
LinxRaspberryPi.cpp file - added new function I2cReadRS (core implementation of I2C_RDWR mode in ioctl() call)
LinxDeviceLib.cpp file - added new function LinxI2cReadRS (LINX Device Abstraction Layer - called from Labview)
liblinxdevice_rpi2.so - Raspberry PI recompiled version of shared library with new functions
LinxI2cReadRS.vi file - used to call new LinxI2cReadRS function from liblinxdevice_rpi2.so shared library
I2C Read RS.vi file - used to call LinxI2cReadRS function in LINX Local IO mode.
Hello, found this topic while trying to connect i2c with a pi3.
i am able to connect and install LabVIEW RT on it using rpi OS latest version and rt 20.xxx
functions such local IO works perfectly.
also tested some other tcp functions such modbus and it is working.
it is not an specific application, i am just messing around with LINX and RPi.
keep getting error 5000 on the linxi2cwrite function.
i am connecting an accelerometer on the bus. and the error occurs inside the open subVI.
i tested changing the EOF of write functions inside open subvi, with no success.
the funny thing: one time, only once, it worked and stopped working after stopping VI, and i cant reproduce the successful time.
i will keep working around my wiring for the bus (i confess it is not the best, but the same physical configuration is working on arduino).
do you believe that the proposed solution of changin hardware to software i2c would help me?
you wouldn't believe, but my slave address was wrong. sorry
hey, how can i edit a post?
I just dropped the .so in and everything worked great. I wonder if a software bit bang is possible with the LV api.