I'm using the MCP_CAN_lib library at a speed of 10 kbps.
Currently, the TIMEOUTVALUE macro is hardcoded to 2500 microseconds,
which makes it difficult to use the library at lower CAN bus speeds like 10 kbps.
At such low speeds, transmitting a single CAN frame can take longer than 2.5 ms,
causing sendMsgBufBlocking() to timeout even in normal conditions.
To work around this, I wrapped the TIMEOUTVALUE definition in a #ifndef,
so that it can be overridden using a compiler flag like -DTIMEOUTVALUE=20000.
This does require modifying the library source code, though.
Is this a reasonable solution, or is there a better/cleaner way to make this configurable?
Pull request link is Make TIMEOUTVALUE macro configurable via compiler flags by zharovdv · Pull Request #35 · coryjfowler/MCP_CAN_lib · GitHub
Looks good to me, it is simple and backwards compatible.
One alternative is to make an uint32_t variable CANtimeout with a default of 2500 and add two functions
- uint32_t getTimeout() and
- bool setTimeout(uint32_t to)
Might need more work to get it working, however the advantage is you could add logic like "0 ==> no time out" to extreme long timeouts of several minutes. And changing the timeout depending on e.g. command sent or device contacted. The set function could guard a reasonable minimal timeout of e.g. 1000 us.
An even more elaborated alternative would combine the two methods.
1 Like
The chip has a transmit buffer so there is no need for the tx function to be blocking.
I modified my version of the library to be non-blocking. Simply put the outgoing packet in one of the free buffer slots and immediatly return. If there are no free slots then return an error code and handle that in your application code.