| |
I’ve been working with José David Parra on the next version of his
RCX.NET project, because 1.) the NXT system is
coming out, and 2.) RCX.NET is basically a .NET wrapper of Spirit.ocx, which
means it’s not so nice to program with.
Another project, Lego.NET, has as its goal to get part of the .NET Framework running on the RCX,
similar to the leJOS VM, except it doesn’t have its own custom firmware (it uses
the BrickOS firmware).
Our project’s goal is to simply let people write programs for Mindstorms bricks
using .NET languages. The Control Lab programs would have to run on the machine,
but the Scout, RCX, and NXT programs would be compiled to LASM and uploaded to
the brick. (Or not. I would like to give people the option to do either.)
Recently I acquired a DACTA Control Lab Interface, which some of you know is the
predecessor to the RCX. It is a simple I/O device, meaning all programs for it
run on the computer, but it uses the same 9V sensors and outputs the newer
Mindstorms system does. I have started
writing a C# control class for it, and now that I have the low-level
communication working, I need to design an API that José and I can also use for
the RCX and NXT systems. The goal is to provide a consistent programming
interface for people to use, regardless of what brick they’re using.
Consider this example C# code. It shows a small part of the API I have in mind
for the redesign of RCX.NET, so I’d like some comments on how people would like
to use this system.
using Mindstorms.ControlLab;
using Mindstorms.RCX2;
class Test
{
// boilerplate
// inside main() or Form1.Load(), etc.
{
ControlLab controlLab = new ControlLab(); // uses "COM1"
RCX2 rcx = new RCX2("COM2");
}
}
|
|
That’s simple object creation. The question now becomes “Should users have to
create ports and sensors explicitly, or just set the sensor type and what
channel it’s on?”
If programmers should be required to create Port objects themselves, then
creating a sensor would look something like this:
Sensor lightSensor = new LightSensor();
rcx.AddSensor(lightSensor, new InputPort("2"));
controlLab.AddSensor(new TouchSensor(new InputPort("1")));
|
|
On the other hand, creating those ports is tedious, especially for the Control
Lab which has 16 ports (8 input, 8 output). Why not simply do this?
rcx.AddSensor(new LightSensor("2")); // will be on port 2
controlLab.SetSensor("1", new TouchSensor()); // will be on port 1
|
|
In this example the RCX and ControlLab objects have created Ports themselves
inside their constructors. This does mean, though, that there could be Port
objects sitting around unused.
I’m simply wondering how much of the internal workings I should want to expose
to programmers. Would there ever be a need to keep references to Port objects?
The only case I can think of is the IR port on the RCX, which is both input
and output.
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
