To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.roboticsOpen lugnet.robotics in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 Robotics / 18661
18660  |  18662
Subject: 
Re: Brainstorms GUID
Newsgroups: 
lugnet.robotics
Date: 
Mon, 12 Aug 2002 05:41:14 GMT
Original-From: 
Steve Baker <sjbaker1@(Spamless)airmail.net>
Reply-To: 
SJBAKER1@ihatespamAIRMAIL.NET
Viewed: 
650 times
  
Bruce Boyes wrote:
Quoting "Russell C. Brown [RR-1]" <rcbrown@austin.rr.com>:

Could you just generate a new UUID for each brick you manufacture and
hardwire it, put it in an EPROM, or something like that?


Well, one easy answer is to use a Dallas serial number chip. They are way less than a dollar in quantity. Actually each 1Wire device has a guaranteed unique ID. Some have EE memory for storing other data (you could add your own tagging information to each device node).

Of course this means you must support the 1Wire protocol...

Using your own EEPROM (such as the little Microchip 8-pin devices) means that someone •  > somewhere must administer who gets what ID numbers.

Maybe you could adapt the Java approach to unique class names, where they are based on the company's web URL (guaranteed unique) such as
{highleveldomain}.{company}.{product}.{device}.{mfgr chosen 32 bit number stored in hex form). This would need say 64 bytes of storage and would handle 2**32 IDs per device. For example, Systronix jcx motor controller serial # 0x0a1b2c3d would be tagged as:
com.systronix.jcx.MotorControl.0a1b2c3d
This takes 39 characters, using a byte per character, 64 chars (or make it 128) would allow for long company, product, and device names.

The trouble with all these fancy approaches is that they all require additional logic.

It might not seem like *much* additional logic - but if the goal is to fit most kinds of brainstorm components
into a single 2x4 brick, you really can't afford *any* additional logic.

From a cursory reading of the I2C spec, it seems that the ten bit address range is allocated such
that every unique *type* of chip has some part of the address defined uniquely by Philips (who own the
licensing rights to I2C).  The remainder of the address is set by dedicated pins on *some* kind of chip - but
not others.

Hence, the kinds that don't have dedicated address pins are hardwired at a single, fixed address and you can
therefore only have one such device on each I2C bus segment (although we could get around that with multiple
busses - it's inconvenient).  Other devices have some number of address pins - and depending on how many that
is, that then limits the number of such devices you can have on the bus.  If a particular chip type has only
three address pins then you can have at most eight of them on a single bus segment.

Thus, for example, one of the EEPROM's that Philips makes has just one address pin - so you can have
at most two of them on a single I2C bus segment.  The PCA9554 parallel port has three address pins,
so you can have eight of them. However, they make another part (the PCA9554-A) which is *identical*
except that it's internal (fixed) address is different from the PCA9554 - so you can have eight
of the basic device and eight more of the '-A' device.

This kind of thing would make this system hard for 'Joe Public' to use - but isn't really a serious
restriction for those who know what they are doing - especially with all the bus extenders, expanders
and hubs that Philips make that would allow you to have yet more devices strung out on different
I2C busses.

What this leads me to believe is that a basic I2C system could still be *tiny* - and still have an
essentially unlimited number of devices connected to it - but this wouldn't be a system that would
be suitable for the mass market because the rules for using it would be horribly complex.

I also learned that there is a yet higher speed mode than the 400kbps - some devices support 'Hs' mode
where data rates as high as 3.4Mbps are possible!  Since you can mix devices of different speeds on the
same I2C bus, that's OK.

Also, it appears that if your bus needs to be more than 10cm long, you have to use twisted pair cables
with power and ground going along the same bundle as the I2C bus.  That makes it more or less impossible
to use Lego wires for the interconnect.

----------------------------- Steve Baker -------------------------------
Mail : <sjbaker1@airmail.net>   WorkMail: <sjbaker@link.com>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net



Message is in Reply To:
  RE: Brainstorms GUID
 
Quoting "Russell C. Brown [RR-1]" <rcbrown@austin.rr.com>: (...) Well, one easy answer is to use a Dallas serial number chip. They are way less than a dollar in quantity. Actually each 1Wire device has a guaranteed unique ID. Some have EE memory for (...) (22 years ago, 12-Aug-02, to lugnet.robotics)

53 Messages in This Thread:
























Entire Thread on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR