You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Inside the i2c resource: configure: func(options: options) (options would be a struct then)
Provide it as part of an interface for a board world.
Personally, I prefer the second option. It seems to me that this follows the conclusions from #2, and I favour (some kind of) uniformity across board worlds.
The text was updated successfully, but these errors were encountered:
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:
interfacei2c-config {
usewasi: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 #2, and I favour (some kind of) uniformity across board worlds.
The text was updated successfully, but these errors were encountered: