Lpc2000

I also write CAN protocol code for multiple devices. There is a lot of time 
invested in a J1939 or other stack, so it makes sense to write it once and 
use it in many places.

Since each device has different special features, I ended up usiing none of 
them. All messages are received by the ISR and put into a software FIFO. All 
filtering/processing is done in software. The CAN interface layer is very 
straight forward: initialise, put frame, get frame, check status.

This code runs fine on devices from 8-bit micros to Pentiums, taking in ARMs 
and some 16-bit devices on the way.

Unless you're going to commit to designing your protocols for use with a 
particular CAN controller, it is easiest to just use the "dumb" interface and 
do it all in software. These days very few people want to commit to a single 
processor for a long time, it is better to keep flexible if you can.

IMHO.



On Thursday 19 May 2005 01:59, Tutors of ESAcademy wrote:
> Some more info from our end on this subject:
>
> We are working with several commercial CANopen protocol stacks and
> originally still followed the "old" concept: in CAN receive interrupt,
> copy message received to a processing queue for later processing,
> pretty much as you would do with the FullCAN mode.
>
> On the LPC2129 we now configured CMX-CANopen to not use a FullCAN
> style mode at all and directly process RPDOs (data messages coming in)
> in the CAN receive interrupt. Including the "dynamic mapping" feature
> (every single byte of a CAN message can have a different, configurable
> destination address in memory). Even at 'only' 48Mhz this interrupt
> executes in less than 5us (that is five microseconds)...
>
> Olaf
> Tutor at ESAcademy
> www.esacademy.com
> www.canopenbook.com
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>