 | | Re: Brainstorms
|
|
All: I think the project that I am working, called RoboBricks, on is quite relevant to this topic. Since this is my first post to this group, I should introduce myself as a very active member of the Home Brew Robitics Club based out of San Jose, (...) (22 years ago, 10-Aug-02, to lugnet.robotics)
|
| |
| | RE: Brainstorms
|
|
Wayne wrote (in his first post no less!) (...) <snip> (...) <snip> This is more like it. I've snipped out the juicy bits on the serial comms channel and modular power connector. The comms channel sounds a bit slow, but then again the fire alarm (...) (22 years ago, 10-Aug-02, to lugnet.robotics)
|
| |
| | RE: Brainstorms
|
|
Wayne, In the spec you indicate that each brick gets its own 128 bit random number. This is like a serial number that is initially use to uniquely identify each brick with a shorter BrickID. This is a common technique in fire alarm systems where (...) (22 years ago, 10-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
(...) the interconnect protocol is run so slowly. Why only 2400 baud? Anything where you have an actual copper wire connection could run orders of magnitude faster. Heck even iRDA goes faster over infraRed. ---...--- Steve Baker ---...--- Mail : (...) (22 years ago, 10-Aug-02, to lugnet.robotics)
|
| |
| | RE: Brainstorms
|
|
(...) <just an opinion> The 2400 baud rate was probably chosen as a compromise between speed and what could reasonably be done on the teeny leetle PIC processor that drive the bricks. In practice, with the dedicated protocol that Wayne describes, (...) (22 years ago, 10-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
Steve: Everything is a compromise. Here is a discussion of the issues that caused us to pick 2400 baud for RoboBricks: 1) Most of the various PIC's that we use (PIC12C509A, PIC12C672, PIC16C505) run at 4MHz. The 4MHz clock rate is divided by 4 to (...) (22 years ago, 11-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
(...) <snipped some reasonable arguments> This is why I recommend that 'brainstorms' goes with something like I2C. That protocol is fast and built into the chip. No software serial I/O is ever needed and every chip already speaks the protocol so (...) (22 years ago, 11-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
(...) The RoboBricks project was started 2-1/2 years ago. At that time, there were no readily available and 8-pin microcontrollers with built in I2C support. The Atmel tinyAVR series had some I2C support, but the chips were extremely difficult to (...) (22 years ago, 11-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
(...) Are you sure? I thought Philips had teeny-tiny microprocessors with I2C at least 10 years ago...before the I2C bus switched speeds from 100kbps to 400kbps. I2C is about 20 years old. (...) Address pins? What address pins? ---...--- Steve Baker (...) (22 years ago, 11-Aug-02, to lugnet.robotics)
|
| |
| | RE: Brainstorms
|
|
This may be totally off-base--I'm not as techy as you guys--but the software biz has the idea of a universally unique ID (UUID, a.k.a. GUID for globally unique ID). It's a way of generating a unique number without any centralized management. Windows (...) (22 years ago, 12-Aug-02, to lugnet.robotics)
|
| |
| | 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)
|
| |
| | Re: Brainstorms
|
|
(...) They may have had them, but they didn't show up in any of the catalogs I was looking at. Semiconductor companies are quite notorious for deciding to stop production on various chips. Lot's of people tried to standardize on the Motorola HC11 (...) (22 years ago, 12-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms GUID
|
|
(...) > somewhere must administer who gets what ID numbers. (...) 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 (...) (22 years ago, 12-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms GUID
|
|
All: I'm not sure I really understand what point is trying to be made. I thought that a globably unique id was a good idea and put them into RoboBricks. My choice was to use a 128-bit random number. There are other solutions. All of the other (...) (22 years ago, 12-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
(...) I did a project with the Philips chips several years ago. I2C worked very well, the smallest chip I used was a 87C751. A little bit bigger than an 8-pin chip, but available in surface mount packages. Also, a friend of mine used a 751 as an I2C (...) (22 years ago, 12-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
hi Fred, I would love to see a reaction from you on the discussion in this thread in lugnet.robotics. Not only because you're the inventor of the RCX but also you've done some some similar things, creating modular, stackable electronics with the aim (...) (22 years ago, 12-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms GUID
|
|
(...) Maybe I completely missed the point myself? I like your idea of intelligence so small it can fit into a brick, and then tie into upper levels of higher intelligence. That sounds like true distributed processing (a good thing) to me. Here's the (...) (22 years ago, 12-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms GUID
|
|
(...) Presuming they can use different seeds, 32 bits is one chance of collision every 4,294,967,296 attempts. If they don't have random seeds then it doesn't matter a damn how many bits you have. The chances of collision on each reboot go up (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms GUID
|
|
(...) That's what we thought as well. (...) If you use a pseudo random number generator with the same seed you will get the same `random' number. The obvious answer is don't do that. I personally use the /dev/random device on Linux which collects (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
(...) [snip Philips uC] (...) The I2C bus is not really designed to support a bus scan. I'm not saying it can't be done, but I certainly haven't figured out how to do it. Until I see somebody who gives an extremely detailed description of how they (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
Matt Lawrence wrote: > I think the addressing problem can be solved with random numbers and some > serious bus scanning. Failing that, burning a serial number into each > chip isn't that hard either. It would still require quite a bit of bus > (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
(...) Since I had to support hot-pluggable devices on the bus (not my idea), I had to continually scan the bus. Unfortunately, that was several years ago and I don't remember all of the details. It took either a zero-length read or a zero-length (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
Hi, (...) Weird idea ... (...) It's way simpler: You just send the address and wait for the acknowledged via the data line. Then you just don't continue ... you don't even need read access to the clock line for this. IMHO something that can carry (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
| |
| | 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)
|
| |
| | 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)
|
| |
| | Re: Brainstorms
|
|
(...) I thought Philips kept a master registry of all the hardwired I2C addresses allocated to each chip vendor? That should mean that just reading the hardwired address is enough to tell you what *kind* of device you've found. ---...--- Steve Baker (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms
|
|
(...) There are only 1024 maximum addresses. There are more than 1024 I2C chips out there. Ergo, there are address conflicts between some of the chips out there. Unfortunately, there is no requirement that 2 chips at the same address implement the (...) (22 years ago, 13-Aug-02, to lugnet.robotics)
|
| |
| | Re: Brainstorms -- A Simple Unique Addressing Scheme
|
|
There's been a lot of messages on how to determine unique addressing for intelligent peripherals. Model railroading has solved this problem in a fairly easy way. THe NMRA (National Model Railroading Association) defined the DCC (Digital Command (...) (22 years ago, 14-Aug-02, to lugnet.robotics)
|
| |
| | 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)
|
| |
| | Re: Brainstorms -- A Simple Unique Addressing Scheme
|
|
(...) [snip DCC references] (...) That might be workable. I2C does not really have a broadcast message (General Call is close, but not quite). However, just scanning the I2C bus for 1024 addresses to find what the current address of the module is (...) (22 years ago, 14-Aug-02, to lugnet.robotics)
|
