Quantum Leaps Discussion Forum

David Smoot

Dec 7, 07 - 8:13 AM

2 beginner questions, multiple timers and sleep

I'm working on a fairly large and complex system and I'm looking at QF to solve a lot of my issues. I sent you guys a license information request yesterday.

1. Can a FSM have multiple timers that don't interfere with each other? For example I have event A with some data and event B with some data and I want to publish one at 1Hz and another at 2Hz. Can I just arm two timers and go? Will the firing of the first timer change the behavior of the second timer?

2. One thing my system does is send CAN messages to another system controlling a motor. The other system can only process 1 message every 100mS and has no buffer. Can I "sleep" in my state machine safely for 100mS every time I send a CAN message or does that violate the "Run To Completion" rules?

Thanks,
David Smoot
Wyle Laboratories

David Smoot

Dec 7th, 2007 - 9:15 AM

Re: 2 beginner questions, multiple timers and sleep

One more beginner question:

Can I do a conditional in my initial function or does it have to be to one state only?

Example:

if (something_worked)
{
Q_INIT(readystate)
}
else
{
Q_INIT(errorstate)
}
David

Miro Samek

Dec 7th, 2007 - 2:13 PM

Re: 2 beginner questions, multiple timers and sleep

=================================================
Question 1:

You can have as many timers (time events) as you want. (Time event is a more “correct” UML terminology, but means the same thing.) Each time event represents one outstanding timeout request, and you can have many such requests pending in parallel.

In QF, the QTimeEvt constructor takes the signal argument, so that you assign a signal to a time event at instantiation and you should not change it later. In your case, you can have two time events with two different signals. And, yes, you can arm the two time events and let them go. They will not interfere with one another. The code might look as follows (in C):



enum MySignals {

    . . .

    TIMEOUT_1HZ_SIG,

    TIMEOUT_2HZ_SIG,

    . . .

};



. . .

typedef struct MyActiveObject {

    QActive super;

    . . .

    QTimeEvt te_1Hz;

    QTimeEvt te_2Hz;

   . . .

};



void MyActiveObject_ctor(MyActiveObject *me) {

    QActive_ctor(&me->super, &MyActiveObject_initial);

    QTimeEvt_ctor(&me->te_1Hz, TIMEOUT_1HZ_SIG);

    QTimeEvt_ctor(&me->te_2Hz, TIMEOUT_2HZ_SIG);

}



QSTATE MyActiveObject_stateXYZ(MyActiveObject *me, QEvent const *e) {

    switch (e->sig) {

        case Q_ENTRY_SIG: {                  /* arm the time events */

            QTimeEvt_postEvery(&me->te_1Hz, (QActive *)me, BSP_TICKS_PER_SEC);

            QTimeEvt_postEvery(&me->te_2Hz, (QActive *)me, BSP_TICKS_PER_SEC/2);

            return (QSTATE)0;

        }

        case Q_EXIT_SIG: {    /* disarm the time events */

            QTimeEvt_disarm(&me->te_1Hz);

            QTimeEvt_disarm(&me->te_2Hz);

            return (QSTATE)0;

        }

        . . .

        case TIMEOUT_1HZ_SIG: /* handle 1Hz timeout */

        . . .

        case TIMEOUT_2HZ_SIG: /* handle 2Hz timeout */

        . . .

    }

    return (QSTATE)&MyActiveObject_stateABC; /* superstate */

}

=================================================
Question 2:

I would advise against “sleeping” (blocking) a state machine for entire 100ms. You can use a one-shot time event to wake you up. That’s exactly what they are for.

Strictly speaking, blocking does not violate the RTC rule, but extends the RTC step and makes the whole state machine unresponsive for that much time.

Of course, efficient blocking requires a multitasking kernel. Without a kernel, if you busy-wait, you tie up the whole CPU and no state machine can respond to events.

In general, event-driven programming is about writing “non-blocking” code, whereas by "blocking code" I understand waiting in-line for some event to occur.

=================================================
Question 3:

The UML spec is quite clear about this one. You cannot have multiple initial transitions, or what’s equivalent, you cannot use a choice pseudostate in an initial transition.

You should handle this case not in an initial transition, but rather in a regular transition (that can have a choice pseudostate). Please note that only events bring new information into the system (as opposed to initial transitions, entry, or exit actions that *don’t* bring any new information). The point is that the “something_worked” condition is actually known earlier, when some event arrived. You could use this event as the trigger for a conditional regular transition.

Miro

David Smoot

Dec 7th, 2007 - 2:51 PM

Re: 2 beginner questions, multiple timers and sleep

Thank you very much.

QF is very cool. Please get back to me on the license info request, this is software worth supporting.

David

Author	Comment
David Smoot Dec 7, 07 - 8:13 AM	2 beginner questions, multiple timers and sleep I'm working on a fairly large and complex system and I'm looking at QF to solve a lot of my issues. I sent you guys a license information request yesterday. 1. Can a FSM have multiple timers that don't interfere with each other? For example I have event A with some data and event B with some data and I want to publish one at 1Hz and another at 2Hz. Can I just arm two timers and go? Will the firing of the first timer change the behavior of the second timer? 2. One thing my system does is send CAN messages to another system controlling a motor. The other system can only process 1 message every 100mS and has no buffer. Can I "sleep" in my state machine safely for 100mS every time I send a CAN message or does that violate the "Run To Completion" rules? Thanks, David Smoot Wyle Laboratories Email: dsmoot@wylehou.com
David Smoot Dec 7th, 2007 - 9:15 AM	Re: 2 beginner questions, multiple timers and sleep One more beginner question: Can I do a conditional in my initial function or does it have to be to one state only? Example: if (something_worked) { Q_INIT(readystate) } else { Q_INIT(errorstate) } David Email: dsmoot@wylehou.com
Miro Samek Dec 7th, 2007 - 2:13 PM	Re: 2 beginner questions, multiple timers and sleep ================================================= Question 1: You can have as many timers (time events) as you want. (Time event is a more “correct” UML terminology, but means the same thing.) Each time event represents one outstanding timeout request, and you can have many such requests pending in parallel. In QF, the QTimeEvt constructor takes the signal argument, so that you assign a signal to a time event at instantiation and you should not change it later. In your case, you can have two time events with two different signals. And, yes, you can arm the two time events and let them go. They will not interfere with one another. The code might look as follows (in C): enum MySignals { . . . TIMEOUT_1HZ_SIG, TIMEOUT_2HZ_SIG, . . . }; . . . typedef struct MyActiveObject { QActive super; . . . QTimeEvt te_1Hz; QTimeEvt te_2Hz; . . . }; void MyActiveObject_ctor(MyActiveObject me) { QActive_ctor(&me->super, &MyActiveObject_initial); QTimeEvt_ctor(&me->te_1Hz, TIMEOUT_1HZ_SIG); QTimeEvt_ctor(&me->te_2Hz, TIMEOUT_2HZ_SIG); } QSTATE MyActiveObject_stateXYZ(MyActiveObject me, QEvent const e) { switch (e->sig) { case Q_ENTRY_SIG: { / arm the time events / QTimeEvt_postEvery(&me->te_1Hz, (QActive )me, BSP_TICKS_PER_SEC); QTimeEvt_postEvery(&me->te_2Hz, (QActive )me, BSP_TICKS_PER_SEC/2); return (QSTATE)0; } case Q_EXIT_SIG: { / disarm the time events / QTimeEvt_disarm(&me->te_1Hz); QTimeEvt_disarm(&me->te_2Hz); return (QSTATE)0; } . . . case TIMEOUT_1HZ_SIG: / handle 1Hz timeout / . . . case TIMEOUT_2HZ_SIG: / handle 2Hz timeout / . . . } return (QSTATE)&MyActiveObject_stateABC; / superstate / } ================================================= Question 2: I would advise against “sleeping” (blocking) a state machine for entire 100ms. You can use a one-shot time event to wake you up. That’s exactly what they are for. Strictly speaking, blocking does not violate the RTC rule, but extends the RTC step and makes the whole state machine unresponsive for that much time. Of course, efficient blocking requires a multitasking kernel. Without a kernel, if you busy-wait, you tie up the whole CPU and no state machine can respond to events. In general, event-driven programming is about writing “non-blocking” code, whereas by "blocking code" I understand waiting in-line for some event to occur. ================================================= Question 3: The UML spec is quite clear about this one. You cannot have multiple initial transitions, or what’s equivalent, you cannot use a choice pseudostate in an initial transition. You should handle this case not in an initial transition, but rather in a regular transition (that can have a choice pseudostate). Please note that only events bring new information into the system (as opposed to initial transitions, entry, or exit actions that don’t* bring any new information). The point is that the “something_worked” condition is actually known earlier, when some event arrived. You could use this event as the trigger for a conditional regular transition. Miro Email: miro@quantum-leaps.com Website: http://www.quantum-leaps.com
David Smoot Dec 7th, 2007 - 2:51 PM	Re: 2 beginner questions, multiple timers and sleep Thank you very much. QF is very cool. Please get back to me on the license info request, this is software worth supporting. David Email: dsmoot@wylehou.com

	Quantum Leaps Discussion Forum Search the Forum for answers or post your questions to the Quantum Leaps community
Return to Website