How to read I2C data without sending a command?

[ea7kir]

Raspberry Pi 4B, RASPIO 64 bit Bullseye Lite, Swift Version 5.5

For example, to read the Status Register of an SHT31 (datasheet page 13)

would require...

i2c.writeByte(0x44, command: 0xF3, value: 0x2D)
let data = i2c.readData(0x44) // would return 6 bytes, but this is not possible.

It would also be helpful to be able to send word commands like this...

i2c.writeWord(0x44, command: 0xF32D)

Any help with this would be most helpful, because I'm completely stuck.

[uraimo]

Hi, that diagram looks identical to the SHT20 one, try doing two readByte in sequence like Sam did, or 3 if you want the CRC (useless imho). That readData expects that the data is sent with an array format and I suppose that's not what the sensor does.

[ea7kir]

Thanks for the reply, but its more complicated with the SHT3x series and all the commands are 16 bit - and so is the user register.

I’ve been taken by surprise that no-one has written anything for SHT31, INA226 and DS18B20 sensors (all I2C) for SwiftyGPIO. I’m completely out of my depth trying to understand the data sheets, so I need help. I posted an issue with Sam a few days ago, but he hasn’t responded. I was hoping he might be interested in writing some more.

Is there anyone I can turn to?

I’ve put 6 months into my project, so it would be a great shame if I can’t find solutions.

https://github.com/ea7kir

Regards, Michael Naylor - EA7KIR https://michaelnaylor.es

On 6 Dec 2021, at 15:30, uraimo @.***> wrote:

Hi, that diagram looks identical to the SHT20 one, try doing two readByte in sequence like Sam did https://github.com/samco182/SwiftySHT20/blob/master/Sources/SwiftySHT20/SwiftySHT20.swift#L131, or 3 if you want the CRC (useless imho). That readData expects that the data is sent with an array format and I suppose that's not what the sensor does.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-986829558, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z2CZNRKB56C5G4ZAXTUPTCJFANCNFSM5JOXHDBA.

[uraimo]

Hmm, 16bits commands are not even allowed by the protocol, I wonder if 8+8 could work, have you tried something like this:

i2c.writeByte(0x44, command: 0xF3, value: 0x2D)
let value = i2c.readWord(0x44, command: 0xF3)
let crc = i2c.readByte(0x44, command: 0xF3) //optional

Also, with that "would return 6 bytes, but this is not possible." did you mean that when you ran that you got 6 bytes? Did you try decoding the value and see if it matched what you expected?

You could also try asking on the swift-arm Slack to check if someone else has already tried something similar, I don't know how active it is lately.

For the DS18B20 if you can't get the i2c version to work I wrote a library for the 1-Wire version of the sensor (should be its native protocol).

[ea7kir]

This is from page 10 of the Datasheet.

As far as I can see, I need to send 0x44, 0x2C 0x06, 0x44 and get back 6 bytes.

If you could show me how to get SwiftyGPIO to do this, I should be able able to figure out the rest.

Regards, Michael Naylor

On 6 Dec 2021, at 21:44, uraimo @.***> wrote:

Hmm, 16bits commands are not even allowed by the protocol, I wonder if 8+8 could work, have you tried something like this:

i2c.writeByte(0x44, command: 0xF3, value: 0x2D) let value = i2c.readWord(0x44, command: 0xF3) let crc = i2c.readByte(0x44, command: 0xF3) //optional Also, with that "would return 6 bytes, but this is not possible." did you mean that when you ran that you got 6 bytes? Did you try decoding the value and see if it matched what you expected?

You could also try asking on the swift-arm https://join.slack.com/t/swift-arm/shared_invite/zt-z7t57yx3-Dr_jfEnn2rcj22FLJ21NVA Slack to check if someone else has already tried something similar, I don't know how active it is lately.

For the DS18B20 https://github.com/uraimo/DS18B20.swift if you can't get the i2c version to work I wrote a library for the 1-Wire version of the sensor (should be its native protocol).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987192654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z33MIMX2SXNDNOMFQTUPUODHANCNFSM5JOXHDBA.

[curuvar]

I’ve been following the thread and figured that I’d throw in my two cents….

The issue is that what Raspberry Pi calls I2C is actually SMB (which always sends the register address).

I found this other thread that addresses the same issue: https://forums.raspberrypi.com/viewtopic.php?t=81615 https://forums.raspberrypi.com/viewtopic.php?t=81615

You would have to extend the SwiftyGPIO I2C class to craft a raw read directly without using the Pi’s I2C library.

Here is a quick and dirty sample that I wrote — it’s not well tested as I don’t have the slave device you are using, but my protocol analyses seem to show a good I2C read.

import Glibc

print("Hello, world!")

if let data = rawRead( slave: 0x33, length: 8 ) { print( data ) }

func rawRead( slave : UInt32, length : Int ) -> [UInt8]? { let O_RDWR : Int32 = 0x02 let I2C_SLAVE : UInt = 0x0703

let file = open( "/dev/i2c-1", O_RDWR )

let i2cStatus = ioctl( file, I2C_SLAVE, CInt( slave ) )

guard i2cStatus == 0 else { print( "ioctl failed" ); return nil }

var buf: [UInt8] = [UInt8]( repeating: 0, count: length )

let readStatus = read( file, &buf, length )

guard readStatus == length else { print( "read failed" ); return nil }

return buf; }

On 7 Dec 2021, at 08:18, Michael Naylor @.***> wrote:

This is from page 10 of the Datasheet.

As far as I can see, I need to send 0x44, 0x2C 0x06, 0x44 and get back 6 bytes.

If you could show me how to get SwiftyGPIO to do this, I should be able able to figure out the rest.

Regards, Michael Naylor

On 6 Dec 2021, at 21:44, uraimo @.***> wrote:

Hmm, 16bits commands are not even allowed by the protocol, I wonder if 8+8 could work, have you tried something like this:

i2c.writeByte(0x44, command: 0xF3, value: 0x2D) let value = i2c.readWord(0x44, command: 0xF3) let crc = i2c.readByte(0x44, command: 0xF3) //optional Also, with that "would return 6 bytes, but this is not possible." did you mean that when you ran that you got 6 bytes? Did you try decoding the value and see if it matched what you expected?

You could also try asking on the swift-arm https://join.slack.com/t/swift-arm/shared_invite/zt-z7t57yx3-Dr_jfEnn2rcj22FLJ21NVA Slack to check if someone else has already tried something similar, I don't know how active it is lately.

For the DS18B20 https://github.com/uraimo/DS18B20.swift if you can't get the i2c version to work I wrote a library for the 1-Wire version of the sensor (should be its native protocol).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987192654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z33MIMX2SXNDNOMFQTUPUODHANCNFSM5JOXHDBA.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987918183, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOAJTIS3QZGIMHT2GGTV6ITUPYCSPANCNFSM5JOXHDBA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[ea7kir]

For the present, I must give up with SHT31 and IN266 and try to get a couple DS18B20 working, and I was wrong to say the DS18B20 is I2C, because it’s a T05 1-wire device.

Unfortunately, your 1-wire code needs updating from Swift 4 on a Pi 2 to something more recent and I suspect the same may also apply to your I2C code. It also needs a way to know which GPIO pin will be used.

Many things have changed in the latest 32 and 64 bit Bullseye release.

Is there any chance you'll be able to work on this in the foreseeable future?

Regards, Michael Naylor

On 7 Dec 2021, at 15:32, curuvar @.***> wrote:

I’ve been following the thread and figured that I’d throw in my two cents….

The issue is that what Raspberry Pi calls I2C is actually SMB (which always sends the register address).

I found this other thread that addresses the same issue: https://forums.raspberrypi.com/viewtopic.php?t=81615 https://forums.raspberrypi.com/viewtopic.php?t=81615

You would have to extend the SwiftyGPIO I2C class to craft a raw read directly without using the Pi’s I2C library.

Here is a quick and dirty sample that I wrote — it’s not well tested as I don’t have the slave device you are using, but my protocol analyses seem to show a good I2C read.

import Glibc

print("Hello, world!")

if let data = rawRead( slave: 0x33, length: 8 ) { print( data ) }

func rawRead( slave : UInt32, length : Int ) -> [UInt8]? { let O_RDWR : Int32 = 0x02 let I2C_SLAVE : UInt = 0x0703

let file = open( "/dev/i2c-1", O_RDWR )

let i2cStatus = ioctl( file, I2C_SLAVE, CInt( slave ) )

guard i2cStatus == 0 else { print( "ioctl failed" ); return nil }

var buf: [UInt8] = [UInt8]( repeating: 0, count: length )

let readStatus = read( file, &buf, length )

guard readStatus == length else { print( "read failed" ); return nil }

return buf; }

On 7 Dec 2021, at 08:18, Michael Naylor @.***> wrote:

This is from page 10 of the Datasheet.

As far as I can see, I need to send 0x44, 0x2C 0x06, 0x44 and get back 6 bytes.

If you could show me how to get SwiftyGPIO to do this, I should be able able to figure out the rest.

Regards, Michael Naylor

On 6 Dec 2021, at 21:44, uraimo @.***> wrote:

Hmm, 16bits commands are not even allowed by the protocol, I wonder if 8+8 could work, have you tried something like this:

i2c.writeByte(0x44, command: 0xF3, value: 0x2D) let value = i2c.readWord(0x44, command: 0xF3) let crc = i2c.readByte(0x44, command: 0xF3) //optional Also, with that "would return 6 bytes, but this is not possible." did you mean that when you ran that you got 6 bytes? Did you try decoding the value and see if it matched what you expected?

You could also try asking on the swift-arm https://join.slack.com/t/swift-arm/shared_invite/zt-z7t57yx3-Dr_jfEnn2rcj22FLJ21NVA Slack to check if someone else has already tried something similar, I don't know how active it is lately.

For the DS18B20 https://github.com/uraimo/DS18B20.swift if you can't get the i2c version to work I wrote a library for the 1-Wire version of the sensor (should be its native protocol).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987192654, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z33MIMX2SXNDNOMFQTUPUODHANCNFSM5JOXHDBA.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987918183, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOAJTIS3QZGIMHT2GGTV6ITUPYCSPANCNFSM5JOXHDBA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987980161, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z7GYKDJ4LHRFUXPMM3UPYLHFANCNFSM5JOXHDBA.

[ea7kir]

Correction: DS18B20 is a TO-92 1-wire device - not TO5.

Regards, Michael Naylor

On 7 Dec 2021, at 20:56, Michael Naylor @.***> wrote:

For the present, I must give up with SHT31 and IN266 and try to get a couple DS18B20 working, and I was wrong to say the DS18B20 is I2C, because it’s a T05 1-wire device.

Unfortunately, your 1-wire code needs updating from Swift 4 on a Pi 2 to something more recent and I suspect the same may also apply to your I2C code. It also needs a way to know which GPIO pin will be used.

Many things have changed in the latest 32 and 64 bit Bullseye release.

Is there any chance you'll be able to work on this in the foreseeable future?

Regards, Michael Naylor

On 7 Dec 2021, at 15:32, curuvar @. @.>> wrote:

I’ve been following the thread and figured that I’d throw in my two cents….

The issue is that what Raspberry Pi calls I2C is actually SMB (which always sends the register address).

I found this other thread that addresses the same issue: https://forums.raspberrypi.com/viewtopic.php?t=81615 https://forums.raspberrypi.com/viewtopic.php?t=81615 <https://forums.raspberrypi.com/viewtopic.php?t=81615 https://forums.raspberrypi.com/viewtopic.php?t=81615>

You would have to extend the SwiftyGPIO I2C class to craft a raw read directly without using the Pi’s I2C library.

Here is a quick and dirty sample that I wrote — it’s not well tested as I don’t have the slave device you are using, but my protocol analyses seem to show a good I2C read.

import Glibc

print("Hello, world!")

if let data = rawRead( slave: 0x33, length: 8 ) { print( data ) }

func rawRead( slave : UInt32, length : Int ) -> [UInt8]? { let O_RDWR : Int32 = 0x02 let I2C_SLAVE : UInt = 0x0703

let file = open( "/dev/i2c-1", O_RDWR )

let i2cStatus = ioctl( file, I2C_SLAVE, CInt( slave ) )

guard i2cStatus == 0 else { print( "ioctl failed" ); return nil }

var buf: [UInt8] = [UInt8]( repeating: 0, count: length )

let readStatus = read( file, &buf, length )

guard readStatus == length else { print( "read failed" ); return nil }

return buf; }

On 7 Dec 2021, at 08:18, Michael Naylor @.***> wrote:

This is from page 10 of the Datasheet.

As far as I can see, I need to send 0x44, 0x2C 0x06, 0x44 and get back 6 bytes.

If you could show me how to get SwiftyGPIO to do this, I should be able able to figure out the rest.

Regards, Michael Naylor

On 6 Dec 2021, at 21:44, uraimo @.***> wrote:

Hmm, 16bits commands are not even allowed by the protocol, I wonder if 8+8 could work, have you tried something like this:

i2c.writeByte(0x44, command: 0xF3, value: 0x2D) let value = i2c.readWord(0x44, command: 0xF3) let crc = i2c.readByte(0x44, command: 0xF3) //optional Also, with that "would return 6 bytes, but this is not possible." did you mean that when you ran that you got 6 bytes? Did you try decoding the value and see if it matched what you expected?

You could also try asking on the swift-arm <https://join.slack.com/t/swift-arm/shared_invite/zt-z7t57yx3-Dr_jfEnn2rcj22FLJ21NVA https://join.slack.com/t/swift-arm/shared_invite/zt-z7t57yx3-Dr_jfEnn2rcj22FLJ21NVA> Slack to check if someone else has already tried something similar, I don't know how active it is lately.

For the DS18B20 <https://github.com/uraimo/DS18B20.swift https://github.com/uraimo/DS18B20.swift> if you can't get the i2c version to work I wrote a library for the 1-Wire version of the sensor (should be its native protocol).

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987192654 https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987192654>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUC65Z33MIMX2SXNDNOMFQTUPUODHANCNFSM5JOXHDBA https://github.com/notifications/unsubscribe-auth/AUC65Z33MIMX2SXNDNOMFQTUPUODHANCNFSM5JOXHDBA>.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987918183 https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987918183>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOAJTIS3QZGIMHT2GGTV6ITUPYCSPANCNFSM5JOXHDBA https://github.com/notifications/unsubscribe-auth/AOAJTIS3QZGIMHT2GGTV6ITUPYCSPANCNFSM5JOXHDBA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-987980161, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z7GYKDJ4LHRFUXPMM3UPYLHFANCNFSM5JOXHDBA.

[uraimo]

Is there any chance you'll be able to work on this in the foreseeable future?

DS18B20 fixed for Swift 5.x.

[ea7kir]

Thank you. It’s getting late in Spain and time for dinner, so I try it out tomorrow.

Regards, Michael Naylor

On 7 Dec 2021, at 21:41, uraimo @.***> wrote:

Is there any chance you'll be able to work on this in the foreseeable future?

DS18B20 fixed for Swift 5.x.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-988249081, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z2PM3ZM2F4FTZFCP6TUPZWOLANCNFSM5JOXHDBA.

[ea7kir]

RUNNING:

let onewires = SwiftyGPIO.hardware1Wires(for:.RaspberryPi2)! print("onewires: (onewires)") let onewire = onewires[0] print("onewire: (onewire)") let slaveId = onewire.getSlaves()[0] print("slaveId: (slaveId)") let ds = DS18B20(onewire,slaveId: slaveId) print(ds.Temperature)

OUTPUT:

onewires: [SwiftyGPIO.SysFSOneWire] onewire: SwiftyGPIO.SysFSOneWire slaveId: 28-3c01d607d440

Couldn't open 1-Wire device: /sys/bus/w1/devices/28-3c01d607d440 /w1_slave: No such file or directory Aborted

BUT THE FILE DOES EXIST:

cat /sys/bus/w1/devices/28-3c01d607d440/w1_slave 2e 01 55 05 7f a5 81 66 99 : crc=99 YES 2e 01 55 05 7f a5 81 66 99 t=18875

Do you have a CR in the string?

On 7 Dec 2021, at 21:41, uraimo @.***> wrote:

Is there any chance you'll be able to work on this in the foreseeable future?

DS18B20 fixed for Swift 5.x.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-988249081, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z2PM3ZM2F4FTZFCP6TUPZWOLANCNFSM5JOXHDBA.

[uraimo]

Yes, the RaspberryPi output for the list of 1wire slaves could very likely now contain a newline. Trimmed in 1.3.9.

[ea7kir]

So far so good, but…

onewires: [SwiftyGPIO.SysFSOneWire] onewire: SwiftyGPIO.SysFSOneWire slaveId: 28-3c01d607d440 line: 31 01 55 05 7f a5 81 66 37 : crc=37 YES line: 31 01 55 05 7f a5 81 66 37 t=19062 words: ["31", "01", "55", "05", "7f", "a5", "81", "66", "37", "t=19062"] temp#1: t=19062 temp#2: t= ds.Temperature: -273.15

On 8 Dec 2021, at 11:43, uraimo @.***> wrote:

Yes, the RaspberryPi output for the list of 1wire slaves could very likely now contain a newline. Trimmed in 1.3.9.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-988698412, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z7CGGMDPOLLS5A3TODUP4ZDNANCNFSM5JOXHDBA.

[uraimo]

https://github.com/uraimo/DS18B20.swift/blob/master/Sources/DS18B20.swift#L40

[uraimo]

2.0.4

[ea7kir]

Working now. Thank you.

On 8 Dec 2021, at 12:07, uraimo @.***> wrote:

2.0.4

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-988715863, or unsubscribe https://github.com/notifications/unsubscribe-auth/AUC65Z2TMM4RGX6AQEJE52TUP437LANCNFSM5JOXHDBA.

[ea7kir]

Googling for SHT31, I found this

https://github.com/torvalds/linux/blob/master/drivers/hwmon/sht3x.c

And I appear to have this in my Raspberry Pi OS.

sudo find / -name sht3x*
/usr/lib/modules/5.10.63-v8+/kernel/drivers/hwmon/sht3x.ko

There's also one for my INA226

ls -l /usr/lib/modules/5.10.63-v8+/kernel/drivers/hwmon/
total 212
-rw-r--r-- 1 root root 14832 Nov 18 17:22 ds1621.ko
-rw-r--r-- 1 root root 19128 Nov 18 17:22 gpio-fan.ko
-rw-r--r-- 1 root root  9848 Nov 18 17:22 iio_hwmon.ko
-rw-r--r-- 1 root root 22144 Nov 18 17:22 ina2xx.ko
-rw-r--r-- 1 root root 13168 Nov 18 17:22 jc42.ko
-rw-r--r-- 1 root root 29520 Nov 18 17:22 lm75.ko
-rw-r--r-- 1 root root 10736 Nov 18 17:22 raspberrypi-hwmon.ko
-rw-r--r-- 1 root root 16352 Nov 18 17:22 rpi-poe-fan.ko
-rw-r--r-- 1 root root 10680 Nov 18 17:22 sht21.ko
-rw-r--r-- 1 root root 21080 Nov 18 17:22 sht3x.ko
-rw-r--r-- 1 root root 13688 Nov 18 17:22 shtc1.ko
-rw-r--r-- 1 root root 11992 Nov 18 17:22 tmp102.ko

So my question is, how can I access these through SwiftyGPIO?

[ea7kir]

To read the SHT31 status register...

Trying this

i2c.writeByte(0x44, command: 0xF3, value: 0x2D)
let _ = i2c.readData(0x44, command: 0x2D)

and I get this

I2C read failed: Protocol error
Aborted

Notice where the S and P bits are in the diagram. I appears the whole operation needs to execute as one command. I've tried everything suggested and everything I can think of. Can SwiftyGPIO can do this in a way I've overlooked? Please can someone come to my aid?

[ea7kir]

Similar situation with an INA266.

[curuvar]

On 15 Dec 2021, at 16:37, Michael Naylor @.***> wrote:

Similar situation with an INA266.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-995232680, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOAJTISAH6BSICWJZRQSK3LUREC7ZANCNFSM5JOXHDBA.

I have a similar issue trying to read data from a MLX90640 Far IR sensor. It too requires a two byte register address and the address write and data read need to be handled in a single transaction. SwiftyGPIO currently doesn’t allow this. The following sample code does seem to allow me to read from the chip. (Tested on 64-bit bullseye)

The compile generated a number of warnings but watching my protocol analyzer indicates that it does seem to work.

import Glibc

struct i2c_msg { var addr: UInt16 var flags: UInt16 var len: UInt16 var buf: UnsafeMutablePointer }

struct i2c_rdwr_ioctl_data { var msgs: UnsafeMutablePointer var nmsgs: UInt32 };

internal let I2C_RDWR : UInt = 0x0707 internal let I2C_M_RD : UInt16 = 0x0001

let fd = open( "/dev/i2c-1", O_RDWR )

let result = i2cWriteAndRead( fd: fd, slave: 0x33, write: [ 0x80, 0x0D ], readLength: 2 )

print( String( describing: result ) )

close( fd )

// ---------------------------------------------------------------------------- // Func i2cWriteAndRead // ---------------------------------------------------------------------------- /// Combined write read operation /// /// @param fd file descriptor of i2c device /// @param slave i2c slave address /// @param write the data to write /// @param readLength the number of bytes to read /// /// @returns an array of bytes or nil on failure func i2cWriteAndRead( fd: Int32, slave: UInt16, write: [UInt8], readLength: Int ) -> [UInt8]? { var writeData: [UInt8] = write var readData: [UInt8] = [UInt8]( repeating: 0, count: readLength )

var status: CInt = 0

var msgs : [i2c_msg] = [ i2c_msg( addr: slave, flags: 0, len: UInt16( write.count ), buf: &writeData ), i2c_msg( addr: slave, flags: I2C_M_RD, len: UInt16( readLength ), buf: &readData ), ]

var cmd = i2c_rdwr_ioctl_data( msgs: &msgs, nmsgs: 2 )

status = ioctl( fd, I2C_RDWR, &cmd )

guard status > 0 else { print( "Errno: (errno)" ); return nil }

return readData;

}

[ea7kir]

It's good to know I'm not the only one and that @curuvar has a possible solution. I kind of get it, but I'd much prefer to have this functionality integrated within SwiftyGPIO, so I hope @uraimo is following this and will be able to can the find the time to see if his library can be extended.

As with so many many others, I'm humbly grateful to @uraimo for his undoubted talent and dedication, So in return I wish to offer this small piece of code that could slot into the 1-wire class.

public func isReachable(_ slaveId: String) -> Bool {
    let pathname = "/sys/bus/w1/devices/" + slaveId + "/w1_slave"
    return open(pathname, O_RDONLY | O_SYNC) > 0 ? true : false
}

[curuvar]

I cleaned to the function to get rid of the warnings and added it to my Safer i2c https://github.com/uraimo/SwiftyGPIO/pull/125/files# pull request.

And as you say, I really appreciate @uraimo https://github.com/uraimo effort to make Swift more useful on the Raspberry Pi.

On 16 Dec 2021, at 09:56, Michael Naylor @.***> wrote:

It's good to know I'm not the only one and that @curuvar https://github.com/curuvar has a possible solution. I kind of get it, but I'd much prefer to have this functionality integrated within SwiftyGPIO, so I hope @uraimo https://github.com/uraimo is following this and will be able to can the find the time to see if his library can be extended.

As with so many many others, I'm humbly grateful to @uraimo https://github.com/uraimo for his undoubted talent and dedication, So in return I wish to offer this small piece of code that could slot into the 1-wire class.

public func isReachable(_ slaveId: String) -> Bool { let pathname = "/sys/bus/w1/devices/" + slaveId + "/w1_slave" return open(pathname, O_RDONLY | O_SYNC) > 0 ? true : false } — Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-995893242, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOAJTIS3RQF4CF5WYWQLVVLURH4ZXANCNFSM5JOXHDBA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.

[ea7kir]

I cleaned to the function to get rid of the warnings and added it to my Safer i2c https://github.com/uraimo/SwiftyGPIO/pull/125/files# pull request. … As I've said before, I'm no expert (especially with GitHub), but this looks good to me. So how/when will I be able to try it?

[ea7kir]

@curuvar, I changed Package.swift to https://github.com/curuvar/SwiftyGPIO.git and get v1.3.15, but writeAndRead and tryWriteAndRead are missing.

[curuvar]

The change are not in my main branch yet. If you change your dependency line to:

  .package( url: "https://github.com/curuvar/SwiftyGPIO.git",   branch: "Safe-I2C" ),

You should get the added call.

On 16 Dec 2021, at 15:43, Michael Naylor @.***> wrote:

@curuvar https://github.com/curuvar, I changed Package.swift to https://github.com/curuvar/SwiftyGPIO.git https://github.com/curuvar/SwiftyGPIO.git and get v1.3.15, but writeAndRead and tryWriteAndRead are missing.

— Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-996180137, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOAJTITWT2A5ORH3VZJZBOTURJFQPANCNFSM5JOXHDBA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.

[ea7kir]

The change are not in my main branch yet. If you change your dependency line to: .package( url: "https://github.com/curuvar/SwiftyGPIO.git", branch: "Safe-I2C" ), You should get the added call. …

Thank you @curuvar.

Your Safe-I2C branch is working for me. So far I've only tested the SHT31 with the writeAndRead function. It can read the status register (verified by toggling the heater). It can read the 6 bytes containing the temperature and humidity (currently ignoring CRC) and these will successfully translate to centigrade and a relative humidity percentage. So I'm up and running and very happy.

I begin to understand why people do forks, but now appear to have 4 options...

1) track your branch 2) track your master (if/when you merge the branch) 3) track @uraimo (if/when he merges your branch) 4) create my own fork (if/when I better understand GitHub - and from who?)

Any of which will mean having to constantly check GitHub to see who's winning.

Comments will be most appreciated.

[curuvar]

I am happy that I was able to help.

I created my own fork because there were some changes I needed to make to do what I needed. It took me a bit to figure out all I needed to do to make that work. Basically once you change code and upload it to GitHub, you have to specifically build a release so swift has something to grab. I’m still learning how do build and test changes efficiently. I’ve been programming for ages (since 1968) but GitHub is new to me.

I made the Safe-I2C branch to isolate just the changes to I2C, so that I would be easier for @uraimo to merge those changes with his project if he choose to do that, though I can understand why @uraimo may not want to adopt my changes immediately. Most of my Raspberry Pi projects are running on 64-bit to get access to the latest Swift versions, so my changes have not been extensively tested on 32-bit Pis, or on any other platform that he supports. He may not want to (or be able to) take the time to make sure that they do.

I’m trying to keep my branch mostly compatible with his so I can easily merge in changes made in his branch. And, yes that does mean I have to check GitHub periodically, but I have to do that anyway when I build a new release of mine.

I have considered making some broader changes to my code. For example, I added versions of the I2C functions that use throw to report errors rather than aborting. On my main branch I working on rewriting I2C to include the error handling at the deepest level, but this will break compatibility with existing code, as all the functions will need to be called with a “try”. I’ll probably make similar changes to other classes that I use. I would doubt that @uraimo would adopt that sort of changes until at least a version 2.

On 17 Dec 2021, at 08:12, Michael Naylor @.***> wrote:

The change are not in my main branch yet. If you change your dependency line to: .package( url: "https://github.com/curuvar/SwiftyGPIO.git https://github.com/curuvar/SwiftyGPIO.git", branch: "Safe-I2C" ), You should get the added call. … <x-msg://8/#> Thank you @curuvar https://github.com/curuvar.

Your Safe-I2C branch is working for me. So far I've only tested the SHT31 with the writeAndRead function. It can read the status register (verified by toggling the heater). It can read the 6 bytes containing the temperature and humidity (currently ignoring CRC) and these will successfully translate to centigrade and a relative humidity percentage. So I'm up and running and very happy.

I begin to understand why people do forks, but now appear to have 4 options...

track your branch track your master (if/when you merge the branch) track @uraimo https://github.com/uraimo (if/when he merges your branch) create my own fork (if/when I better understand GitHub - and from who?) Any of which will mean having to constantly check GitHub to see who's winning.

Comments will be most appreciated.

— Reply to this email directly, view it on GitHub https://github.com/uraimo/SwiftyGPIO/issues/129#issuecomment-996711636, or unsubscribe https://github.com/notifications/unsubscribe-auth/AOAJTIQS5BHH5YF4MCYSDJLURMZKLANCNFSM5JOXHDBA. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.