>>>>> "Ø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).
>> 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?
David
--
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
