POSIX semaphores across ISR/non-ISR contexts

[Sebastian Huber]

On 2014-06-26 18:01, John Harwell wrote:
> Hello,
>
> I am using the GR712RC, and due to the way the UARTs have been routed out on
> our board, we do not have access to UART0/the RTEMS console driver. I have
> therefore created my own printk() function that simply writes data out to
> another UART.

You can still use printk() if you set

BSP_output_char_function_type BSP_output_char = your_output_char;

accordingly.

You can also modify the standard driver to be more flexible.  I think with 
RTEMS 4.11 this is already available.

> Access to the debug UART is protected by a binary semaphore as
> follows:
>
>      if (_ISR_Nest_level == 0) {
>                  sem_wait(&dbg_access_sem);
>      }
>      uart_write(dbg_uart,(uint8_t*)proc_buf,strlen(proc_buf));
>      if (_ISR_Nest_level == 0) {
>              sem_post(&dbg_access_sem);
>      }

In case this is used for debugging only, then I would disable interrupts 
instead of using a semaphore.  You get also into trouble in case you try to 
obtain a semaphore with thread dispatching disabled.  You have also a problem 
in case of nested interrupts.

>
>      The if statements around the semaphore functions are necessary because if
> an RTEMS task is within the uart_write() call), and an interrupt occurs, and
> the ISR happens to have a debug print statement,
> , then the first uart_write() call is interrupted, and the ISR debug statement
> is seen. However, after the ISR handler returns, the original RTEMS task is
> effectively dead (no more debug statements are seen, and no more work is done)
>
> The guards ensure that you do not attempt semaphore related actions while in an
> ISR context. With them, my code works as expected, but I would like to
> understand why they are necessary.
>
> How are POSIX semaphores handled when they are shared across ISR/non-ISR
> contexts, or are they not meant to be shared in that way? Why did the debug
> statement in the ISR print, even though the original RTEMS task had already
> locked the semaphore? Why is the RTEMS task unresponsive after the ISR returns?

You cannot block in ISR context.  So never perform a potentially blocking 
operation in this context.  The RTEMS services that can be safely used in ISR 
context are listed here:

http://rtems.org/onlinedocs/doc-current/share/rtems/html/c_user/Interrupt-Manager-Directives-Allowed-from-an-ISR.html#Interrupt-Manager-Directives-Allowed-from-an-ISR

>
> All other RTEMS tasks that I have running remain active and their debug
> statements show up without issue after the ISR returns.
>
> I am using RTEMS 4.10.
>
> Thanks,
>
> John Harwell
> Engineer, Southwest Research Institute
> _______________________________________________
> users mailing list
> users at rtems.org
> http://lists.rtems.org/mailman/listinfo/users


-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.