Page Comparison

...

1. Define protocol buffers for each piece of hardware, i.e. stm32, ads1015, spv1020, etc. (start with just stm32 and one driver)

2. Generate protobufs using the nanopb protobuf-c library for c headers and the regular protoc compiler for python / javascript bindings

3. Use the C headers directly for communication between the harness and drivers. Note it would then be useful to add a make target that only compiles the protos and puts the headers in the right spots.

   1. Each piece of hardware gets its own ‘store’ within the master data store. Each project shares the memory for that store directly with the harness. These stores should be allocated and mapped by the harness in advance, then upon init each driver should grab the key to that store.

   2. As in SOFT-251, projects are run from the harness via popen().

4. For websockets, stores can be encoded in protobufs and sent periodically (tick rate can be determined later). CAN messages should be forwarded directly. Harness should accept a query for all data that sends everything at once.

   1. Python library can do something similar to candump where it can listen for incoming messages and log them. Should also be able to have a non-blocking socket listener running that updates a local store that contains the most recent state.

   2. Flask + web client can use the library to handle state etc., just needs to pass that state along to the web client. This can be via json, or we could forward the socket messages from the harness directly to the client for less decoding/encoding steps.

TL;DR: generate headers from protobufs using nanopb. Mmap stores from the harness and have the projects access those stores. The harness taps into the can network. There shouldn’t be a need for messages between the harness and the projects.

MCP2515 design problem - different uses of the driver in different projects

...