SparkFun SX1509 - byte data type on Omega2
Since I already have a couple SX1509 GPIO expanders, I decided to make use of them with my Omega2 and wanted to port the Ardunio library over to work with the Omega to supporting all the board's features. (https://github.com/sparkfun/SX1509_IO-Expander)
I started on basically rerouting the read/write commands to the Omega's i2c_read/write functions but came across an issue I hadn't thought about. The Ardunio platform uses 'byte' (uint8_t) types which the omega doesnt. (unless I'm missing something?) I could try to find a way to continuously convert types back and forth, or, I was thinking just switching the code to replace 'byte' with 'int'
My question: if I switched everything to 'int' (like the onion_i2c libraries use), will I get unexpected behavior out of the code? Aside from memory size, does an int behave differently than the Ardunio's byte? Why does Arduino use bytes?
Maximilian Gerhardt last edited by
The Onion I2C library internally also uses byte-wise transfers, not int-sized. Things like
int i2c_write (int devNum, int devAddr, int addr, int val);
are just badly written function prototypes which don't represent what's actually going on. The
int addrdoesn't indicate a 4-byte wide address, and neither das
val. In that case the driver code immediately converts it back to an
uint8_tby masking it with
0xffand writing it in a
For some reference code on I2C writes/reads you can refer to one of libraries.
Be aware when writing driver code that you will have to work-around several bugs in the I2C library: From out-of-bounds reads/writes to heap corruption and seg-faults, a lot of things can happen when you don't read the code that's behind the library. I've reported a lot of issues bot none of them were answered (1, 2, 3, 4).
This post is deleted!
@Maximilian-Gerhardt wow! Thank you very much for your response, at least I don't have the feeling like I'm shouting into an empty cave!
I'm surprised at how beta the i2c library is for something that's been out for ~years. I feel like the first feature for boards like this (after GPIO control on its own pins) should be a matured and robust i2c library. Since, almost anything you want to do with them will require i2c communication...
Again, thank you for the heads up with known issues. I'll try to keep stumbling through this and if I succeed I'll make it available.