This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: stdio vs. diag_printf
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