Subject:
|
RE: LNP Repost
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Sat, 17 Apr 1999 18:28:17 GMT
|
Reply-To:
|
<jbarrett@acm.wwu.edu=StopSpammers=>
|
Viewed:
|
1190 times
|
| |
|
|
Those are some really good points, but I am still concerned about the
complexity and overhead of implementing IPC on the lego. Since resources
are so limited it might just be easier to use shared memory and semaphores
to communicate. On the other hand we could have a network protocol stack
and an IPC stack. Since they really don't have any real need to be
together. That would leave the LNP stack with all its ports free for
network communication, then those who need IPC could compile in IPC.
I like the idea you mentioned about Markus possibly trying to get everything
to act as a stream, as in unix. That makes it really easy to program to.
As far as the $2000 worth of legos; my university, Western Washington
University, is actually teaching a class this quarter on robotics and
artificial intelligence. We are using the Lego Mindostorms to do this.
There are probably about 20 legos involved in this class. The protocol
would work great in here. That is why I would like to start crunching
something out soon.
Lets keep it going... Comment time...
-Jake
-----Original Message-----
From: news-gateway@lugnet.com [mailto:news-gateway@lugnet.com]On Behalf
Of Lou Sortman
Sent: Saturday, April 17, 1999 10:23 AM
To: lugnet.robotics.rcx.legos@lugnet.com
Subject: Re: LNP Repost
"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.
|
|
Message has 1 Reply:
 | | Re: LNP Repost
|
| (...) Indeed. I just figured that since the infrastructure would already be there for networking, it would be elegant to use the same for IPC. As you said, they don't actually need to be integrated. Then, there is your point about compiling in LNP (...) (25 years ago, 17-Apr-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: LNP Repost
|
| (...) 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 (...) (25 years ago, 17-Apr-99, to lugnet.robotics.rcx.legos)
|
21 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
|
|
|
|
