Closed nwdepatie closed 5 months ago
Note: I might rethink how we are doing routing here. It might be beneficial to spin up a few tasks that wait forever until we signal them to take something off of the CAN queue, and the CAN Router only signals to the correct handler. We might also need to have the CAN Router not pop off of the queue, and only receive a signal on the callback.
New architecture for handling CAN messages: Decentralized Routing of messages via signaling in the callback. This will enable the handling of CAN messages to not obstruct the flow of any other tasks if we need to have a long wait or something
Description
Since we get data from various nodes over CAN, and some of them update interfaces within the codebase, we need to link the CAN Message Router with each respective callback. Specifically, we need to do this for:
Acceptance Criteria
Code should build and be reviewed. Also be able to successfully run on hardware without crashing the system
Proposed Solution
I think that we need to expand the functions
getFunction
(which we should rename to meet our C standards) and thevRouteCanIncoming
task that calls it.get_function
should return the specific callback relevant to a message, possibly returning one callback for multiple unique CAN IDs if it is the same node.