How to read I2C data without sending a command? #129
Comments
|
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). |
|
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>.
|
|
Hmm, 16bits commands are not even allowed by the protocol, I wonder if 8+8 could work, have you tried something like this: 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). |
|
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>.
|
|
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>.
|
|
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>.
|
|
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>.
>
|
DS18B20 fixed for Swift 5.x. |
|
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>.
|
|
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>.
|
|
Yes, the RaspberryPi output for the list of 1wire slaves could very likely now contain a newline. |
|
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>.
|
|
2.0.4 |
|
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>.
|
|
Googling for SHT31, I found this And I appear to have this in my Raspberry Pi OS. There's also one for my INA226 So my question is, how can I access these through SwiftyGPIO? |
|
To read the SHT31 status register...
Trying this and I get this 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? |
|
Similar situation with an INA266. |
|
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 <#129 (comment)>, 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<UInt8>
}
struct i2c_rdwr_ioctl_data
{
var msgs: UnsafeMutablePointer<i2c_msg>
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;
}
|
|
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. |
|
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 <#129 (comment)>, 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.
|
|
|
@curuvar, I changed Package.swift to https://github.com/curuvar/SwiftyGPIO.git and get v1.3.15, but writeAndRead and tryWriteAndRead are missing. |
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...
Any of which will mean having to constantly check GitHub to see who's winning. Comments will be most appreciated. |
|
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 <#129 (comment)>, 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.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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...
It would also be helpful to be able to send word commands like this...
Any help with this would be most helpful, because I'm completely stuck.
The text was updated successfully, but these errors were encountered: