Open Zelzahn opened 4 months ago
I prefer the second option too. It keeps simple use cases very simple, and complex use cases can still add configuration mechanisms if they need to.
If there is a set of configuration options that are common across a sufficient set of boards, an option would be to define a common interface for configuration, perhaps something in roughly this shape:
interface i2c-config {
use wasi:i2c/i2c@0.2.0-draft.{i2c, error-code};
/// maybe like this? and more functions like this?
set-speed: static func(bus: i2c, speed: u32) -> result<_, error-code>;
/// or combine the options into a record?
configure: static func(bus: i2c, options: options) -> result<_, error-code>;
}
That way, worlds could include it if it happens to fit their needs, rather than defining their one board-specific interfaces. I don't think we need to design this right now though; I just wanted to mention the option in case the need arises.
Some kind of host configuration function should be defined, some of the parameters that could be set: operating speed, target/controller, 10 bit/7 bit addressing, etc.
I see two possible locations:
configure: func(options: options)
(options
would be a struct then)Personally, I prefer the second option. It seems to me that this follows the conclusions from https://github.com/WebAssembly/wasi-i2c/issues/2, and I favour (some kind of) uniformity across board worlds.