Subject:
|
Re: FW: Something else is needed, I think...
|
Newsgroups:
|
lugnet.robotics
|
Date:
|
Tue, 4 May 1999 20:30:47 GMT
|
Original-From:
|
Laurentino Martins <lau@mailSAYNOTOSPAM.telepac.pt>
|
Viewed:
|
1114 times
|
| |
|
|
At 19:43 04/05/99 Tuesday , you wrote:
> On Tue, 4 May 1999, Kekoa Proudfoot wrote:
>
> > > - 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.
>
> 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 precision located anywhere throughout the range (in
> IEEE 32-bit floats). If you need precision in a range that doesn't vary
> much, using fixed-point math is superior since you aren't wasting bits
> on the exponent. Ie, treat your 32-bit integer as having a decimal after
> 16 bits.
>
> > 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.
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 for a project I would need all the standard firmware, plus floating point support and a math module with functions like sin() cos(), etc... or even a communications module that would enable an RCX to communicate with other RCX?
Of course I would have less memory for my program(s), but on the other hand if I know that my program is not going to use certain modules I could choose simply to never download them and save memory.
A downloaded program would interact with the downloaded firmware as if it was only a block, and would never miss the non downloaded modules because it will never call functions from them.
And if the module file structure could be made available to the general public, new modules would appear with specialized tasks like (for instants) modules that can convert raw data from non standard sensors to more usable values, etc.
Better, the firmware could dynamically download modules from the PC as soon as they are needed by the programs!
I think this approach opens new possibilities and retaining the best of both worlds. This is what we need! =:-D
What do you think?
Laurentino Martins
[mailto:lau@mail.telepac.pt]
[http://www.terravista.pt/Enseada/2808/]
--
Did you check the web site first?: http://www.crynwr.com/lego-robotics
|
|
Message has 2 Replies:
 | | Re: FW: Something else is needed, I think...
|
| (...) Precisely. The JVM class loader already provides that functionality. Say for example, you want the various math functions, you have java.math loaded. If you want a fancy package that interprets the raw sensor data for you, load (...) (26 years ago, 4-May-99, to lugnet.robotics)
|
Message is in Reply To:
| | Re: FW: Something else is needed, I think...
|
| (...) 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, (...) (26 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
|
|
|
|
Active threads in Robotics
|
|
|
|
|
|
