"printf()" from ISR worked consistently? Huh?

[Joel Sherrill]

On Wed, Aug 18, 2021 at 3:13 PM Peter Dufault <dufault at hda.com> wrote:
>
> I've been porting some old code to rtems-6 and I had a "logtxt()" function that I'd used for years that was callable from an ISR - it buffered up the info and sent it to a task to log.
>
> I didn't realize that the old library had a fall-back "logtxt()" that used printf() that I'd over-ridden in the applications where I'd been using it.  A lot of things weren't working right yet, but "logtxt()" appeared to be working just fine.  More things started working once I replaced "logtxt()" with a version that used "printk()".
>
> How could printf() from an ISR work at all, let alone seem to work well?  The "logtxt()" was only to the console, maybe that's why.

Just lucky. It somehow didn't use the FPU and managed to enqueue the
characters without conflicting with a task using it or using a mutex
that tripped a fatal error.

Another approach might be to write an sprintk (thought we had it)
calling _IO_Vprintf which is the guts of printk and have it print to a
buffer. Then send the buffer via a message queue to a thread to print
it. More complicated but doesn't force the caller to incur the
overhead of polling the characters out. That polling output overhead
maybe breaking timing and causing you some issues. Does the code work
without the logging?

> Also, is there an equivalent to the VxWorks "in_isr()" for a simple-minded "logtxt()" that switches between printk() and printf()?

The cleverly named rtems_interrupt_is_in_progress() should be the answer.

https://docs.rtems.org/releases/rtems-docs-4.11.0/c-user/interrupt_manager.html#rtems-interrupt-is-in-progress

But the IO may be mixed between printf() and printk().

>
>
> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>
>
>
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users