VxWorks Beginner - eventLib implementation - VxWorks

This is a discussion on VxWorks Beginner - eventLib implementation - VxWorks ; Hello again! Just posted one question, already have another Basically, I wish to implement an event driven system. I set out to do this originally using a very simple concept. Spawn "event-listener" tasks for each event I wish to receive. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: VxWorks Beginner - eventLib implementation

  1. VxWorks Beginner - eventLib implementation

    Hello again! Just posted one question, already have another

    Basically, I wish to implement an event driven system. I set out to do
    this originally using a very simple concept. Spawn "event-listener"
    tasks for each event I wish to receive. These event-listeners
    typically consist of an infinite while loop, blocked by a semaphore:

    void TaskA_EventA_Handler()
    {
    while(1)
    {
    semTake(TaskA_EventA_Semaphore, WAITFOREVER);
    // Handle the event
    }
    }

    Then somewhere else (either driven off of an interrupt, or some other
    task), you could raise an event by simply making a call to:

    semGive(TaskA_EventA_Semaphore);

    This implementation worked well, but was rather cumbersome to write.
    It involved quite a bit of semaphore management, task registration, and
    care in event producing/consuming. It often bloated the event handler
    code (the example above is oversimplified in that the semaphore is
    global. My implementation actually had the semaphore stored in a
    global linked list of task registry nodes).

    Then, I stumbled upon eventLib.h in some VxWorks 5.5 documentation.
    This eventLib library offered a more complete and robust event library.
    To my dismay, however, it seems that the eventLib wasn't introduced
    into the VxWorks operating system until after version 5.2 (which I cam
    using).

    The implementation I've used works fine enough, but I began wondering
    if I should write my own event management library to mimick what the
    VxWorks 5.5 eventLib.h did. It could be beneficial to mimick the
    eventLib.h as closely as I can so that in the future, if I upgrade our
    VxWorks license, I can adopt their libraries with little hassle. It is
    also a great learning experience for me as a beginner VxWorks
    programmer. I was wondering if anyone had any thoughts on how to
    implement an event-driven framework and could perhaps point me in the
    right direction.

    Thanks!


  2. Re: VxWorks Beginner - eventLib implementation


    alydis wrote:
    > Hello again! Just posted one question, already have another
    >
    > Basically, I wish to implement an event driven system. I set out to do
    > this originally using a very simple concept. Spawn "event-listener"
    > tasks for each event I wish to receive. These event-listeners
    > typically consist of an infinite while loop, blocked by a semaphore:
    >
    > void TaskA_EventA_Handler()
    > {
    > while(1)
    > {
    > semTake(TaskA_EventA_Semaphore, WAITFOREVER);
    > // Handle the event
    > }
    > }
    >
    > Then somewhere else (either driven off of an interrupt, or some other
    > task), you could raise an event by simply making a call to:
    >
    > semGive(TaskA_EventA_Semaphore);
    >
    > This implementation worked well, but was rather cumbersome to write.
    > It involved quite a bit of semaphore management, task registration, and
    > care in event producing/consuming. It often bloated the event handler
    > code (the example above is oversimplified in that the semaphore is
    > global. My implementation actually had the semaphore stored in a
    > global linked list of task registry nodes).
    >
    > Then, I stumbled upon eventLib.h in some VxWorks 5.5 documentation.
    > This eventLib library offered a more complete and robust event library.
    > To my dismay, however, it seems that the eventLib wasn't introduced
    > into the VxWorks operating system until after version 5.2 (which I cam
    > using).
    >
    > The implementation I've used works fine enough, but I began wondering
    > if I should write my own event management library to mimick what the
    > VxWorks 5.5 eventLib.h did. It could be beneficial to mimick the
    > eventLib.h as closely as I can so that in the future, if I upgrade our
    > VxWorks license, I can adopt their libraries with little hassle. It is
    > also a great learning experience for me as a beginner VxWorks
    > programmer. I was wondering if anyone had any thoughts on how to
    > implement an event-driven framework and could perhaps point me in the
    > right direction.
    >
    > Thanks!


    Alydis,
    I am not aware of versions before vxworks 5.4.But generally AFAIK,Event
    library premitive should be available with all vxworks versions,though
    I am not sure.Why I am saying this is because events form the most
    important communication mechanism between tasks in most RTOS and
    embedded applications.
    I am just giving my thoughts of how generally events can be
    implemented:

    Set a 32 bit flag.So you can set each bit in it.So now if you see all
    the combinations possible,you can have in all 2^32-1 events.Code each
    combination as ENUM and so you will have 2^32-1 as enums.Now When you
    would like to raise an event,set flag to one of the 2^32-1 combinations
    available depending on your application requirement.Now the place where
    you would like to recieve it,make a check to see if the flag is
    set.Incase the flag is set,handle it according to your wish.Now for
    this to work we generally have the concept of event raisers and
    susbcribers.
    A single event can be subscribed by multiple tasks.

    Generally the approach would be to create a listener task as you said
    and create a switch case statement inside it,to find out who is the
    event raiser and then handle them according to your requirement.For eg
    same event may be raised from different tasks.In such a case,you would
    prefer to handle them according to the raiser.So in such a case having
    a listener task is worth while.

    But incase you have a single raiser and multiple subscribers,theres no
    need to have a listener task.You can handle them individually in your
    subscriber tasks accordingly.

    But your idea of using a semaphore may have one draw back that
    generally semaphores are time consuming premitives,and if your idea is
    to communicate or just signal the receiver you would better off using a
    signal rather then a semaphore.

    You can go for semaphores incase you need synchronisation or resource
    protection.

    Hope it helps you.
    Regards,
    s.subbarayan


  3. Re: VxWorks Beginner - eventLib implementation

    I'm not saying that event programming and events do not exist on all
    versions of VxWorks. What I'm stating is that eventLib.h
    (http://www.eelab.usyd.edu.au/tornado.../eventLib.html)
    is not available in my copy of VxWorks. This library implements a
    couple of event functions that allows a developer to implement a
    convenient event-driven framework into their applications.

    Since this library is not available, I'm fishing around for ideas on
    how to implement my own event library. It would be awesome to mimick
    this existing library, so that when I can convince my boss to purchase
    a copy of a newer version of VxWorks, I don't have to rewrite a whole
    lot of code to migrate over my applications.

    I've tried to stay away from a signal-driven event framework. I'm not
    exactly sure why, but most websites warn to not try to use signals to
    implement event-driven programming. The semaphore concept I used in my
    sample code above is one idea I had, but I'm not stuck on it.

    I guess my dilemma comes from my lack of solid understanding concerning
    the very fundamentals of the VxWorks RTOS (or any RTOS for that
    matter). So let me ask some generic questions:

    If I'm writing an event library, is there a difference between:
    1) Creating a bunch of event listeners (each a seperate task) and send
    each of these tasks into an infinite while loop and waiting on a bit to
    set in a global variable.
    2) Creating a bunch of event listeners (each a seperate task) and
    suspend each of these tasks. Then, in a seperate task, continually
    check the status of the events. Once a requested event triggers for a
    specific task, I would resume the task.

    I would think that having having 1 task constantly checking for events
    would be more efficient than having 20+ tasks wasting CPU in a while
    loop.

    If I were to implement such a task, I would have to create a method of
    registering/requesting events, raising events, and waiting for events.
    I'm pretty sure that this is how the eventLib.h (library link above)
    handles the event framework.

    Now, the question is... how do I pend a task like the library above?
    How do I set a task into a pended state (versus a Suspend) and then how
    do I control my timeouts (NOWAIT, WAITFOREVER much like how Semaphores
    work?)


  4. Re: VxWorks Beginner - eventLib implementation

    On 12 Oct 2005, Alydis@gmail.com wrote:

    [snip]

    > If I were to implement such a task, I would have to create a method
    > of registering/requesting events, raising events, and waiting for
    > events. I'm pretty sure that this is how the eventLib.h (library
    > link above) handles the event framework.


    > Now, the question is... how do I pend a task like the library above?
    > How do I set a task into a pended state (versus a Suspend) and then
    > how do I control my timeouts (NOWAIT, WAITFOREVER much like how
    > Semaphores work?)


    There is no event library for vxWorks. Events are like a "multiple
    sematics semaphore". PSOS and other OS's have event type
    functionality.

    I think that the eventLib.h you are talking about has something to do
    with WindView. This is a completely different concept than what you
    want.

    Signals are asynchronous; this is probably why some web sights
    discourage them. Events will be synchronous, which means that your
    event handling won't be able to "prioritize" events [you cann't
    interrupt in the middle of event handling code to handle a higher
    priority event].

    Most GUIs are event based. Zinc and WindML are for example. In these
    cases, the programmers used the selectLib to wait on multiple
    files/sockets. This is also the party line given by WRS. Supposedly
    selectLib was better than an event library. However, I think that an
    event library would have less overhead...

    Anyways, you can create an event library with a single semaphore and
    some atomic operations. I would do this if you have time and want the
    system to perform optimally. There are many different design patterns
    you can use to achieve this.

    If you have a lot of extra CPU cycles and/or are pressed for time, you
    can use the pipeLib and sockets to create "synthetic" files to use
    with selectLib. Actually, the selectLib is fairly efficient. I might
    use this unless you need to handle multiple events *VERY* quickly.
    However, if this is the case, an interrupt might be better?

    hth,
    Bill Pringlemeir.

    --
    Nature intended me for the tranquil pursuits of Science by rendering
    them my supreme delight. - Thomas Jefferson

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  5. Re: VxWorks Beginner - eventLib implementation

    Hello alydis,

    alydis schrieb:
    > I'm not saying that event programming and events do not exist on all
    > versions of VxWorks. What I'm stating is that eventLib.h
    > (http://www.eelab.usyd.edu.au/tornado.../eventLib.html)
    > is not available in my copy of VxWorks. This library implements a
    > couple of event functions that allows a developer to implement a
    > convenient event-driven framework into their applications.


    This is the reason why they have been added in VxWorks 5.5.


    > Since this library is not available, I'm fishing around for ideas on
    > how to implement my own event library. It would be awesome to mimick
    > this existing library, so that when I can convince my boss to purchase
    > a copy of a newer version of VxWorks, I don't have to rewrite a whole
    > lot of code to migrate over my applications.


    Since other RTOS like pSOS+ have had events since ages and Wind River
    merged with Integrated Systems, the eventlib has been ported from pSOS+
    to VxWorks 5.5. So this is the reason you don't have it in your old
    version of VxWorks. Certainly events are also supported on 6.0, 6.1 and
    future releases I am convinced.

    Since events can't be emulated via signals or semaphores efficiently,
    they have been introduced since 5.5.
    So there is no easy way to get events implemented.

    But:
    If you search for a pSOS+ compatibility library for e.g. VxWorks or
    other RTOS there is a good chance to fins out, what others invented to
    have the events in place.

    Since events are task speciffic and in pSOS+ are implemented in the
    kernel I am in doubt that you can get events easily without an update.

    I am an pSOS+ veteran and I loved events.

    > I've tried to stay away from a signal-driven event framework. I'm not
    > exactly sure why, but most websites warn to not try to use signals to
    > implement event-driven programming. The semaphore concept I used in my
    > sample code above is one idea I had, but I'm not stuck on it.
    >
    > I guess my dilemma comes from my lack of solid understanding concerning
    > the very fundamentals of the VxWorks RTOS (or any RTOS for that
    > matter). So let me ask some generic questions:
    >
    > If I'm writing an event library, is there a difference between:
    > 1) Creating a bunch of event listeners (each a seperate task) and send
    > each of these tasks into an infinite while loop and waiting on a bit to
    > set in a global variable.
    > 2) Creating a bunch of event listeners (each a seperate task) and
    > suspend each of these tasks. Then, in a seperate task, continually
    > check the status of the events. Once a requested event triggers for a
    > specific task, I would resume the task.


    This is very unefficient. see above.

    > I would think that having having 1 task constantly checking for events
    > would be more efficient than having 20+ tasks wasting CPU in a while
    > loop.
    >
    > If I were to implement such a task, I would have to create a method of
    > registering/requesting events, raising events, and waiting for events.
    > I'm pretty sure that this is how the eventLib.h (library link above)
    > handles the event framework.

    Yes, it does, but with internal data of the kernel and sheduler etc. to
    which you as a user don't have access to.

    > Now, the question is... how do I pend a task like the library above?
    > How do I set a task into a pended state (versus a Suspend) and then how
    > do I control my timeouts (NOWAIT, WAITFOREVER much like how Semaphores
    > work?)


    The only idea is to emulate via semaphores and helper tasks, one task
    for each target task.

    Hope it helps.

    --
    BaSystem Martin Raabe
    E: Martin.RaabeB-a-S-y-s-t-e-mde

  6. Re: VxWorks Beginner - eventLib implementation

    Firstly, I appreciate the detailed responses from everyone on this
    thread. You've given me a bit of insight into some of what has been
    just a confusing jumble up until now.

    I realize that an exact implementation of the eventLib is impossible
    with the VxWorks 5.2 I have here. I have no interest into trying to
    write a very complicated library to do what I need to do.

    But, if I were to emulate this eventLib (via sockets+selectLib, or
    message queues as others have done in this forum), I would want to keep
    its interface (calling statement, etc) very similar to the VxWorks 5.5
    eventLib library. If and when I find that an emulated approach is too
    inefficient, I have some "ammo," so to speak, to go up to my boss and
    ask for an upgrade.

    In truth, an emulated approach may be sufficient for my task. All my
    time-critical events are driven by the AuxClk interrupt, and are
    handled in a different way. All my other processes (console IO, etc)
    are handle via the event driver.

    This leads me one step away from a solution. Many people have
    implemented a event framework with pipeDrv + selectLib, other have done
    it with Message Queues. How does one solution compare with the other?


  7. Re: VxWorks Beginner - eventLib implementation


    Bill Pringlemeir wrote:
    > On 12 Oct 2005, Alydis@gmail.com wrote:
    >
    > [snip]
    >
    > > If I were to implement such a task, I would have to create a method
    > > of registering/requesting events, raising events, and waiting for
    > > events. I'm pretty sure that this is how the eventLib.h (library
    > > link above) handles the event framework.

    >
    > > Now, the question is... how do I pend a task like the library above?
    > > How do I set a task into a pended state (versus a Suspend) and then
    > > how do I control my timeouts (NOWAIT, WAITFOREVER much like how
    > > Semaphores work?)

    >
    > There is no event library for vxWorks. Events are like a "multiple
    > sematics semaphore". PSOS and other OS's have event type
    > functionality.
    >
    > I think that the eventLib.h you are talking about has something to do
    > with WindView. This is a completely different concept than what you
    > want.
    >
    > Signals are asynchronous; this is probably why some web sights
    > discourage them. Events will be synchronous, which means that your
    > event handling won't be able to "prioritize" events [you cann't
    > interrupt in the middle of event handling code to handle a higher
    > priority event].
    >
    > Most GUIs are event based. Zinc and WindML are for example. In these
    > cases, the programmers used the selectLib to wait on multiple
    > files/sockets. This is also the party line given by WRS. Supposedly
    > selectLib was better than an event library. However, I think that an
    > event library would have less overhead...
    >
    > Anyways, you can create an event library with a single semaphore and
    > some atomic operations. I would do this if you have time and want the
    > system to perform optimally. There are many different design patterns
    > you can use to achieve this.
    >
    > If you have a lot of extra CPU cycles and/or are pressed for time, you
    > can use the pipeLib and sockets to create "synthetic" files to use
    > with selectLib. Actually, the selectLib is fairly efficient. I might
    > use this unless you need to handle multiple events *VERY* quickly.
    > However, if this is the case, an interrupt might be better?
    >
    > hth,
    > Bill Pringlemeir.
    >
    > --
    > Nature intended me for the tranquil pursuits of Science by rendering
    > them my supreme delight. - Thomas Jefferson
    >
    > vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"


    Bill and others,
    I am not aware of the exact difference between an event and a signal.I
    was under impression what was available as events in other RTOS is
    available as Signals with Vxworks.Can you please elaborate me the
    difference between the two or point me to some links where I can get
    the difference between the two?

    Advanced thanks for your replys,
    Regards,
    s.subbarayan


+ Reply to Thread