[En-Nut-Discussion] RFC: can_dev.c proposed changes

[Henrik Maier]

While the principal features of the AT90CAN128 CAN controller like 
receiving and sending have been implemented in the new CAN driver 
atcan.c, the filter configuration is still open.

The current can_dev generic CAN driver API is for my opinion too much 
SJA1000 centric and and the filters are configured as follow:

void CAN_SetFilter(NUTDEVICE *dev, u_char *ac, u_char *am);

ac and am point to 4 bytes each, with bit 31 the MSB of an either 11 bit 
or 29 bit CAN identifier. A special bit is reserved to identify if it is 
a remote frame or not. To set the filter bit shifting and casting is 
required.

I propose to split and change the function as follow:

CAN_SetAccCode(NUTDEVICE * dev, u_long id, int8_t idIsExt, int8_t idRemTag);
CAN_SetAccMask(NUTDEVICE * dev, u_long mask, int8_t maskIsExt, int8_t 
maskRemTag);

id and mask are 32 bit identifiers with bit 0 as LSB. The two following 
parameters are boolean parameters and identify if the id or mask is 
standard (11 bit) or extended (29 bit) and whether the frame is a remote 
frame.

Reasons: 1) Having bit 0 as LSB of either 11 or 29 bit identifiers and 
using a long type makes CAN ids easy to read and verify in the code. No 
bit shifting is required to set the filters.
2) Separating IDs and flags into separate variables makes code also 
easier to read. 3) Unlike the SJA1000, the AT90CAN128 CAN controller 
needs additional information to distinguish if the ID is 11 or 29 bit.

I am not sure if there are many users of the current can_dev driver out 
there, but the API change will certainly break their code when upgrading 
to latest Nut/OS.

To overcome this issue one could leave the current CAN_SetFilter() 
function and mark it as deprecated.

Any comments or suggestions?

Henrik Maier