Unified I/O

[stevesims]

MOS currently has separate sets of I/O API calls for files, UART1, and i2c. they all support very similar APIs, performing very similar functions.

It would make sense to support unified I/O, allowing the same basic operations via the same API calls to work for all these various I/O mechanisms.

UART1 would gain support for reading and writing blocks of data. i2c would get per-character read/write, and possibly/probably the ability to read/write blocks larger than 32 bytes at once. EOF detection on them probably wouldn't be meaningful.

From the perspective of the API surface, this could probably be achieved by just adding in two new API calls - mos_api_uopenf and mos_api_i2c_openf to open either a UART1 or i2c connection returning back a file handle.

in the case of i2c, the "openf" call should take both the frequency (as per it's existing "open") and also the I2C Address (as provided in its read and write calls). if an open call has been made on i2c opening the bus at a different frequency than it's been activated at, then the call should just fail. closing an i2c file handle would only close the i2c bus connection if it was the last open i2c file handle

[richardturnnidge]

I believe there may be an issue, or lacking feature with the i2c write and read operations.
I am trying to get a VEML7700 module to work. It is an ambient light sensor. It is the only module I have found which MIGHT require a write then read operation without stopping the connection in between.
My module works with an Arduino library, so unit is functional, just can't get it to work on Agon :-(

[stevesims]

@richardturnnidge that feels like as it's an issue with the current i2c implementation this may well be a problem that would be perpetuated into the newer unified I/O system this issue is talking about

right now I don't really understand anything about the existing i2c APIs - my feeling is that this is something that should be made to work with the existing APIs, and that would probably then let this work with the proposed unified I/O

we should probably have a separate issue filed to track this problem

[richardturnnidge]

I am no expert either, but I have built up a basic understanding doing the videos and code examples. It is the only module so far that seems to exhibit this requirement. And I've coded for about 10 different ones so far!