>
> On 30/03/2022 15:19, [email protected] wrote:
> >>> Ok, it seems the pps_event() could be called by interrupt service
> >>> routines. In this case, you cannot use a mutex and condition variables.
> >>> You have to use a thread queue directly. Use the thread queue ISR
> >>> lock for mutual exclusion. Use _Thread_queue_Enqueue() to emulate
> >>> sleep() and
> >>> _Thread_queue_Flush_critical() to emulate wakeup(). Check all
> >>> critical sections that they can be protected by an ISR lock (no blocking
> >>> calls and short).
> >> Is this even so if pps_event() calls signal or broadcast? Because
> >> pps_fetch() is the only function that is waiting (and locking a
> mutex).
> > Do you mean something like this?
> >
> [...]
> >
> > Unfortunately something should be missing because it doesn't work.
>
> In cpukit/score/src/futex.c you have a working example.
The code I sent to you is based on condition.c, which is very similar, but
probably something is wrong because it hangs after calling
_Thread_queue_Enqueue() (my question was pointing into that direction)
> You would have to replace the mutex with the thread queue lock. I had a look
> at some FreeBSD drivers which use this stuff and it
> would not be possible to support them with this approach. You could move the
>
> if (abi_aware(pps, 1) && pps->driver_mtx != NULL) {
> if (pps->flags & PPSFLAG_MTX_SPIN) {
> err = msleep_spin(pps, pps->driver_mtx,
> "ppsfch", timo);
> } else {
> err = msleep(pps, pps->driver_mtx,
> PCATCH,
> "ppsfch", timo);
> }
> } else {
> err = tsleep(pps, PCATCH, "ppsfch", timo);
> }
>
> and
>
> /* Wakeup anyone sleeping in pps_fetch(). */
> wakeup(pps);
>
> blocks into RTEMS-specific sleep/wakeup callouts in struct pps_state.
Yes, these are the parts that I'm implementing. For now I'm focusing to emulate
the behavior of tsleep() because it will be enough to get something working.
_______________________________________________
devel mailing list
[email protected]
http://lists.rtems.org/mailman/listinfo/devel
