upcoming lpc17xx CAN driver

upcoming lpc17xx CAN driver

[Bernard Fouché]

Hi All.

I shall propose in the next weeks a CAN driver for the LPC17XX. At the 
moment it is based on the LPC2XXX CAN driver to try to keep code reuse. 
However I face a problem: I don't have any LPC2XXX hardware at hand (and 
would not have time to perform LPC2XXX specific tests anyway).

One problem is that the LPC2XXX has two ways of processing the CAN 
related interrupts: some versions have different TX and RX interrupts, 
some others have a single interrupt for both, like the LPC17XX: I'm 
unable to test the behavior of the first kind of processing, I did not 
reflect my changes in the involved DSRs because of this. More, the 
LPC2XXX driver takes care of two MCU errata that do not exist for the 
LPC17XX. Again I have no mean to test this.

Beside being based on the LPC2XXX code, I've added features I need:

- TX events fully processed, allowing the event consumer to retrieve the 
content of sent messages (as soon as more than one TX buffer is involved 
(see next change), user code must be able to know what message has been 
sent when a TX event is reported because it's the hardware that decides 
of the order of TX buffer sending). This means that in case of 
simultaneous RX and TX conditions reported by the hardware, the DSR must 
call more than once the event handler (the CAN IO package knows only 
about a single event at a time).

- support for the 3 TX buffers instead of a single one. This requires 
the following combinations to be supported:

     - single TX buffer, without TX event processing (LPC2XXX base code)
     - single TX buffer, with TX event processing (was not functional in 
LPC2XXX)
     - triple TX buffer,  without TX event processing.
     - triple TX buffer, with TX event processing.
     - optional TX message content retrieval (either for single or 
triple buffers)

(of course the processing must be optimal for each case so it introduces 
different #ifdef in the DSR...)

- repeated processing in the DSR since a single RX interrupt may report 
more than one RX free buffer: the hardware has two RX buffers, and to 
lower chances to reach a RX overrun (a major concern for me), the 
updated DSR tries to process more than a single event (of any kind) if a 
new event appears during DSR processing (because these 2 RX buffers 
appears as a FIFO). However the number of DSR loops is limited to avoid 
a never ending loop. Such a condition occurs for instance when the CAN 
bus is left hi-z, the 'bus error' condition is nearly continuous.

- many small fixes here and there + support for cdl configuration of the 
bit nominal time (for CAN buses that require specific setup, or to have 
the user certain of using the bit setup it wants instead of relying on 
an invisible bit rate definition)

- I did not implement yet single shot TX because this would require a 
modification in the CAN IO package, but why not :-)

If someone reading this is using the LPC2XXX hardware and have time to 
perform tests, then we may keep a single driver for all variants. 
However the combination of the different options (hw/ with or w/o 
errata/sw) is large. Serious testing also means being able to use an 
altered CAN bus to check error processing/reporting, this is the only 
way to be sure that the driver can handle real world situations.

If no one volunteers for LPC2XXX testing, then I think it is more 
reasonable to release the updated driver as a LPC17XX only driver.This 
would also allow me to drop the LPC2XXX code for errata managment as 
well as the old interrupt scheme and the resulting driver would be less 
complex to maintain.

BTW the driver could always be ported back to LPC2XXX at a later time by 
a volunteer ;-)

Comments welcome!

    Bernard