| |
I am coming into the middle of this (or at the end considering the posting
dates), and am hoping I don't sound like a fool putting out these ideas (since
I don't yet know how legOS works). Is the RCX# used as a sort of ethernet MAC
address? If you included it, 6 decimal digits would be 21 bits, not 5. How
does an RCX get an assigned address? Are you using a kind of DHCP where an RCX
sends out a special packet asking for a unique address (5 bits, 0-31)? And
someone (an RCX or tower) gives it to them? Could a token passing mechanism be
used to prevent the IR flooding? It would slow down transmission and would
require a lost-token/token-election process. I like the idea of having
broadcast capability. Can you have multiple sockets/file handles open at the
same time to the same IR Tower (or RCX)? My thought was: It might be nice to
have a process (application/device driver) on the PC that would read the
protocol from the IR port and converted to TCP/IP sockets. A standard
debugging library and PC based IDE application could be used independent of the
sockets used to gather information and control the RCX from the PC. It would
allow you to write your host software in any language that had socket support.
Lou Sortman wrote:
"Jacob S. Barrett" wrote:
>
> I personally can't see needing more than about 7 tasks listening at one
> time anyway. Keep in mind that the resources on the lego are very very
> small. As far as reserving an address for IPC that would be fine. We
> could reserve 00000b for IPC and 11111b for broadcast then. It could be
> quite possible to go to 4 bits a piece but this may limit the number of
> legos too much. Although, like I said earlier, too many legos will just
> result in flooding...
>
> What does everyone think about this?
For IPC, each (unshared) connection would take 2 ports (src/dest), so 4
bits at least lets us have 7 IPCs (assuming port 0 is reserved as it is
in Berkeley sockets, 8 if it is not). I could certainly see having need
of more than 3 IPC connections. The need for IPCs may be reduced by
Markus' (I think I heard it from him) idea of making everything (even
sensors) look like any other device, using open, read, ioctl, etc.
As for limiting the number of legos, you could use a bit of the version
nybble to indicate 5/3 addressing, or you could use one of the "extra"
payload length bits for it. If one wants to have more than 14 RCXs in
one area, they could compile to use the 5/3 format. That would, of
course, render them unable to communicate with differently compiled
legos, though.
The only case that I can see for having over $2000 worth of RCXs in one
area would be some sort of group event or a very large scale project.
In either case, compiling for the other version would not be an
unmanageable restriction. And, yes, you would have problems with high
collision rates unless you forced a master/slave model.
Frederick N. Brier
Sr. Software Engineer
Multideck Corporation
|
|
Message has 1 Reply:
 | | Re: LNP Repost
|
| (...) As am I - it looks interesting, but looks like it may have died. Hopefully not! (...) election process. I had wondered about this. My big suggestion is for us to come up with a software API for both the RCX end and PC (or whatever) end. This (...) (25 years ago, 28-Jul-99, to lugnet.robotics.rcx.legos)
|
2 Messages in This Thread:
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
