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
The work on adding a "clock_stretch" and making different devices work at different speeds on the bus gave me lots of ideas; but namely it grounded something I'd been thinking about for a while now; that it should be possible to encode all the configuration required for an I2C Request in a single numeric identifier that can be "reused" and "passed around".
An application would feed in the details into a function and get back a single 32-bit or 64-bit identfier that represented that "request" as a "request_id". Then one mechanism to trigger a request is just to ask for it by request_id. These ids (with certain "fill in the blank" bits masked out) could be sent over a network or other communication lines to have other devices execute them at your request and send back the results. [This is like what slave I2C devices in some chips do, or what an I2C aggregator/hub is doing.]
So I started wondering about using an I2C bus library that acted like a "virtual i2c hub".
I'd register requests, set up precanned fetches/puts, and then interact with it much the same I would an actual device. I'd call a couple "update" functions at the start of "loop()" and a "commitChanges()" at the end; and the library would get the state/values from the preconfigured devices, I'd manipulate/read them inside loop(), and the library would push back the changes.
We could call commitChanges(), or update(), as often as required.
The work on adding a "clock_stretch" and making different devices work at different speeds on the bus gave me lots of ideas; but namely it grounded something I'd been thinking about for a while now; that it should be possible to encode all the configuration required for an I2C Request in a single numeric identifier that can be "reused" and "passed around".
An application would feed in the details into a function and get back a single 32-bit or 64-bit identfier that represented that "request" as a "request_id". Then one mechanism to trigger a request is just to ask for it by request_id. These ids (with certain "fill in the blank" bits masked out) could be sent over a network or other communication lines to have other devices execute them at your request and send back the results. [This is like what slave I2C devices in some chips do, or what an I2C aggregator/hub is doing.]
So I started wondering about using an I2C bus library that acted like a "virtual i2c hub".
I'd register requests, set up precanned fetches/puts, and then interact with it much the same I would an actual device. I'd call a couple "update" functions at the start of "loop()" and a "commitChanges()" at the end; and the library would get the state/values from the preconfigured devices, I'd manipulate/read them inside loop(), and the library would push back the changes.
We could call commitChanges(), or update(), as often as required.
For example:
"Device Id" + "Item Id" == 64-bit "Request Id"
The text was updated successfully, but these errors were encountered: