Searching \ for '[EE] Ethernet - Bus?' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/index.htm?key=ethernet+bus
Search entire site for: 'Ethernet - Bus?'.

Exact match. Not showing close matches.
PICList Thread
'[EE] Ethernet - Bus?'
2009\05\02@233203 by solarwind

picon face
Hey all! So far I am considering the RS485 bus for my inter-controller
communication system. That's because I understand how RS485 works.
It's simple and very very flexible. However it seems that ethernet is
another interesting option. I tried to do more research on it but I
didn't get very far. (Probably because I wasn't searching for the
right thing.)

Anyway, my question is: can ethernet be used as a BUS? Like RS485,
that is - without a hub or switch. I want to be able to hook up
several microcontrollers with Microchip's ENC26J60 together. Is it
possible to tie them together in a bus fashion? Or is a
hub/switch/router required?

How does this work exactly?

-- [ solarwind ] -- http://solar-blogg.blogspot.com/

2009\05\02@234932 by peter green

flavicon
face
solarwind wrote:
> Hey all! So far I am considering the RS485 bus for my inter-controller
> communication system. That's because I understand how RS485 works.
> It's simple and very very flexible.
Seems like a good choice, simple and cheap, can run long distances as
long as you make sure it's terminated right and fast enough for most
microcontroller applications.

>  However it seems that ethernet is
> another interesting option.
It's good from a performance point of view but it is also far more
complex to work with and requires quite a bit of hardware at each node
(you need a dedicated controller chip and you need the magnetics and a
load of other passives).
> I tried to do more research on it but I
> didn't get very far. (Probably because I wasn't searching for the
> right thing.)
>
> Anyway, my question is: can ethernet be used as a BUS? Like RS485,
> that is - without a hub or switch. I want to be able to hook up
> several microcontrollers with Microchip's ENC26J60 together. Is it
> possible to tie them together in a bus fashion? Or is a
> hub/switch/router required?
>  
Old-school coaxial 10BASE5 and 10BASE2 ethernet was a bus network.
10BASE-T is point to point only so you need a hub/switch if you want
more than two nodes. The ENC28J60 is 10BASE-T only.


2009\05\03@023926 by William \Chops\ Westfield

face picon face

On May 2, 2009, at 8:49 PM, peter green wrote:

>>  my question is: can ethernet be used as a BUS?
>>
> Old-school coaxial 10BASE5 and 10BASE2 ethernet was a bus network.

Old-school 10base5 and 10base2 also required large and expensive  
"transceiver" units in between the "phy" controller and the "bus"  
cable (complete with internal DC-DC converters to power the  
transceiver electronics while maintaining isolation.)   A single-chip  
10baseT hub/switch is MUCH simpler.  I believe that it's possible to  
use some of these chips without magnetics when you don't need  
isolation, further simplifying things (but with the price of off-the-
shelf hubs, I'm not sure there's much point.)

BillW

2009\05\03@052157 by Mike Harrison

flavicon
face
On Sun, 03 May 2009 04:49:29 +0100, you wrote:

{Quote hidden}

For suitable applications, you probably could do  a ring, although each node would have the burden
of forwarding data.
For high speeds, LVDS may be worth a look.


2009\05\03@071119 by Dave Tweed

face
flavicon
face
solarwind wrote:
> Anyway, my question is: can ethernet be used as a BUS? Like RS485,
> that is - without a hub or switch.

Of course! That's how Ethernet was originally implemented -- on coax.
Look for "10base2" (or even "10base5").

> I want to be able to hook up
> several microcontrollers with Microchip's ENC26J60 together. Is it
> possible to tie them together in a bus fashion?

Probably not. But if you can get some old ISA cards that support
10base2, they're relatively easy to hack for embedded purposes.

-- Dave Tweed

2009\05\03@093302 by olin piclist

face picon face
solarwind wrote:
> Hey all! So far I am considering the RS485 bus for my inter-controller
> communication system.

If you're considerng RS-485 then you really should look at CAN.  It can work
on the same wires, but the low level protocol details are taken care of for
you in the silicon.  This includes collision detection and retry.  RS-485 is
a electrical spec only.  The protocol is totaly left as a exercise to the
implementer.  You have to think hard and write a bunch of code to deal with
multiple units possibly wanting to send at the same time, data integrity,
flow control, etc.

> That's because I understand how RS485 works.
> It's simple and very very flexible.

Just like CAN if you only look at the electrical signalling.

> Anyway, my question is: can ethernet be used as a BUS?

Yes, the original ethernet was a bus and the later "thin LAN" (10base-2 ?)
variant was also a bus.  However, ethernet is much faster and therefore
cable impedence is a important issue.  All ethernet bus implementations
require termination at each end of the bus, and all taps must be very short
and not mess up the bus impedence for signals going by.  While it is
possible to use ethernet this way if you can string one piece of 50ohm coax
past all locations, it's going to be a lot more trouble than you think.
Unless you really need the bandwidth (and apparantly not if you're
considering RS-485), then I wouldn't try ethernet for this app.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\03@093451 by olin piclist

face picon face
peter green wrote:
> The ENC28J60 is 10BASE-T only.

Really?  Please show me the reference to back that up.  I am pretty sure the
ENC28J60 has options for full and half duplex and for collision detection.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\03@102237 by Peter Onion

flavicon
face
On Sun, 2009-05-03 at 09:33 -0400, Olin Lathrop wrote:
> solarwind wrote:
> > Hey all! So far I am considering the RS485 bus for my inter-controller
> > communication system.
>
> If you're considerng RS-485 then you really should look at CAN.

The learning curve for using CAN looks steep, but having just climbed it
once you understand how to set up the ECAN module the manual makes a lot
more sense than it does the first few times you read it ;-)

PeterO


2009\05\03@140153 by peter green

flavicon
face

> Really?  Please show me the reference to back that up.  
The enc28j60 datasheet clearly states it is an "Integrated MAC and
10Base-T PHY". While the data sheet doesn't say it explicitly it is
pretty clear from the pinout diagrams that there is no provision for use
with an external PHY.

You could have the enc298j60, then a 10BASE-T link to a "repeater" which
could in turn connect to the phy of your choice but thats a lot of extra
hassle.

> I am pretty sure the
> ENC28J60 has options for full and half duplex
It does, unfortunately it doesn't have autonegotiation which means you
usually end up stuck running half duplex.  Full duplex mode is only
usable if you have managed switches with thier ports manually configured
to full duplex mode (if you try and use it in full duplex mode with a
switch in autonegotiation mode you will get a duplex mismatch resulting
in terrible performance)



2009\05\03@172847 by Gerhard Fiedler

picon face
Peter Onion wrote:

>> If you're considerng RS-485 then you really should look at CAN.
>
> The learning curve for using CAN looks steep, but having just climbed
> it once you understand how to set up the ECAN module the manual makes
> a lot more sense than it does the first few times you read it ;-)

Right... :)

If you consider the time it takes to write all the code that takes care
of the subset of the CAN functionality that you need in your application
and that is provided "free" after correctly configuring the CAN
hardware, the time to understand how to set up the CAN module doesn't
look so bad anymore.

Gerhard

2009\05\03@174925 by solarwind

picon face
On Sun, May 3, 2009 at 9:28 PM, Gerhard Fiedler
<spam_OUTlistsTakeThisOuTspamconnectionbrazil.com> wrote:
> Right... :)
>
> If you consider the time it takes to write all the code that takes care
> of the subset of the CAN functionality that you need in your application
> and that is provided "free" after correctly configuring the CAN
> hardware, the time to understand how to set up the CAN module doesn't
> look so bad anymore.

Thanks, everyone. I'll be using CAN then. What is CAN usually set up
over? RS485?

2009\05\03@183032 by olin piclist

face picon face
solarwind wrote:
> Thanks, everyone. I'll be using CAN then. What is CAN usually set up
> over? RS485?

RS-485 is a separate electrical spec that has nothing to do with CAN.
However, CAN usually uses differential signalling just like RS-485, so the
same twisted pair of wires will usually work for either.  One pair of a CAT5
cable will work fine for CAN, but you have to terminate the two ends.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\03@200959 by solarwind

picon face
On Sun, May 3, 2009 at 6:31 PM, Olin Lathrop <.....olin_piclistKILLspamspam@spam@embedinc.com> wrote:
> RS-485 is a separate electrical spec that has nothing to do with CAN.
> However, CAN usually uses differential signaling just like RS-485, so the
> same twisted pair of wires will usually work for either.  One pair of a CAT5
> cable will work fine for CAN, but you have to terminate the two ends.

I don't understand what you mean by "terminate" the two ends. I tried
to google for it, but searching for phrases involving "CAN" are
difficult.

2009\05\03@202932 by Bob Blick

face
flavicon
face
solarwind wrote:
> On Sun, May 3, 2009 at 6:31 PM, Olin Lathrop <olin_piclistspamKILLspamembedinc.com> wrote:
>> RS-485 is a separate electrical spec that has nothing to do with CAN.
>> However, CAN usually uses differential signaling just like RS-485, so the
>> same twisted pair of wires will usually work for either.  One pair of a CAT5
>> cable will work fine for CAN, but you have to terminate the two ends.
>
> I don't understand what you mean by "terminate" the two ends. I tried
> to google for it, but searching for phrases involving "CAN" are
> difficult.

A resistor connected across the two wires, it prevents fast signal edges
from ringing back to the other end and corrupting your data by creating
false transitions or canceling out real ones.

Both ends of the bus require termination.

I think RS-485 uses 120 ohms.

Cheers,

Bob

2009\05\03@203233 by Joseph Bento

face
flavicon
face

On May 3, 2009, at 6:09 PM, solarwind wrote:

>
> I don't understand what you mean by "terminate" the two ends. I tried
> to google for it, but searching for phrases involving "CAN" are
> difficult.
>

This is a website I frequently refer to regarding the CAN specification:

http://www.interfacebus.com/Design_Connector_CAN.html

You essentially need just three wires - CAN High and CAN Low in a  
twisted pair, and Ground.  High noise may require shielding.  
Termination is via a 120 ohm resistor, though in the case of National  
Instruments equipment I've worked with in the past, that resistor was  
inclusive in the interface.

Joe

2009\05\03@203303 by David Harris

picon face
solarwind wrote:
> On Sun, May 3, 2009 at 6:31 PM, Olin Lathrop <.....olin_piclistKILLspamspam.....embedinc.com> wrote:
>  
>> RS-485 is a separate electrical spec that has nothing to do with CAN.
>> However, CAN usually uses differential signaling just like RS-485, so the
>> same twisted pair of wires will usually work for either.  One pair of a CAT5
>> cable will work fine for CAN, but you have to terminate the two ends.
>>    
>
> I don't understand what you mean by "terminate" the two ends. I tried
> to google for it, but searching for phrases involving "CAN" are
> difficult.
>
>  
To reduce reflections at two ends of the bus, you need to 'terminate'
them.  This is usually done passively using a resistor.  For fancier
installations you can use active-terminators.

For CAN, Google the specification and it will discuss it.

David

2009\05\03@203304 by Richard Prosser

picon face
2009/5/4 solarwind <EraseMEx.solarwind.xspam_OUTspamTakeThisOuTgmail.com>:
> On Sun, May 3, 2009 at 6:31 PM, Olin Lathrop <olin_piclistspamspam_OUTembedinc.com> wrote:
>> RS-485 is a separate electrical spec that has nothing to do with CAN.
>> However, CAN usually uses differential signaling just like RS-485, so the
>> same twisted pair of wires will usually work for either.  One pair of a CAT5
>> cable will work fine for CAN, but you have to terminate the two ends.
>
> I don't understand what you mean by "terminate" the two ends. I tried
> to google for it, but searching for phrases involving "CAN" are
> difficult.
>
>

2009\05\03@203844 by solarwind

picon face
On Sun, May 3, 2009 at 8:32 PM, Joseph Bento <@spam@josephKILLspamspamkirtland.com> wrote:
> This is a website I frequently refer to regarding the CAN specification:
>
> http://www.interfacebus.com/Design_Connector_CAN.html
>
> You essentially need just three wires - CAN High and CAN Low in a
> twisted pair, and Ground.  High noise may require shielding.
> Termination is via a 120 ohm resistor, though in the case of National
> Instruments equipment I've worked with in the past, that resistor was
> inclusive in the interface.
>
> Joe

Thanks for the website! It's really helpful.

2009\05\03@204406 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 5:49 AM, solarwind <KILLspamx.solarwind.xKILLspamspamgmail.com> wrote:
> On Sun, May 3, 2009 at 9:28 PM, Gerhard Fiedler
>> If you consider the time it takes to write all the code that takes care
>> of the subset of the CAN functionality that you need in your application
>> and that is provided "free" after correctly configuring the CAN
>> hardware, the time to understand how to set up the CAN module doesn't
>> look so bad anymore.
>
> Thanks, everyone. I'll be using CAN then. What is CAN usually set up
> over? RS485?

CAN is limited to 1Mbps. RS485 can usually go much faster. Profibus
uses RS485 and can go up to 12Mbps. We use RS485 as one of
the backplanes which goes up to 16Mbps and use proprietory upper
layers.  On the other hand, we have backplanes which is based on
CAN and use DeviceNet/CIP as the upper layer.

--
Xiaofan http://mcuee.blogspot.com

2009\05\03@205652 by Herbert Graf

picon face
On Sat, 2009-05-02 at 23:31 -0400, solarwind wrote:
> Hey all! So far I am considering the RS485 bus for my inter-controller
> communication system. That's because I understand how RS485 works.
> It's simple and very very flexible. However it seems that ethernet is
> another interesting option. I tried to do more research on it but I
> didn't get very far. (Probably because I wasn't searching for the
> right thing.)
>
> Anyway, my question is: can ethernet be used as a BUS? Like RS485,
> that is - without a hub or switch. I want to be able to hook up
> several microcontrollers with Microchip's ENC26J60 together. Is it
> possible to tie them together in a bus fashion? Or is a
> hub/switch/router required?

You need a switch. Hubs don't really exist anymore.

Considering they cost around $10 I don't see what the issue is with
needing a switch.

TTYL

2009\05\03@205924 by solarwind

picon face
On Sun, May 3, 2009 at 8:44 PM, Xiaofan Chen <RemoveMExiaofancTakeThisOuTspamgmail.com> wrote:
> CAN is limited to 1Mbps. RS485 can usually go much faster.

Is it the protocol that limits data rate?

2009\05\03@214918 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 8:59 AM, solarwind <spamBeGonex.solarwind.xspamBeGonespamgmail.com> wrote:
>> CAN is limited to 1Mbps. RS485 can usually go much faster.
>
> Is it the protocol that limits data rate?

I think it is because of the implementation.

This is an answer by an CAN expert to my question why nobody want to enhance
the CAN protocol to support bigger packet and higher speed.

http://www.microchip.com/forums/tm.aspx?m=384193

"Bosch did a very clever thing when they licensed the CAN protocol.
Each licensee get's access to all sorts of developmental information
and test suites.  Anyone who wants to change or upgrade the protocol
can apply to have the changes installed into the protocol.  But here's
the rub.  All other license holders also get the same information and
don't have to pay any extra royalties.  No royalties means all the
development money spent on enhancing the protocol can't be
recovered and all your competitors also get your R&D.  There is
no competitive advantage to enhancing the protocol.

This means CAN protocol baseband development has been frozen
since the CAN II enhanced identifier spec was released.  That's a
good thing.  If it had remained with one vendor, then other
vendors would have developed other types of CSMA/CR protocols.
The down side is no changes are forthcoming until the patents expire."

--
Xiaofan http://mcuee.blogspot.com

2009\05\03@215303 by Dave Tweed

face
flavicon
face
Herbert Graf <TakeThisOuThkgrafEraseMEspamspam_OUTgmail.com>
> You need a switch. Hubs don't really exist anymore.

Sure they do, you just have to look harder for them.

> Considering they cost around $10 I don't see what the issue is with
> needing a switch.

Switches are fine for "typical" desktop usage patterns, but can be a real
pain in embedded applications, when you really do want the traffic on any
port repeated to all of the other ports, regardless of how the packets may
appear to be addressed.

Switches, especially the cheap unmanaged ones, are easily confused. Just
try diagnosing an embedded network with WireShark, when the switch isn't
showing you all of the traffic in the first place. Or, it IS showing you
packets that aren't getting forwarded to one of your embedded devices for
some reason. Been there, done that.

The Linksys NH1005 is a nice 10/100 Mbps 5-port hub that I've used on more
than one occasion, and still seems to be readily available.

-- Dave Tweed

2009\05\03@215611 by Funny NYPD

picon face
>CAN is limited to 1Mbps. RS485 can usually go much faster.
Officially, yes, the CAN is designed with 1M max baud rate for best balance on cost and performance.

Actually this may not always be right. High baud rate doesn't really means high data communication rate. If the traffic is high the RS485 will lose most of the time/performance for bus arbitration at a multi-master network (e.g. the SAE J1708 (a modified RS485 network) can only run 9.6K for truck application, quite on the opposite, auto and truck industry can run CAN at 250K, 500K, 1M baud rate at the same application). CAN naively support multi-master, and is very reliable, most of today's vehicle's drive-by-wire technology are CAN bus based.

People does run CAN at higher speed than 1M bps occasionally.
Funny N.
Au Group Electronics, http://www.AuElectronics.com




________________________________
From: Xiaofan Chen <RemoveMExiaofancspamTakeThisOuTgmail.com>
To: Microcontroller discussion list - Public. <piclistEraseMEspam.....mit.edu>
Sent: Sunday, May 3, 2009 8:44:01 PM
Subject: Re: [EE] Ethernet - Bus?

On Mon, May 4, 2009 at 5:49 AM, solarwind <EraseMEx.solarwind.xspamgmail.com> wrote:
> On Sun, May 3, 2009 at 9:28 PM, Gerhard Fiedler
>> If you consider the time it takes to write all the code that takes care
>> of the subset of the CAN functionality that you need in your application
>> and that is provided "free" after correctly configuring the CAN
>> hardware, the time to understand how to set up the CAN module doesn't
>> look so bad anymore.
>
> Thanks, everyone. I'll be using CAN then. What is CAN usually set up
> over? RS485?

CAN is limited to 1Mbps. RS485 can usually go much faster. Profibus
uses RS485 and can go up to 12Mbps. We use RS485 as one of
the backplanes which goes up to 16Mbps and use proprietory upper
layers.  On the other hand, we have backplanes which is based on
CAN and use DeviceNet/CIP as the upper layer.

--
Xiaofan http://mcuee.blogspot.com

2009\05\03@221730 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 9:56 AM, Funny NYPD <RemoveMEfunnynypdEraseMEspamEraseMEyahoo.com> wrote:
>>CAN is limited to 1Mbps. RS485 can usually go much faster.
> Officially, yes, the CAN is designed with 1M max baud rate for best balance
>  on cost and performance.
>
Actually this may not always be right. High baud rate doesn't really means high
> data communication rate. If the traffic is high the RS485 will lose most of the
> time/performance for bus arbitration at a multi-master network (e.g. the SAE
> J1708 (a modified RS485 network) can only run 9.6K for truck application,
> quite on the opposite, auto and truck industry can run CAN at 250K, 500K,
> 1M baud rate at the same application). CAN naively support multi-master,
> and is very reliable, most of today's vehicle's drive-by-wire technology are
> CAN bus based.

Yes CAN is widely used in Automotive and Industrial control. However,
once you want to go for higher speed, it is the bottle neck. Therefore
Industrial Ethernet is starting to catching up in the automation field.
And FlexRay and other technology are also starting to appear in the
automotive world.

As explained in this thread, the CAN protocol will still be there for a long
time. However, there will not be much enhancement to CAN.
http://www.microchip.com/forums/tm.aspx?m=384193

RS485 physical layer can be replaced by M-LVDS to achieve much
higher speed (200Mbps or even higher).
www.interfacebus.com/Design_Connector_899_MLVDS.html
http://www.ti.com/mlvds

Where is the 10Mbps CAN? You can probably push some CAN tranceriver
to 2Mbps or slightly higher, but that is all about it.

Other problems with CAN is related to latency. That is why enhancement
like TTP is about. FlexRay seems to be quite good but right now it
is a bit expensive. It will not replace CAN.


--
Xiaofan http://mcuee.blogspot.com

2009\05\04@053816 by peter green

flavicon
face

> A resistor connected across the two wires, it prevents fast signal edges
> from ringing back to the other end and corrupting your data by creating
> false transitions or canceling out real ones.
>
> Both ends of the bus require termination.
>
> I think RS-485 uses 120 ohms.
>  
Termination resistance depends primerally on the cable type not the
protocol. Generally the termination resistance should be matched to the
characteristic impedance of the cable. IIRC cat5 cable is usually 120
ohm (IIRC 100 ohm cat5 exists as well but is very rare), most coax is
either 50 ohm or 75 ohm.

2009\05\04@065635 by olin piclist

face picon face
solarwind wrote:
> I don't understand what you mean by "terminate" the two ends. I tried
> to google for it, but searching for phrases involving "CAN" are
> difficult.

It's not a CAN thing, but a transmission line thing.  The theory behind this
is too much to explain in a short email.  There must be loads about it out
there.  Search for things like "transmission line", "characteristic
impedence" and "terminate".

In practise this means you need to put a resistor at each end of a
transmission line.  The resistor value should match the characteristic
impedence of the transmission line.  If it doesn't, edges will come bouncing
back making a mess.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\04@071421 by olin piclist

face picon face
Xiaofan Chen wrote:
> CAN is limited to 1Mbps.

Yes, but it's probably a good idea to run it slower.  Remember, he's reading
temperature sensors.  NMEA2000 specifies 200KHz as the bit rate.  If that's
good enough to use over the length of a oil tanker with a tight physical
spec, then it should leave some margin for using in a house with a little
slop in the physical implementation.

> RS485 can usually go much faster. Profibus
> uses RS485 and can go up to 12Mbps. We use RS485 as one of
> the backplanes which goes up to 16Mbps and use proprietory upper
> layers.  On the other hand, we have backplanes which is based on
> CAN and use DeviceNet/CIP as the upper layer.

I think you're confusing more than illuminating with this.  Keep it simple.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\04@072208 by olin piclist

face picon face
Xiaofan Chen wrote:
>> Is it the protocol that limits data rate?
>
> I think it is because of the implementation.

The inherent limit comes from the total propagation time between the two
farthest devices on the bus and back again in time to detect a collision.

Just use 200Kbit/S and be done with it.  Let's not confuse the OP more.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\04@091550 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 7:15 PM, Olin Lathrop <RemoveMEolin_piclistspam_OUTspamKILLspamembedinc.com> wrote:
> Xiaofan Chen wrote:
>> CAN is limited to 1Mbps.
>
> Yes, but it's probably a good idea to run it slower.  Remember, he's reading
> temperature sensors.  NMEA2000 specifies 200KHz as the bit rate.  If that's
> good enough to use over the length of a oil tanker with a tight physical
> spec, then it should leave some margin for using in a house with a little
> slop in the physical implementation.

You are right here.

>> RS485 can usually go much faster. Profibus
>> uses RS485 and can go up to 12Mbps. We use RS485 as one of
>> the backplanes which goes up to 16Mbps and use proprietory upper
>> layers.  On the other hand, we have backplanes which is based on
>> CAN and use DeviceNet/CIP as the upper layer.
>
> I think you're confusing more than illuminating with this.  Keep it simple.
>

You may be right here as well. But I am not convinced CAN is simpler
than RS485. So if you really want to keep it simple, RS485 may
be the way to go.


--
Xiaofan http://mcuee.blogspot.com

2009\05\04@102811 by olin piclist

face picon face
Xiaofan Chen wrote:
> You may be right here as well. But I am not convinced CAN is simpler
> than RS485.

Both can use the same physical layer.  RS-485 ends there.  CAN hardware
provides peer to peer bus arbitration, collision detection, retry, and data
integrity check.  The most the hardware provides for RS-485 is a UART and
then you're on your own.  Using the CAN hardware sounds a lot simpler than
writing the code and dealing with the many pitfals to roll this yourself in
firmware.

Inventing your own bus arbitration protocol is trickier than most people
realize if they haven't tried it themselves or thought it all the way thru.
You have to assume bit errors can happen anywhere, including in vital
control information.  Nodes must be able to to down without locking up the
protocol, etc.  It gets even more complicated if you want true peer to peer
without a master controller.  Normal RS-485 hardware driven from a PIC UART
isn't set up to detect collisions.  After you think it all the way thru,
you'll realize CAN isn't so complicated after all.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\04@110451 by Herbert Graf

picon face
On Sun, 2009-05-03 at 21:52 -0400, Dave Tweed wrote:
> Herbert Graf <RemoveMEhkgrafTakeThisOuTspamspamgmail.com>
> > You need a switch. Hubs don't really exist anymore.
>
> Sure they do, you just have to look harder for them.

That's why I said "don't really", yes you can find them, but it's not
usually worth the effort IMHO.

> > Considering they cost around $10 I don't see what the issue is with
> > needing a switch.
>
> Switches are fine for "typical" desktop usage patterns, but can be a real
> pain in embedded applications, when you really do want the traffic on any
> port repeated to all of the other ports, regardless of how the packets may
> appear to be addressed.

Do it the "right" way then and use the protocol: broadcast packets. My
house monitoring network uses broadcast packets, that way any node can
hear every other node.

> Switches, especially the cheap unmanaged ones, are easily confused. Just
> try diagnosing an embedded network with WireShark, when the switch isn't
> showing you all of the traffic in the first place. Or, it IS showing you
> packets that aren't getting forwarded to one of your embedded devices for
> some reason. Been there, done that.

This is one area where I agree, when trying to debug problems a switch
can be a real pain. The solution is to have your wireshark machine act
as a switch, not the easiest solution (certainly not as easy as using a
hub) but I've had good success with it.

OTOH, hubs were horrible for performance at 10Mbps speeds (I remember
that little "collision" light on my old 10Mbps hub being lit almost
continuously when more then two machines were using the network), I
can't image how saturated a network would be at 100Mbps speeds if you
used a hub. Fine for debug, but hell for normal use.

TTYL


2009\05\04@114623 by Harold Hallikainen

face
flavicon
face

> This is one area where I agree, when trying to debug problems a switch
> can be a real pain. The solution is to have your wireshark machine act
> as a switch, not the easiest solution (certainly not as easy as using a
> hub) but I've had good success with it.

I keep a hub and a switch on my desk for just this purpose! I normally run
everything through the switch, but when using WireShark, it moves over to
the hub so I can see what's going on.

Harold



--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2009\05\04@122744 by olin piclist

face picon face
Herbert Graf wrote:
>> Switches are fine for "typical" desktop usage patterns, but can be a
>> real pain in embedded applications, when you really do want the
>> traffic on any port repeated to all of the other ports, regardless of
>> how the packets may appear to be addressed.
>
> Do it the "right" way then and use the protocol: broadcast packets. My
> house monitoring network uses broadcast packets, that way any node can
> hear every other node.

You don't always get to design the protocol you have to debug or implement
one side of, and there are also obvious downsides to using broadcast.

In any case, this has nothing to do with Dave's original point, which is
that switches won't let you see all network traffic going thru the switch
from any one port.  Using a hub instead of a switch is one way around this.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\04@124729 by William \Chops\ Westfield

face picon face

On May 4, 2009, at 8:04 AM, Herbert Graf wrote:

> hubs were horrible for performance at 10Mbps speeds (I remember
> that little "collision" light on my old 10Mbps hub being lit almost
> continuously when more then two machines were using the network), I
> can't image how saturated a network would be at 100Mbps speeds if you
> used a hub. Fine for debug, but hell for normal use.

Huh?  Hubs are (should be) equivalent to the bus cable.  Collisions  
happen, and it's not nearly as big a deal as some people (token ring  
zealots) would have you believe.  A simple TCP connection between two  
hosts on a 10Mbps ethernet bus gets a collision every couple of  
packets, and still sees 8+Mbps throughput (Biggs, et al.)

People user to run quite a few systems on single "collision domains",  
and it worked pretty well.

BillW

2009\05\04@132025 by Eoin Ross

flavicon
face
For further reading on why you need termination http://en.wikipedia.org/wiki/Time_domain_reflectometer
'If the conductor is of a uniform impedance and properly terminated, the entire transmitted pulse will be absorbed in the far-end termination and no signal will be reflected.'

Imagine what happens at a mid-point (or thereabouts) of a long, high speed communications bus - if there were a reflection of your communications signal.

solarwind wrote:
> I don't understand what you mean by "terminate" the two ends. I tried
> to google for it, but searching for phrases involving "CAN" are
> difficult.


2009\05\04@140438 by Herbert Graf

picon face
On Mon, 2009-05-04 at 09:47 -0700, William "Chops" Westfield wrote:
> On May 4, 2009, at 8:04 AM, Herbert Graf wrote:
>
> > hubs were horrible for performance at 10Mbps speeds (I remember
> > that little "collision" light on my old 10Mbps hub being lit almost
> > continuously when more then two machines were using the network), I
> > can't image how saturated a network would be at 100Mbps speeds if you
> > used a hub. Fine for debug, but hell for normal use.
>
> Huh?  Hubs are (should be) equivalent to the bus cable.  Collisions  
> happen, and it's not nearly as big a deal as some people (token ring  
> zealots) would have you believe.  A simple TCP connection between two  
> hosts on a 10Mbps ethernet bus gets a collision every couple of  
> packets, and still sees 8+Mbps throughput (Biggs, et al.)

I used to run a network in a, let's just say, "cash constrained"
environment. These were places where each run of CAT3 actually had two
Ethernet plugs on each end.

We used hubs, and things worked swimmingly until windows file sharing
started to get big. Once more then just a few machines started
transferring files, overall network performance completely tanked. More
important then bandwidth was the latency, the insane flood of collision
backoffs resulted in some machines taking SECONDS before they could get
their packet through (not good when most of the machines were doing
things over telnet).

Obviously better network planning would have lessened the problems, in
the end though I finally convinced them to move over to switches, the
network never experienced those issues again.

2009\05\04@222644 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 10:27 PM, Olin Lathrop <EraseMEolin_piclistspamspamspamBeGoneembedinc.com> wrote:
{Quote hidden}

Ok. I see your points here. However, he is also facing problems trying
to use Star topology. Given that and if you think it all the way through,
maybe Ethernet + US$10 Ethernet Switch is the way to go. ;-)

--
Xiaofan http://mcuee.blogspot.com

2009\05\04@223304 by Xiaofan Chen

face picon face
On Mon, May 4, 2009 at 11:53 PM, Harold Hallikainen
<RemoveMEharoldKILLspamspamhallikainen.org> wrote:
>
>> This is one area where I agree, when trying to debug problems a switch
>> can be a real pain. The solution is to have your wireshark machine act
>> as a switch, not the easiest solution (certainly not as easy as using a
>> hub) but I've had good success with it.
>
> I keep a hub and a switch on my desk for just this purpose! I normally run
> everything through the switch, but when using WireShark, it moves over to
> the hub so I can see what's going on.
>

My colleague who is doing some work on Ethernet/IP uses a managed
switch. It has port mirroring function which is quite convenient so that
he can configure the ports he needs to listen using WireShark.

Normal switch and hub will not work well for him because of
issues with multi-cast. With normal switch, multi-cast becomes
broadcast.

--
Xiaofan http://mcuee.blogspot.com

2009\05\04@225107 by William \Chops\ Westfield

face picon face

On May 4, 2009, at 7:33 PM, Xiaofan Chen wrote:

> With normal switch, multi-cast becomes broadcast.

I should HOPE so.  It's up to the hosts to filter out which multicasts  
are actually received (in the ethernet controller, or in software, or  
a combination of both.)  It would take a ridiculously complicated  
switch to do correct multicast switching (I'm not even sure it's  
physically possible.)

I suspect that most cheap switches don't do multicast or broadcast  
replication very well...

BillW


2009\05\04@225948 by Richard Prosser

picon face
2009/5/5 Xiaofan Chen <xiaofancSTOPspamspamspam_OUTgmail.com>:
{Quote hidden}

>

2009\05\04@233051 by solarwind

picon face
On Mon, May 4, 2009 at 10:59 PM, Richard Prosser <KILLspamrhprosserspamBeGonespamgmail.com> wrote:
> As long as you avoid fast edges by using a slew rate limited driver or
> a LPF and limiting baud rate then running RS485 unterminated and with
> star etc configuration works fine. We've been doing it on systems for
> 10-15 years so far without problems. (19k2 baud rate, run length up to
> 100m or so and tested to much longer lengths).

Since this is for hobby purposes, I'm going to try both ethernet and CAN.

2009\05\05@014120 by Xiaofan Chen

face picon face
On Tue, May 5, 2009 at 10:51 AM, William "Chops" Westfield
<EraseMEwestfwspamEraseMEmac.com> wrote:
>
>> With normal switch, multi-cast becomes broadcast.
>
> I should HOPE so.  It's up to the hosts to filter out which multicasts
> are actually received (in the ethernet controller, or in software, or
> a combination of both.)  It would take a ridiculously complicated
> switch to do correct multicast switching (I'm not even sure it's
> physically possible.)
>
> I suspect that most cheap switches don't do multicast or broadcast
> replication very well...
>

Hmm, that is what I read.
http://www.erg.abdn.ac.uk/users/gorry/course/lan-pages/switch.html

And I was told so by my colleague sitting next to me who knows quite
a bit about Ethernet. The managed switch he bought is not terribly
expensive actually and it so far serves the purpose of monitoring the
traffic which includes multicast.

--
Xiaofan http://mcuee.blogspot.com

2009\05\05@055357 by Alan B. Pearce

face picon face
>solarwind wrote:
>> Thanks, everyone. I'll be using CAN then. What is CAN usually set up
>> over? RS485?
>
>RS-485 is a separate electrical spec that has nothing to do with CAN.
>However, CAN usually uses differential signalling just like RS-485, so
>the same twisted pair of wires will usually work for either.  One pair
>of a CAT5 cable will work fine for CAN, but you have to terminate the
>two ends.

In fact, when you look at at RS485 and CAN bus transceiver chips, you will
notice they are very similar. We used RS485 chips on a space craft CAN bus,
as we couldn't get space qualified CAN driver chips. The transmit/receive
switching was dealt with by having an RC network on the direction pin that
sensed when the the device was attempting to transmit. The data levels on
the differential bus are very similar, and we had a mix of RS485 and CAN
transceiver chips on the bus during bench testing.

2009\05\05@080206 by Ruben Jönsson

flavicon
face
>
> In fact, when you look at at RS485 and CAN bus transceiver chips, you will
> notice they are very similar. We used RS485 chips on a space craft CAN bus, as
> we couldn't get space qualified CAN driver chips. The transmit/receive switching
> was dealt with by having an RC network on the direction pin that sensed when the
> the device was attempting to transmit. The data levels on the differential bus
> are very similar, and we had a mix of RS485 and CAN transceiver chips on the bus
> during bench testing.
>

How does this work out with the dominant/recessive states of the drivers for
collision detection?

I was under the impression that RS485 drivers just drive as much as they can
regardless if they transmit a "1" or a "0" bit. In fact, when I have tried to
do some collision detection with RS485, I have found that the receiver just
senses the state of the nearest driver if there is long enough cable (or high
enough resistance) to the next active driver with opposite state. And since the
closest receiver is the one on the same chip as the transmitter, the software
just reads what it is transmitting and does not sense a collision.

/Ruben


==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
@spam@ruben@spam@spamspam_OUTpp.sbbs.se
==============================

2009\05\05@082816 by Alan B. Pearce

face picon face
>> In fact, when you look at at RS485 and CAN bus transceiver chips, you
>> will
>> notice they are very similar. We used RS485 chips on a space craft CAN
>> bus,

>How does this work out with the dominant/recessive states
>of the drivers for collision detection?

>From memory the drivers have the same state as CAN ones, but IIRC, we did
have a resistor string between supply and ground, as the terminators, which
would have ensured everything was correct with all devices tristate.

>I was under the impression that RS485 drivers just drive as much
>as they can regardless if they transmit a "1" or a "0" bit.

Not if you tri-state the transmitter ...

>In fact, when I have tried to do some collision detection with RS485,
>I have found that the receiver just senses the state of the nearest
>driver if there is long enough cable (or high enough resistance) to
>the next active driver with opposite state. And since the closest
>receiver is the one on the same chip as the transmitter, the software
>just reads what it is transmitting and does not sense a collision.

This does sound like you were not controlling the transmitter enable, just
left it permanently enabled.

2009\05\05@093705 by Ruben Jönsson

flavicon
face
{Quote hidden}

Do you mean that I should have the transmitter disabled when transmitting a "1"
and passively pull it up?

/Ruben

==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
spamBeGonerubenspamKILLspampp.sbbs.se
==============================

2009\05\05@095119 by Ruben Jönsson

flavicon
face
{Quote hidden}

That should be - passively pull the data lines to a "0" state.

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
.....rubenspam_OUTspampp.sbbs.se
==============================

2009\05\05@134522 by Justin Richards

face picon face
Only $10.00 for a switch much less for a NIC, but the cost to setup a
development environment for a PIC - Ethernet combo seems high by comparison.

So I have tried think of the cheap or obsolete ethernet devices that could
be hacked. like ISA NIC Cards, PCMCIA NIC cards, VOIP adapters, ADSL modems
with my favorite choice so far being a jetdirect printer server.

I like the mini-web and maxi-web type devices but it seems that this will
force me to take the plunge and  get hold of a icsp and a c compiler of some
sort.

I have enjoyed using kit81 to prog 16f628 in assembler without the need for
smt.

My B-Day is coming up so i just might have to treat myself to an iscp.

Cheers Justin





>
> You need a switch. Hubs don't really exist anymore.
>
> Considering they cost around $10 I don't see what the issue is with
> needing a switch.
>
> TTYL
>
> -

2009\05\06@041839 by Xiaofan Chen

face picon face
On Tue, May 5, 2009 at 10:26 AM, Xiaofan Chen <TakeThisOuTxiaofanc.....spamTakeThisOuTgmail.com> wrote:
{Quote hidden}

Moreover, you do not need to use peer to peer or mulit-master
in this application. You can always use Master Slave with
RS485, then there is no need of arbitration.


--
Xiaofan http://mcuee.blogspot.com

2009\05\06@043736 by Bob Ammerman

picon face

{Quote hidden}

It seems pretty obvious to me....

If you can live with a single master/multi-slave environment then RS-485 is
likely to be your simplest solution.

If you need multimaster, or nodes sending arbitrary messages to one-another
then CAN makes more sense, even tho' configuring it is a bit of a pain.

-- Bob Ammerman
RAm Systems

2009\05\06@045108 by Alan B. Pearce

face picon face
>> Do you mean that I should have the transmitter disabled
>> when transmitting a "1" and passively pull it up?
>
>That should be - passively pull the data lines to a "0" state.

Well, I cannot remember offhand, the relevant polarities, but if using a
normal UART to send and receive on the bus, with all transmitters tristated,
the output of the receivers should be in the idle state. Then when a device
wants to transmit, you enable that transmitter using the enable pin driven
by the RTS signal from the UART. AIUI the receiver chips are arranged to
have enough bias inside them to passively pull the inputs to the idle state.

If you are not controlling the enable line on the transmitters, then you
will not be able to do a multi-drop connection.

2009\05\06@075909 by olin piclist

face picon face
Xiaofan Chen wrote:
> Moreover, you do not need to use peer to peer or mulit-master
> in this application. You can always use Master Slave with
> RS485, then there is no need of arbitration.

You can, but that's still a lot of protocol to think thru properly and then
develop the firmware for.  Most RS-485 systems are master/slave, but that
doesn't get around all the problems.  Even then you still have to implement
some sort of ACK/NACK, packets, checksums, timeouts for non-responding
slaves, making sure slaves don't get confused by retransmissions when a ACK
gets lost, discovery of new devices, etc.  This stuff may seem simple at
first glance, but it's not trivial at all.  CAN, on the other hand, has most
of this defined in the spec and implemented in the silicon.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2009\05\07@150032 by Ruben Jönsson

flavicon
face
> >> Do you mean that I should have the transmitter disabled
> >> when transmitting a "1" and passively pull it up?
> >
> >That should be - passively pull the data lines to a "0" state.
>
> Well, I cannot remember offhand, the relevant polarities, but if using a
> normal UART to send and receive on the bus, with all transmitters tristated,
> the output of the receivers should be in the idle state. Then when a device
> wants to transmit, you enable that transmitter using the enable pin driven
> by the RTS signal from the UART. AIUI the receiver chips are arranged to
> have enough bias inside them to passively pull the inputs to the idle state.
>
> If you are not controlling the enable line on the transmitters, then you
> will not be able to do a multi-drop connection.

I understand that but what I don't understand is how CAN can have one dominant
and one recessive state with a standard RS485 driver. One way could be to pull
the line to the recessive state (at one place on the bus only), set the data
input to the dominant state (constantly) and connect the uart TX pin to the
enable pin (perhaps inverting it to get things right). Is this how it is done?

/Ruben
==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
.....rubenspamRemoveMEpp.sbbs.se
==============================

2009\05\12@063516 by Alan B. Pearce

face picon face
>I understand that but what I don't understand is how CAN can have one
>dominant and one recessive state with a standard RS485 driver. One way
>could be to pull the line to the recessive state (at one place on the
>bus only), set the data input to the dominant state (constantly) and
>connect the uart TX pin to the enable pin (perhaps inverting it to get
>things right). Is this how it is done?

Yes it is. Having had a look at the schematic, there are a number of R & C
components in there as well, but I believe these are there just to allow a
5V part to connect to a 3V3 FPGA. It is done by having RxD and /TxD in our
case, but with complimentary enables on a 26c31 style part, it could have a
TxD.

2009\05\13@021406 by Ruben Jönsson

flavicon
face
> >I understand that but what I don't understand is how CAN can have one
> >dominant and one recessive state with a standard RS485 driver. One way
> >could be to pull the line to the recessive state (at one place on the
> >bus only), set the data input to the dominant state (constantly) and
> >connect the uart TX pin to the enable pin (perhaps inverting it to get
> >things right). Is this how it is done?
>
> Yes it is. Having had a look at the schematic, there are a number of R & C
> components in there as well, but I believe these are there just to allow a 5V
> part to connect to a 3V3 FPGA. It is done by having RxD and /TxD in our case,
> but with complimentary enables on a 26c31 style part, it could have a TxD.
>

OK, thanks for the explanation.

How does this work out with EMI, cable lengths and termination? I mean,
normally you wold have these 3 states on your transmission line: tristated very
weakly driven to idle state ("0"?), actively driven to "0" state and actively
driven to "1" state. Instead you have 2 states: passively driven to "0"/idle
state with resistors and actively driven to "1" state.

Is this the way a normal can driver works (passive drive to recessive state and
active drive to dominant state) or does it have any other clever circuitry to
handle collision detection and arbitration?

I have been thinking of using this method to also automatically handle
turnaround for RS485 nodes (switching between txing and rxing). That way
turnaround would be handled automatically without the need of a TX enable
signal but I'm afraid I will reduce maximum cable length and increase EMI
susceptibility.

/Ruben

==============================
Ruben Jönsson
AB Liros Electronic
Box 9124, 200 39 Malmö, Sweden
TEL INT +46 40142078
FAX INT +46 40947388
RemoveMErubenspamspamBeGonepp.sbbs.se
==============================

2009\05\13@152046 by Alan B. Pearce

face picon face
>OK, thanks for the explanation.

You are welcome.

>How does this work out with EMI, cable lengths and termination?

Don't know. In our case the CAN was point to point for the second
instrument, I don't know enough about the spacecraft architecture for the
first instrument to know if multiple instruments were on the CAN bus, but
believe this may have been the case.

>Is this the way a normal can driver works (passive drive to
>recessive state and active drive to dominant state)

Essentially yes, as I understand it. It may be that they have current
source/sink in the driver chips, but I don't have a driver chip datasheet
handy to check.

>I have been thinking of using this method to also automatically
>handle turnaround for RS485 nodes (switching between txing and
>rxing). That way turnaround would be handled automatically without
>the need of a TX enable signal but I'm afraid I will reduce maximum
>cable length and increase EMI susceptibility

Hmm, I am looking at using MCP2551 CAN transceiver chips for the same
purpose for the same reason ...

The termination we used on the spacecraft instrument was 150 ohms across the
differential pairs, and then 300 ohm full up and pull down to set the
recessive state condition. This would have given pretty good transitions
from dominant to recessive state, (the other end had the same I believe),
and we were operating at 500kbs. So I suspect that with suitable
terminations setting the recessive state, there would be no or little
difference to active drive to the recessive state, unless running at very
high rates that RS485 can go to.

More... (looser matching)
- Last day of these posts
- In 2009 , 2010 only
- Today
- New search...