Improve CAN send reliability and program flow

[superdan-t]

If too many CAN frames are sent, the program crashes with a segmentation fault. Something within CAN send is probably buffered, and thus sends are non-blocking (evident by the fact it's even possible to send too fast).

It is likely possible to do blocking sends on the CAN socket so that this doesn't happen. Then, sends can be moved to a new thread.

This design will use two threads:

• Main thread for network, calculations, etc.
• CAN thread that checks the timers and sends updates

[superdan-t]

The original description is from 13 days ago. It summarizes some of the problems, but the solution is still in design. I will post my ideas within the next hour.

[superdan-t]

My ideas:

• Move code for can socket into an object: rover_can::Socket
• Socket has a send function: async_send_to(<variables needed to send...>, const std::function<void(rover_can::ErrorCode)>& send_callback = nullptr);
  • Async send will add the data and callback to an outgoing queue and then return immediately.
  • The worker thread will eventually send the data, and if the callback is not null, dispatch it with the send status (success or error)
  • The outgoing queue must be protected by a lock (std::mutex) and also have a condition variable std::condition_variable. When enqueuing, the lock must be locked, and then the condition variable notified before returning.
  • The worker must lock to check the queue. If the queue is empty, wait on the condition variable and then retry. If data is available, copy the outgoing queue and release the lock. Then, do a blocking send on the copy. (Making a copy means that the queue can be used while the send is in progress)
• Socket has a receive function: async_receive_from(<variables needed to request...>, const std::function<void(ReceivedDataType, rover_can::ErrorCode)>);
  • Similar to async send, but the callback is dispatched when the data is received
• I don't know if you want to implement the socket object so that you can send and receive on the same one, or if you want to make it so two sockets are required. Either is fine
• Handlers must be called on the main thread, even though the worker threads will want to dispatch them. To synchronize them, you can use a vector of callbacks that are ready for dispatch. The main loop should call a method to run everything in the queue and clear it.

[superdan-t]

@jmcmah10 Is this issue relevant anymore? I think everything here got worked into other issues.

[jmcmah10]

@superdan-t it's not, it can be closed