Subject:
|
Re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Wed, 14 Aug 2002 04:50:59 GMT
|
Viewed:
|
1021 times
|
| |
|
|
In lugnet.robotics, "Andy Gombos" <gombos_2000@earthlink.net> writes:
> >
> > It is fairly easy to find out what addresses are occupied on an I2C
> > bus. Address conflicts may be detectable, but I sure do not know
> > how it is done. Figuring out whether the user plugged in a serial
> > EEPROM, an A/D, or another microcontroller is the far harder task
> > to solve. Again, I'm not saying it can't be solved, but until
> > someone really articulates how they plan on pulling it off, I will
> > remain skeptical of people who claim it is easy.
>
>
> I have read this dicsussion, and have been most interested. From what I can
> understand (I have no current desire to read the I2C spec) the random ID
> number will identify that device on the bus once it is detected (or the
> permenant number, however they are given). Please correct me if I
> misunderstood.
Andy:
I can understand not wanting to read the I2C spec., I haven't
done it in a while myself. However, you are going to have to
do a little homework on I2C. There is no real way around it,
the bus is sufficiently complex that one's intuition about how
it `should' work, will probably be incorrect. A good place to
start is the I2C FAQ. A old copy can be found at:
http://www.ping.be/~ping0751/i2cfaq/i2cindex.htm
The rest of my comments are going to be rather terse.
Please do not interpret them as being rude; that is not
the intent. I suspect that after you have read up a little
more on I2C, you will see why.
> Assuming every device has the capability to be given this unique ID for
> detection, define ranges that a device must be in. With a 128 bit number,
> you have many combinations. Much like an IP address, a range is given for
> each device, one for motor drivers, one for touch sensors, one for extra CPU
> modules, etc. When the bus is scanned and the ID numbers are returned, you
> *know* the device in a range must be a CPU, or it must be an EEPROM, or it
> must be a motor controller, by the design of the system.
Alas, the I2C bus only has 10-bits maximum. The 128-bits will not
do you any good for device identification.
> Standardization is also key. By limiting the number of clone devices (this
> assumes the clone is not perfectly compatible with the currently used
> devices, or could be masked to appear as such), you limit the number of
> problems.
>
> Say motor drivers get ID numbers 0-100. Now, driver A, which was agreed
> upon (in some fashion, as the "standard") has number 0. Any device which
> can be controlled with the exact same code, would be allowed to occupy the
> same ID number. If a device was not compatible, it would require a new
> number.
This is a good idea, but it doesn't help get them assigned to
unique addresses on the I2C bus.
> Using this number system, Steve Baker's idea of PC drivers could be used.
> When someone uses the chip with ID 0, a driver would be written that
> supports standard device functionaliy (the same across all drivers of that
> device type), but in the backend supports only that controller/it's clones.
> Another driver for the chip with ID 1 looks exactly the same to user code,
> only the driver downloaded and used (possibly like a C preprocessor, where
> the necessary commands are simply inserted for use) differs.
>
> Again, by standardizing on chips, connections, protocol, and ID ranges, a
> motor controller homemade and a motor controller bought from someone else
> who makes those controllers for sale will behave in exactly the same way,
> *by design*.
>
> This whole I2C vs. RS232 issue seems to be a debate of which system each
> likes/uses, not a discussion of the pros/cons without regard to
> implementation.
Actually, I've been trying to keep the discussion on the pros and
cons. Unfortunately, some people seem to think that the I2C bus
has more capabilities than it really has. What I said is:
My biggest problem with I2C is addressing. Each device needs
needs to have its address pins properly set. The 10 bit
(2^10=1024 total) address space means that many dissimilar
devices have address conflicts. The only way I can see to
work around these issues is to front end every device with
a dedicated microcontroller. I still do not see a way to
reliably assign a a unique address to each microcontroller
on the I2C bus. It seems quite likely that people will
accidentally get the same device programmed with the same
I2C address and I2C bus chaos will ensue.
I still stand by this statement. The I2C bus has many
wonderful attributes, high speed, multi-master, synchronization,
self clocking, interrupts, etc. It also has some problems in
terms of bus length, termination, and limited device addressing.
You can not get the benifits of the I2C bus without dealing with
its limitations as well. When I personally looked at the I2C bus,
I could not figure out reasonable work-arounds for the addressing
limitations. Maybe someone smarter than I can.
> Wayne, you seem to be promoting RS232 based on it's use in
> RoboBricks. While it may have been the best solution then, is it still?
There is no such thing as a "best" solution. Engineering is
always the art of compromise. Our goal when designing RoboBricks
was to design a system that would not be nearly as limiting as
the RCX has turned out to be. We knew we needed more I/O.
We also knew we wanted to simplify the programming.
When we looked at bandwith requirements, we were surprised at
how little we really needed. We concluded that our architecture
would handle just about everything except a vision system.
We figured the vision system would need its own high speed
bus anyhow.
> Would you use hardware UARTs for communication? What about things besides
> I2C, like DS 1 wire protocol previously mentioned? How are these systems
> "worse" than a RS232 based system?
With a clean sheet of paper, we would probably not use I2C
because of its addressing limitations. SPI deserves another
look because they did not screw up the addressing like I2C;
however, SPI has its own issues and limitations that need
further inspection. We'd have to look at the DS 1-wire,
USB, CAN, Ethernet, and Firewire. I can not say for sure what
we'd do. We might just stick with UART's and crank up the baud
rate by mandating hardware UART's.
> Is managing the connection in software
> better, from a usability standpoint? Or is hardware easier to implement
> since most of the work is done automatically?
In general, it is best to take advantage of Moore's law
whenever possible. My tendency is to use more hardware,
not less.
> Issues like these need to be
> discusses without bias from which ever system you favor. Taking a side and
> trying to convert the other side to your point of view instead of reaching
> some middle ground only hurts everyone.
I actually do not care what people use to build their robots,
since I view it as a hobby rather than a occupation. I think
that robots will use a variety of buses in the future that range
from custom protocols such as Cricket, serial protocols such as
RoboBricks, I2C such as BrainStem, SPI such as JCX, etc.
My primary issue is that numerous claims have been made about
I2C's capabilities that are simply not correct. I have a
difficult time letting incorrect information stand. Sorry 'bout
that.
-Wayne
|
|
Message is in Reply To:
 | | Re: Brainstorms
|
| (...) I have read this dicsussion, and have been most interested. From what I can understand (I have no current desire to read the I2C spec) the random ID number will identify that device on the bus once it is detected (or the permenant number, (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
53 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
