Searching \ for 'Buses, IDs.... How to' 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=buses+ids+how
Search entire site for: 'Buses, IDs.... How to'.

Truncated match.
PICList Thread
'Buses, IDs.... How to'
1996\08\30@021246 by icio culibrk

flavicon
face
SendTo:   spam_OUTpiclistTakeThisOuTspammitvma.mit.edu

Hi PIC gurus,

Lately (a few months now), I'm working on a project/product involving many
PICes 84 or eventualy 61 (up to 64 for now, but expandable to 256 (or more?)
in the future) organized in groups of four (as modules) controlled by a
'master' 16C65. The code in all 'slave' PICes is identical. Each of this
4 PIC 'modules' is powered and clocked separately and can be randomly
switched (powered) on or off. The problem is that I developed the code in
both 84 & 65 as they were dirrectly connected (ie. PIC84 <--> PIC65) and
always repeating to myself "... it will be easy to modify the communication
for more devices... " what a stupid presumption! (very bad technique...)
Now, when I have more devices, I'm pulling my hair off...

This PICes are connected on a I2C like bus (i.e. 1 CLK + 4 DATA lines
driven by OC pins).

Now, the questions:

1) How many devices can be connected to this type of bus? or is this
  calculation correct?
  Is there anything else I'm missing?

  - Is (input leakage) is max +- 5uA per I/O pin, as 95/96 databook says
  - R (pull up) is one 3K3 per line
  - Vih (min V input high) is 3.5 V for CMOS

  N = Vih / (Is * R)  ==>  N=212

2) Is there any way/trick to assign a unique ID to each device on power
  up or run time, so that each device gets always the same ID (this is
  neccessary!)?

  I think the simplest solution is to program each device with
  different ID, but I'd like to use max 8bit ID (bacause of the overhead
  in communication), so I'm limited to 256 IDs.
  Because the system is expandable by modules containing 4 units, I'll
  run out of 'unique' modules after 64. This will limit the existance
  of only few such systems. That is why I need a run-time assignation.
  Another 'trouble making' situation is that modules my be turned on/off
  as neccessary. I have few ideas if all the modules could be active at
  least for the setup time.

3) Did anybody implement a Ehternet (CSMA/CD) like (coax - single wire)
  communication protocol? Suggestions?

4) Any idea/suggestion how to connect and distinguish all that PICes?



Thank you for your time,

regards,

mauricio


Mauricio&arne.si

http://www.arne.si

1996\08\30@041134 by Lee Jones

flavicon
face
> This PICes are connected on a I2C like bus (i.e. 1 CLK + 4 DATA lines
> driven by OC pins).

> Now, the questions:

> 1) How many devices can be connected to this type of bus? or is this
>    calculation correct?
>    Is there anything else I'm missing?
>
>    - Is (input leakage) is max +- 5uA per I/O pin, as 95/96 databook says
>    - R (pull up) is one 3K3 per line
>    - Vih (min V input high) is 3.5 V for CMOS
>
>    N = Vih / (Is * R)  ==>  N=212

Your calculation might be right on -- if you allow the bus to
settle for a significant fraction of a second between transitions.
Probably not acceptable.

I would expect you'd have to take into account the pulse nature
of the signal plus the inductance/capacitance of the transmission
line.  Receiver will see each new voltage level only a finite
period of time after the transmitter changes it's output.

Also remember that the characteristics of the interconnection
wiring will vary with distance.  Farther apart the stations will
"see" different electrical properties and different pulse shapes.


> 2) Is there any way/trick to assign a unique ID to each device on power
>    up or run time, so that each device gets always the same ID (this is
>    neccessary!)?

>   I think the simplest solution is to program each device with
>   different ID, but I'd like to use max 8bit ID (bacause of the overhead
>   in communication), so I'm limited to 256 IDs.

But this involves programming each one differently -- yuck.

The 1 octet identifier does limit you to 256 discrete stations.
If you need more than 256 IDs, you'll just have to use a wider
field and eat the communications overhead.

>    Because the system is expandable by modules containing 4 units, I'll
>    run out of 'unique' modules after 64.

Here's a suggestion.  I assume each module of 4 PICs will have a
singe communcations "goes in" port and a seperate "goes out" port.
Number each PIC on the module from 0 to 3.  This should be done so
that the address value depends on the socket each PIC occupies.
This way, the low 2 bits of the address octet select which PIC
on that module.

When a packet arrives on the module (outbound from the controller),
check the upper 6 bits of the address for all zeros.  If it's zero,
then that module is selected.  If there's at least one 1 bit, then
decrement the address octet's upper 6 bits (i.e. subtract 0x04) and
send the packet on to the next module.

For traffic header from the module tail to the central controller,
each module increments the address octet as it passes through.

Using this, each PIC in each module can be programmed identically
(at least for the communications subroutines).

                                               Lee Jones

-------------------------------------------------------------------
Jones Computer Communications             .....leeKILLspamspam@spam@frumble.claremont.edu
509 Black Hills Dr, Claremont, CA 91711         voice: 909-621-9008
-------------------------------------------------------------------

1996\08\30@111659 by Mr. Brooke Clarke

flavicon
face
Hi:

You might look into the methods that Dallas uses.
They have "branches" that are switched to account for
leackage currents on their one wire buss.

Have Fun,
Brooke


'Buses, IDs.... How to'
1996\09\04@023935 by icio culibrk
flavicon
face
SendTo:   piclistspamKILLspammitvma.mit.edu

Hi PIC gurus,

Lately (a few months now), I'm working on a project/product involving many
PICes 84 or eventualy 61 (up to 64 for now, but expandable to 256 (or more?)
in the future) organized in groups of four (as modules) controlled by a
'master' 16C65. The code in all 'slave' PICes is identical. Each of this
4 PIC 'modules' is powered and clocked separately and can be randomly
switched (powered) on or off. The problem is that I developed the code in
both 84 & 65 as they were dirrectly connected (ie. PIC84 <--> PIC65) and
always repeating to myself "... it will be easy to modify the communication
for more devices... " what a stupid presumption! (very bad technique...)
Now, when I have more devices, I'm pulling my hair off...

This PICes are connected on a I2C like bus (i.e. 1 CLK + 4 DATA lines
driven by OC pins).

Now, the questions:

1) How many devices can be connected to this type of bus? or is this
  calculation correct?
  Is there anything else I'm missing?

  - Is (input leakage) is max +- 5uA per I/O pin, as 95/96 databook says
  - R (pull up) is one 3K3 per line
  - Vih (min V input high) is 3.5 V for CMOS

  N = Vih / (Is * R)  ==>  N=212

2) Is there any way/trick to assign a unique ID to each device on power
  up or run time, so that each device gets always the same ID (this is
  neccessary!)?

  I think the simplest solution is to program each device with
  different ID, but I'd like to use max 8bit ID (bacause of the overhead
  in communication), so I'm limited to 256 IDs.
  Because the system is expandable by modules containing 4 units, I'll
  run out of 'unique' modules after 64. This will limit the existance
  of only few such systems. That is why I need a run-time assignation.
  Another 'trouble making' situation is that modules my be turned on/off
  as neccessary. I have few ideas if all the modules could be active at
  least for the setup time.

3) Did anybody implement a Ehternet (CSMA/CD) like (coax - single wire)
  communication protocol? Suggestions?

4) Any idea/suggestion how to connect and distinguish all that PICes?



Thank you for your time,

regards,

mauricio


Mauricio&arne.si

http://www.arne.si

1996\09\06@021619 by icio culibrk
flavicon
face
SendTo: .....piclistKILLspamspam.....mitvma.mit.edu


Hi again,

sorry for this long delay, but I was so busy...

First, thanx to Lee, Brooke, Richard and Antti who responded to my
questions, next, few comments and clarifications.

Lee wrote:
{Quote hidden}

This is a very good idea, but presuming that inactive modules in and out
ports act as 'pass through' connections, turning on or off one module
somewhere in the 'chain' will cause the incrment or decrement of all
remaining modules in the chain (from position N to end).


Brooke wrote:
>
> You might look into the methods that Dallas uses.
> They have "branches" that are switched to account for
> leackage currents on their one wire buss.
>
I'll take a look, thanx.



Richard wrote:
>
> I too am looking at going something similar down the road.  I would
> be interested in hearing the results of your work.
>

Sure, I'll keep you informed on any progress

> > This PICes are connected on a I2C like bus (i.e. 1 CLK + 4 DATA lines
> > driven by OC pins).
>
> Why four data lines?  My thinking has been to use one clock, and two
> data lines.
>

4 data lines are really NOT necessary, but I have few pins left and with 4
lines I can TX in just 2 cycles (not instruction cycles) and RX in 3.

{Quote hidden}

If you need to store additional data, the solution with the SEEPROM is
the best, IMO, but if you need only to 'get' the 8 bit ID, you can
use the combination of DIP SW, pull-ups to set the ID and connect this
8 bit(pin) path to the PIC through an OC bus buffer. In this way, you
can read the ID by enabling the buffer OC outputs with another PIC pin.
Sure, you must take care of possible interference with normal operation
of used pins but another OC buffer may solve the problem.



Antti wrote:

{Quote hidden}

this is interesting, very interesting, but the requirement of uniqe IDs
is not so nice because requires have to 'serialize' each PIC, and that's
what I hoped to avoid.



Again, thanks to all who responded and excuse me for this long message
(I wished to kill 4 flys with 1 hit....)

By the way, I have PC Keyboard Emulation, PC Keyboard Host Emulation and
a Half duplex serial engine code available, if anybody is interested.


Bye, mauricio

1996\09\06@141121 by maud

picon face
mauricio culibrk wrote:

> By the way, I have PC Keyboard Emulation, PC Keyboard Host Emulation and
> a Half duplex serial engine code available, if anybody is interested.
>
> Bye, mauricio

Hi Mauricio

Yes, I would be interested in your PC Keyboard Emulation and Host
Emulation code.  You may respond directly

TIA.

John

1996\09\06@154822 by Wireless Scientific

flavicon
face
At 8:08 PM 9/6/96, John Maud wrote:
>Yes, I would be interested in your PC Keyboard Emulation and Host
>Emulation code.  You may respond directly
>
>TIA.
>
>John



TIA? is that sum kinda furien language? You know you might be angering some
on the list.

craig
ps. I know it's "thanks in advance".

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