| |
Lou Sortman <lou_sortman@servicemerchandise.com> wrote:
> Matthew E Cross wrote:
> > Another thing I've done is write out a number where the upper byte
> > indicates a position in the code and the lower byte is some useful data,
> > and put a second or two pause after displaying each number. It's kind
> > of a poorman's trace mechanism.
> I did that too. In my case, the lower byte was the priority level.
> I assume the pause relates to work in user space. I'm going to have to figure
> something else out for use inside of the scheduler, since msleep depends on
> timer ticks happening, and the interrupt is blocked while I'm in the
> scheduler. If I need it badly enough, I could poll the hardware timer and
> wait for a certain bit to flip.
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 interact with the scheduler.
> > I'm working on a debugger for LegOS that will allow you to suspend &
> > resume tasks, examine the registers of suspended tasks, look at memory,
> > and set breakpoints, all over the IR port. But don't hold your breath
> > waiting for it - I just switched jobs recently and that is taking most
> > of my time :-)
> 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.
> 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.
-Matt
|
|
Message has 2 Replies:
 | | Re: Debugging
|
| (...) 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 (...) (28 years ago, 17-Mar-99, to lugnet.robotics.rcx.legos)
| | | Re: Debugging
|
| (...) Try delay(). It's the non-scheduler version of msleep(). If you have a version that's better calibrated, please patch delay() in conio.c to reflect that. (...) A branch to itself is probably the best you can do, as you need an atomic (...) (28 years ago, 20-Mar-99, to lugnet.robotics.rcx.legos)
|
Message is in Reply To:
| | Re: Debugging
|
| (...) I don't think it does. Of course, the source would answer definitively, but I also know that until I remembered to put the refreshes in there, I didn't get useful output. (...) I did that too. In my case, the lower byte was the priority (...) (28 years ago, 16-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
|
|
|
|
