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 <#129 (comment)>, 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 <#129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUC65Z33MIMX2SXNDNOMFQTUPUODHANCNFSM5JOXHDBA>.

[Uthedris]

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 <#129 (comment)>, 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 <#129 (comment)>, 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 <#129 (comment)>, 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 <#129 (comment)>, 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 <#129 (comment)>, 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 <#129 (comment) <#129 (comment)>>, 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 <#129 (comment) <#129 (comment)>>, 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 <#129 (comment)>, 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 <#129 (comment)>, 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 <#129 (comment)>, 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 <#129 (comment)>, 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 <#129 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AUC65Z2TMM4RGX6AQEJE52TUP437LANCNFSM5JOXHDBA>.