Re: [ECOS] stdio vs. diag_printf

[Grant Edwards <grante at visi dot com>]

On Tue, Jul 11, 2000 at 05:30:03PM +0100, Hugo Tyson wrote:

> > > But beware: diag_printf is synchronous 
> > 
> > That's a good thing if you're using the messages to figure out
> > if a particular line of code has executed.  ;)
> 
> Yup, that's part of the point.
>  
> > > and disables interrupts for quite a long time.  
> > 
> > That would be a problem. 
> > 
> > I can't find the spot where interrupts are disabled in
> > daig_printf.  Can you perhaps point me towards the right source
> > file?
> 
> It tends to be in the individual HAL's diagnostic print routine; ints
> aren't off for the whole time of printf processing, but they are off for
> the whole time it takes to send a GDB $O packet down the serial
> string... (if you're using stubs)

Ah.  I'm not using stubs (I've got a UART for diagnostics -- a
happy accident: the UARTs on the uController didn't have enough
speed/features for the application, so we had to go add
external UARTs, leaving the built-in ones free).  The HAL
routines I wrote don't disabled interrupts at all; they just
poll the UART.  This means that messages from different tasks
sometimes get interleaved, but it's a worthwhile trade-off to
avoid disabling interrupts.

> > > Whether this matter depends on your network performance needs...
> > 
> > I try to keep diagnostic messages small enough to fit in the
> > UART's FIFO, so they generally don't "block".  If long messages
> 
> Divide by 2.delta for GDB $O formatting...?  But yes, you clearly
> understand the issue here.
> 
> > start to delay things, I'll crank up the baud rate some more.
> > I'm currently running at 57.6K, and can go as high as 460.8K if
> > I need to.
> 
> <FX: whistles appreciatively>

I still wish I had a real ICE with a trace buffer sometimes,
but that ain't going to happen.

-- 
Grant Edwards
grante@visi.com