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

[Henrik Maier]

Ole Reinhardt wrote:
> Hi all,
> 
> 
>>To overcome this issue one could leave the current CAN_SetFilter() 
>>function and mark it as deprecated.
> 
> 
> I would leave the current CAN_SetFilter and would create the new
> function as CAN_SetFilterMask().
> 
> All the other suggestions I totaly agree with.
> 
> RFQ: How to implement SJA specific "two filter" function for 11 Bit IDs?
> (See SJA1000 datasheet page 47). That was the main reason to implement
> the filter like it is right now.

A good point.

The filter capabilities of the various CAN chips are quite different and 
the can_dev layer can only implement a very basic filter model which can 
be implemented for all chips.

The SJA1000 has it's specific dual filter mode. The AT90CAN128 on the 
other hand can have a different filter for each of the 15 receive 
buffers. Another chip might have again a different filter model.

These differences hardly can be modelled into a generic driver, so 
applications requiring these capabilities should then bypass can_dev and 
access the sja1000.c or atcan.c driver's filter functions directly.

In case of the SJA1000 it would mean calling SJASetAccMask() and 
SJASetAccCode() instead of CAN_SetFilter().

If a user requires one of the chip specific filter functions, then he 
has to use the chip level drivers filter functions which are not generic 
but more powerful as they represent the chip's full capabilities.


Henrik