upcoming lpc17xx CAN driver

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

upcoming lpc17xx CAN driver

Bernard Fouché-2
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