On Tue, Aug 5, 2008 at 5:30 PM, David Kuehling <[EMAIL PROTECTED]> wrote:
>>>>>> "Øyvind" == Øyvind Harboe <[EMAIL PROTECTED]> writes:
>
>> 200ms?
>
>> OpenOCD, being single threaded, really won't be able to honor that
>> frequency...
>
>> At best a callback could be guaranteed to be serviced every
>> 1000-2000ms, because that is a requirement imposed by the keep_alive()
>> protocol in GDB.
>
> That might do the job. Watchdog timeout is 2000ms +/- 6%.
>
> What is restricting the event processing speed of OpenOCD? Timeouts for
> 'select' could be reduced, and operations taking a long time could be
> augmented to call the event processing routine (i.e. what 'update' does
> in TCL).
Bugs. It is defined as a bug not to invoke keep_alive() less often
than every 1000ms.
>
>>> If patching the sources were required, maybe adding another kind of
>>> target script ("while_halted") might be a solution and I'd be happy
>>> to write a patch if nobody objects.
>
>> Pre/post_halt/resume?
>
>> Not quite sure about the most elegant way of doing this. The # of
>> events could explode...
>
> Well, then just add something equivalent to TCL's 'after' command, which
> could be called from post_halt and pre_resume.
>
> Browsing through JIM SVN, I just found an 'after' implementation:
>
> http://cvs.berlios.de/cgi-bin/viewcvs.cgi/jim/jim/jim-eventloop.c?rev=HEAD&content-type=text/vnd.viewcvs-markup
>
> Maybe this can be added to OpenOCD?
Should work. Do you want to give it a try?
--
Øyvind Harboe
http://www.zylin.com/zy1000.html
ARM7 ARM9 XScale Cortex
JTAG debugger and flash programmer
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
