Design Patterns for Code Generation#

Good generated code starts with deliberate design decisions — not with tweaking the code generator afterwards. This page collects the patterns that matter most when working with SinelaboreRT. Use it as a quick reference when planning a new state machine or reviewing an existing model.

The patterns below are not classical GoF design patterns (Strategy, Observer, …). Sinelabore replaces many of them by generating the state machine logic directly. Instead, this guide covers three layers:

1. Architecture patterns — how state machines integrate into your system
2. Code generation patterns — how generated code is structured and configured
3. UML modeling patterns — how the state diagram should be built

For background on architecture alternatives see also the Designers Toolbox overview. For UML element details see State Machines in a Nutshell.

Decision Guide#

Use this flowchart to pick an architecture pattern first, then refine code generation and modeling choices.

flowchart TD
    Start([New state machine design]) --> RTOS{RTOS available?}
    RTOS -->|Yes| AO[RTOS Active Object<br/>one task per state machine]
    RTOS -->|No| LP{Low power required?}
    LP -->|Yes| LPE[Low-Power Event-Driven<br/>sleep until event or timeout]
    LP -->|No| IRQ{Run inside IRQ?}
    IRQ -->|Yes| IRQSM[State Machine in Interrupt]
    IRQ -->|No| Queue{Events from IRQ,<br/>timers, or other SMs?}
    Queue -->|Yes| MLQ[Main Loop + Event Queue]
    Queue -->|No| ML[Main Loop Polling]

    AO --> Inst{Multiple instances<br/>of same machine?}
    MLQ --> Inst
    LPE --> Inst
    ML --> Inst
    IRQSM --> Single[Single Instance pattern]

    Inst -->|Yes| Obj[Object pattern]
    Inst -->|No| Single
    Obj --> Hide{Hide implementation<br/>from other modules?}
    Single --> Hide
    Hide -->|Yes| Opq[Opaque Object pattern]
    Hide -->|No| Done([Configure backend<br/>and model transitions])
    Opq --> Done

1. Architecture Integration Patterns#

These patterns describe how generated state machines are called, how events arrive, and how timing is handled. Detailed examples and code snippets are in the Designers Toolbox overview.

Pattern notes#

Main Loop + Event Queue is the most versatile bare-metal pattern. Each state machine should have its own queue. IRQ handlers and timer callbacks push events; the main loop pulls and dispatches them.

RTOS Active Object maps one state machine to one task. The task blocks on a message queue until an event arrives, then calls the generated state machine function. The pattern is RTOS-independent — only queue and task APIs differ.

State Machine in IRQ requires backend configuration without instance parameters. Set StateMachineFunctionPrefixCFile and HsmFunctionWithInstanceParameters=no as described in the IRQ section.

2. Code Generation Patterns#

These patterns are selected through backend configuration (codegen.cfg). They apply primarily to the C backend but similar concepts exist for C++, C#, and other targets.

Example: Object vs. Single Instance#

/* Object pattern — multiple instances possible */
void oven(OVEN_INSTANCEDATA_T *instanceVar, OVEN_EVENT_T msg);

OVEN_INSTANCEDATA_T ovenA = OVEN_INSTANCEDATA_INIT;
OVEN_INSTANCEDATA_T ovenB = OVEN_INSTANCEDATA_INIT;
oven(&ovenA, evStart);
oven(&ovenB, evStart);

/* Single instance — typical for IRQ context */
#pragma vector=UART0TX_VECTOR
__interrupt void uart_irq(void) {
    uart_sm(evRxByte);
}

Generate a full configuration template with:

java -cp path_to_bin_folder/* codegen.Main -l cx -gencfg > codegen.cfg

3. UML Modeling Patterns#

How you draw the state diagram directly affects code size, readability, and correctness of the generated output. See State Machines in a Nutshell for syntax details.

Transition syntax reminder#

Event-based transition:

evDoorClosed[timer_preset() > 0]/timer_start()

Condition-based transition (no event):

[DI0 == true]/led_on()

Modeling depth#

The code generator is tested with up to four hierarchy levels. If your diagram goes deeper, reconsider the design — flatten or split into cooperating state machines.

Keep all actions (entry, exit, do, transition) short and non-blocking. Long-running work belongs outside the state machine, triggered by an action that starts it and completed via a callback event.

4. Application Patterns (Examples)#

These real-world examples combine architecture, backend, and modeling choices. Use them as templates for your own designs.

5. Anti-Patterns#

Avoid these common mistakes. They lead to bloated generated code, subtle runtime bugs, or models that are hard to maintain.

Run the built-in model check before code generation to catch structural issues early. For static analysis of generated C/C++ code see Static Source Code Checkers.

Quick Checklist#

Before generating code, verify:

• Architecture pattern chosen (main loop, queue, RTOS, IRQ, low power)
• Backend pattern matches instance count (Object, Single Instance, Opaque)
• Event mode matches problem (event-driven vs. condition-driven)
• Composite states have default substates
• Choices have an else path
• Actions are short and non-blocking
• Hierarchy depth ≤ 4 levels
• Model check passed

This page is a living catalog. As new backend features and examples are added, corresponding patterns will be documented here.