How to use rtems_event_system_send and rtems_event_system_receive?

Cliff Geschke cliff.geschke at preciseautomation.com
Fri Jul 27 15:45:34 UTC 2018


Hello Sebastian,

I'm afraid that moving to version 5.x would have even more incompatibilities to
deal with.

I tried the hack and it seems to work okay.  It was a mystery as to why my waits
on SBWAIT were never satisfied.  I would have appreciated a mention of the new
system events somewhere.

If I were adding system events, I think I would extend the event mask to be 64
bits and then let the user routines access only the low 32 bits.  But let the
system routines access them all.  

Thanks for the advice.

Cliff

-----Original Message-----
From: Sebastian Huber [mailto:sebastian.huber at embedded-brains.de] 
Sent: Friday, July 27, 2018 3:36 AM
To: Cliff Geschke; users at rtems.org
Subject: Re: How to use rtems_event_system_send and rtems_event_system_receive?

Hello Cliff,

On 26/07/18 22:27, Cliff Geschke wrote:
>
> I am migrating an application from RTEMS 4.6 to 4.11
>

I would directly migrate to the latest RTEMS master if you do such a 
huge version step.

> I see that the BSD stack now uses the new rtems_event_system_receive() 
> and rtems_event_system_send() rather than the older rtems_event_*().
>
> I cannot find any documentation or guidelines for 
> rtems_event_system_*.  Can anyone point me to them?
>

These functions should be only used by the system and not application 
code. Therefore they are not documented in the user guide.

> In my application, I want to wait for the OR of system event SBWAIT 
> and some user-defined events.  Is there an efficient way to wait for 
> both a system event or a user event?
>

No, they are separated. You can only wait for one or the other.

> Do I need to hack my application to use system events rather than user 
> events?  That seems to defeat the purpose of having system events.
>

Yes, currently this hack is the only solution. I think the basic problem 
is that RTEMS offers no general purpose event system such as kqueue() or 
epoll(). In libbsd (the new network stack), we support kqueue(). 
Depending on your target, the libbsd might be an option.

-- 
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.





More information about the users mailing list