Searching \ for 'Networked PICs - suggestions invited' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devices.htm?key=pic
Search entire site for: 'Networked PICs - suggestions invited'.

Truncated match.
PICList Thread
'Networked PICs - suggestions invited'
1999\02\24@034216 by Russell McMahon

picon face
A not totally unfamiliar thread -

I have been asked to take over a project which involves "networking"
up to 400 PIC based devices on a physically short bus (typically 100
metres). Don't ask why yet. There are some very interesting aspects
which will be of wider interest which I will be able to share in due
course. Prior prototype used 12C508 but something with more I/O will
be needed.

I need a protocol which allows good use of the bus without data loss.
I have seen much discussion here previously about various home bus's,
automation protocols etc. One of these may be suitable. Any comments
appreciated.
I am contemplating rolling my own protocol but someone may wish to
talk me out of this.

DETAILS:

A master station (M) sends commands to up to 400 slaves (S).
Action at the PIC is relatively trivial (display, LEDs switches type
stuff).

Data transfer must be assured with high confidence.
Error rate is low but cannot be assumed to be zero.
ACKing by Slaves is therefore considered appropriate.

Slaves also originate autonomous messages back to the Master.
Acking by Master is considered appropriate.

Slaves will listen real-time so can ack as soon as message block to
them is completed.
Master is PC based (so far) so potentially may not be real time
enough to ensure that an ack can be returned instantly when a message
is received.
A submaster may therefore be required to ensure real time ackimg.
Alternatively acking could be an autonomous action at some later time
but this increases potential for bus contention.
Acking in a reserved time slot (only 1 byte needed) immediately after
a transmission allows a slave the certainty that there would (should
:-)) be no other bus traffic.

Master may transmit at either 2400bps or 19200 (no other speeds)
Slaves will transmit at 19200
For technical reasons the bus is available for the Master to transmit
at 2400 bps at any time and at high speed only in slots about 10% of
the time.
Slaves can only transmit in the 10% slot.
Therefore Master transmissions during the slow speed time can not be
acked by slaves until the 10% high speed slot arrives.

Sounds confusing?
You bet!

Probably the bus will cycle about once per second with 0.1s available
for "high speed" interaction ie about 192 bytes of data at 100%
utilisation. A faster cycle time with shorter data slots may be used.

Master transmissions PROBABLY will be 4 or 8 bytes including CRC
(probably)
   Either may be needed depending on msg purpose.
Slave transmissions probably need to be 2 or 3 bytes (only one or
other)
Acks can probably be 1 byte if we assume that only the intended
recipient will try to ack (a partial recipient id and message number
can be contained in 1 byte)

Typical worst case seems to require about 10 - 20% bus utilisation
but this would not be often. usually rather lower (a few messages per
second in either direction).

Collision control by

Aloha            none, retry if no ack
Slotted Aloha    Send in defined slots
Random backoff on collision (HDLC etc etc)
Multiple sends in different "slots"
   Something like random backoff
   eg Slot 6 the first time
      If fail send in slot 3 next time,
      If fail send in ...
      With pseudo random slot allocation.
etc

have been thought about.

Token passing and polling seem too slow for the number of stations
involved.
Pure anarchy seems too dangerous for the given max required
utilisation.

Processor will probably ultimately be 16C505 or similar (MUST be
cheap)
Using 16F84 for the moment but avoiding interrupts etc

Other makers devices have been considered but at the price none seem
substantially better than PIC.


TIA


           Russell McMahon




================

Copied to Roger fyi.

1999\02\24@112827 by Jim Lee

picon face
>A not totally unfamiliar thread -
>
>I have been asked to take over a project which involves "networking"
>up to 400 PIC based devices on a physically short bus (typically 100
>metres). Don't ask why yet. There are some very interesting aspects
>which will be of wider interest which I will be able to share in due
>course. Prior prototype used 12C508 but something with more I/O will
>be needed.
>
>I need a protocol which allows good use of the bus without data loss.
>I have seen much discussion here previously about various home bus's,
>automation protocols etc. One of these may be suitable. Any comments
>appreciated.
>I am contemplating rolling my own protocol but someone may wish to
>talk me out of this.
>
 You could try a sharlock and a shared serial ram for communication. An
example would be.. (Although far far smaller than you need)

http://www.concentric.net/~Jjlee/robotics/stampCarriers/jmbosStampCarriers.shtml

Good luck

-jim lee

1999\02\24@113449 by Harrison Cooper

flavicon
face
if....Microchip would release their CAN product....that might be a good
solution?
Anyone know the latest on it?

1999\02\24@114250 by John Esposito

flavicon
face
uChip's website indicated that they are near production of the CAN chips.
I don't remember the details; check out the site.

--John




Harrison Cooper <spam_OUThcooperTakeThisOuTspamES.COM> on 02/24/99 11:33:59 AM

Please respond to pic microcontroller discussion list
     <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>

To:   PICLISTspamKILLspamMITVMA.MIT.EDU
cc:    (bcc: John Esposito/gg/DadeInt)
Subject:  Re: Networked PICs - suggestions invited




if....Microchip would release their CAN product....that might be a good
solution?
Anyone know the latest on it?

1999\02\24@131555 by Marc

flavicon
face
For the hardware structure I suggest the use 4 RS485 nets. Each of them can
have up to 127 devices connected. The master device has 4 separate bus drivers t
o
control each section electrically independant. That allows for a total of 508 sl
aves,
and more traffic than on a single bus.

The PC should be talked to by the master board with RS232 at a high enough rate,
for
example 57600 RTS/CTS.

Considering the PC is a WINDOWS machine, it is a good idea to handle all the ACK
/NAK
and retransmission in the master board directly. You can then use tight response
times for ACK/NAK.

1999\02\24@153011 by Harold Hallikainen

picon face
On Wed, 24 Feb 1999 21:37:03 +1300 Russell McMahon <.....apptechKILLspamspam.....CLEAR.NET.NZ>
writes:

>Collision control by
>
>Aloha            none, retry if no ack
>Slotted Aloha    Send in defined slots
>Random backoff on collision (HDLC etc etc)
>Multiple sends in different "slots"
>    Something like random backoff
>    eg Slot 6 the first time
>       If fail send in slot 3 next time,
>       If fail send in ...
>       With pseudo random slot allocation.
>etc
>
>have been thought about.
>
>Token passing and polling seem too slow for the number of stations
>involved.
>Pure anarchy seems too dangerous for the given max required
>utilisation.

       Sounds like an interesting project!  I kinda like "mini-slotted"
access.  I've also called it "absence of data token passing."  A minimum
slot time is set aside for each site to begin transmission.  If that site
does not begin transmission, site counters in all sites advance,
authorizing the next site to transmit.  If an authorized site starts
transmitting, advancing of the site counters in all sites is held off
until slot-time after transmission ceases.  All sites listen to the line
and resynchronize their site counters based on received data (they assume
that data received from any site indicates that site had permission to
transmit).
       This is a form of token passing in that each site authorizes the
next to transmit through its not transmitting (or ceasing to transmit).
However, there is no way to lose the token.
       Depending on the number of sites and the mini-slot time, access
time may not be acceptable.
       I used this technique in a system developed about 15 years ago.
It used Bell 202 modems operating over voice-grade circuits that, in some
cases, ran several hundred miles.  With Bell 202, I ran a mini-slot time
of 50mS.  The system allowed up to 100 sites, but a more typical
installation was about 15 sites.


Harold





Harold Hallikainen
EraseMEharoldspam_OUTspamTakeThisOuThallikainen.com
Hallikainen & Friends, Inc.
See the FCC Rules at http://hallikainen.com/FccRules and comments filed
in LPFM proceeding at http://hallikainen.com/lpfm

___________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com/getjuno.html
or call Juno at (800) 654-JUNO [654-5866]

1999\02\24@155457 by Russell McMahon

picon face
Herewith a little better definition of the problem:

For technical reasons the "bus" is accessed by a single data line -
same line for transmit and receive.
I have no control over the bus method used for reasons which are
technically good.

Signal level is essentially 5v cmos.

The bus may physically be driven with whatever signals one wishes but
for technical reasons data at the actual clock rate (eg 19K2) will be
more likely to be received correctly. eg a pulse 2.5 bits long may
appear more like 2 or 3 bits to the recipients. Signal transitions at
whole bit boundaries are much preferred.

While sending it is unlikely that collision / contention with other
stations can be sensed during low level bits - ie if I send a "0" I
will see a "0" on the common tx/rx line. However, while sending a 1 I
MAY be able to determine that a contending 0 has been sent - this is
possibly not so and would ideally not be relied on.
ie CSMA/CD in its purest form is not really viable. Carrier detect is
available but not collisions.

Therefore transmission success is liable to be determinable only by
acking or failure of a response within a predetermined time. (It's
essentially immaterial whether the message or the returning ack
failed - either way you must re-send).


Russell McMahon


From: Marc <marcspamspam_OUTAARGH.FRANKEN.DE>


>For the hardware structure I suggest the use 4 RS485 nets. Each of
them can
>have up to 127 devices connected. The master device has 4 separate
bus drivers to
>control each section electrically independant. That allows for a
total of 508 slaves,
>and more traffic than on a single bus.


Bus partitioning is not possible - all 400 must love on same bus

>The PC should be talked to by the master board with RS232 at a high
enough rate, for
>example 57600 RTS/CTS.


19200 data rate is constrained by other factors.

>Considering the PC is a WINDOWS machine, it is a good idea to handle
all the ACK/NAK
>and retransmission in the master board directly. You can then use
tight response
>times for ACK/NAK.


Agree.

1999\02\24@161220 by John Mitchell

flavicon
face
On Thu, 25 Feb 1999, Russell McMahon wrote:

> Herewith a little better definition of the problem:
>
> For technical reasons the "bus" is accessed by a single data line -
> same line for transmit and receive. I have no control over the bus
> method used for reasons which are technically good.
>
> Signal level is essentially 5v cmos.


!!  One, 5v wire?  Plus ground?  100M?  hmm.

how about I2C?  It requires 3 wires (clock, data, ground), but is
well-documented and supported directly by a number of chips.  The distance
requirement might be met with buffers.  You could "fake" the clock wire
with a 19.2K clock generated locally.

Check out the I2C FAQ, which mentions a 100M implementations, buffering,
extensions, and even network pseudocode:

       http://www.ping.be/electrozone/i2cfaq/i2cindex.htm


- j

1999\02\24@162636 by Russell McMahon

picon face
No - I didn't make it clear enough.
The ACCESS to the bus is via a 5 volt signal level bi-directional
interface.
The bus media is rather unusual (and not presently discussable
:-))(but will be) and is not directly accessible to me.
I suppose the closest comparison is an Ethernet environment but
complicating factors reduce the ability to detect collisions.

From: John Mitchell <@spam@johnmKILLspamspamMAGNET.COM>


>> Signal level is essentially 5v cmos.
>
>
>!!  One, 5v wire?  Plus ground?  100M?  hmm.

>how about I2C?  It requires 3 wires (clock, data, ground),

The 100m range is not a problem here due to the "true" nature of the
"media" and actual signalling used (which is hidden from my units by
the media access electronics).

So I2C is unavailable in this context. For practical purposes it can
be considered as a one wire plus ground bidirectional bus (its not
but .... ).

>well-documented and supported directly by a number of chips.  The
distance
>requirement might be met with buffers.  You could "fake" the clock
wire
>with a 19.2K clock generated locally.
>Check out the I2C FAQ, which mentions a 100M implementations,
buffering,
>extensions, and even network pseudocode:


I2C relies on the open collector nature of the bus allowing the
recipient to signal to the master. That's not available here.
I'll look at the site you mention though.



Russell McMahon

1999\02\24@162859 by ben

flavicon
face
> While sending it is unlikely that collision / contention with other
> stations can be sensed during low level bits - ie if I send a "0" I
> will see a "0" on the common tx/rx line. However, while sending a 1 I
> MAY be able to determine that a contending 0 has been sent - this is
> possibly not so and would ideally not be relied on.
> ie CSMA/CD in its purest form is not really viable. Carrier detect is
> available but not collisions.

If each chip can have a unique preamble, you could probably devise a
scheme which allows collisions to be detected in a fairly bulletproof
manner, even if they start talking at exactly the same moment.

> Bus partitioning is not possible - all 400 must love on same bus

Sounds like a Kesey-esque hippy fantasy gone crazy!

Cheers,

Ben

1999\02\24@173406 by ben

flavicon
face
> While sending it is unlikely that collision / contention with other
> stations can be sensed during low level bits - ie if I send a "0" I
> will see a "0" on the common tx/rx line. However, while sending a 1 I
> MAY be able to determine that a contending 0 has been sent - this is
> possibly not so and would ideally not be relied on.
> ie CSMA/CD in its purest form is not really viable. Carrier detect is
> available but not collisions.

Ooops... sorry - didn't read properly - you're saying that possible
failure
to detect a contending 0 even if you're sending a 1 is a property of the

media you're transmitting over, right? Not a timing issue or anything.

> So I2C is unavailable in this context. For practical purposes it can
> be considered as a one wire plus ground bidirectional bus (its not
> but .... ).

So "idle" is not going to be the same as "high" then? I'm assuming this
because otherwise, failure to detect a '0' when sending a '1' (ie. being

idle) would suggest difficulties receiving '0's at all.

Can you make any predictions as to the level of bus traffic? If it's
going
to be fairly busy, then some form of time-slicing would be necessary,
otherwise simple ACKs with slightly random retry timing would probably
suffice.

Cheers,

Ben

1999\02\24@173825 by Gerhard Fiedler

picon face
At 16:10 02/24/99 -0500, John Mitchell wrote:
>how about I2C?  It requires 3 wires (clock, data, ground), but is
>well-documented and supported directly by a number of chips.  The distance
>requirement might be met with buffers.  You could "fake" the clock wire
>with a 19.2K clock generated locally.

how would you fake the clock line locally? doesn't the i2c protocol rely
heavily on the (async) state of the clock line, eg. for start and stop
conditions, clock sync, bus arbitration?

ge

1999\02\25@113153 by Marc

flavicon
face
> For technical reasons the "bus" is accessed by a single data line -
> same line for transmit and receive.
> I have no control over the bus method used for reasons which are
> technically good.
>
> Signal level is essentially 5v cmos.

I think it is very difficult to have 400 RX/TX units on a 100 meter
cable at a datarate of 19200 and just 5 Volts referenced to Ground.

I don't want to discourage you, maybe you can make it work. But I'd
seriously think about it a second time before ordering 400 slave PCBs.

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