...

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

...

• The scripts emulate the hardware pieces (i.e. elcon charger or wavesculptor motor contorller)

• Scripts attach callbacks to shared memory

  • e.g. can_tx() and can_rx()

  • scripts should decode these messages and respond accordingly

• MCP2515 calls those callbacks and registers an rx() callback to be called by the script

Block Diagram

...

Of course this is a WIP

Components:

• CAN handler

  • receives messages to send from the message handler in main, stores them in a TX queue, and sends them asap

  • Reads messages off the CAN bus and sends them to the message handler in main.

• Project Manager

  • takes commands to power on and off boards

  • sends logs from projects to the log parser in main

  • each project runs in its own process

  • project manager holds a handle to each running project and gathers the logs accordingly

  • Project manager should also handle running drivers for the motor controller and charger, etc. Basically the logic for any hardware interactions we have should be run in project manager

• Data store

  • stores the shared data for the projects

  • handles mapping / unmapping of shared memory depending on what project is spun up (should expose an API to be called by project manager? for whenever a new project spins up)

  • sends updates to the update handler in main

• Websockets

  • receives commands over websockets and passes them to the message handler in main to be processed accordingly

  • sends messages passed to it by the message handler over websocket to expose to clients (e.g. CAN messages, datastore updates, project logs)

Questions:

• do we need a queue for RXing CAN messages?

• should modules call main, or should main grab messages from queues stored in the modules?

Notes from July 1st, Max and Jess

• worked out structure of ring buffer (to use for queues)

• Yes, we need a queue for RXing CAN messages. CAN and Websocket will both expose TX and RX queues. The module will act as the consumer for the TX queue and the producer for the RX queue. Main will act as the consumer for the RX queues and the producer for the TX queues.

• Main will be implemented as an infinite loop that constantly checks the RX queues. Each queue will expose a read-only counter for how many items there are that main can check for values at. This doesn’t have to happen atomically since the number will never decrement after main checks it because main is the only consumer.