I-class CAN driver APIs

[tinito]

Hi,

I'm working a lot with ChibiOS & CAN, and I've noticed that the CAN driver is pretty different from other drivers, e.g., no interrupt callbacks and no I-class functions.
There is any plan to "upgrade" the CAN driver? I would be happy to modify it to reflect the structure of the UART driver for example. Any drawback / suggestion?

[Giovanni]

Not sure, is a callback scenario needed for this driver? as long the new implementation is capable of dealing with FIFOs of messages the we can discuss it. Make your proposal.

(The scenario would not be one-callback for one-message).

Giovanni

[tinito]

Callbacks can be useful in real-time applications, e.g. to reduce latency and jitter and timestamp data in distributed control loops, But I know this may be a not so common scenario. (in my particular application, I need one callback for one message).

Anyway, what I miss are the I-class functions, as I have to transmit time-triggered messages from a timer interrupt handler. I was thinking about introducing the I-class functions like other drivers, with the standard functions locking the system and calling the I-class functions.

[Giovanni]

Adding variants of the current API would be simple but note that the variants of canReceive() and canTransmit would be S-class not I-class because both functions change the thread state inside.

Creating I-class variants would be a bit more complicated because the API would have to change slightly or two new functions would have to be added:
- canTryReceiveI()
- canTryTransmitI().

(without internal wait, immediate exit in any case).

I think it would be a good enhancement of the driver. Adding callbacks in addition or as alternative to events would also be possible.

Giovanni

[tinito]

It turned out that we require some more "custom" CAN functionality to have our real-time CAN messaging system working. So we are designing a specific driver (something like "RTCAN") replicating the standard ChibiOS HAL driver schema, I'll post it when it will be ready, maybe someone could be interested in it.

Thanks,
Martino

[Giovanni]

That is a good approach too, the HAL is meant to be extensible with custom drivers and, of course, custom drivers can use the same templates and conventions.

Anyway, I am interested in a CAN driver rework, it is the only driver that did not receive a revision since first appearance. Keep us updated.

Giovanni

[tinito]

Ok, finally back to CAN driver development (after 1 month, ough).
I've looked into other HAL implementations and read the I2C development thread, and I'm trying to reorder my idea to match general ChibiOS style and "requirements".
Here a list of concepts I've collected, please correct me if I'm wrong:
- the CAN driver is almost the only driver that uses Events (despite from what written here http://www.chibios.org/dokuwiki/doku.ph ... :kb:events)
- generally callbacks-based asynchronous drivers are preferred, with optional synchronous (WAIT) support
- timeouts are present only in CAN and I2C implementations (in this case, i suppose to overcome STM32 i2c issues). They (I guess) also prevent from having I-class APIs as chSemWaitTimeoutS() is needed, and as a consequence prevent using from inside an ISR.

So, I would like to develop a driver more similar to ADC/SPI drivers model, with:
- canStartTransmit()/Receive(), and their I-class APIs, as asynchronous interface with callbacks (and maybe events if enabled through a CAN_USE_EVENTS define)
- canTransmit()/Receive(), if CAN_USE_WAIT is TRUE, that put the calling thread in wait state as in the other drivers
- canAbortTransmit()/Receive() to exit the wait state from the application
- if needed, a canTransmitTimeout()/ReceiveTimeout() using a GPT or an hardware timer like in I2C driver to prevent infinite wait (but - i'm not sure - CAN controllers usually count tx/rx fails and raise an interrupt when some limit is reached)

I would also include a mailbox/fifo field in the CanTxFrame/RxFrame structures to store where the message has been enqueued, needed to abort ongoing operations.

A note: a CAN message at 1Mbps (maximum CAn speed) takes from about 45uS to 160uS to complete their transmission, so callbacks should not be called more often then when performing adc/spi transfer, that are usually much faster.

Do you think it could be a reasonable driver structure? Or did you think a different architecture?

Thanks,
Martino

[Giovanni]

There are other drivers using events, MAC and Serial for example but I think that CAN could go in the direction of a callback-based driver.

In general, I agree with the proposed direction:

1) Introduce callbacks: OK.
2) Add optional synchronous calls like SPI: OK.
3) Timeout: Only in the synchronous calls, see MAC driver.
4) Optional events: OK, again see MAC driver.
5) Extra fields: OK as long the default fields are retained and the extra ones can be defaulted to zero.

Just a note, probably also errors will need their callback.

Giovanni

[tinito]

I forgot another thing: i would like to have filters configurable at run-time, but this means have a non-const filter structure, that consumes RAM.
Should this be an optional feature, leaving const filters as default?

[Giovanni]

Hi,

Currently the CAN configuration structure points to a separate table of filtes which can already point to a non-const table, what are you proposing exactly?

Giovanni