A real world migration from TI-RTOS to the POSIX API of TI SimpleLink.

Texas Instruments migrated from the proprietary TI-RTOS to the open POSIX API.

I'm migrating a project that extensively used the TI paradigms to that POSIX API. You're my witness.

photo courtesy IKEA of Sweden: KVISSLE Letter tray, white

The blog assumes that you are a TI-RTOS user and want to adapt to the new ways of working.


Hardcore POSIX again. Moving from TI-RTOS MailBox API to POSIX message queues. Again, not too complex. The changes to the code are small.

As always, the ideas are not my own. This time I used a Stack Overflow question as guideline: https://stackoverflow.com/questions/3056307/how-do-i-use-mqueue-in-a-c-program-on-a-linux-based-system.


Message Queue


The use of a POSIX message queue is virtually identical to a TI-RTOS MailBox.

You have a task that puts info on the message queue. In our case, that is a SCPI command that tells our Programmable Electronic Load to enable or disable its input.

There's also a task that listens to the message queue and is woken up by the RTOS when a message is available on the mailbox. In our case the task that guards the Input Enable functionality.

If nothing is posted on that queue, the message is inactive and takes very little resources. Only when the SCPI command puts a message on the queue, the task gets processor time to consume the message and go back to sleep.


In the spirit of this blog series, I don't show the original TI-RTOS code. You can find it back by surfing to github:




Let's first look at the consumer side - the task that sleeps unless there's a message arriving. The first part of that task initialises the queue in read mode. The while() loop sleeps and reacts on messages.

#include <mqueue.h>



    mqd_t mq;
    struct mq_attr attr;

    attr.mq_flags = 0;
    attr.mq_maxmsg = 1;
    attr.mq_msgsize = MSGINPUTENABLE_SIZE;
    attr.mq_curmsgs = 0;
    mq = mq_open(QUEUE_NAME_INPUTENABLE, O_CREAT | O_RDONLY, 0644, &attr);

    while (1) {
        ssize_t bytes_read;
        bytes_read = mq_receive(mq, (char *)&d_msg, MSGINPUTENABLE_SIZE, NULL);

        /* wait for mailbox to be posted by writer() */
        if (bytes_read) {
            d_iotxBuffer[1] = d_msg.value ? 0x3F : 0xFF; // bit 7 low is output enable.
            if (! I2C_transfer(i2c_implGetHandle(), &d_ioi2cTransaction)) {
            } else {
                bInputEnable_State = d_msg.value;


The sender side is also straightforward. We post a message when we want to enable or disable our instrument's input.



void eloadInputEnable(bool bEnable) {
    MsgInputEnable pMsg;

    // value has to be validated before it arrives here. We assume it's valid
    pMsg.value = bEnable;
    /* enqueue message */
    mqd_t mq;
    mq_send(mq, (char *)&pMsg, MSGINPUTENABLE_SIZE, 0);


In this case, we open the queue for writing. I don't close the queue - not sure if that's correct or if I'm leaking resources. Shout out in the comments if this is wrong.

To understand the code a little better, here's the declaration of the message structure:


#define QUEUE_NAME_INPUTENABLE "/inputenable_queue"

typedef struct MsgInputEnable {
     bool value;
} MsgInputEnable;

// for TI-RTOS message size, use the structure size:
#define MSGINPUTENABLE_SIZE (sizeof(MsgInputEnable))


The whole setup isn't very different from what's happening in TI-RTOS. And the functionality is identical.

Very little resources are necessary to support the mechanism. No loops are polling for input. The  microcontroller time is either spent on another task or the processor goes into a well deserved sleep.


Related Blog
Switch from TI-RTOS to SimpleLink POSIX: Threads and Semaphores
Switch from TI-RTOS to SimpleLink POSIX: EEPROM API

Switch from TI-RTOS to SimpleLink POSIX: From MailBox to Message Queue

Switch from TI-RTOS to SimpleLink POSIX: LCD Display Driver
Switch from TI-RTOS to SimpleLink POSIX: Sleep when Idle