Re: [ECOS] cyg_hal_diag_mangler_gdb_putc vs. interrupt latency

[Jesper Skov <jskov at redhat dot com>]

On Thu, 2002-01-17 at 08:14, Hiroshi Lockheimer wrote:
> Hi there,
> 
> Just curious what the intent of the HAL_DISABLE_INTERRUPTS is in
> cyg_hal_diag_mangler_gdb_putc (hal_if.c)? 

The reason is in the comment just about the line:

        // Disable interrupts. This prevents GDB trying to interrupt us
        // while we are in the middle of sending a packet. The serial
        // receive interrupt will be seen when we re-enable interrupts
        // later.


> When debugging an application with many printfs over gdb, this can kill our
> interrupt latency...they can be disabled for more than 50ms, because of
> printf! During those 50ms we need to service a separate UART's RX interrupts
> or else we start dropping data there.
> 
> Would it be safe to modify this function to mask the interrupt that services
> gdb's stream only (for example masking gdb's UART's interrupts only), or
> does it really have to disable *all* interrupts?

We disable all interrupts to make sure the debugger has full control of
the system - which is necessary for breakpoint handling,
single-stepping, and debugging in general. I don't think you could get
away with changing that.

However, seeing as you are apparently primarily using the channel for
diagnostics output, going through GDB is overkill. Do you have a spare
serial channel? If so, you could direct diag_printf to that channel in
raw format.

If you only have the one channel for sharing between GDB and
diag_printf, you could try to change the interrupt masking - but things
would likely break down if the code ever hit a breakpoint, caused an
exception, or you try to do interactive debugging.  

So maybe you'd be better off just starting the application from RedBoot,
which will cause the diag_printf output to be written raw to the serial
line, without the GDB O-packetization (which is what's causing the long
delays because GDB has to ACK each of these).

Jesper