You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CAN.write() in this core returns 0 for errors but should return a negative error code.
Details
The docstring for the Arduino CAN API states that HardwareCAN::write() returns:
1 if the message was enqueued, an implementation defined error code < 0 if there was an error
This core implements HardwareCAN::write() by calling mbed::CAN::write() and directly returning the result (code, header).
However mbed::CAN::write() has a different spec for returning errors:
0 if write failed, 1 if write was successful
Discussion
This was brought up by @bthacher-crabi in odriverobotics/ODriveArduino#4 and I'd be interested what the maintainers of this repo think. Technically the meaning of return 0 is unspecified in the API, so it's unclear what client code should do with it. It's conceivable that other cores use 0 to mean "success" (which is a fairly common convention). Should we add a preprocessor special case for the mbed core specifically?
Separately, going forward it would be cool if either the code or the API specs are changed so that they are consistent.
The text was updated successfully, but these errors were encountered:
CAN.write()
in this core returns 0 for errors but should return a negative error code.Details
The docstring for the Arduino CAN API states that
HardwareCAN::write()
returns:This core implements
HardwareCAN::write()
by callingmbed::CAN::write()
and directly returning the result (code, header).However
mbed::CAN::write()
has a different spec for returning errors:Discussion
This was brought up by @bthacher-crabi in odriverobotics/ODriveArduino#4 and I'd be interested what the maintainers of this repo think. Technically the meaning of
return 0
is unspecified in the API, so it's unclear what client code should do with it. It's conceivable that other cores use 0 to mean "success" (which is a fairly common convention). Should we add a preprocessor special case for the mbed core specifically?Separately, going forward it would be cool if either the code or the API specs are changed so that they are consistent.
The text was updated successfully, but these errors were encountered: