3 State Machine Design Pattern

Here are the initialization of all three application tasks:

void APP_LED_Initialize ( void )
{
    /* Place the App LED state machine in its initial state. */
    app_led_data.state = APP_LED_STATE_INIT;

    /* TODO: Initialize your application's LED state machine and other
     * parameters.
     */
    app_led_data.TimerCount = 0;
}


void APP_KEY_Initialize ( void )
{
    /* Place the App S2 state machine in its initial state. */
    app_key_data.state = APP_KEY_STATE_INIT;

    /* TODO: Initialize your application's S2 state machine and other
     * parameters.
     */
    app_key_data.DebounceCount = 0;
}


void APP_UART_Initialize ( void )
{
    // Place the App KEY state machine in its initial state.
    app_uart_data.state = APP_UART_STATE_INIT;

    // TODO: Initialize your application's KEY state machine and other
    // parameters.

    app_uart_data.RxChar = 0;
    app_uart_data.TxChar = 0;
}

DecodeSerial is a function which decodes the serial input and responds appropriately.

• If an ‘A’ is received, then the latest Analog-to-Digital (ADC) value is transmitted
• If an ‘H’ is received, then the “Hello World!” message is transmitted

void DecodeSerial( void )
{

    switch ( app_uart_data.RxChar )
    {
        // 'H' print Hello World!
        case 'H':
        case 'h':
        {
        printf("Hello World! \n\r");
        break;
        }

        default :
            break;
    }
}

void APP_UART_Tasks ( void )
{
    // Check the application's current state.
    switch ( app_uart_data.state )
    {
        // Application's initial state.
        case APP_UART_STATE_INIT:
        {
            app_uart_data.state = APP_UART_STATE_WAIT;
            break;
        }

        // TODO: Implement your application state machine.
        case APP_UART_STATE_SEND:
        {
            if (UART1_IsTxReady()) // TXREG is empty?
            {// yes, then load value to be transmitted in TXREG
                U1TXB = app_uart_data.TxChar;
                app_uart_data.state = APP_UART_STATE_WAIT;
            }
            break;
        }
        case APP_UART_STATE_GET:
        {
            app_uart_data.RxChar = U1RXB; // Read RCREG
            U1RXB = 0;                  // Clear RCREG
            DecodeSerial();             // Decode value received
            app_uart_data.state = APP_UART_STATE_WAIT; // goto WAIT
            break;
        }
        case APP_UART_STATE_WAIT:
        {
            if (UART1_IsRxReady()) // is a char received?
                // yes, then go to GET state
                app_uart_data.state = APP_UART_STATE_GET;
            break;
        }

        // The default state should never be executed.
        default:
        {
            // TODO: Handle error in application's state machine.
            break;
        }
    }
}

This design pattern is ideal for managing complex, multitasking, and time-sensitive operations. Porting from state machine to RTOS can be smooth due to their complementary nature.

An RTOS-based control flow in embedded applications, ideal for managing complex, multitasking, and time-sensitive operations, facilitates efficient task scheduling and resource management, contrasting with the state machine's linear approach, focusing on internal states and transitions. Key differences include:

1. Task Management - RTOS handles multiple concurrent tasks, while state machines manage a single control flow.

2. Time-Critical Operations - RTOS meets real-time constraints, ensuring predictable execution, unlike state machines.

3. Resource Utilization - RTOS efficiently allocates resources across tasks, unlike state machines centering on logic within states.

4. Complexity and Overhead - Implementing RTOS is an intricate process but offers powerful capabilities for complex applications, whereas state machines are more straightforward.

Porting from a state machine to an RTOS can be smooth due to its complementary nature, as the modularity and defined transitions of state machines align well with the task-based and event-driven model of RTOS, including:

• Modular Design - The distinct states and transitions of the state machines fit the task structure of the RTOS
• Defined State Transitions - Easily managed with RTOS features like message queues and semaphores
• Scalability and Expandability - State machines can expand to multitasking with RTOS
• Event-Driven Nature - Aligns with the RTOS way of handling events through interrupts and callbacks
• Task Prioritization and Timing - Critical in RTOS for timely execution
• Enhanced Resource Management - RTOS optimizes resource use across state machine tasks

However, using RTOS for simple applications can lead to unnecessary complexity and resource overhead.

1. Resource Utilization - RTOSs are built for handling multiple tasks, complex scheduling and resource allocation, potentially leading to unnecessary overhead of memory and CPU usage in a simple application which does not fully utilize these capabilities.

2. Complexity - An RTOS adds layers of complexity in development, requiring a grasp of concepts such as task scheduling, inter-task communication and real-time constraints. This additional complexity may not offer proportional benefits for straightforward applications.

3. Development Time - Setting up an RTOS involves various steps, such as configuring the system, defining tasks and managing their interactions, which can increase the development time compared to simplified control structures.

4. Debugging and Maintenance - Troubleshooting and maintaining an RTOS-based application can be more challenging due to the concurrent nature of tasks and interactions between them. This level of complexity is often unnecessary for simple applications.

A state machine-based control flow could be considered an ‘RTOS-ready’ architecture. While MCC Melody does not provide direct RTOS support, if your application has reached the required level of complexity, consider MPLAB Harmony, which has full support for third-party solutions like FreeRTOS™ and Eclipse ThreadX.