Subject:
|
Re: questions, comments, and suggestions
|
Newsgroups:
|
lugnet.robotics.rcx.legos
|
Date:
|
Tue, 1 Aug 2000 01:21:32 GMT
|
Viewed:
|
1210 times
|
| |
|
|
> *) 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?
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.
> *) 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.
Should be fixed.
> *) 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.
CONF_VIS does the same you want to do with CONF_LCD_ACTIVITY below.
You could disable CONF_LCD_REFRESH, this will disable automatic LCD
refreshes. But powersaving by not using the LCD is minimal. More power
is saved by idling the CPU as much as possible, there are quite a few
changes coming in 0.2.5 that will help save power.
> *) 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.
You don't need to look at include/sys/lcd.h and kernel/lcd.c, unless
you want to understand how the LCD driver chip works.
If you want to print text or numbers, you don't need include/dlcd.h
Maybe useful constants from include/rom/lcd.h could be merged into
include/conio.h.
> *) 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?
This is the refresh period for a single byte of the LCD buffer, so a
complete LCD refresh runs every 9 * 6 = 54 ms. This is eye friendly,
but still better than calling the ROM's lcd_refresh every 100ms in terms
of CPU and battery costs. Faster refresh doesn't help you see things
better, slower refresh leads to flickering LCD, so this constant is
meant to be constant and not configurable.
> *) 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?
This will change into a separtate kernel thread soon, the rewriter could
maybe make this configurable.
> *) 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.
This might be possible.
> *) 'Direct' Motor/Sound/Sensor/etc
> Why are they called 'direct' anything. Being a bit of a newbie
> to legOS, the 'd' throws me off.
Direct as opposed to some driver API. These things are rather helpers
to directly modify bits in the hardware, then being a device driver of
any kind.
> *) include/sys/battery.h has a few references to the __template_h_ stuff
Oops.
> *) 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.
This could maybe move, and also be calibrated. I will look into this.
> *) 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.
This should be handled by the user. To handle such a beast correctly,
it would cost lots of kernel code, and would be hard to get right at
all places.
> *) 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?
What would it help?
> *) 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.
This is a hard philosophical question I dare not answer by myself.
> *) More documenation on LNP would be fairly nice. But everyone
> knows that.
Yes.
> *) 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
Needs checking. I never tried that.
> *) Shouldn't program.c have #ifdef's to check if CONF_LNP is
> enabled? It currently seems to use LNP code without checking.
This is checked in config.h. No use to have CONF_PROGRAM without the
network.
> *) 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?
The transmitter is turned of, if it is idle. We need a measurement on
the savings of turning of the complete serial engine, but I doubt this
is much.
> *) 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? ;-)
PROG_MAX from include/sys/program.h
> *) Is there a way to start other stored programs from inside a program?
> And be running them both at the same time? Message passing?
I thought about that lately. Starting the second program is the hard
part...
Doing this would only be necessary for the hack of it, not for anything
good. You can code this using execi() with separate threads in one prog.
There would be no difference whatsoever with separate programs running.
Communication is no problem, you have semaphores and shared memory.
> *) Maybe i should just ask for sourceforge developer access, and
> start making some of the simple fixes myself.
Slowly. Just listing many points is no warranty to convince everybody
about the need of many changes...
> *) Is it possible to modify the kernel/program.c and/or the `dll`
> program to allow us to upload new firmware without resetting?
This should be easily done.
> *) 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 ...
All these checks are at the end of config.h.
> *) 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.
Call it panic(), so it doesn't look like pSOS (where k_fatal doesn't really
help most of the time).
> *) 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?
See above.
> *) 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.
To much bloat in the kernel. Write a user program for that, make that
available to everyone. This program could be loaded to the RCX, so you
have all those features.
> *) 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.
:set nowrap
should fix that.
> *) What is the difference between dbutton.h and dkey.h? Why are there
> two of them? It makes sense to me to merge them.
This might be doable.
> *) 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.
See CONF_VIS above.
> *) 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.
For the first problem, you can write software to deal with, the second
problem is rather hardware related and can be fixed with an external power
supply.
> *) include/unistd.h:
> line 70, there seems to be an extra semi-colon. Stupid details.
> Don't imagine that it would matter.
Fixed.
> *) 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?
Do you know what exactly changes if you change this define?
> *) 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.
This is basically what libgcc.a exports for gcc/egcs compiled code.
It must be documented somewhere in "Using and porting gcc"...
> *) Does the h8300.rcx file need to be in the legOS directory? it'd
> be nice, IMO, to move that somewhere else... legOS/boot/ ?
No direct need to be in legOS.
> *) 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
Does anyone really use C++? I mean for more than experimental use?
If you have an example on the savings and a diff to change the Makefiles
it would be easy to fix this.
Eddie C. Dost
ecd@skynet.be
|
|
Message has 1 Reply:
 | | Re: questions, comments, and suggestions
|
| (...) only (...) Do you know if RCX_COMPILER patch need to be used in GCC 2.95.2 cross compiler too? (...) Fixed right now. I'm ready to commit. (...) indicator (...) could (...) It will be changed in 0.2.5, but two notes: 1) The counter is in ms. (...) (24 years ago, 11-Aug-00, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | questions, comments, and suggestions
|
| 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 (...) (24 years ago, 31-Jul-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
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
