Python pigpio bb_i2c_zip() OK, but with pigpio-GPIO, how?

I am struggling with I2C and a flow-meter Sensirion SFM3000 connected to a Pi4B.

Using Python command line and pigpio bb_i2c_zip() I can read the correct expected value, but
is it here at all possible to use Xojo with pigpio-GPIO?

I tried i2c_write_device() and i2c_read_device(). Both give errors -82 and -83 respectively.
The write I can do, without errors, using three i2c_write_byte() instead,
but a corresponding i2c_read_byte() seems missing(?)
And the i2c_read_byte_data() needs a register (unknown).

I donā€™t know how much pigpio-GPIO will take care of start, restart, stop, end and what not.

i2cdetect -y 1 says &h40 as expected.
In this example I try to read the Scale factor from the device with the command &h30DE
The command sequence here for pigpio bb_i2c_zip() is


# address 0x40            4 0x40
# start                   2
# write two bytes         7 2 0x30 0xDE
# restart                 2
# read 2 bytes            6 2
# stop                    3
# end                     0

Thus
cmd = [4, 0x40, 2, 7, 2, 0x30, 0xDE, 2, 6, 2, 3, 0]

So, with Python which gives correct result:

pi@raspberrypi:~ $ sudo pigpiod
pi@raspberrypi:~ $ sudo python
Python 2.7.16 (default, Oct 10 2019, 22:02:15)
[GCC 8.3.0] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pigpio
>>> pi=pigpio.pi()
>>> SDA=2
>>> SCL=3
>>> baud=50000
>>> pi.bb_i2c_open(SDA, SCL, baud)
0L
>>> cmd = [4, 0x40, 2, 7, 2, 0x30, 0xDE, 2, 6, 2, 3, 0]
>>> (count, data) = pi.bb_i2c_zip(SDA, cmd)
>>> print(count, data)
(2L, bytearray(b'\x00\x8c'))
>>> pi.bb_i2c_close(SDA)
0L
>>>
pi@raspberrypi:~ $

x8C = 140 which is the expected Scale factor.

Trying the same in Xojo. Baudrate is set in Pi4B to 50000.
For better readability I removed error checks and property declarations below.
Window1.Open:

pi = New pigpio
Call pi.gpioInitialise()
pi.Handle = pi.pigpio_start(nil, nil)
bus = 1
FileHandle = pi.i2c_open(bus, &h40, 0)   'Sensirion SFM3000: &h40

Pushbutton.Action:

Dim returncode As integer
dim buf as Ptr
dim mb as MemoryBlock
mb = NewMemoryBlock(3)

returncode=pi.i2c_write_byte(FileHandle,&h40)   'Gives returncode = 0
returncode=pi.i2c_write_byte(FileHandle,&h30)   'Gives returncode = 0
returncode=pi.i2c_write_byte(FileHandle,&hDE)   'Gives returncode = 0
MessageBox "In case a delay is needed"   'Didn't seem to matter.
'
buf = mb
returncode=pi.i2c_read_device(FileHandle,buf,2)   'Gives returncode = -83
'

Help, please.

Hello Lennart,

I looked up the bb_i2c_zip function and here is what I found: pigpio library

I havenā€™t written this function in the GitHub - eugenedakin/pigpio-GPIO: Code for Xojo apps to access the Raspberry Pi GPIO pins through the pigpio library library since I donā€™t have any electronics to test that it works.

Just a thought to help you out, could you run the Python program using a Xojo Shell and then import the data into your Xojo program?

Thank you Eugene,

I was just thinking of that possibility.
Good to get confirmed that it might be a way to go.

Btw, with so many methods in your library it seems odd that there is no i2c_read_byte.
(as opposed to i2c_read_byte_data, where you need to know a register)
I wonder why, if you care to elaborate, please.

Hello Lennart,

The answer is quite simple, I havenā€™t had a need for it.

The reason why pigpiod was created for Xojo was because my clients asked me for a new library that did not use the deprecated wiringPi library. As I was working on projects for clients, I would require methods to complete their project, and I would create a simple example in my ā€œI Wish I Knew How Toā€¦Program Raspberry Pi 4B Electronics with Xojoā€ book, which is almost 700 pages. The free library is posted on GitHub so that others can use it for free.

All examples are created by me and have been tested by me. Theoretical examples have not been created, since I donā€™t know if they actually work (There are too many books that deal with theory and not the real-world). :slight_smile:

When I have a project that actually uses the bb_i2c_zip method, and I have a piece of equipment that I can verify that this actually works, then I write the method, update the Github library, and provide an actual simple working example in the book. This is my quality-control on the information that is in my books.

I donā€™t have a piece of equipment that uses the bb_i2c_zip method, so it has not been included in the github library, or in my book.

Does this help?

Thanks.
Very fair.
Note, that I didnā€™t ask for the bb_i2c_zip per se, but the i2c_read_byte,
which sounds so basic to the unexperienced like me.

Oops, my apologies Lennart. Do you happen to know of an inexpensive piece of equipment that uses the i2c_read_byte method? If so, then I can purchase one and write the code.

Eugene,

You are very generous.
However, I should have written ā€˜asking aboutā€™ instead of ā€˜asking forā€™, since it was merely curiosity.

Looking around I see other people solving clock stretching issues by using the bb_i2c_zip.
And, as you suggested, I am heading for using a shell script since that command works well from the command line.
But the scripting technique for that I will probably discuss in another thread.

Thanks and regards
Lennart

1 Like