Subject:
|
Re: FW: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 4 May 1999 17:54:14 GMT
|
Viewed:
|
1109 times
|
| |
|
|
Laurentino Martins <lmartins@marktest.pt> wrote:
> - To be able to run a function/task at a predetermined time, once or on
> a regular basis. This is very useful for using with rotation sensors.
Do you mean, when a timer reaches a certain value, run a specified task?
Can't you do this already, or is something broken with the current firmware
in this regard? (It seem that some combination of wait and start_task
should do the trick, no?)
> - Floating point is not optional. You may reduce the precision to a few
> bits, or do a few hacks instead of a full blown floating point support,
> but we definitely need some sort of floating point. If you want a bot
> that keeps track of it's position, you need it (you also need at least a
> sin() function/lookup table). Just one example.
My take on this is that you can use fixed point if you really need extra
decimal places. That is, work in fractions, not whole numbers.
Providing sin() is difficult because of the tradeoff between memory usage
and usability. My thoughts are that the cost of memory usage outweighs the
benefit of having the functions available for the few (?) that will use
them.
> - People don't ask this because they currently have in the firmware, but
> if you build something from scratch you must definitely create some
> library for the PC/Mac/whatever for interacting with the unit at real
> time. Nowadays we can read the contents of a var/sensor/etc from the PC
> and create a PC program that reacts to it. Don't take that from us!
I agree, you should be able to query all meaningful state of the RCX from
the PC, and you should be able to control all RCX inputs/outputs from the
PC also, hopefully with a library for making all of this simple. Along
with this will hopefully come tools and primitives for complete host-side
debugging of byte code running on the RCX, which I think would also be very
useful at some point.
> - I think most of us don't give much importance to preemptive
> multitasking, exceptions and all the "sophisticated" programming like
> that. Most our programs are so small that 90%+ of us will never need
> them.
Don't forget that the current firmware has multiple concurrent tasks which
are (effectively) preempted every instruction. This at least is very
useful, and I see it remaining useful.
Regarding what high-level language is supported, C is also a given in my
mind, but really it is up to the compiler writer(s) what high-level
languages are supported, under the assumption that they can be compiled to
byte code similar to that in the original firmware in the first place.
Regarding interfacing to peripherals (you gave the example of accessing a
rotation sensor), my thoughts are to leverage the routines in ROM,
providing a similar interface to what exists in the current byte code
already.
> - A IDE like the RcxCC and an on-line Help IS A MUST. :-)
If, when the time comes, somebody is willing to write this, I'm all for it.
As I see it, support for this sort of environment will be built into the
firmware.
My current thoughts are that, with exception of minor details (like better
debugging support), the primary addition made by a first crack at new
firmware (under the assumption that it is based in principle on the current
firmware) is going to be adding better support for variables. This will
also be the largest addition and the biggest change to the machine model
implemented by the current firmware. So if anybody has ideas on what
they'd like to see in this regard, I'd like to hear them. My current ideas
encompass support for the following:
- function-local variables, with provisions for recursion
- task-local variables
- global variables
- mechanisms for passing variables between caller and callee
- possibly but doubtfully: variable references
- no dynamic memory allocation
Variables of different types (function-local, task-local, global, maybe
also function-parameter) are accessed using new source + argument
combinations. One or more new opcodes are introduced to support the
allocation of the various types of variable spaces. The other opcodes
remain mostly the same.
There are certainly other ways to provide better variable support; if you
know of any, let me know.
-Kekoa
|
|
Message has 4 Replies:
 | | Re: FW: Something else is needed, I think...
|
| (...) Remember that a floating point number is still stored as "integers" in RAM and simply represents m*2^e where m is the mantissa and e is the exponent. FP is useful when you need to represent a wide range of values, since you can have 24 bits of (...) (25 years ago, 4-May-99, to lugnet.robotics)
| | | Re: FW: Something else is needed, I think...
|
| (...) What about instead of creating a full featured firmware that will never be good enough for *everything* we want to do, we create a dynamic firmware downloader that we could specify what we would want to download? I could say for instants that (...) (25 years ago, 4-May-99, to lugnet.robotics)
| | | Re: FW: Something else is needed, I think...
|
| (...) I believe that a new bytecode instruction set should provide native support for non-integer numbers of some type. Whether this is implemented as ieee single precision numbers or as 32-bit fixed-point numbers is an issue that may be up for some (...) (25 years ago, 4-May-99, to lugnet.robotics)
| | | Re: FW: Something else is needed, I think...
|
| (...) sin() can be simulated to enough accuracy using a small table of floating point constants, and some math. Fairly fast, and very small. (...) multiple concurrent tasks can also be simulated within your own program. (...) These are all not (...) (25 years ago, 5-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: FW: Something else is needed, I think...
|
| I've been reading all this discussion of an new OS for the RCX (or whatever it will be) with great interest. I know I'm out of this discussion/development from the start due not having much low level knowledge on what you are all talking about, but (...) (25 years ago, 4-May-99, to lugnet.robotics)
|
32 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
|
|
|
|
