Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

I2C: User-facing interface library #211

Open
omeh-a opened this issue Aug 16, 2024 · 1 comment
Open

I2C: User-facing interface library #211

omeh-a opened this issue Aug 16, 2024 · 1 comment
Assignees
Labels
drivers Issues pertaining to driver code for a device class enhancement New feature or request protocol Issues pertaining to protocols for interfacing with drivers

Comments

@omeh-a
Copy link
Member

omeh-a commented Aug 16, 2024

I2C operations with our driver look identical in all applications, unless the user is doing something very weird. As a result, it makes sense to extract this logic into a library which can be used by clients to interface with the virtualiser and ensure that they always compose semantically correct I2C transactions. This will also make the driver significantly easier to employ since end users simply can call I2C_init and then read or write operations as needed.

@omeh-a omeh-a added enhancement New feature or request drivers Issues pertaining to driver code for a device class protocol Issues pertaining to protocols for interfacing with drivers labels Aug 16, 2024
@omeh-a omeh-a self-assigned this Aug 25, 2024
@omeh-a
Copy link
Member Author

omeh-a commented Aug 25, 2024

@Ivan-Velickovic As a change to what we discussed, I am going to write something a bit more minimal to start. Rather than having a full API which implements blocking or non-blocking semantics, I am going to basically just extract the current logic used in examples to library calls.

I have more important work to move on to and this lets us have the benefit of decoupling the examples from the exact transport logic still. I guess this technically still constitutes a non-blocking API, although due to the lack of completion (i.e. no read/write ops, etc. - just "make token chain", "send token chain" and "unpack response") I will refer to this as something more minimal

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
drivers Issues pertaining to driver code for a device class enhancement New feature or request protocol Issues pertaining to protocols for interfacing with drivers
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

1 participant