| Subject: |
|
Re: Immediate transition to substate within ENTRY handler |
| Name: |
|
Harry |
| Date Posted: |
|
Feb 11, 08 - 4:07 PM |
| Email: |
|
harrymc@decisions-and-designs.com.au |
| Message: |
|
Thanks Miro
Your suggestions were the mental nudge I needed to rework the approach; posted back here in case it is useful for other designs.
After reading your reply I pondered if I'd thought enough about what I wanted Widget to do. To clarify the requirements, I wrote a storyboard:
-//-
A Widget receives a Config event and immediately starts responding to incoming buffers and free outgoing buffers to process data between the two.
If an external task or the Widget task issues a Restart then the Widget abandons any partial processing and restarts processing when a new input buffer and free output buffer are available (neglected to explain the external use of Restart earlier).
A Config0 event returns the Widget to an "unconfigured" or reset state and processing stops (another detail I omitted).
-//-
You explained that "New information is provided only through external events, and self posting does not provide any _new_ information to the state machine. ..."
From your comment, the only _new_ information to get the machine processing is the Config event which _should_ be sufficient to move Widget to immediately start processing.
I also realised that WidgetRun was really only serving to handle Restart events not handled by the three sub-states to provide common behaviour.
So if I merged the WidgetIdle and WidgetRun states together (renamed Widget) some handy commonality emerged. As the diagram below shows, the only difference in behaviour between Config (which could also be called Start) and the Restart event is that Config sets up the configuration of Widget operating
parameters and also the hardware (enableWidget()).
![]()
src="http://www.decisions-and-designs.com.au/images/electron/widget_simpler.gif"
alt="Improved Widget HSM diagram">
Config0 turns off the hardware with disableWidget(). I've also deleted clearConfigData() since it is private data and is therefore unused while the HSM is stopped waiting for another Config; so why bother to clear it.
Given that Restart means "start using a new incoming data buffer" I can see that resetting the buffer index (idx) fits into Restart behaviour.
The common behaviour means I could use a drop-through for the new implementation (see code below). While I can see on the diagram the behaviour in Widget state is common , I'm wondering if there is any way to rework the UML so it articulates the final code implementation ? I'd prefer
this than have tidier code being disallowed because the UML diagram prevents it :)
static QSTATE Widget(Widget *me)
{
switch (Q_SIG(me)) {
case Q_INIT_SIG: {
return (QSTATE)0;
}
case Q_EXIT_SIG: {
return (QSTATE)0;
}
case Q_ENTRY_SIG: {
return (QSTATE)0;
}
case Q_CONFIG0_SIG: {
widgetDisable();
return (QSTATE)0;
}
case Q_CONFIG_SIG: {
setConfigData();
widgetEnable();
/* drop through into Restart handler */
/* The rest of the Config behaviour is
* identical to Restart */
}
case Q_RESTART_SIG: {
me->idx = 0;
if (!haveData()) {
Q_TRAN(&Widget_awaitInputData);
return (QSTATE)0;
}
if (!haveBuffer()) {
Q_TRAN(&Widget_awaitOutBuffer);
return (QSTATE)0;
}
Q_TRAN(&Widget_processData);
return (QSTATE)0;
}
}
return (QSTATE)&Widget_idle;
}
static QSTATE Widget_processData(Widget *me)
{
switch (Q_SIG(me)) {
case Q_INIT_SIG: {
return (QSTATE)0;
}
case Q_EXIT_SIG: {
return (QSTATE)0;
}
/* ENTRY has identical behaviour to ChunkReminder event so .. */
case Q_ENTRY_SIG: /* .. drop through into ChunkReminder handler */
case Q_CHUNKREMINDER_SIG: {
if (!endOfBuffer(me->idx)) {
processData(me->idx);
me->idx += CHUNK_SIZE;
}
if (endOfBuffer(me->idx)) {
post(Q_RESTART_SIG);
return (QSTATE)0;
}
post(Q_CHUNKREMINDER_SIG);
return (QSTATE)0;
}
}
return (QSTATE)&Widget_run;
}
I've also deleted the (incorrect) self-transition ChunkReminder. I misunderstood that the internal transition was already documented inside the state.
Thanks for your feedback. A close proximity to this design is something I can use for quite a few processing tasks.
All the best
Harry McNally |
|
Replies:
|
|
|
|
|
Reply
Forum
bravenet.com