Yahoo Groups archive

68300

Index last updated: 2026-04-29 00:01 UTC

Thread

68376: CAN bus rate and length issue

68376: CAN bus rate and length issue

2002-08-28 by Godiska, Jim

Hello List,
 
I am currently using the MC68376 (using a 20 MHz external clock oscillator
chip) along with Phillips TJA1050 CAN transceiver and the typical 120 ohm
terminating resistors on the bus.  Currenly, I have a machine set up with a
1 MHz bit rate, 35 nodes (in a linear network with no stubs), and a length
of about 85 feet, but the CAN bus starts going nuts.  It seems that if I
shorten the network to 31 nodes (with about 13 feet less cable length), then
the CAN bus appear to be working.  If I try a different combination of 31
nodes out of the 35, it also works again.  If I take the 31 node network and
remove one 1 foot interconnect cable and insert a 26 foot cable, the bus
goes nuts again.
 
At this point I am beginning to believe that the problem is simply the cable
length of the network.  The obvious solution may be to drop the bit rate
down to, say, 500 kHz.  However I have a few questions first.
 
1.  I can set up the parameters in the CAN module one of two ways.
Currenlty, I am using:
 
        _TOUCAN.CANCTRL1 = 0x87;        // Low tolerance clock, 1MHz CAN bus
        _TOUCAN.PRESDIV = 0x00;
        _TOUCAN.CANCTRL2 = 0xF3;
 
The other option is:
 
        _TOUCAN.CANCTRL1 = 0x04;        // High data rate, 1MHz CAN bus
        _TOUCAN.PRESDIV = 0x01;
        _TOUCAN.CANCTRL2 = 0x49;

Which would be better?
 
2.  If I drop the bit rate, does should I set the paramters more for a
higher data rate mode or for more of a less accurate clock mode?
 
3.  Does anyone have a chart showing recommended cable length, nodes, and
various bit rates for the CAN bus?
 
4.  Using a split terminating resistor with a center tapped capacitor tied
to ground, would help with noise issues, but I am thinking this is not the
main cause.  Do you agree?
 
5.  I am currently using 22AWG twisted shielded cable with the shield being
termiated at one end only.  I can increase the wire size to 20 AWG which
should help the bus length somewhat according to one application note that I
found, but I do not believe it to be a significant contributor to the
problem.  Any opinions?
 
6.  In the early days of investigating CAN bus implementations, I thought I
saw that the maximums were 1 MHz bit rate at a 50 meter length and about 110
nodes.  I thought that these three things could be achieved at the same
time.  Am I right or wrong about this?  Are there certain other things that
I need to do to meet this description?
 
Thanks in advance,
Jim
 
 


[Non-text portions of this message have been removed]

Re: [68300] 68376: CAN bus rate and length issue

2002-08-28 by jeffrey.tenney@gm.com

Hello again, Jim, seems like you've made a lot of progress since last year.

You're right about the length issue.  Running at 1Mbps, you're doing about
as well as possible (and probably pushing it) with 72 feet.  I don't know
the exact spec, but I do know that the spec for 500Kbps is 30 meters (98
feet) per SAE J2284.

1.  The only difference in your given choices is 10 or 20 time quanta per
bit.  Data rates, sample points, and resync tolerances are the same in both
your choices.  So, 20 Tq per bit (what you've called Low tolerance clock)
is better because you resync to the edges more accurately.  What you've
called High data rate allows greater chance for errors (greater chance for
retransmissions) due to clock drift.  (In reality you won't have errors
with either setting.)

2.  Again, stick with more Tq per bit.

3.  Sorry, don't have one.

4.  You're right that noise is probably not an issue.

5.  You're right that your cable is just fine now.  I don't think you can
gain any appreciable length by using larger guage conductors.  This is
outside my knowledge base, though.

6.  1 Mhz at 50M sounds too good to be true.

Jeff





"Godiska, Jim" <jgodiska@...> on 08/28/2002 11:11:21 AM

Please respond to 68300@yahoogroups.com

To:    68300@yahoogroups.com
cc:
Show quoted textHide quoted text
Subject:    [68300] 68376: CAN bus rate and length issue


Hello List,

I am currently using the MC68376 (using a 20 MHz external clock oscillator
chip) along with Phillips TJA1050 CAN transceiver and the typical 120 ohm
terminating resistors on the bus.  Currenly, I have a machine set up with a
1 MHz bit rate, 35 nodes (in a linear network with no stubs), and a length
of about 85 feet, but the CAN bus starts going nuts.  It seems that if I
shorten the network to 31 nodes (with about 13 feet less cable length),
then
the CAN bus appear to be working.  If I try a different combination of 31
nodes out of the 35, it also works again.  If I take the 31 node network
and
remove one 1 foot interconnect cable and insert a 26 foot cable, the bus
goes nuts again.

At this point I am beginning to believe that the problem is simply the
cable
length of the network.  The obvious solution may be to drop the bit rate
down to, say, 500 kHz.  However I have a few questions first.

1.  I can set up the parameters in the CAN module one of two ways.
Currenlty, I am using:

        _TOUCAN.CANCTRL1 = 0x87;        // Low tolerance clock, 1MHz CAN
        bus
        _TOUCAN.PRESDIV = 0x00;
        _TOUCAN.CANCTRL2 = 0xF3;

The other option is:

        _TOUCAN.CANCTRL1 = 0x04;        // High data rate, 1MHz CAN bus
        _TOUCAN.PRESDIV = 0x01;
        _TOUCAN.CANCTRL2 = 0x49;

Which would be better?

2.  If I drop the bit rate, does should I set the paramters more for a
higher data rate mode or for more of a less accurate clock mode?

3.  Does anyone have a chart showing recommended cable length, nodes, and
various bit rates for the CAN bus?

4.  Using a split terminating resistor with a center tapped capacitor tied
to ground, would help with noise issues, but I am thinking this is not the
main cause.  Do you agree?

5.  I am currently using 22AWG twisted shielded cable with the shield being
termiated at one end only.  I can increase the wire size to 20 AWG which
should help the bus length somewhat according to one application note that
I
found, but I do not believe it to be a significant contributor to the
problem.  Any opinions?

6.  In the early days of investigating CAN bus implementations, I thought I
saw that the maximums were 1 MHz bit rate at a 50 meter length and about
110
nodes.  I thought that these three things could be achieved at the same
time.  Am I right or wrong about this?  Are there certain other things that
I need to do to meet this description?

Thanks in advance,
Jim




[Non-text portions of this message have been removed]



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Re: [68300] 68376: CAN bus rate and length issue

2002-08-28 by jeffrey.tenney@gm.com

Jim,

Oops, correction here.  Another difference in your choices for TouCAN
settings is the sample mode, once per bit or three times per bit.  I have
no idea why they even put that option into the TouCAN, but my opinion is
that it's useless.  Pick your sample point (as you've picked 80%) and let
the CAN protocol do the rest.

Jeff

RE: [68300] 68376: CAN bus rate and length issue

2002-08-29 by Godiska, Jim

Jeff,
 
My sincere thanks for your replies.  I felt I was going in the right
direction, but it is always good to hear confirmation from the experts.
 
Although I was hoping to avoid it, I do have the option to cut my data rate
in half (to 500 kHz).  At 1 MHz my loading of the bus would be about 15%,
with 500 kHz we would be about 30% for a maximum.  In the early days, I
found that 250 kHz was a definite problem, and I needed something in the 330
kHz range for decent operation.
 
I do have another questions, though.  If I would end up needing the 1 MHz
data rate and a longer network on a future design, do you have any
suggestions as for how to do this?  I came up with a couple of ideas, but I
do not know how well they would work:
 
1.  Replace the line tranceiver chip with a fiber optic cable network.
 
2.  Make up a repeater module using a microcontroller with 2 CAN bus
controller modules to act as a CAN message receiver / buffer /
re-transmitter unit.  But some of the effective data bandwidth will
obviously be limited by the repeater's processing time.
 
Again, thanks for your help, Jeff.
 
Jim
Show quoted textHide quoted text
-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Wednesday, August 28, 2002 7:54 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] 68376: CAN bus rate and length issue



Jim,

Oops, correction here.  Another difference in your choices for TouCAN
settings is the sample mode, once per bit or three times per bit.  I have
no idea why they even put that option into the TouCAN, but my opinion is
that it's useless.  Pick your sample point (as you've picked 80%) and let
the CAN protocol do the rest.

Jeff



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
05:HM/A=1212975/R=0/*http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ
et=mm/g22lp.tmpl> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]

RE: [68300] 68376: CAN bus rate and length issue

2002-08-29 by Godiska, Jim

Hello Jeff,
 
I just found this website link for calculating bit times and though you
might be interested.....
 
http://www.port.de/engl/canprod/content/sv_req_form.html
<http://www.port.de/engl/canprod/content/sv_req_form.html> 
 
Regards,
Jim
Show quoted textHide quoted text
-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Wednesday, August 28, 2002 7:54 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] 68376: CAN bus rate and length issue



Jim,

Oops, correction here.  Another difference in your choices for TouCAN
settings is the sample mode, once per bit or three times per bit.  I have
no idea why they even put that option into the TouCAN, but my opinion is
that it's useless.  Pick your sample point (as you've picked 80%) and let
the CAN protocol do the rest.

Jeff



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
05:HM/A=1212975/R=0/*http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ
et=mm/g22lp.tmpl> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]

Re: [68300] 68376: CAN bus rate and length issue

2002-08-29 by Rod.Niner@gsescales.spx.com

The cable capacitance, network design and stub length into each device can 
have a big effect.  From the RF standpoint you want your network to look 
like a straight line from the master to your last node with very short 
(<6") side branches if any.   These side branches especially if just using 
any wire will cause reflections which can cancel the signal at one node 
and not another.  Try using profibus or device net cable and see if this 
makes a difference.  I think Device Net cable matches your 120 ohms while 
Profibus is 150 ohms.





"Godiska, Jim" <jgodiska@...>
08/28/2002 02:11 PM
Please respond to 68300

 
        To:     68300@yahoogroups.com
        cc: 
Show quoted textHide quoted text
        Subject:        [68300] 68376: CAN bus rate and length issue


Hello List,
 
I am currently using the MC68376 (using a 20 MHz external clock oscillator
chip) along with Phillips TJA1050 CAN transceiver and the typical 120 ohm
terminating resistors on the bus.  Currenly, I have a machine set up with 
a
1 MHz bit rate, 35 nodes (in a linear network with no stubs), and a length
of about 85 feet, but the CAN bus starts going nuts.  It seems that if I
shorten the network to 31 nodes (with about 13 feet less cable length), 
then
the CAN bus appear to be working.  If I try a different combination of 31
nodes out of the 35, it also works again.  If I take the 31 node network 
and
remove one 1 foot interconnect cable and insert a 26 foot cable, the bus
goes nuts again.
 
At this point I am beginning to believe that the problem is simply the 
cable
length of the network.  The obvious solution may be to drop the bit rate
down to, say, 500 kHz.  However I have a few questions first.
 
1.  I can set up the parameters in the CAN module one of two ways.
Currenlty, I am using:
 
        _TOUCAN.CANCTRL1 = 0x87;        // Low tolerance clock, 1MHz CAN 
bus
        _TOUCAN.PRESDIV = 0x00;
        _TOUCAN.CANCTRL2 = 0xF3;
 
The other option is:
 
        _TOUCAN.CANCTRL1 = 0x04;        // High data rate, 1MHz CAN bus
        _TOUCAN.PRESDIV = 0x01;
        _TOUCAN.CANCTRL2 = 0x49;

Which would be better?
 
2.  If I drop the bit rate, does should I set the paramters more for a
higher data rate mode or for more of a less accurate clock mode?
 
3.  Does anyone have a chart showing recommended cable length, nodes, and
various bit rates for the CAN bus?
 
4.  Using a split terminating resistor with a center tapped capacitor tied
to ground, would help with noise issues, but I am thinking this is not the
main cause.  Do you agree?
 
5.  I am currently using 22AWG twisted shielded cable with the shield 
being
termiated at one end only.  I can increase the wire size to 20 AWG which
should help the bus length somewhat according to one application note that 
I
found, but I do not believe it to be a significant contributor to the
problem.  Any opinions?
 
6.  In the early days of investigating CAN bus implementations, I thought 
I
saw that the maximums were 1 MHz bit rate at a 50 meter length and about 
110
nodes.  I thought that these three things could be achieved at the same
time.  Am I right or wrong about this?  Are there certain other things 
that
I need to do to meet this description?
 
Thanks in advance,
Jim
 
 


[





[Non-text portions of this message have been removed]

RE: [68300] 68376: CAN bus rate and length issue

2002-08-29 by Tena Britt

I have a CAN application in which I need to provide the option for a fiber
optic output.  I can't use an external converter, it has to be on the board.
Any ideas on how to implement this?  I can't find any "CAN fibre
transceivers", so I am assuming I will have to build one?
Show quoted textHide quoted text
-----Original Message-----
From: Godiska, Jim [mailto:jgodiska@...]
Sent: Wednesday, August 28, 2002 8:05 PM
To: '68300@yahoogroups.com'
Subject: RE: [68300] 68376: CAN bus rate and length issue


Jeff,

My sincere thanks for your replies.  I felt I was going in the right
direction, but it is always good to hear confirmation from the experts.

Although I was hoping to avoid it, I do have the option to cut my data rate
in half (to 500 kHz).  At 1 MHz my loading of the bus would be about 15%,
with 500 kHz we would be about 30% for a maximum.  In the early days, I
found that 250 kHz was a definite problem, and I needed something in the 330
kHz range for decent operation.

I do have another questions, though.  If I would end up needing the 1 MHz
data rate and a longer network on a future design, do you have any
suggestions as for how to do this?  I came up with a couple of ideas, but I
do not know how well they would work:

1.  Replace the line tranceiver chip with a fiber optic cable network.

2.  Make up a repeater module using a microcontroller with 2 CAN bus
controller modules to act as a CAN message receiver / buffer /
re-transmitter unit.  But some of the effective data bandwidth will
obviously be limited by the repeater's processing time.

Again, thanks for your help, Jeff.

Jim

-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Wednesday, August 28, 2002 7:54 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] 68376: CAN bus rate and length issue



Jim,

Oops, correction here.  Another difference in your choices for TouCAN
settings is the sample mode, once per bit or three times per bit.  I have
no idea why they even put that option into the TouCAN, but my opinion is
that it's useless.  Pick your sample point (as you've picked 80%) and let
the CAN protocol do the rest.

Jeff



Yahoo! Groups Sponsor      

ADVERTISEMENT

<
http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
<http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
> 
05:HM/A=1212975/R=0/*
http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ
<http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ> 
et=mm/g22lp.tmpl>       

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>  <
http://www.motorola.com/mcu <http://www.motorola.com/mcu> > 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
< http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> > . 




[Non-text portions of this message have been removed]



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
05:HM/A=1212975/R=0/*http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ
et=mm/g22lp.tmpl> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 



***
The information in this e-mail is confidential and intended solely for the
individual or entity to whom it is addressed. If you have received this
e-mail in error please notify the sender by return e-mail, delete this
e-mail, and refrain from any disclosure or action based on the information.
****


[Non-text portions of this message have been removed]

RE: [68300] 68376: CAN bus rate and length issue

2002-08-29 by Godiska, Jim

I do not know of specific CAN fiber optic units.  However, try going to
Agilent (formerly Hewlett-Packard), they have fiber optic transmitters,
receivers, and cables.  But I do not know about a transceiver.  The units I
used in the past were good to at least 10 MHz, if not more.  If you can
figure out a way to connect them, I think this should work.
Show quoted textHide quoted text
-----Original Message-----
From: Tena Britt [mailto:tbritt@...]
Sent: Thursday, August 29, 2002 8:57 AM
To: '68300@yahoogroups.com'
Subject: RE: [68300] 68376: CAN bus rate and length issue


I have a CAN application in which I need to provide the option for a fiber
optic output.  I can't use an external converter, it has to be on the board.
Any ideas on how to implement this?  I can't find any "CAN fibre
transceivers", so I am assuming I will have to build one?

-----Original Message-----
From: Godiska, Jim [mailto:jgodiska@...]
Sent: Wednesday, August 28, 2002 8:05 PM
To: '68300@yahoogroups.com'
Subject: RE: [68300] 68376: CAN bus rate and length issue


Jeff,

My sincere thanks for your replies.  I felt I was going in the right
direction, but it is always good to hear confirmation from the experts.

Although I was hoping to avoid it, I do have the option to cut my data rate
in half (to 500 kHz).  At 1 MHz my loading of the bus would be about 15%,
with 500 kHz we would be about 30% for a maximum.  In the early days, I
found that 250 kHz was a definite problem, and I needed something in the 330
kHz range for decent operation.

I do have another questions, though.  If I would end up needing the 1 MHz
data rate and a longer network on a future design, do you have any
suggestions as for how to do this?  I came up with a couple of ideas, but I
do not know how well they would work:

1.  Replace the line tranceiver chip with a fiber optic cable network.

2.  Make up a repeater module using a microcontroller with 2 CAN bus
controller modules to act as a CAN message receiver / buffer /
re-transmitter unit.  But some of the effective data bandwidth will
obviously be limited by the repeater's processing time.

Again, thanks for your help, Jeff.

Jim

-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Wednesday, August 28, 2002 7:54 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] 68376: CAN bus rate and length issue



Jim,

Oops, correction here.  Another difference in your choices for TouCAN
settings is the sample mode, once per bit or three times per bit.  I have
no idea why they even put that option into the TouCAN, but my opinion is
that it's useless.  Pick your sample point (as you've picked 80%) and let
the CAN protocol do the rest.

Jeff



Yahoo! Groups Sponsor      

ADVERTISEMENT

<
http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
<http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
> 
<
http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
<http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
> 
> 
05:HM/A=1212975/R=0/*
http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ
<http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ> 
< http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ
<http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ> > 
et=mm/g22lp.tmpl>       

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>  <
http://www.motorola.com/mcu <http://www.motorola.com/mcu> >  <
http://www.motorola.com/mcu <http://www.motorola.com/mcu>  <
http://www.motorola.com/mcu <http://www.motorola.com/mcu> > > 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
< http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/>  <
http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> > > . 




[Non-text portions of this message have been removed]



Yahoo! Groups Sponsor      

ADVERTISEMENT

<
http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
<http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
> 
05:HM/A=1212975/R=0/*
http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ
<http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ> 
et=mm/g22lp.tmpl>       

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>  <
http://www.motorola.com/mcu <http://www.motorola.com/mcu> > 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
< http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> > . 



***
The information in this e-mail is confidential and intended solely for the
individual or entity to whom it is addressed. If you have received this
e-mail in error please notify the sender by return e-mail, delete this
e-mail, and refrain from any disclosure or action based on the information.
****


[Non-text portions of this message have been removed]



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=232673.2303527.3721118.2225243/D=egroupweb/S=17065542
05:HM/A=1194123/R=0/*http://www.adinsdirect.com/> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]

RE: [68300] 68376: CAN bus rate and length issue

2002-08-29 by jeffrey.tenney@gm.com

Jim,

My first impression is to go with approach #2 to save cost and development
time.  You can go with a "hardware" gateway that requires *very* little
software and *no* microcontroller.  I investigated the Infineon TwinCAN
module (SAK 82C900) a while back.  It is a standalone controller with *two*
CAN interfaces.  It has a hardware gateway mode, and it can operate without
a host microcontroller if you put some minimal initialization code into a
SPI EEPROM.  It should be cheap, easy, and have miniscule processing lag
during message forwarding.

Caveat:  We decided not to pursue the TwinCAN in our CAN project so I can't
vouch for the TwinCAN.  It could be a piece of junk for all I know.

Jeff





"Godiska, Jim" <jgodiska@...> on 08/28/2002 07:05:05 PM

Please respond to 68300@yahoogroups.com

To:    "'68300@yahoogroups.com'" <68300@yahoogroups.com>
cc:
Show quoted textHide quoted text
Subject:    RE: [68300] 68376: CAN bus rate and length issue


Jeff,

My sincere thanks for your replies.  I felt I was going in the right
direction, but it is always good to hear confirmation from the experts.

Although I was hoping to avoid it, I do have the option to cut my data rate
in half (to 500 kHz).  At 1 MHz my loading of the bus would be about 15%,
with 500 kHz we would be about 30% for a maximum.  In the early days, I
found that 250 kHz was a definite problem, and I needed something in the
330
kHz range for decent operation.

I do have another questions, though.  If I would end up needing the 1 MHz
data rate and a longer network on a future design, do you have any
suggestions as for how to do this?  I came up with a couple of ideas, but I
do not know how well they would work:

1.  Replace the line tranceiver chip with a fiber optic cable network.

2.  Make up a repeater module using a microcontroller with 2 CAN bus
controller modules to act as a CAN message receiver / buffer /
re-transmitter unit.  But some of the effective data bandwidth will
obviously be limited by the repeater's processing time.

Again, thanks for your help, Jeff.

Jim

-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Wednesday, August 28, 2002 7:54 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] 68376: CAN bus rate and length issue



Jim,

Oops, correction here.  Another difference in your choices for TouCAN
settings is the sample mode, once per bit or three times per bit.  I have
no idea why they even put that option into the TouCAN, but my opinion is
that it's useless.  Pick your sample point (as you've picked 80%) and let
the CAN protocol do the rest.

Jeff



Yahoo! Groups Sponsor

ADVERTISEMENT

<
http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
05:HM/A=1212975/R=0/*http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ

et=mm/g22lp.tmpl>

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> .




[Non-text portions of this message have been removed]



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

RE: [68300] 68376: CAN bus rate and length issue

2002-08-29 by Godiska, Jim

It's not a processor issue.  The 68376 has a single TouCAN Module (i.e. - a
single CANTX pin and a single CANRX pin).  The idea is to receive a CAN
message from one CAN bus network and resend the message down a separate CAN
bus network.  It is just that you now end up with 2 CAN networks effectively
acting as a single network, although now with some processing delay between
the two parts.
Show quoted textHide quoted text
-----Original Message-----
From: Jeff Andle [mailto:andle@...]
Sent: Thursday, August 29, 2002 12:47 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] 68376: CAN bus rate and length issue


doesn't the '376 have twin CAM?  The '375 does...
Do you have the processor capacity to do it in the existing processor?



Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=229441.2311215.3726473.2225242/D=egroupweb/S=17065542
05:HM/A=1189560/R=0/*www.bmgmusic.com/acq/ee/q6/enroll/mhn/10/> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]

RE: [68300] 68376: CAN bus rate and length issue

2002-08-29 by Godiska, Jim

Jeff,
 
Cool idea.  I am not to the point of needing it today, but it's great to
know it exists.
 
Jim
Show quoted textHide quoted text
-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Thursday, August 29, 2002 12:44 PM
To: 68300@yahoogroups.com
Subject: RE: [68300] 68376: CAN bus rate and length issue



Jim,

My first impression is to go with approach #2 to save cost and development
time.  You can go with a "hardware" gateway that requires *very* little
software and *no* microcontroller.  I investigated the Infineon TwinCAN
module (SAK 82C900) a while back.  It is a standalone controller with *two*
CAN interfaces.  It has a hardware gateway mode, and it can operate without
a host microcontroller if you put some minimal initialization code into a
SPI EEPROM.  It should be cheap, easy, and have miniscule processing lag
during message forwarding.

Caveat:  We decided not to pursue the TwinCAN in our CAN project so I can't
vouch for the TwinCAN.  It could be a piece of junk for all I know.

Jeff





"Godiska, Jim" <jgodiska@...> on 08/28/2002 07:05:05 PM

Please respond to 68300@yahoogroups.com

To:    "'68300@yahoogroups.com'" <68300@yahoogroups.com>
cc:
Subject:    RE: [68300] 68376: CAN bus rate and length issue


Jeff,

My sincere thanks for your replies.  I felt I was going in the right
direction, but it is always good to hear confirmation from the experts.

Although I was hoping to avoid it, I do have the option to cut my data rate
in half (to 500 kHz).  At 1 MHz my loading of the bus would be about 15%,
with 500 kHz we would be about 30% for a maximum.  In the early days, I
found that 250 kHz was a definite problem, and I needed something in the
330
kHz range for decent operation.

I do have another questions, though.  If I would end up needing the 1 MHz
data rate and a longer network on a future design, do you have any
suggestions as for how to do this?  I came up with a couple of ideas, but I
do not know how well they would work:

1.  Replace the line tranceiver chip with a fiber optic cable network.

2.  Make up a repeater module using a microcontroller with 2 CAN bus
controller modules to act as a CAN message receiver / buffer /
re-transmitter unit.  But some of the effective data bandwidth will
obviously be limited by the repeater's processing time.

Again, thanks for your help, Jeff.

Jim

-----Original Message-----
From: jeffrey.tenney@... [mailto:jeffrey.tenney@...]
Sent: Wednesday, August 28, 2002 7:54 PM
To: 68300@yahoogroups.com
Subject: Re: [68300] 68376: CAN bus rate and length issue



Jim,

Oops, correction here.  Another difference in your choices for TouCAN
settings is the sample mode, once per bit or three times per bit.  I have
no idea why they even put that option into the TouCAN, but my opinion is
that it's useless.  Pick your sample point (as you've picked 80%) and let
the CAN protocol do the rest.

Jeff



Yahoo! Groups Sponsor

ADVERTISEMENT

<
http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
<http://rd.yahoo.com/M=233351.2287382.3722243.2225243/D=egroupweb/S=17065542
> 
05:HM/A=1212975/R=0/*
http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ
<http://www.gotomypc.com/u/tr/yh/grp/300_mapG/g22lp?Targ> 

et=mm/g22lp.tmpl>

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu>  <
http://www.motorola.com/mcu <http://www.motorola.com/mcu> >



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
< http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> > .




[Non-text portions of this message have been removed]



---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
<http://docs.yahoo.com/info/terms/> 










Yahoo! Groups Sponsor	

ADVERTISEMENT
 
<http://rd.yahoo.com/M=229441.2311215.3726473.2225242/D=egroupweb/S=17065542
05:HM/A=1189560/R=0/*www.bmgmusic.com/acq/ee/q6/enroll/mhn/10/> 	

---------------------------------------------------
To unsubscribe from this group, send an email to:
68300-unsubscribe@yahoogroups.com

To learn more about Motorola Microcontrollers, please visit
http://www.motorola.com/mcu <http://www.motorola.com/mcu> 



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service
<http://docs.yahoo.com/info/terms/> . 




[Non-text portions of this message have been removed]

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.