@johntalton/i2c-port v1.0.0
I²C MessagePort based Bus
Provides tooling that allows for I2CBus
to be hosted natively, over MessagePort
, within Worker
and over WebSockets
.
This allows the I2CBus
api to be used in a wide range of deployment cases.
It can also be using with bus Multiplexing such as @johntalton/i2c-bus-tca9548a that adheres to the I2CBus
interface. As well as using i2c-bus as the default concrete/base implementation.
Provided Abstraction
Key is providing multiple abstraction layers.
- A
Message
type definition (includingRead
,ReadResult
,Error
, etc) - An
I2CPort
function that mapsMessage
intoI2CBus
commands on providedbus
- And
I2CPortBus
which implementsI2CBus
over aMessagePort
interface
The corresponding WebSocket
to MessagePort
example can be run to provide this service.
The Message definition layer provides a naming convention and contract without implementation details. It is ideal for abstracting the service at each layer.
The Port utility layer allows for mapping of the generalized message into I2CBus
interface commands. This layer provides the mirror binding the I2CPortBus
implementation.
This utility operates over an I2CBus
interface, allowing for further abstraction and requires the caller to manager its allocation and state.
The Bus interface layer (along with example server) creates a WebSocket
service which allows for the above Message
interactions to a concrete - and remote - implementation.
The I2CPortBus
uses a simple one-call-one-response per MessagePort
in order to bridge the WebSocket
on
/send
api into the I2CBus
more friendly Promise
based async/await code.
Direction
Having a full I2CWebBus
that implements I2CBus
enables moving other Sensor implementations that currently use the I2CBus
over to a web-safe version. This will increase code portability and quality as wall as validate many of the timing and latency issues that are otherwise not seen locally in most cases.
Further mocking and virtualizing can be provided once a common WebSocket
message api is established. Providing virtual sensor and other services in a web-centric fashion.
Single 1:1 calls allow for basic interactions, however, extending the message with 'scripting' style operation could provide performant solution when latency of the transit layer becomes and issue. This could be extended to enable service-side interactions such as keep alive or default access polling. Other common data-fetch or read-comp-trigger features could be added.
3 years ago