I-class CAN driver APIs

[Giovanni]

At least the weirdness would be restricted to the weird platform

[tinito]

Ehehe That unfortunately is the platform I have to use every day...

Last thing: about giving back to the caller the ID of the filter that as been added, in order to have, e.g., an array of callback to handle the incoming filtered message, where should I put it? In an additional field of the canFilter structure, that is filled by canAddFilter()?

EDIT: adding a whole bank at time on STM32 means that I cannot give back a _single_ filter ID, thus I cannot set an array of callbacks...

[Giovanni]

How the STM32 identifies the filter once a packet is received and accepted?

[tinito]

This is the weirdest part: the filtering scheme is a total mess, the number of a filter depends on how the previous filters have been configured. And also depends on which FIFO the filters have been assigned to.
As attachment a filter numbering example from the reference manual, that shows the "scheme" (I would not call it "scheme" at all).
Then, when a CAN frame matches a filter, the ID of the filter is inserted in the FIM (Filter Index Match) of the RxFrame that can be retrived by the application.

[Giovanni]

The FMI is already returned to the application in the CANRxFrame structure so there is no need to pass this index to the callback nor to add abstractions over this part IMO.

[tinito]

Yes, but how can I map that FMI to my application?
The application registers a filter, but it has to know where it has been inserted (its index), to later recognize which filter that FMI corresponds to. If not, I know the FMI but I cannot use it to recognize the message, I've to look at the CAN ID in my software. I was thinking for example about having an ordered array with callbacks, so filter X calls callback X. But to setup that array I need the index back when I register a new filter, this is why I thought about some tracing of the filter numbers (for STM32: on other microcontrollers it is much easier as they have MOBs).

[Giovanni]

Having arrays of callbacks would negate memory savings, having such arrays in RAM is not even an option. What you could do is to create some kind of STM32-specific conversion routine from index to FMI.

Alternatively canAddFilter() could return some kind of platform-specific identifier (FMI).

Giovanni

[tinito]

Sorry, the array of callbacks is in my application not in the CAN driver.
What I would have in the driver is that canAddFilter() returns the platform-specific identifier, but if we have to program a complete filter bank at time, I have to return multiple indexes..

[Giovanni]

Then probably it is better to leave filters like now in configuration, it is up to the application to deal with those platform-specific details, complete abstraction is not a requirement in the HAL, the aim is to provide a reasonable abstraction level and seal the platform-specific details into the configuration structures.

The configuration structures are now written manually but the idea is to have SW configuration tools that generate them starting from a GUI or an high level description XML.

Giovanni

[tinito]

Ok, I'll leave it as is, while trying to write some helper function that keep trace of the last FMI inserted without the need of filling an entire bank at time (trying to emulate MOBs based filters). If they will work I'll post them and you will evaluate them