Lpc2000

The following statement was given as response to a question via
Philips online support: 

"The attached errata lists the known bugs in the LPC2119.  Note that
FullCAN mode is not operative. Hence the CAN module on our ARM7
doesn't currently support 29 bit identifier because Full CAN is
inoperative."

Did there somebody mix up the terms FULL-CAM and 29 Bit identifier's??

Of course we use 29 Bit identifier in our actual LPC2292 project.
But we found a problem with global acceptance filtering:
We have a master sending frames to severall slaves and the slave
respond to this frames.
To reduce the interrupt overhead in the slaves, we use acceptance
filtering to filter all master frames, this is possible because we
defined one Identifier bit to be a direction Bit (0: Master => Slave,
 1: Slave => Master)

Before we used exceptance filtering we got overflow errors, because
every slave node also got the answer of all the other slave nodes.

When we use acceptance filtering we don't get this overflow errors,
but now it happens that our LPC-2292 Node stops to generate
CAN-Interrupts at all !

Did anybody made comparable experiences with the CAN-Interrupts.

Andreas Lipowsky

Andreas,

you are right and you are right. It seems somebody mixed up FallCAN 
and extended identifiers and 29-bit identifiers are supported. For 
sure the LPC229x and as well the single chip versions 21x9, 2194 they 
are all using the same CAN interface and they all support 29-bit 
indentifiers.  The filtering works perfectly for extended 
identifiers. 

The mix up might be from the fact that even when the FullCAN mode 
will be fixed, the FullCAN mode does not support 29-bit identifiers, 
only 11-bit.

A little bit more information about the difference between the 
FullCAN mode and let's call it the gateway mode assuming a fully 
functional FullCAN. 

If a message is received in FullCAN mode, it is transfered by an 
internal statemachine (let's call it CAN-DMA) into the assigned 
message object buffer. The other feature that is often assigned to 
FullCAN, the filtering can also (even better) be done in the gateway 
mode. 

In the gateway mode, the CAN implementation offers up to 1024!! 
filters for standard frames (11-bit identifiers) or up to 512 filters 
for extended (29-bit) identifiers.  This is MUCH more than any 
existing FullCAN implementation would allow.

Summary: you can filter for 29-bit, the filtering options in gateway 
mode outperform any existing FullCAN implementation but your software 
has to deal with the (filtered) messages you receive and move them to 
their final destination in memory otherwise they can be overwritten 
by new incoming messages.

Hope this helps you and does not confuse too many of the others not 
so familiar with CAN :-)

Robert 

--- In lpc2000@yahoogroups.com, "alipowsky" <a.lipowsky@g...> wrote:
> 
> The following statement was given as response to a question via
> Philips online support: 
> 
> "The attached errata lists the known bugs in the LPC2119.  Note that
> FullCAN mode is not operative. Hence the CAN module on our ARM7
> doesn't currently support 29 bit identifier because Full CAN is
> inoperative."
> 
> Did there somebody mix up the terms FULL-CAM and 29 Bit 
identifier's??
> 
> Of course we use 29 Bit identifier in our actual LPC2292 project.
> But we found a problem with global acceptance filtering:
> We have a master sending frames to severall slaves and the slave
> respond to this frames.
> To reduce the interrupt overhead in the slaves, we use acceptance
> filtering to filter all master frames, this is possible because we
> defined one Identifier bit to be a direction Bit (0: Master => 
Slave,

>  1: Slave => Master)
> 
> Before we used exceptance filtering we got overflow errors, because
> every slave node also got the answer of all the other slave nodes.
> 
> When we use acceptance filtering we don't get this overflow errors,
> but now it happens that our LPC-2292 Node stops to generate
> CAN-Interrupts at all !
> 
> Did anybody made comparable experiences with the CAN-Interrupts.
> 
> Andreas Lipowsky

Is it correct, that the FullCANmode is not yet operational? When will
it be fixed? What will be the expected performance advantage of the
FullCANmode compared to the BasicCANmode?

Thanks, Klaus    
--- In lpc2000@yahoogroups.com, "philips_apps" <philips_apps@y...>
wrote:
> 
> Andreas,
> 
> you are right and you are right. It seems somebody mixed up FallCAN 
> and extended identifiers and 29-bit identifiers are supported. For 
> sure the LPC229x and as well the single chip versions 21x9, 2194
they 
> are all using the same CAN interface and they all support 29-bit 
> indentifiers.  The filtering works perfectly for extended 
> identifiers. 
> 
> The mix up might be from the fact that even when the FullCAN mode 
> will be fixed, the FullCAN mode does not support 29-bit
identifiers, 
> only 11-bit.
> 
> A little bit more information about the difference between the 
> FullCAN mode and let's call it the gateway mode assuming a fully 
> functional FullCAN. 
> 
> If a message is received in FullCAN mode, it is transfered by an 
> internal statemachine (let's call it CAN-DMA) into the assigned 
> message object buffer. The other feature that is often assigned to 
> FullCAN, the filtering can also (even better) be done in the
gateway 
> mode. 
> 
> In the gateway mode, the CAN implementation offers up to 1024!! 
> filters for standard frames (11-bit identifiers) or up to 512
filters 
> for extended (29-bit) identifiers.  This is MUCH more than any 
> existing FullCAN implementation would allow.
> 
> Summary: you can filter for 29-bit, the filtering options in
gateway 
> mode outperform any existing FullCAN implementation but your
software 
> has to deal with the (filtered) messages you receive and move them
to 
> their final destination in memory otherwise they can be overwritten 
> by new incoming messages.
> 
> Hope this helps you and does not confuse too many of the others not 
> so familiar with CAN :-)
> 
> Robert 
> 
> --- In lpc2000@yahoogroups.com, "alipowsky" <a.lipowsky@g...> wrote:
> > 
> > The following statement was given as response to a question via
> > Philips online support: 
> > 
> > "The attached errata lists the known bugs in the LPC2119.  Note
that
> > FullCAN mode is not operative. Hence the CAN module on our ARM7
> > doesn't currently support 29 bit identifier because Full CAN is
> > inoperative."
> > 
> > Did there somebody mix up the terms FULL-CAM and 29 Bit 
> identifier's??
> > 
> > Of course we use 29 Bit identifier in our actual LPC2292 project.
> > But we found a problem with global acceptance filtering:
> > We have a master sending frames to severall slaves and the slave
> > respond to this frames.
> > To reduce the interrupt overhead in the slaves, we use acceptance
> > filtering to filter all master frames, this is possible because we
> > defined one Identifier bit to be a direction Bit (0: Master => 
> Slave,
> >  1: Slave => Master)
> > 
> > Before we used exceptance filtering we got overflow errors,
because
> > every slave node also got the answer of all the other slave nodes.
> > 
> > When we use acceptance filtering we don't get this overflow
errors,

> > but now it happens that our LPC-2292 Node stops to generate
> > CAN-Interrupts at all !
> > 
> > Did anybody made comparable experiences with the CAN-Interrupts.
> > 
> > Andreas Lipowsky

--- In lpc2000@yahoogroups.com, "Klaus" <klaus276@y...> wrote:
> Is it correct, that the FullCANmode is not yet operational? When 
will
> it be fixed? What will be the expected performance advantage of the
> FullCANmode compared to the BasicCANmode?

Just do all your filtering etc in software. This does not add any real 
loading to an ARM7.

Unless you need absolutely every % of the CPU I doubt you'd notice the 
difference between FULL and Basic modes.

Charles and Klaus,

a little update on CAN and a few clarifications.
The term FullCAN and BasicCAN seem to be a little mixed with assumption 
was the one or the other does / does not do.
The FullCAN mode is still not operational on the current CAN devices 
such as LPC21x9, LPC2194 and LPC229x but the redesign has started, 
can't tell you yet for sure when the bug-fixed devices will be on the 
market but my best guess is end of Q4 this year.

FILTERING:
The difference between FullCAN (FC) and our other CAN mode, which I 
like to call Extended CAN (EC) is filtering but not as you expect. The 
EC offers MUCH more fitlering options than the FC mode. Literally 
hundreds of messages can be filtered from a stream of ongoing CAN 
messages without receiving a single message you are not interested in. 

OFFLOADING RECEIVE REGISTER:
This is the real difference between FC and EC. In FC mode, the message 
will automatically be transferred into a dedicated message buffer, in 
EC mode, your software will have to take care of moving the (filtered) 
message to its final destination before the next complete message has 
been received. As Charles mentioned this is not a high CPU load for an 
ARM running at ?? MHz. 

29-BIT IDENTIFIERS:
FC as implemented does not and will not support 29-bit identifiers, 
however our EC mode does fully support 29-bit identifiers. 

CAN PERFORMANCE:
You can definitely run all (max 4) CAN interfaces at max speed of 1 
Mbit and even receive every single message with 100% busload and still 
have processing power left to do something else. So there is no impact 
on CAN performance because of fixing the FC mode. 

Hope this helps and gives some additional information, Robert


--- In lpc2000@yahoogroups.com, "embeddedjanitor" <manningc2@a...> 
wrote:
> --- In lpc2000@yahoogroups.com, "Klaus" <klaus276@y...> wrote:
> > Is it correct, that the FullCANmode is not yet operational? When 
> will
> > it be fixed? What will be the expected performance advantage of the
> > FullCANmode compared to the BasicCANmode?
> 
> Just do all your filtering etc in software. This does not add any 
real 
> loading to an ARM7.
> 
> Unless you need absolutely every % of the CPU I doubt you'd notice 
the 
> difference between FULL and Basic modes.

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

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
>
>
>