Page Comparison

...

1. Web socket interface receives command to start up a project

2. Project manager allocates memory in data store for project

3. Project manager runs system("make run PROJECT=blablabla PLATFORM=x86") and pipes output to log manager

4. Project manager sets up message queue for project to talk to project manager

5. Each driver gets key to the message queue project manager set up

6. Log manager taps into virtual CAN bus to collect those messages

7. Project updates data store and sends a message via message queue

8. Web socket interface sends web sockets upon data store being updated

9. Log manager sends CAN messages over web socket upon receiving them

Communication between the harness and projects [SOFT-252]

Idea:

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 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.