Searching \ for 'serial port dilemma - design advise requested' 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/io/serials.htm?key=serial
Search entire site for: 'serial port dilemma - design advise requested'.

Truncated match.
PICList Thread
'serial port dilemma - design advise requested'
2004\06\22@114937 by Trungie*!

flavicon
face
I have a PIC device that connects to my PC via serial port for constant
communication.

I would like to have over 10 PIC devices connected to my PC somehow for
communication.

However, i would not like to buy some sort of expensive multi serial port
card for it.

What sorts of things can i do to over come this problem? Potentially i would
like to use over 10 of these PIC devices at once.

Thanks all!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@115606 by Spehro Pefhany

picon face
At 01:44 AM 6/23/2004 +1000, you wrote:
>I have a PIC device that connects to my PC via serial port for constant
>communication.
>
>I would like to have over 10 PIC devices connected to my PC somehow for
>communication.
>
>However, i would not like to buy some sort of expensive multi serial port
>card for it.
>
>What sorts of things can i do to over come this problem? Potentially i would
>like to use over 10 of these PIC devices at once.
>
>Thanks all!

RS-232 to RS-485 converter on the PC, then use RS-485 on all the devices.

There are hack ways to use RS-232 to make a multidrop network, but I'll
let someone else suggest *that*.

Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@135210 by Herbert Graf

flavicon
face
On Tue, 2004-06-22 at 11:44, Trungie*! wrote:
> I have a PIC device that connects to my PC via serial port for constant
> communication.
>
> I would like to have over 10 PIC devices connected to my PC somehow for
> communication.
>
> However, i would not like to buy some sort of expensive multi serial port
> card for it.
>
> What sorts of things can i do to over come this problem? Potentially i would
> like to use over 10 of these PIC devices at once.

       What about USB? Either by converting your devices to USB or using
USB-serial ready made convertors. I think the limit on ONE USB port is
127 devices, FAR more then the software limitations you'll hit first! :)
TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@144342 by Peter Moreton

flavicon
face
Herbert,

I have used Win2K / XP with multiple USB serial devices, and can report 2
big problems:

1/ The COM ports frequently re-enumerate (especially when
plugged/unplugged), and as a result the COM port numbering sequence can
change.

2/ Many of the USB COM port drivers don't work reliably with more that 2
adaptors present. I have however, used a device from 'Keyspan' that reliably
supports 4 USB com ports.

Can I suggest RS485?

Peter Moreton


> {Original Message removed}

2004\06\22@152658 by Wouter van Ooijen

face picon face
> 1/ The COM ports frequently re-enumerate (especially when
> plugged/unplugged), and as a result the COM port numbering
> sequence can change.

Funny, I do see enumerations, but I have *never* seen the port number
change.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@153732 by David VanHorn

flavicon
face
At 01:44 AM 6/23/2004 +1000, Trungie*! wrote:

>I have a PIC device that connects to my PC via serial port for constant
>communication.
>
>I would like to have over 10 PIC devices connected to my PC somehow for
>communication.
>
>However, i would not like to buy some sort of expensive multi serial port
>card for it.
>
>What sorts of things can i do to over come this problem? Potentially i would
>like to use over 10 of these PIC devices at once.

Connect them all in a ring.
Packetize the data with source and destination addresses.
For each widget, if it gets a packet that isn't for it, then send it along.

Add a "time to live" byte, that is decremented by each widget, to prevent packets from looping forever.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@154620 by David VanHorn

flavicon
face
At 07:41 PM 6/22/2004 +0100, Peter Moreton wrote:

>Herbert,
>
>I have used Win2K / XP with multiple USB serial devices, and can report 2
>big problems:
>
>1/ The COM ports frequently re-enumerate (especially when
>plugged/unplugged), and as a result the COM port numbering sequence can
>change.
>
>2/ Many of the USB COM port drivers don't work reliably with more that 2
>adaptors present. I have however, used a device from 'Keyspan' that reliably supports 4 USB com ports.

Edgeport adaptors avoid all these problems. I've had over 40 ports on one USB connection. You wouldn't want to see the list price though.

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@162231 by Byron A Jeff

face picon face
On Wed, Jun 23, 2004 at 01:44:11AM +1000, Trungie*! wrote:
> I have a PIC device that connects to my PC via serial port for constant
> communication.

OK.

>
> I would like to have over 10 PIC devices connected to my PC somehow for
> communication.

Well that's a challenge. A couple of questions:

1) Do all of the PICs have to be able to communicate at the same time?
2) Is the communcations required going to have to be bidirectional?

> However, i would not like to buy some sort of expensive multi serial port
> card for it.

That could be painful.

>
> What sorts of things can i do to over come this problem? Potentially i would
> like to use over 10 of these PIC devices at once.

Well it gets back to the questions above. If each and every PIC needs to be
able to independently communicate at the same time, then you're pretty much
stuck with having a serial port per PIC and the multi-serial solution.

However if you can arrange so that the PC can pick which PIC to talk to, then
you can arrange what is known as a multidrop network where all of the PICs
share the same serial connection.

The most popular hardware interface for multidrop serial is EIA485 (also known
as RS485). It's cheap and reliable. However there's no specified protocol that
sits on top of it to talk to each of the individual PIC nodes. So you'll have
to fish around for ways of doing it.

Hope this gets you started on the subject.

BAJ

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\22@162523 by D. Jay Newman

flavicon
face
> The most popular hardware interface for multidrop serial is EIA485 (also known
> as RS485). It's cheap and reliable. However there's no specified protocol that
> sits on top of it to talk to each of the individual PIC nodes. So you'll have
> to fish around for ways of doing it.

We're working on it.

http://enerd.ws/robots/robin/
--
D. Jay Newman           ! DCX - it takes off and lands base first,
.....jayKILLspamspam@spam@sprucegrove.com     !       as God and Robert Heinlein intended.
http://enerd.ws/robots/ !

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

2004\06\23@023835 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: David VanHorn [dvanhornspamKILLspamCEDAR.NET]

>Connect them all in a ring.
>Packetize the data with source and destination addresses.
>For each widget, if it gets a packet that isn't for it, then
>send it along.
>
>Add a "time to live" byte, that is decremented by each widget,
>to prevent packets from looping forever.

Trouble with this approach is that two serial ports per PIC would be
required, and only the newer(and larger) 18F support this in hardware.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
.....postmasterKILLspamspam.....bookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam_OUTspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@030400 by Luis Moreira

flavicon
face
use a RS232 to RS485 adapter and sort your S/W to suit.
regards
       Luis


-----Original Message-----
From: Trungie*! [trungiespamspam_OUTDOTGEEK.ORG]
Sent: 22 June 2004 16:44
To: @spam@PICLISTKILLspamspammitvma.mit.edu
Subject: serial port dilemma - design advise requested


I have a PIC device that connects to my PC via serial port for constant
communication.

I would like to have over 10 PIC devices connected to my PC somehow for
communication.

However, i would not like to buy some sort of expensive multi serial port
card for it.

What sorts of things can i do to over come this problem? Potentially i would
like to use over 10 of these PIC devices at once.

Thanks all!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@033756 by Alan B. Pearce

face picon face
>>Add a "time to live" byte, that is decremented by each widget,
>>to prevent packets from looping forever.
>
>Trouble with this approach is that two serial ports per PIC would be
>required, and only the newer(and larger) 18F support this in hardware.

No you need only one serial port, and the connection goes around a ring in
token ring network style.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@034418 by Amaury Jacquot

flavicon
face
Luis Moreira wrote:
> use a RS232 to RS485 adapter and sort your S/W to suit.
> regards
>         Luis

> What sorts of things can i do to over come this problem? Potentially i would
> like to use over 10 of these PIC devices at once.
>
> Thanks all!

As luis said, it's easy, RS485 multi drop with master/slave protocol

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@040323 by Alan B. Pearce

face picon face
>As luis said, it's easy, RS485 multi drop with master/slave protocol

However the multidrop RS232 using open collector or diode connection saves a
pin on the PIC to turn around the RS485 chip from receive to transmit, and
saves the RS485-RS232 convertor at the PC end. The required protocol is the
same, but the turnarounds in data direction are instead done as timeouts
(which would probably be needed with RS485 anyway)

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservEraseMEspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@041154 by Amaury Jacquot

flavicon
face
Alan B. Pearce wrote:
>>As luis said, it's easy, RS485 multi drop with master/slave protocol
>
>
> However the multidrop RS232 using open collector or diode connection saves a
> pin on the PIC to turn around the RS485 chip from receive to transmit, and
> saves the RS485-RS232 convertor at the PC end. The required protocol is the
> same, but the turnarounds in data direction are instead done as timeouts
> (which would probably be needed with RS485 anyway)

right, but then you are distance limited, unless you use a midi-like
current loop interface

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@042647 by Alan B. Pearce

face picon face
>> However the multidrop RS232 using open collector or diode connection
saves a
>> pin on the PIC to turn around the RS485 chip from receive to transmit,
and
...
>right, but then you are distance limited, unless you use a midi-like
>current loop interface

Hmm, when I remember the distances we used to run those wires without using
a current interface, I guess it becomes a case of what baud rate is
required. The OP was wanting to poll them each second, but no indication of
message sizes.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspam.....mitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@050046 by Luis Moreira

flavicon
face
There is a circuit where change over from receive to transmit is done
automatically by sensing the transmit line , I can not find it at this point
but I will send it to you when I do find it.

       regards
               Luis

{Original Message removed}

2004\06\23@051152 by hael Rigby-Jones

picon face
>-----Original Message-----
>From: Alan B. Pearce [EraseMEA.B.PearcespamRL.AC.UK]
>Sent: 23 June 2004 08:38
>To: RemoveMEPICLISTEraseMEspamEraseMEMITVMA.MIT.EDU
>Subject: Re: serial port dilemma - design advise requested
>
>
>>>Add a "time to live" byte, that is decremented by each widget, to
>>>prevent packets from looping forever.
>>
>>Trouble with this approach is that two serial ports per PIC would be
>>required, and only the newer(and larger) 18F support this in hardware.
>
>No you need only one serial port, and the connection goes
>around a ring in token ring network style.
>

Alan,

I don't understand how the scheme would work in that case.  The suggestion
by David VanHorn was that a packet is sent to a PIC.  If the packet is not
destined for that PIC, it is sent onto the next one.  This implies (to me at
least) that the PIC's are daisy chained, and the PC always talks to the
first one in the link.

If this implemented with a common bus, then all the PIC's would receive the
packet at once, so there would surely be no need to keep sending it on?

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
RemoveMEpostmasterspam_OUTspamKILLspambookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservTakeThisOuTspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@052642 by Trungie*!

flavicon
face
> Hmm, when I remember the distances we used to run those wires without
using
> a current interface, I guess it becomes a case of what baud rate is
> required. The OP was wanting to poll them each second, but no indication
of
> message sizes.

The more i read, the more interesting this adventure is getting! Message
sizes will be small. In the measure of a kbyte or two max?

Two types of messages:
- Requests will be sent to the PICmicro and data stored on an small eeprom
or maybe the PIC itself will be transmitted.
- The PICmicro communicating back to the PC reporting it's status. Which is
would be small 64 bytes?

I was thinking of the concept of using ethernet, which will INSTANTLY solve
my problems! Each PIC would have an IP address and be connected by ethernet.
But those solutions require purchase of a device similar to the Xport which
is in the order of $50.

My dream goal is to be able to have each PIC have an ip address, a small
very web server for data display.

Can a multidrop help me achieve my goal?

Thanks guys

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@053719 by Alan B. Pearce

face picon face
>I was thinking of the concept of using ethernet, which will
>INSTANTLY solve my problems! Each PIC would have an IP address
>and be connected by ethernet. But those solutions require
>purchase of a device similar to the Xport which is in the
>order of $50.

Not necessarily. Look at the protocol in the document of this link.
http://www.digitrax.com/loco1hdr.htm and download the PDF file from the link
at the bottom. This implements something similar to what you suggest above.
The hardware required at the PC end can be pretty minimal. I have not linked
direct to the PDF as it is a proprietary protocol, and you should read the
conditions of use before downloading, but it will give you an idea of how to
go about it on an ordinary serial line.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservKILLspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@054135 by Alan B. Pearce

face picon face
>I don't understand how the scheme would work in that case.  The suggestion
>by David VanHorn was that a packet is sent to a PIC.  If the packet is not
>destined for that PIC, it is sent onto the next one.  This implies (to me
at
>least) that the PIC's are daisy chained, and the PC always talks to the
>first one in the link.

This is how the IBM Token Ring network does it, which is what I believed you
were referring to. Each device is daisy chained to the next, and the master
device starts a transaction by sending a token into the ring, As each device
receives the token it knows that it can read the message for something
destined for itself, and/or tag a message destined for another device onto
the end of the message as it passes the message on to the next device. My
understanding is that one network message can have several device messages
embedded into it.

>If this implemented with a common bus, then all the PIC's would receive the
>packet at once, so there would surely be no need to keep sending it on?

Correct, which is what I was suggesting with the multidrop RS232, and others
suggest RS485.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservSTOPspamspamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@075846 by Herbert Graf

flavicon
face
On Wed, 2004-06-23 at 02:39, Michael Rigby-Jones wrote:
> >-----Original Message-----
> >From: David VanHorn [spamBeGonedvanhornSTOPspamspamEraseMECEDAR.NET]
>
> >Connect them all in a ring.
> >Packetize the data with source and destination addresses.
> >For each widget, if it gets a packet that isn't for it, then
> >send it along.
> >
> >Add a "time to live" byte, that is decremented by each widget,
> >to prevent packets from looping forever.
>
> Trouble with this approach is that two serial ports per PIC would be
> required, and only the newer(and larger) 18F support this in hardware.

       I don't see why? All you do is connect the TX of one PIC to the RX of
the next, and so on, forming a ring, only one UART per PIC necessary.
The ring ends up transmitting all the data. It's actually a very neat
way of solving alot of problems, and was used quite extensively in
earlier networking days. These days however technology has advanced
enough such that the benefits of ring relay are outweighed by the added
annoyances. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email KILLspamlistservspamBeGonespammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@080509 by Herbert Graf

flavicon
face
On Wed, 2004-06-23 at 05:11, Michael Rigby-Jones wrote:

> I don't understand how the scheme would work in that case.  The suggestion
> by David VanHorn was that a packet is sent to a PIC.  If the packet is not
> destined for that PIC, it is sent onto the next one.  This implies (to me at
> least) that the PIC's are daisy chained, and the PC always talks to the
> first one in the link.

       Correct. The PC's TX is connected to the RX of PIC1. The TX of PIC1 is
connected to the RX of PIC2, and so on, until the TX of PICxx is
connected the the RX of the PC, forming a ring. Only one UART per device
needed.

> If this implemented with a common bus, then all the PIC's would receive the
> packet at once, so there would surely be no need to keep sending it on?

       They are daisy chained, they don't share a common bus, only one TX is
seen by each RX, the TX of the device before it on the ring. TTYL


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@081927 by hael Rigby-Jones

picon face
{Quote hidden}

Thanks for that, as always, it seems blatantly obvious once you've been
told!

I guess one of the potential problems would be the variable latency of the
packet depending on how many slave nodes it has to travel through.  At low
baud rates with lots of slaves this could start to add up a bit.

Regards

Mike




=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================
Any questions about Bookham's E-Mail service should be directed to
.....postmasterspam_OUTspambookham.com.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistserv.....spamTakeThisOuTmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@095119 by David VanHorn

flavicon
face
At 07:39 AM 6/23/2004 +0100, Michael Rigby-Jones wrote:

>>-----Original Message-----
>>From: David VanHorn [TakeThisOuTdvanhornKILLspamspamspamCEDAR.NET]
>
>>Connect them all in a ring.
>>Packetize the data with source and destination addresses.
>>For each widget, if it gets a packet that isn't for it, then
>>send it along.
>>
>>Add a "time to live" byte, that is decremented by each widget,
>>to prevent packets from looping forever.
>
>Trouble with this approach is that two serial ports per PIC would be
>required, and only the newer(and larger) 18F support this in hardware.

No, you only need one port.
TXD of A goes to RXD of B, and so on.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email .....listservspamRemoveMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@095454 by David VanHorn

flavicon
face
>
>I don't understand how the scheme would work in that case.  The suggestion by David VanHorn was that a packet is sent to a PIC.  If the packet is not destined for that PIC, it is sent onto the next one.  This implies (to me at least) that the PIC's are daisy chained, and the PC always talks to the first one in the link.

That's what I meant.

>If this implemented with a common bus, then all the PIC's would receive the
>packet at once, so there would surely be no need to keep sending it on?

Unfortunately, 232 isn't designed to drive more than one receiver.
You can usually get away with it, but it's not guaranteed.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email RemoveMElistservspamspamBeGonemitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@095708 by cisco J. A. Ares

flavicon
face
Michael Rigby-Jones wrote:

>Thanks for that, as always, it seems blatantly obvious once you've been
>told!
>
>I guess one of the potential problems would be the variable latency of the
>packet depending on how many slave nodes it has to travel through.  At low
>baud rates with lots of slaves this could start to add up a bit.
>
>Regards
>
>Mike
>
>

Not that much, if the slaves are able to start echoing the incomming
message as soon as the second byte is being received.

I've missed the beginning of this thread, but some Sony cameras use this
kind of RS232 ring and a protocoll runing in such ring, callded VISCA ,
as you can see from page 39 of the following PDF.

http://bssc.sel.sony.com/Professional/docs/manuals/fcb_ex480b_e.p.pdf

Francisco

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email spamBeGonelistserv@spam@spamspam_OUTmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@100530 by Alan B. Pearce

face picon face
>I guess one of the potential problems would be the variable latency of the
>packet depending on how many slave nodes it has to travel through.  At low
>baud rates with lots of slaves this could start to add up a bit.

I believe that IBM Token Ring performs much better than Ethernet when they
are pushing the maximum data transfer capacity. Ethernet has lower latency
when the system is lightly loaded, but gets worse as collisions increase
when the required data to be transferred is increased.

I have never been in a situation to verify this, just been told so by others
who were more into networks than I ever have been.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email TakeThisOuTlistservspamspammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@101533 by David VanHorn

flavicon
face
>
>I have never been in a situation to verify this, just been told so by others who were more into networks than I ever have been.

Well, in a loop of N devices, you can have N packets transferring at the same time.  In ethernet, you can have one, or two if it's full duplex (most aren't)

Of course ethernet goes faster..

One little thing to be aware of, if a device is broken, or removed from the ring, then everything stops.  Single point failures can be diagnosed by periodic "I'm OK" packets which make it up the remaining segment of the ring to the master.

If Z,Y, and X are reporting, then the faiure must be between X and W.
Packets sent out from the master might be getting to W, but you can't know for sure.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservEraseMEspammitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@110441 by Byron A Jeff

face picon face
On Wed, Jun 23, 2004 at 07:39:34AM +0100, Michael Rigby-Jones wrote:
> >-----Original Message-----
> >From: David VanHorn [RemoveMEdvanhornEraseMEspamspam_OUTCEDAR.NET]
>
> >Connect them all in a ring.
> >Packetize the data with source and destination addresses.
> >For each widget, if it gets a packet that isn't for it, then
> >send it along.
> >
> >Add a "time to live" byte, that is decremented by each widget,
> >to prevent packets from looping forever.
>
> Trouble with this approach is that two serial ports per PIC would be
> required, and only the newer(and larger) 18F support this in hardware.

No it doesn't. The whole point of a ring is that data travels in a single
direction. So the RxD of a single USART connects to the previous node in the
ring while the TxD of that same USART connects to the succeeding node. It
only takes one port. The problem with rings in general is the latency in
data travelling around the ring and the potential for a single node failure
to crash the ring. Another point is that every node in the ring until it gets
to the target has to process every packet. On a shared bus with 9 bit
addressing it's possible to configure the USART to ignore data and only
interrupt on an address byte. This is really efficient because each node can
set to listen for just the address byte, and when it comes, each checks to
see if the packet is for them. All of the non addressed nodes simply go back
to listening for the next address byte, while the target turns interrupts on
for all data thus receiving the packet. This is one the primary reasons that
I plan to implement a EIA485 bus when I get around to this project.

However rings are simple and there are no potential for collisions because
every connection is point to point.

BAJ

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email @spam@listservRemoveMEspamEraseMEmitvma.mit.edu with SET PICList DIGEST in the body

2004\06\23@210544 by William Chops Westfield

face picon face
On Jun 23, 2004, at 7:06 AM, Alan B. Pearce wrote:

>> I guess one of the potential problems would be the variable latency
>> of the packet depending on how many slave nodes it has to travel
>> through.  At low baud rates with lots of slaves this could start to
>> add up a bit.
>
> I believe that IBM Token Ring performs much better than Ethernet when
> they are pushing the maximum data transfer capacity. Ethernet has
> lower latency when the system is lightly loaded, but gets worse as
> collisions increase when the required data to be transferred is
> increased.
>
This was widely believed at the time token ring was first offered, and
it was supported by some real computer science, but the assumptions
turned out to be questionable, and some actual experiments with real
traffic on real networks showed the beliefs to be wrong.  Token ring
networks were more predictable than ethernet, but there were not very
many instances where that turned out to be very important.

See Boggs, et al, "Measured Capacity of an Ethernet: Myths and Reality"
(1988)  http://www.rh.edu/~denoial/lmi/DEC-enet-performWP.pdf

And that was before ethernet interface prices came down by a factor of
100 while token ring prices stayed constant, and before ethernet speed
got increased by a factor of 10 to blow away FDDI (also a token ring.),
and that 10 times faster ethernet followed the same percipitous price
curve.  And before ethernet "switching" changed ethernet behavior for
the better.  And then they did the whole factor of 10 thing AGAIN.  And
it looks like they'll do it one more time.

Note that with IBM token ring, each node adds at most a couple of bit
times worth of latency (the packet goes all the way around the ring.)
With a uart based token ring, each node adds at least a bytes worth of
latency, and it's a slower byte...

(So has anyone standardized the async uart ring network?  It certainly
seems to get reinvented rather frequently...)

BillW

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email EraseMElistservspam@spam@mitvma.mit.edu with SET PICList DIGEST in the body

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