| |
Matthew E Cross wrote:
> Lou Sortman <lou_sortman@servicemerchandise.com> wrote:
> > Do you guys have an established mechanism for debugging?
>
> > I'm thinking of writing certain numbers to the display using cputw().
>
> That's the method I've used. Just be sure to put an lcd_refresh() after
> the cputw() call - I can't remember if cputw() does the lcd_refresh() or
> not.
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.
> 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.
I was able to get enough information from this debugging method without the
sleeps to know that I was spinning in a loop looking for the next process to
run. Since the display was changing so rapidly, some of the segments were
just not quite on. In some cases, the loop rate beats against the LCD scan
rate with interesting effects.
> 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 :-)
>
> -Matt
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.
I'll be interested in seeing if you can make breakpoints work. I can't think
of an easy way with the available hardware.
Oh, I know all about the job switching thing. I don't know if I've fully
recovered from the last time yet. A bunch of people got down sized a week or
so ago, and I might be on the pavement again in the indeterminate future.
|
|
Message has 1 Reply:
 | | 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)
|
Message is in Reply To:
| | Re: Debugging
|
| (...) That's the method I've used. Just be sure to put an lcd_refresh() after the cputw() call - I can't remember if cputw() does the lcd_refresh() or not. Another thing I've done is write out a number where the upper byte indicates a position in (...) (26 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
|
|
|
|
