Un bel giorno Fizzy digit�:

> Still no buddy telling me what is time stamping? Is the recorded time
> when a message is received. If this is so ...... isn't it easy just to
> see that time and calculate down the time. (Obviously you have to know
> the data rate of the incomming message consider worst case senario)
> ??????

I don't understand this need for hardware timestamping for CAN messages. We
aren't talking about asynchronous capture inputs when even 100 nanoseconds
latency is an issue. On a CAN bus you hardly will see more than 5000-10000
messages/s (and on a real-world CAN bus, not more than 1000 msg/s),
therefore I think that the latency from the message entering the mailbox
and the ISR that will process it is irrelevant. You just have to add the
timestamp in the ISR, when you dispatch the message from the mailbox to
wherever you want.

-- 
asd

Fizzy wrote:

> Hi Tim,
> 
> I like your idea of timestamping. But i have a very little knowledge
> about timestamping since it is not the part of CAN protocol. I guess
> may be my question was not completely understood. As i said transmitter
> does not send any information about the freshness of data or the time
> when the data is sent. My CONCERN is to make sure that i receive the
> data after every certian time and if do not see the data than i declare
> it stale. One of the idea that i had was to look at the interrupt and
> when i see interrupt happeing start a downward-counter. Now until the
> counter reaches to 0 if i see another interrupt happening than i have a
> new data other wise i would flag the data stale. Problem is that if i
> have 100 different messages how would i keep track of all thoes 100
> messgaes (with different ID).
> 
> Thanks
> 
Many CAN controllers have a register as part of each mailbox that gives 
you the local time that the message was received.  As others have 
pointed out, this only tells you when the message was received -- not 
when it was transmitted.

If you need to be able to tell when a message was constructed, then you 
should put a timestamp in the message (or perhaps a sequence number). 
You'll still need a way to globally synchronize your devices on the bus, 
but you can do this with a special, short, high-priority sync message.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

Fizzy wrote:

> Well Tim, Interrupt just tell you that data is received they are not
> tied to message ID. What i am trying to say is that interrupt will tell
> you that there is a message but it won;t tell you what message
> 
True -- you have to stay on top of the incoming messages.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

On Thu, 20 Apr 2006 18:03:46 +0000, Hans-Bernhard Broeker wrote:

> Paul Keinanen <keinanen@sci.fi> wrote:
> 
>> If accurate time information is needed, the event should be time
>> stamped at the source and the time stamp and the event value should be
>> transmitted in the same frame. 
> 
> Unfortunately, this can easily open a whole new can of worms all by
> itself.  CAN nodes don't routinely have real-time clocks.

If my memory is correct, Freescale's MSCAN module has a two byte timestamp
for both transmitted and received messages.  I believe the transmitted
message timestamp is updated on receipt of ACK.  The module can be
configured to zero this timer on receipt of a message into buffer 0.  

I don't know if other manufacturers modules have this capability, but the
OP did mention Freescale.


    ~Dave~

Well Tim, Interrupt just tell you that data is received they are not
tied to message ID. What i am trying to say is that interrupt will tell
you that there is a message but it won;t tell you what message

Still no buddy telling me what is time stamping? Is the recorded time
when a message is received. If this is so ...... isn't it easy just to
see that time and calculate down the time. (Obviously you have to know
the data rate of the incomming message consider worst case senario)
??????

Paul Keinanen wrote:

> On Thu, 20 Apr 2006 16:12:47 -0000, Grant Edwards <grante@visi.com>
> wrote:
> 
>>I think he wants to know when the data was sent, not when it
>>was received.  On a high-traffic CAN bus, low-priority packets
>>can (in theory) be delayed in the sending controller for a long
>>time.
> 
> At least when using CanOpen, this is a practical problem, if the
> TxPDOs are triggered by the SYNC message from the master. In a large
> system with 64-127 nodes in the worst case you may have more than 100
> TxPDO1 response frames after a SYNC request message, delaying any low
> priority message with hundreds of frame times if multiple TxPDOs are
> used.
> 
> Paul

But in this case, a SYNC protocol using CANopen network, the importand
messages should be SYNCronized, synchrounous PDOS. And in this case its
really clear, not the time of receiving or transmitting is importand but
the time the data were sampled, and that is the time when all nodes saw the
SYNC message. And SYNC can have a jitter, but thats known, it's typical the
maximum length of CAN message. 

Best regards
  Heinz

On Thu, 20 Apr 2006 16:12:47 -0000, Grant Edwards <grante@visi.com>
wrote:

>I think he wants to know when the data was sent, not when it
>was received.  On a high-traffic CAN bus, low-priority packets
>can (in theory) be delayed in the sending controller for a long
>time. 

At least when using CanOpen, this is a practical problem, if the
TxPDOs are triggered by the SYNC message from the master. In a large
system with 64-127 nodes in the worst case you may have more than 100
TxPDO1 response frames after a SYNC request message, delaying any low
priority message with hundreds of frame times if multiple TxPDOs are
used.

Paul
  

Fizzy <fpgalearner@gmail.com> wrote:
> Hi Tim,

> I like your idea of timestamping. But i have a very little knowledge
> about timestamping since it is not the part of CAN protocol. I guess
> may be my question was not completely understood. As i said transmitter
> does not send any information about the freshness of data or the time
> when the data is sent. 

I already pointed out that in this case, unless that transmitting node
is seriously negligent in design and documentation, there still has to
be *some* way of finding out how non-fresh those data will ever be.
It'll say omewhere that this gadget will re-acquire actual data no
longer than <n> milliseconds than the previous one, and it will
trigger a transmission of its message ever <m> milliseconds.  Find
this information and use it.  If you can't find it, sue the gadget's
vendor and/or remove their junk from your designs.

> My CONCERN is to make sure that i receive the data after every
> certian time and if do not see the data than i declare it stale. 

It's impossible to say much about whether this is worth trying without
knowing more about the traffic on your CAN bus: bit rate, message load,
priorities, and such.

> have 100 different messages how would i keep track of all thoes 100
> messgaes (with different ID).

Not in a single timer, obviously.  You'll need a receive-everything
message box, 100 "receive slots " in main RAM, each with a time stamp
stating "this data is until:", and static data that tell the interrupt
handler how long this validity period, starting the moment it was
received.  Then you need an interrupt handler that stuffs the message
in the appropriate slot, and updates the "best before:" stamp.  And
some other task will have to watch that list for stale data,
continuously.  It may be necessary to optimize that watcher task by a
priority queue of which data will go stale next.


-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Paul Keinanen <keinanen@sci.fi> wrote:

> In networks with more than one potentially active transmitting node,
> the transmission of any low priority message can be greatly delayed
> due to any messages from other nodes with higher priority (lower
> message-ID).

Suffice it to say that if that ever becomes a realistic concern,
somebody must have royally blown the message priority planning of his
CAN bus.  CAN has message priorities for the express purpose of
avoiding this problem.

If a message can go stale (as in: too old to be useful) waiting in its
outgoing message box, because other messages hogged the bus for too
long, then the priority of those other messages relative to the one
under study is clearly too high, or the CAN bus was loaded beyond its
capabilities.

> If accurate time information is needed, the event should be time
> stamped at the source and the time stamp and the event value should be
> transmitted in the same frame. 

Unfortunately, this can easily open a whole new can of worms all by
itself.  CAN nodes don't routinely have real-time clocks.

> In this way, the receiver can
> reconstruct when the event actually happened, even if the message
> delivery was delayed by several frame transmission times due to
> several high priority messages from other nodes.

> Paul


-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.