CANBUS: SJA1000 talks to MICROCHIP

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
My system has 3 types of CAN Node:
1.SJA1000
2.PIC18F458
3.87C592

I encounter one problem when I run my system.
The SJA1000 repeats occuring BUS Error(type:stuff error on IDxx.xx)
 for every 4 sec.
I found the error occurs on receving one specific message.

the crystal on each device are 11.0592.
I set the sampling point on 80%.

The register definition in PIC and SJA1000 are different.
PIC needs to define the PROP delay.
SJA1000 has no means to define that delay.

So I don't know how to set the register.

How to choose the PIC's PROP delay ?
and
Why SJA1000 don't need it ?

Re: CANBUS: SJA1000 talks to MICROCHIP

Quoted text here. Click to load it

That's not exactly the information needed to define a CAN bus bit
timing.  What are the clock dividers for each of those devices,
i.e. what's the time quantum?  And what _are_ the actual settings on
each type of node?  (N_TSEG1, N_TSEG2, N_SJW, others?)

Quoted text here. Click to load it

That's a strange way to set up things, indeed.  Are you sure you're
reading the PIC's datasheet correctly regarding the meaning of that
setting?

The actual propagation time, t_PROP is not even a controllable
parameter of the definition of the actual bit timing in the first
place.  It's a limit set by the transceivers and cabling that the bit
timing must be designed to obey:

  t_PROP < (N_TSEG1 + 1 - 25 * (N_TSEG1 + N_TSEG2 + 1) * \delta(t_q)) * t_q

Note that this includes \delta(t_q), the error of the time quantum
length due to clock variations.  That's a rather volatile parameter
not really under control of the uC, so I really don't see you could
ever deduce values for N_TSEG1 or N_TSEG2 from a set value for t_PROP.

Quoted text here. Click to load it

And rightly so, I'd say...

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

Site Timeline