On 5/07/2011 8:36 AM, Andrew Leech wrote:
On 4/07/2011 6:22 PM, Spencer Oliver wrote:
On 4 July 2011 08:12, Andrew Leech<[email protected]> wrote:
On 1/07/2011 8:47 PM, Spencer Oliver wrote:
On 1 July 2011 00:41, Andrew Leech<[email protected]> wrote:
Only problem is, it's incredibly slow, unusably slow. A single
step can
take
5 seconds, where on a normal tcp connection with same configs
feels close
to
instant, so maybe about 1/4 of a second. Did your windows one behave
better?
If so, do you know what version/release of gdb you used?
used Sourcery G++ Lite 2011.03-42
Have not noticed any speed issues, most of my testing was under linux
however.
I am running winxp, that has always proved fairly nippy compared to
vista anyway.
Delving into openocd logs, taking a -d3 on both pipe and tcp usage,
I get
exactly the same commands being run for both when stepping over the
first
line of my program, but in pipe usage lots of them take 100ms longer:
That 100ms may well be caused by the win32 version of select - win32
select does not support pipes so had to create a special version.
Check out the MsgWaitForMultipleObjects and you see your 100ms delay.
Perhaps this function needs tweaking.
Cheers
Spen
If it's a code issue with openocd code, I would have thought you'd see
the same problem in pipe mode on windows, I know you said you never
used it much, but I find it's instantly noticeable, around a factor of
10 different in speed.
With all this playing around though, I've also found that openocd
doesn't shut down properly in pipe mode with eclipse, neither hitting
terminate not disconnect in eclipse will actually shut down openocd or
gdb, they just sit there hanging. I just have to resort to task
manager to shut it down. Maybe I'll just have to stick with using
openocd as a separate external tool still. Unfortunately I'm locked to
windows for using Altium Deisgner (my main role is electroncis
design), and I just get sick of trying to do too much in vm's.
Thanks,
Andrew
Thanks for the tip about MsgWaitForMultipleObjects, I went hunting. It's
not the timeout on that call that causes the delay, but the
tvslice.tv_usec setting above it. In particular:
diff --git a/src/helper/replacements.c b/src/helper/replacements.c
index ef20e77..00e6bd1 100644
--- a/src/helper/replacements.c
+++ b/src/helper/replacements.c
@@ -216,7 +216,7 @@ int win_select(int max_fd, fd_set *rfds, fd_set
*wfds, fd_set *efds, struct time
aexcept = sock_except;
tvslice.tv_sec = 0;
- tvslice.tv_usec = 100000;
+ tvslice.tv_usec = 30000;
retcode = select(sock_max_fd + 1, &aread,
&awrite, &aexcept, &tvslice);
}
Speeds up stepping dramatically (about 3 x faster ;-)
I have a feeling it makes other things a little less reliable, I seemed
to have more trouble connecting to my target, but then connecting to my
target goes through phases of being difficult, there's some other
settings that I've never got completely ironed out. So I don't know if
this change is really what made it worse, or if it's unrealted.
Either way I'll leave my local copy like this for now and give it a go,
but if I get a chance I'll have a look deeper into whether there's a
better way of doing it.... don't know if/when that may ever happen though.
Thanks,
Andrew
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
