On 30/03/2022 15:19, gabriel.moy...@dlr.de 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.
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.
--
embedded brains GmbH
Herr Sebastian HUBER
Dornierstr. 4
82178 Puchheim
Germany
email: sebastian.hu...@embedded-brains.de
phone: +49-89-18 94 741 - 16
fax: +49-89-18 94 741 - 08
Registergericht: Amtsgericht München
Registernummer: HRB 157899
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
Unsere Datenschutzerklärung finden Sie hier:
https://embedded-brains.de/datenschutzerklaerung/
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
