Subject:
|
Re: Brainstorms
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 13 Aug 2002 21:21:33 GMT
|
Original-From:
|
Andy Gombos <GOMBOS_2000@EARTHLINK.NETihatespam>
|
Viewed:
|
1178 times
|
| |
|
|
>
> 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.
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.
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.
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. 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?
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? 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? 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.
|
|
Message has 1 Reply:
 | | Re: Brainstorms
|
| (...) 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 (...) (22 years ago, 14-Aug-02, to lugnet.robotics)
|
Message is in Reply To:
| | Re: Brainstorms
|
| (...) [snip hot pluggable] (...) That is only a partial bus scan. It does not tell you what is at each address. A full bus scan allows people to plug arbitrary devices into the bus and allows the bus master to to reliably figure out what has been (...) (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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
