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
The CAN specification reserves a bit in the arbitration header to signal if the frame is a Remote Transfer Request (RTR) frame or a normal Data frame. This is the bit that follows the 11 identifier bits in the standard header, or the 18 bits of the second part of the identifier in an extended frame.
This is useful for system that use RTR (yes I know this is frowned on by some in the CAN community, see linked doc). However systems exist that require this support so we should enable the Uno R4 to detect if a frame has been sent with the RTR bit.
Given that the flag is already detected by the underlying FSP and the type appears in the "can_frame_t" CAN data frame struct, there is a relatively simple enhancement which I will float here.
The first part is to add it as a data member to the CanMsg class (in CanMsg.h)
uint32_t id;
uint8_t data_length;
uint8_t data[MAX_DATA_LENGTH];
bool remote; // == new member ==
and then add it to the constructors as an optional argument
(It would also need to be copied across in the copy constructor and probably useful to emit it in the printTo function.)
This now makes it available, however it is always set to false so the msg will default as a data frame unless the flag is set when the object is created.
For incoming messages in the R4 Uno this occurs in the R7FA4M1_CAN.cpp file
void R7FA4M1_CAN::onCanCallback(can_callback_args_t * p_args)
{
switch (p_args->event)
{
case CAN_EVENT_TX_COMPLETE: break;
case CAN_EVENT_RX_COMPLETE: // Currently driver don't support this. This is unreachable code for now.
{
/* Extract the received CAN message. */
CanMsg const msg
(
(p_args->frame.id_mode == CAN_ID_MODE_STANDARD) ? CanStandardId(p_args->frame.id) : CanExtendedId(p_args->frame.id),
p_args->frame.data_length_code,
p_args->frame.data,
(p_args->frame.type == CAN_FRAME_TYPE_REMOTE) // == new argument ==
);
/* Store the received CAN message in the receive buffer. */
_can_rx_buf.enqueue(msg);
}
//snip
I have not considered whether this would also require a change to files related to other 32 bit Renases chips (most likely yes).
However it appears to be largely backwards compatible as it does not affect the id (the other option was to use bit 30 if the id).
So, looking for some feedback before I do any further work and potentially provide a PR.
I am transferring the issue you've created over here from ArduinoCore-renesas since your request needs to be added to the high-level API shared by all CAN-supporting cores (apart from ArduinoCore-renesas that's only ArduinoCore-mbed at this moment).
Maybe you can provide a PR to this repository how you'd like to augment CanMsg.h in order to enable RTR?
The CAN specification reserves a bit in the arbitration header to signal if the frame is a Remote Transfer Request (RTR) frame or a normal Data frame. This is the bit that follows the 11 identifier bits in the standard header, or the 18 bits of the second part of the identifier in an extended frame.
This is useful for system that use RTR (yes I know this is frowned on by some in the CAN community, see linked doc). However systems exist that require this support so we should enable the Uno R4 to detect if a frame has been sent with the RTR bit.
Given that the flag is already detected by the underlying FSP and the type appears in the "can_frame_t" CAN data frame struct, there is a relatively simple enhancement which I will float here.
The first part is to add it as a data member to the CanMsg class (in CanMsg.h)
and then add it to the constructors as an optional argument
(It would also need to be copied across in the copy constructor and probably useful to emit it in the printTo function.)
This now makes it available, however it is always set to false so the msg will default as a data frame unless the flag is set when the object is created.
For incoming messages in the R4 Uno this occurs in the R7FA4M1_CAN.cpp file
I have not considered whether this would also require a change to files related to other 32 bit Renases chips (most likely yes).
However it appears to be largely backwards compatible as it does not affect the id (the other option was to use bit 30 if the id).
So, looking for some feedback before I do any further work and potentially provide a PR.
/-------------------
https://copperhilltech.com/content/CiA%20802%20AN%20V1.0%20CANopen%20CAN%20remote%20frames%20%E2%80%93%20Avoiding%20of%20usage.pdf
The text was updated successfully, but these errors were encountered: