| |
Matthew E Cross wrote:
> Oh, you're doing stuff inside the scheduler. Yeah, msleep doesn't work
> too well there :-)
However, last night, I wrote a brute force (spin loop) msleep which works fine in
the scheduler. I found that 800 iterations of an empty for loop with a 16 bit index
comes pretty close to 1ms. Granted, I cheated a little, knowing that the clock
speed was 16MHz.
I then made some debugging functions which feed a short or two chars to cputw, call
lcd_refresh, and then invoke that delay.
It probably won't be of broad interest, so I won't be releasing that code unless
people are interested in it.
>
>
> Yes, the pauses were only so I could see what was going on.
Indeed. It is hard to read numbers which are there for less time than it takes to
(electrically) refresh the LCD.
I find that 500ms is pretty good for being able to read the numbers.
> Another thing you could do is print messages out the IR port; but I'm
> not sure how it would interact with the scheduler.
Something I might try if (when) the current approach proves inadequate. I'll want
to get experience playing with IR in user space first with a working scheduler,
though.
> > Markus has planted a bug in my head with regard to suspending and resuming
> > tasks. I can't get to it just yet because I need to get the scheduler
> > working. It involves adding a suspend queue in addition to the run queue in
> > each priority.
>
> Alternatively, you could just change tm_switcher() to ignore tasks that are
> in a 'P_SUSPENDED' state or something like that.
The simplicity of that approach could well be worth the trivial drop in performance
vs the separate queue approach.
> > I'll be interested in seeing if you can make breakpoints work. I can't think
> > of an easy way with the available hardware.
>
> The best I could come up with was to overwrite the instruction with a jump
> to itself, and when the scheduler reschedules a task, it would check if it
> was stopped on this instruction; and if it was it would tell the denugger.
On this architecture, are all instructions the same length as the mentioned jump (or
longer)? (I don't have the manual handy.) If so, this does seem like a good way
to do it. The scheduler could dereference the stack pointer and see if it points to
(or just past) that opcode, and only (take the time to) scan the breakpoint list if
it does. I am assuming that a jump to one's own address is going to be a relative
jump, and, therefore, always the same byte sequence.
|
|
Message has 1 Reply:
 | | Re: Debugging
|
| (...) It's what I'm doing for now in my debugger work. I haven't tried it out yet, though. (...) I carefully looked at the opcodes, and found that the shortest opcodes are all 2 bytes, and hand-coded the 2 byte instruction that jumps to itself. The (...) (26 years ago, 17-Mar-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: Debugging
|
| (...) Oh, you're doing stuff inside the scheduler. Yeah, msleep doesn't work too well there :-) Yes, the pauses were only so I could see what was going on. Another thing you could do is print messages out the IR port; but I'm not sure how it would (...) (26 years ago, 17-Mar-99, to lugnet.robotics.rcx.legos)
|
7 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
|
|
|
|
