| |
The lugnet registration takes forever :)
After reading this post a light went on in my head. A few weeks ago I wrote a
multi-threaded program for the RCX (about 7 threads, each running an endless
loop).
When I added one more thread, the robot started gerking around continuously,
not moving an inch from where it started. "Great, a memory leak" - I
thought. But I found none. After reading this post (and while waiting for the
registration process to complete :) I dug the old code back from the grave,
and, sure enough, after tweaking mm_init():
MM_BLOCK_FREE (&mm_start); // ram
// something at 0xc000 ?
MM_BLOCK_RESERVED(0xef30); // lcddata
MM_BLOCK_FREE (0xef50); // ram2
MM_BLOCK_RESERVED(0xf000); // motor
// MM_BLOCK_FREE (0xf010); // ram3
// MM_BLOCK_RESERVED(0xfd80); // vectors
MM_BLOCK_FREE (0xfe00); // ram4
MM_BLOCK_RESERVED(0xff00); // stack, onchip
all worked out. It seems the thread I added was being executed (continuously)
in this troubled memory area, messing up the motors.
I just think that if you actually allow the user to use this memory area
(wich I think it's a good idea), it should be protected in some way. Some
kind of flag the user has to set "on" (the idea of a function wrapper seems
appealing) to make sure he knows what he is doing.
In my case I lost a few hours looking around the code searching for the cause
of the problem (when I decreased the stack size in execi the problem would
magically go away). After these hours I was convinced it would either be a
compiler error, or a kernel error, greatly decreasing my trust in these
tools. Of course now that I know the cause, this no longer applies.
Don't get me wrong. I still think Leg^H^H^H BrickOS rules!
Ricardo Ferreira
|
|
Message is in Reply To:
16 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
