On Mon, Aug 16, 2010 at 11:30:39AM +1200, Daniel Beer wrote:
> On Sun, Aug 15, 2010 at 04:31:47PM +0100, Robert Spanton wrote:
> > Hi,
> > 
> > At the moment, the uif driver in mspdebug waits 0.5 seconds between
> > polling the device's state -- i.e. querying whether it has hit an
> > interrupt etc.  There's a comment that states that this poll prevents
> > the loss of breakpoints.
> > 
> > Out of curiosity I removed the usleep(500000) and was surprised to find
> > that it still works.  Does anyone know the circumstances in which this
> > is required?
> > 
> > I've tried this using a FET430 with a F169 and a F247 through 4-wire
> > JTAG and it seems to work fine.  Obviously its removal results in
> > significant latency improvements when single-stepping through code!
> > 
> > (Some wild postulation: maybe the delay's required for the EZ430 or
> > spy-bi-wire?)
> 
> Hi Rob,
> 
> I did notice that without the delay, I got some odd behaviour with the
> RF2500. However, this was way back when I didn't have breakpoints
> working properly either. I'll try it again when I get a chance and see
> what happens.
> 
> There probably still needs to be _some_ delay, because the polling
> functions are called repeatedly when the chip is running, and it's
> probably best that we don't chew up a lot of CPU time on it.
> 
> I had considered moving the delay into the two run loops (in devcmd.c
> and gdb.c), but then we don't want this delay for the simulation
> driver.

Well, I retested this with the RF2500 and couldn't find any problems.
I've reduced the polling interval down to 50 ms, which feels much more
responsive. According to "top", CPU consumption is below 2% on my
laptop.

- Daniel

Reply via email to