SparkFun SX1509 - byte data type on Omega2

OSO Bear

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?

Thanks!

Maximilian Gerhardt

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 addr doesn't indicate a 4-byte wide address, and neither das val. In that case the driver code immediately converts it back to an uint8_t by masking it with 0xff and writing it in a uint8_t buffer[..] (source)

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).

OSO Bear

This post is deleted!

OSO Bear

@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.