Subject:
|
questions, comments, and suggestions
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Mon, 31 Jul 2000 18:09:17 GMT
|
Viewed:
|
1577 times
|
| |
|
|
Hello,
I'm just rooting through the kernel code, and have a few questions:
[note: after actually writing this, there not all questions, more
comments, or suggestions. And there aren't just a few of them.
Good luck getting through it! ;-) ]
*) What is RCX_COMPILER? Does anyone still use it? Is it useful to
still have those checks in the code -- they are a bit annoying, and
hinder readability, IMO.
What exactly does HANDLER_WRAPPER do? It seems to make calls to
batter_refresh do some assembly before calling a different function.
Does that save the registers?
*) Include files don't have the
#ifdef __cplusplus
extern "C" {
#endif
...
#ifdef __cplusplus
}
#endif
Which makes the user do that for cpp files. That seems a bit
backwards to me.
*) CONF_VIS, .. CONF_LCD?
What exactly is CONF_VIS supposed to enable.. It seems to enable
text being displayed on the screen. Is there anyway to
enable/disable the LCD screen from being used? Some sort of
CONF_LCD? This could be useful for people who dont need it, or only
want it on for short amounts of time. I would imagine this could
save a fair bit of power for those who dont have it enabled.
*) include/rom/lcd.h, include/sys/lcd.h, include/dlcd.h,
include/conio.h kernel/lcd.c
Why are there some many different files for using the lcd. At
the very least, it seems to me that rom/lcd.h and dlcd.h seem
to be fairly similar. What are the differences? It would be nice
to get one "big" page with all the lcd functionality, instead of
having 3 or 4 or more different pages in the API doc to have
to look at.
*) kernel/lcd.c there is a variable called lcd_refresh_period, and
it is set to 6, which is refresh period in ms. First, i thought
it was supposed to be 100ms (at least, that's the # i recall reading
somewhere). Second, shouldn't there be a CONF_LCD_REFRESH_PERIOD
in the config.h file, so that it can easily be changed?
*) battery.c: line 38-41: (comments removed)
#ifdef CONF_BATTERY_INDICATOR
unsigned int battery_refresh_counter = 0;
unsigned int battery_refresh_period = 2000;
#endif
The 2000 is a counter, in seconds, in which the battery indicator
on the LCD is updated. Should not the 2000 be something that
can be configured by the user: be put in the config.h file?
*) Is there a way we can get the auto-shut off thing? I know i've
forgotten to turn it off overnight! Of course, the timeout should
be configurable, as should its actual useage.
*) 'Direct' Motor/Sound/Sensor/etc
Why are they called 'direct' anything. Being a bit of a newbie
to legOS, the 'd' throws me off.
*) include/sys/battery.h has a few references to the __template_h_ stuff
*) Is kerenel/conio.c supposed to have a public/global function
delay()? It seems a bit out of place, to say the least. Not
to mention it is "not well calibrated" (a quote from the source).
(It does seem to get used by dsensor.c) Perhaps lcd.c is more
of an approriate place for it.
*) For all the better hackers out there, more familiar with legOS,
an idea for output is to provide a method to print out messages
longer than five characters. In the kernel, sys_time, i presume,
we would need a function which rotates the message every X
milliseconds. There would have to be interaction rules with other
functions, such as the current "cputs". (unless we modify cputs
to handle this functionality.) A CONF_LCD_CONIO_SCROLL or something.
*) CONF_CONIO and CONF_ASCII.
Since CONF_ASCII is a dependant of CONIO, shouldn't it be
CONF_CONIO_ASCII or such? Or perhaps rename them
CONF_IO (or CONF_IO_CONSOLE) and CONF_IO_ASCII?
*) How about creating CONF_KEY_NO_KEY_OFF, and a CONF_KEY_NO_KEY_RUN
Both which work as is when there is not program running, but
if there *is* a program running, then the program has complete
control over them.
*) More documenation on LNP would be fairly nice. But everyone
knows that.
*) I would also like to see the ability return to statically link in
a program. But i think i've read that it is no longer possible.
Why not?
I would guess it would take some hacking on kernel/program.c
*) Shouldn't program.c have #ifdef's to check if CONF_LNP is
enabled? It currently seems to use LNP code without checking.
*) Should there be a way to tell the kernel NOT to automatically handle
IR data, or a way to turn it off from inside a program? (to save
battery juice). This would be more usefull in the case where we
statically compiled in the program w/ the kernel. Or a way to
turn it off after uploading one program?
*) How many programs can be uploaded? Where is this set, and why is
it not set in the config.h file? (or how come i'm blind and stupid
and can't see it in the config.h file? ;-)
*) Is there a way to start other stored programs from inside a program?
And be running them both at the same time? Message passing?
*) Maybe i should just ask for sourceforge developer access, and
start making some of the simple fixes myself.
*) Is it possible to modify the kernel/program.c and/or the `dll`
program to allow us to upload new firmware without resetting?
*) kernel/semaphore.c
#includes <semaphore.h> before the #ifdef CONF_SEMAPHORES..
*) Do the include files, like <semaphore.h> check if the kernel config.h
file really have the approriate CONF_??? enabled? Semaphore sort
of does. It only defines stuff if CONF_SEMAPHORES is enabled.
Perhaps it should output an error or warning if CONF_SEMAPHORES
is not enabled. ke:
#ifdef CONF_SEMAPHORES
.... // define what we need to define
#else /* else: CONF_SEMAPHORES is NOT defined */
# warning No kernel support for CONF_SEMAPHORES, no definitions made
#endif /* CONF_SEMAPHORES */
This type of thing may useful for other functionality, like
the CONIO, or ASCII, SENSOR, MOTOR, SOUND ...
*) kernel/tm.c
There is a #define for fatal(a), which for production, does nothing.
However, below it there is a commented out #define making it
output a message. Having this fatal, seems like a pretty good idea
to me. Although, i would recommend changing it to a function
call, and naming it something like k_fatal.
*) kernel/vis.c
Another refresh counter, not being configure able via config.h!
This one is called vis_refresh_period.
*) kernel/vis.c -- what does it do?
*) I think it might be a "cool" feature if we had a configurable option
which used the view option to go through a few different choices,
which allow the user to view the state of the system. For example,
pressing the VIEW button, would rotate through a list of choices,
for example, "batt"(ery), "mem"(ory), ""(ie, the program selection
and run mode). When, for example, 'batt' is selected, and the
user presses run, it displays the current battery level. (no pun
intended). When 'mem' is selected, it either displays the amount
of memory used, or the amount available yet (perhaps two options:
"mem u", or "mem a".
Hmm.. yet another idea. How about the naming of programs? When
a program is installed, it runs a "required" function, which
returns the function name. Or perhaps use a #define to name the
program. This way the user can select program based on its name,
instead of the program number. Of course, it'd be nice if the
program name would have a default, like "prog n", if no name was
specified. The 'n' would be replaced by the system, using some
sort of numbering system. (ie the current system?)
Then the "mem" and "batt" programs can just be automatically
installed programs for use. We could also change the system to
have a "inst"all program, which, when ran, allowed for the
installation of new programs, and a "firm"ware program, which
allowed for the installation of a new firmware.
*) There are a bunch of comments, used for seperating sections, ie:
///////////////////////////////////////////////////////////////////////////////
//
// Functions
//
///////////////////////////////////////////////////////////////////////////////
This is slightly annoying for those of us (er, or at least me),
who use a 72 column screen for editing files. I use vi, and have
numbers showing, which gives me 72 columns. So, anything longer
than that wraps, and is relatively annoying.
*) What is the difference between dbutton.h and dkey.h? Why are there
two of them? It makes sense to me to merge them.
*) How about a CONF_LCD_ACTIVITY, which makes legOS to display things
like which direction the motors are going, or if there is input
coming in on a sensor... sort of like what happens w/ the default
firmware.
*) include/sound.h
I'm not sure if some of it's configuration things should be in
the config.h: DSOUND_DEFAULT_16th_ms (duration of 1/16th of a note),
and DSOUND_DEFAULT_internote_ms. (duration internote spacing)
*) include/time.h
A bug is listed saying time_t is a 32 bit value, which will overflow
after 49.7 days of continuous operation. Well, that's good and all
to warn us about this bug.. however, it does seem to me that there
is a bigger and more important bug which I'd be very suprised if
it doesnt strick before 49.7 days. This bigger bug is this:
THE BATTERIES WILL DIE BEFORE THEN! I'd be fairly amazed if any
program actually doing something would last 49.7 days.
*) include/unistd.h:
line 70, there seems to be an extra semi-colon. Stupid details.
Don't imagine that it would matter.
*) include/unistd.h:
apparently the function extern void kill(pid_t pid) belongs in
another file (just a reminder from reading the source code)
*) include/rom/sound.h: there are some register clobbering. (?)
*) Should perhaps the header files for kernel files be located in
an 'include/legOS' or 'include/kernel' directory... so that it is
more explicit if you are calling a kernel provide function, or
more of a library call. (ie, str functions are library calls, while
reading a sensor is a kernel call).
*) include/sys/time.h
Defines a TM_DEFAULT_SLICE to be 20. Shouldn't this be in the
config.h file?
*) libmint: what does it do? I figure it does some low-level cool
things for division, etc. It may be nice to just have some docs
somewhere, mentioning what it does. IMO.
*) Does the h8300.rcx file need to be in the legOS directory? it'd
be nice, IMO, to move that somewhere else... legOS/boot/ ?
*) How about including the "freshly generated API docs" in the
legOS/doc/ directory?
*) Hmm.. Doxyfile seems to be out of date (PROJECT_NUMBER = 0.2.2 ;-)
Also, there doesn't seem to be documenation generated for the
lib/* files. Although I think the info is provided in the include
directory. (ie, string.h).
*) For C++, an idea would be to use g++'s -fno-rtti, to save some
memory space. Esp, since rtti isn't (yet?) supported
WOW! That's a *LOT* of comments about legOS. Hope at least someone
made it all the way through! Its about 42 points.. Yikes
Shows you what going through all the most all the source code does for
you!
Anyways, I hope this generates some discusion and some new features
for 0.2.5 release!
Ryan
--
Ryan VanderBijl http://www.calvin.edu/~rvbijl39
(Frodo:) "I don't want to answer a string of questions while I am
eating. I want to think!" "Good heavens!" said Pippin. "At breakfast?"
|
|
Message has 1 Reply:
 | | Re: questions, comments, and suggestions
|
| (...) RCX_COMPILER is an internal gcc/egcs define, when patched correctly to support RCX interrupts. This is still used and useful, as it saves only the required registers, unlike the HANDLER_WRAPPER macro, which saves all volatile registers. (...) (...) (24 years ago, 1-Aug-00, to lugnet.robotics.rcx.legos)
|
10 Messages in This Thread:
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
