Searching \ for 'Here's a difficult one (re networking)' 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=heres+difficult
Search entire site for: 'Here's a difficult one (re networking)'.

Truncated match.
PICList Thread
'Here's a difficult one (re networking)'
1997\10\16@000953 by Jonathan Baker

flavicon
picon face
Im working on a network using PICS.

All nodes on the network are identical, all joining onto a single bus -
ie each pic doesnt receive and the re-transmit the data.

(each pic is also programmed identicaly - including ID bits)

Can anyone think of a way to get each PIC to allocate itself a unique
number -  node ID. ... but if there are 50 PIC modules then I want the
numbers 1 to 50 or 0 to 49 for the numbers no more no less.

I think I have a way of doing this but Im not saying anything right now.

Comms between modules are 1) TX/RX line 2) CLOCK 3) CTS

sort of a cut down serial com protocol

Ideas anyone? ...

--
Jonathan Baker

1997\10\16@012345 by Sean Breheny

face picon face
At 04:23 AM 10/16/97 +0100, you wrote:
{Quote hidden}

Here is an untested and not completely thought out idea:

Lets say you use 16F84s and you have a random number generating routine
that generates numbers between 0 and 49 and you set aside 7 bytes(56 bits)
of EEPROM to use in the negotiating sequence. Each bit in this 7 bytes
would represent a number from 0-49 (bit 0, bit 1...bit 49), the upper 6
bits would be ignored.

Each pic would be programmed like this:

1.) Clear the 7 bytes of EEPROM and initialize random generator.

2.) Pick a random number N (from 0 to 49). Check to see if the
corresponding bit in the 7 byte file is set. If it is set, pick another N,
if not procede.

3.) Wait a random number of milliseconds (from say 10-200).  While waiting,
if you hear another PIC send a number, set its bit in the 7 byte file. If
this is the same as your number N, not only set the bit, but also goto step 2

4.) transmit your number N

5.) If all the bits in the 7 byte file are set except one, select the
number corresponding to that bit as your assigned station ID and end
negotiating procedure.


You might be able to change this routine so that it is more efficient if
you use the CTS signal that you are providing, but it is late at night and
I've got early classes tomorrow, so I can't think about that part of it
now.:) I do think that as it stands, all of the PICs would have an assigned
number in less than a few seconds. You could make this even shorter if you
reduced the delay to increments of 100 microseconds instead of
milliseconds. I was not sure what baud rate you were using. You will also
have to provide an error detecting scheme so that a number that is sent is
not misinterpreted. You might also(possibly instead of the error
detetection) make it so that if all of the bits in any of the PICs' 7 byte
files get set, that PIC will wait a random length of time and then send an
error code which tells all the PICs to start over again (go to step 1).

I guess that this is a "brute force" method, but since it is so simple, it
should not take up too much of the resources of even a simple PIC, and this
is the advantage that I see.

Sean

Sean Breheny,KA3YXM
Electrical Engineering Student

1997\10\16@045352 by wwl

picon face
>Here is an untested and not completely thought out idea:
>
>Lets say you use 16F84s and you have a random number generating routine
>that generates numbers between 0 and 49 and you set aside 7 bytes(56 bits)
>of EEPROM to use in the negotiating sequence. Each bit in this 7 bytes
>would represent a number from 0-49 (bit 0, bit 1...bit 49), the upper 6
>bits would be ignored.
>
>Each pic would be programmed like this:
>
>1.) Clear the 7 bytes of EEPROM and initialize random generator.
>
>2.) Pick a random number N (from 0 to 49). Check to see if the
>corresponding bit in the 7 byte file is set. If it is set, pick another N,
>if not procede.
>
How do you generate a random number? - if all PICs are identical, any
of the normal algorithms will generate the same number!
The only way I can think of to do it would be to time the (long
prescaled) WDT to a few uS (not too hard), and hope the difference
between the RC WDT osc characteristics due to temp/voltage are
sufficiently different.

1997\10\16@063058 by Andrew Warren

face
flavicon
face
Jonathan Baker <spam_OUTPICLISTTakeThisOuTspamMITVMA.MIT.EDU> wrote:

> Im working on a network using PICS.
>
> All nodes on the network are identical, all joining onto a single
> bus - ie each pic doesnt receive and the re-transmit the data.
>
> (each pic is also programmed identicaly - including ID bits)
>
> Can anyone think of a way to get each PIC to allocate itself a
> unique number

Jonathan:

Someone -- I forget who -- already suggested a method that involved
random-number generation, and I'm sure that others will post similar
methods that are a little simpler.

If you use one of those methods, remember that absent any difference
between the PICs, each PIC will generate the same random numbers,
thereby preventing the ID-allocation method from working.

So... You need some differences between the PICs.  The easiest way is
to put a low-accuracy RC on each PIC's MCLR line or -- if the PICs
don't need to have accurate timing for anything else they're doing --
to clock the PICs with RC oscillators rather than crystals or ceramic
resonators.

-Andy

=== Andrew Warren - .....fastfwdKILLspamspam@spam@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499

1997\10\16@100805 by Andy Kunz

flavicon
face
>If you use one of those methods, remember that absent any difference
>between the PICs, each PIC will generate the same random numbers,
>thereby preventing the ID-allocation method from working.

Since good pseudo-random number generators produce widely varying outputs
depending upon small differences in seed values (much like CRC's do -
hint-hint), even a small difference in the oscillator speed will generate
sufficient randomness.

Even small differences between ceramic resonators and/or crystals should
help somewhat.

>So... You need some differences between the PICs.  The easiest way is
>to put a low-accuracy RC on each PIC's MCLR line or -- if the PICs
>don't need to have accurate timing for anything else they're doing --
>to clock the PICs with RC oscillators rather than crystals or ceramic
>resonators.

Another place to put the RC value would be the RA4/TMR0 input pin.

Absolute homogeneity is a pain.

The other Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\10\16@103918 by myke predko

flavicon
face
>>If you use one of those methods, remember that absent any difference
>>between the PICs, each PIC will generate the same random numbers,
>>thereby preventing the ID-allocation method from working.
>
>Since good pseudo-random number generators produce widely varying outputs
>depending upon small differences in seed values (much like CRC's do -
>hint-hint), even a small difference in the oscillator speed will generate
>sufficient randomness.
>
>Even small differences between ceramic resonators and/or crystals should
>help somewhat.
>
>>So... You need some differences between the PICs.  The easiest way is
>>to put a low-accuracy RC on each PIC's MCLR line or -- if the PICs
>>don't need to have accurate timing for anything else they're doing --
>>to clock the PICs with RC oscillators rather than crystals or ceramic
>>resonators.
>
>Another place to put the RC value would be the RA4/TMR0 input pin.

Has anybody characterized the accuracy of the WDT?  Maybe a simple counter
could be put there.

Probably the simplest (and most reliable) method of doing this is if there
is a pin available on the '84s, use it to enable the _MCLR of another PIC
and keep them going down the chain (each PIC will wait for the previous PIC
to send it it's address).

Interesting question...

myke

Check out "Programming and Customizing the PIC Microcontroller" at:

http://www.myke.com

1997\10\16@105210 by electronics

flavicon
face
Jonathan Baker wrote:
{Quote hidden}

I make
- project with I2c interface : one master module and up 16 slave ones
- project with current loop serial module connection, up 256 modules in
loop.
Vladimir Dobrovinski

1997\10\16@115527 by Pierce Nichols

flavicon
face
On Thu, 16 Oct 1997, Mike Harrison wrote:

> How do you generate a random number? - if all PICs are identical, any
> of the normal algorithms will generate the same number!
>  The only way I can think of to do it would be to time the (long
> prescaled) WDT to a few uS (not too hard), and hope the difference
> between the RC WDT osc characteristics due to temp/voltage are
> sufficiently different.

       You can get OTP parts from Microchip that have individual serial
numbers burned into them. You could initialize the PRNGs off of a
combination of those and some sort of system timer, perhaps?

       Pierce Nichols

"I have a work order for the immediate demolition of your reality tunnel."

       -Bob, RAW Construction Corp.

===========================================================================
Geek Code v2.1: d?H+sg+a-w++v+c++UHS+P+L+E+N+K!WM--!V-po+Y+t+5+j+R+G!tvb+++
D+B---e+u*hf+r+*n-y+

1997\10\16@145929 by Steve Baldwin

flavicon
face
> All nodes on the network are identical, all joining onto a single bus -
> ie each pic doesnt receive and the re-transmit the data.
>
> (each pic is also programmed identicaly - including ID bits)

For the sake of a longer development time for a method that might work,
wouldn't it be easier to buy, borrow, rent a programmer with serialising in
it ? Some of the low end ones do it.

Steve.

======================================================
 Very funny Scotty.  Now beam down my clothes.
======================================================
Steve Baldwin                Electronic Product Design
TLA Microsystems Ltd         Microcontroller Specialists
PO Box 15-680                email: stevebspamKILLspamkcbbs.gen.nz
New Lynn, Auckland           ph  +64 9 820-2221
New Zealand                  fax +64 9 820-1929
======================================================

1997\10\16@173907 by Bob Buege

picon face
In a message dated 97-10-16 12:07:38 EDT, you write:

> Im working on a network using PICS.
>
>  All nodes on the network are identical, all joining onto a single bus -
>  ie each pic doesnt receive and the re-transmit the data.
>
>  (each pic is also programmed identicaly - including ID bits)
>
>  Can anyone think of a way to get each PIC to allocate itself a unique
>  number -  node ID. ... but if there are 50 PIC modules then I want the
>  numbers 1 to 50 or 0 to 49 for the numbers no more no less.

Several responses to this thread have mentioned use of random numbers with
repeated attempts whenever a collision occurs with a previously allocated ID.
This will cause very long delays for the last allocations. Unless I am
missing something in the specs, the introduction of random numbers seems to
be a needless complication. I make the assumption that the nodes are being
allocated and deallocated at random times instead of all turning on at once.
Is this assumption true?

If this assumption is true, each node can request ID allocation when it signs
on. Node 0 can assume the responsibility of sending the next available ID
number. If the request for an ID number times out, the node is the 1st one
and should be allocated as node 0.

The 7 byte bitmap suggested by Sean Breheny is a good way to keep track of
allocated IDs. If nodes can disconnect without notifying node 0 it may be
neccessary for node 0 to sequentially poll the nodes occasionally (one node
per second would verify the next every minute) to verify that each node is
still active.

Things could get complicated if node 0 disconnects without changing the ID of
the next node to 0 and passing on its responsibilities but this may be a rare
enough occurance to ignore.

>  I think I have a way of doing this but Im not saying anything right now.
>
>  Comms between modules are 1) TX/RX line 2) CLOCK 3) CTS
>
>  sort of a cut down serial com protocol
>

Is the TX/RX line one line that is shared for both sending and receiving or
are there separate lines?

>  Ideas anyone? ...
>
>  --
>  Jonathan Baker
>

Bob

1997\10\17@025315 by ruben

flavicon
face
{Quote hidden}

You can use the Dallas DS2224 memory chip which has a 32 bit unique
serialnumber in ROM (and 224 bit SRAM) instead of a random number.
It interfaces with one I/O pin.

-----------------------------------
Ruben Jonsson
AB Liros Elektronik, Sweden
.....rubenKILLspamspam.....sbbs.se
-----------------------------------

1997\10\17@053635 by Mal Goris

flavicon
face
Jonathan Baker writes:
> Im working on a network using PICS.
>
> All nodes on the network are identical, all joining onto a single bus -
> ie each pic doesnt receive and the re-transmit the data.
>
> (each pic is also programmed identicaly - including ID bits)
>
> Can anyone think of a way to get each PIC to allocate itself a unique
> number -  node ID. ... but if there are 50 PIC modules then I want the
> numbers 1 to 50 or 0 to 49 for the numbers no more no less.
>
> I think I have a way of doing this but Im not saying anything right now.

The problem as you have written it does not make sense to me. Unless,
that is, you are talking about a network of nodes that do only
processing and no I/O. In this case you can have a master allocate a
number to the first slave that answers a broadcast.

But, surely you have some additional hardware that makes each node
different from the others. And the node must know what is special
about itself for it to work. Imagine a network with two nodes, one
connected to a hot water tap and the other to a cold water tap. Each
node has to know whether it is hot or cold for it to do its job. Given
this, if you think about your hardware you should be able to come up
with a node ID based on the hardware it is attached to.

Mal
--
http://www.nfra.nl/~mgoris/

1997\10\17@055338 by Luc Martin

flavicon
face
>Jonathan Baker writes:
>> Im working on a network using PICS.
>>
>> All nodes on the network are identical, all joining onto a single bus -
>> ie each pic doesnt receive and the re-transmit the data.
>>
>> (each pic is also programmed identicaly - including ID bits)
>>
>> Can anyone think of a way to get each PIC to allocate itself a unique
>> number -  node ID. ... but if there are 50 PIC modules then I want the
>> numbers 1 to 50 or 0 to 49 for the numbers no more no less.
>>
>> I think I have a way of doing this but Im not saying anything right now.

 I'm doing something simillar, with a I2C like bus.
You may give each PIC an 16 bits number, to avoid the same number for 2 PICs.
A master on your bus then gives every PIC, that responds to a 16 bits
address, an ID number from 0 to the number of PICs connected. PICs
further responds to commands with their ID number.

 Problem : You have to do that on every power up, with I2C it lasts
quite a minute...

 I tried only with 5 PICs, but more soon...

          |\_____/|
   ___    |[o] [o]|        ___     ___                 ___
  (o,o)   |   V   |       (o o)   (o o)               (o,o)
 <  .  >   |       |     (  V  ) (  V  )             <  .  >
----"-"----ooo---ooo--------m-m- /--m-m-----------------"-"-------

                         Luc Martin
                 EraseMElucspam_OUTspamTakeThisOuTgreco2.polytechnique.fr
       www.geocities.com/SiliconValley/Bay/2752

1997\10\17@064234 by William Chops Westfield

face picon face
   > All nodes on the network are identical, all joining onto a single bus -
   > ie each pic doesnt receive and the re-transmit the data.
   >
   > (each pic is also programmed identicaly - including ID bits)
   >
   > Can anyone think of a way to get each PIC to allocate itself a unique
   > number -  node ID. ... but if there are 50 PIC modules then I want the
   > numbers 1 to 50 or 0 to 49 for the numbers no more no less.

The easy way out is to make ONE system on your bus different, and it becomes
the "master" that assigns addresses to everyone else.  Otherwise, you use
a random algorithm of some kind to pick a master, then proceed as if it
were different.

BillW

1997\10\17@175018 by Jonathan Baker

flavicon
picon face
In article <3.0.2.32.19971016012145.008b4a70spamspam_OUTpostoffice2.mail.cornell.ed> u>, Sean Breheny <@spam@shb7KILLspamspamCORNELL.EDU> writes

>Each pic would be programmed like this:
>
>1.) Clear the 7 bytes of EEPROM and initialize random generator.
>
>2.) Pick a random number N (from 0 to 49). Check to see if the
>corresponding bit in the 7 byte file is set. If it is set, pick another N,
>if not procede.

Ah.  But what if I dont know the number of active PICs in the network?


>Sean Breheny,KA3YXM
>Electrical Engineering Student

--
Jonathan Baker

1997\10\17@213725 by Jonathan Baker

flavicon
picon face
In article <l03110700b06cf21a2b5a@[129.104.17.45]>, Luc Martin
<KILLspamlucKILLspamspamGRECO2.POLYTECHNIQUE.FR> writes
>
>  I tried only with 5 PICs, but more soon...

The network will be quite large maybe 50 or so (thats large enough for
now anyway)
I think I'll opt the the Node 0 network manager.
{Quote hidden}

--
Jonathan Baker

1997\10\17@214549 by Jonathan Baker

flavicon
picon face
In article <spamBeGone971016173601_1134222344spamBeGonespamemout04.mail.aol.com>, Bob Buege
<TakeThisOuTBobBuegeEraseMEspamspam_OUTAOL.COM> writes

OK, OK. I'll tell you more.

Im working on a hardware neural network.

{Quote hidden}

Each node may be active or not at any time.  There is no guarantee that
a particular node will be on.

>
>If this assumption is true, each node can request ID allocation when it signs
>on. Node 0 can assume the responsibility of sending the next available ID
>number. If the request for an ID number times out, the node is the 1st one
>and should be allocated as node 0.

Perhaps that is a good idea. One PIC dedicated to managing the network
addresses wont be too much of an overhead!
{Quote hidden}

Node 0 will always be on then, and could act as a bridge between more
than one network.

{Quote hidden}

TX/RX is one line.


--
Jonathan Baker

1997\10\18@061259 by Alec Myers

flavicon
face
This might be a good time to mention the text by Tannenbaum:
"Computer Networks" 2nd ed. 1989 ISBN 0-13-166836-6. (Mine's an el-cheapo
soft-back student edition - I don't know if the ISBN is generic to the
text.)

It's quite old now (don't know if there's a third edition) but it does go
into detail about different LAN protocols right down to the Physical Layer.
There's some mathematical treatment of how Channel Utilisation varies (for
different protocols) against Loading as well as good comaparative studies
of bus vs. ring topologies. If you look at Ethernet protocols vs. TokenRing
and TokenBus, you get a feel for some of the problems, particularly the way
new stations announce themselves, and how they deal with bus conflicts and
dead stations. The author discusses in some lengths the pros and cons of
protocols with and without Master stations, and the problems with each sort.

He's also got a sense of humour - albeit rather dry - so it's not as heavy
going as the subject suggests.

Alec

__________________________________________________________________________
                                   ________
_______          ______          __/   ____/    W5 Ltd.
\      \        /      \        / /  /_
\      \      /        \      / /___  \        33 Sneath Avenue
 \      \    /          \    /      \  \       London NW11 9AJ
  \      \  /            \  /       /  /       United Kingdom
   \      \/      /\      \/   ____/  /
    \            /  \         /______/         Telephone +44 181 922 7778
     \          /    \          /              Fax       +44 976 650 110
      \        /      \        /               eMail     RemoveMEmailspamTakeThisOuTW5.co.uk
       \______/        \______/

           Technology * Innovation * Design * Solutions
__________________________________________________________________________

1997\10\18@083651 by Andy Kunz

flavicon
face
At 10:50 AM 10/18/97 +0100, you wrote:
>This might be a good time to mention the text by Tannenbaum:
>"Computer Networks" 2nd ed. 1989 ISBN 0-13-166836-6. (Mine's an el-cheapo
>soft-back student edition - I don't know if the ISBN is generic to the
>text.)
...
>He's also got a sense of humour - albeit rather dry - so it's not as heavy
>going as the subject suggests.

Tannenbaum's books have always been great material.  Never having read this
one in particular, I can't say much, but we used them in college and his
were the best.

I like his humor, btw.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

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