Last month, we spoke with the co-founders of IOTAS, Sce Pike, CEO and Jeremy Steinhauer, VP of Data Services and learned how multi-family residential buildings, otherwise known as apartments, have recently stepped up their smart home game. IOTAS, which stands for IoT as a Service, has been a key player in making this happen after creating a smart home platform for apartment renters several years ago. The platform, built for residents, property owners and installers, provides residents with a seamless IoT solution that monitors apartment unit systems, including thermostats, motion detectors, security and lighting. The solution is so easy to use renters have been asking to take it with them when moving out of their apartment.

IOTAS has grown rapidly since its inception four years ago and was recently recognized by the Bay Area’s Start-up Grind as the 2019 Start-up of the Year. The company’s install base has grown to 100,000 smart devices in more than 70 communities.

Read more below about our conversation with IOTAS and how the company tapped into a major new market opportunity for smart home technologies.

 

How did IOTAS get started?

Sce: In 2014, a real estate developer in Portland approached me and explained he was looking for technology differentiation for his apartment property. My background is in mobile design development, and I had recently sold my first mobile consumer company, so the idea of focusing on the technology experience in the real estate market was intriguing. I quickly realized the $5 billion real estate market had the potential to scale a new technology extremely fast.

I went ahead and recruited Jeremy as my co-founder and we immediately built out a technology solution focused exclusively on apartments. We installed 40 smart home devices in a 1,000 square foot apartment unit to create a true smart home experience, not something that was cumbersome to put together. We wanted to create a move-in ready solution that just worked. We then took the idea out on a real estate conference roadshow, and it became obvious fast that we had created the next amenity commercial property owners were seeking. Property owners knew they had to provide technological advancements in their buildings to meet the demands of millennials and GenZ.

Once we received this feedback, we scaled the solution exponentially over the next few years, with our installs growing by 500 percent last year alone. We see the potential of disruption for all multi-family properties within five years, with all of them having some level of smart technology.

How did the real estate market know they needed this?

Sce: The real estate industry is 13 percent of the U.S. GDP and does a great deal of collective research. Property companies understand their own demographic very well, and at the time they were seeing technology become pervasive across their tenants’ lives, but the shift wasn’t reflected in apartment buildings. The industry saw this void as an opportunity to create an edge for their properties. Five years ago, when we first entered the market, the conferences were only starting to talk about smart home technology, but now smart apartments are mainstream, and the vast majority of properties are allocating budgets to incorporate smart home technologies.

Tell me about your product.

Jeremy: We’re focused on making the smart home experience extremely easy for residents and property managers. We work with property developers and managers to install smart devices in apartments with a suite of applications, including door locks, thermostats, light switches, power outlets and sensors to monitor leaks, motion, temperature, etc. Residents simply download the app to their phone and get a smart home out of the box. We also created automated defaults, like “out for the day” or “welcome home,” which set up preferred systems for that specific time period.

The second application is geared towards property managers to improve efficiencies – it’s the tool managers use to link the residential units and create their own automations for vacant units, such as temperature, appliances and lighting. Property managers can use it to immediately set-up for tours of certain units by turning on lights, setting the thermostat to a comfortable temperature, etc. on and off before or after. The application also has alerts for property managers if something is amiss, such as extremely high or low temperatures or humidity levels for vacant units.

The third application is the installer and/or auto-provisioning application. During our initial foray into smart apartment, we were installing 40 devices and quickly learned that commissioning that many devices to a gateway was a painful process and not scalable. We then spent the next few years perfecting the provisioning process. Now we have several auto-provisioning patents, where we have reduced the time to install devices for an installer from one hour to 15 minutes.

The final application is our internal application – how we administrate the system and create the data around the buildings and users.

Have you ever thought about going beyond multi-family homes?

Sce: From the onset, we have been focused on the multi-family market, for a variety of reasons. The economy of scale is a big reason – we didn’t want to sell one device at a time, we wanted to sell to buildings and make installations quickly. It’s much easier to design a solution for multiple homogenous units versus custom homes.

Though we have had many residents leave their apartments and ask how they can take IOTAS with them – so much so, that we’re now working on a way for residents to be able to upgrade their systems and go on a subscription basis to take IOTAS into their new home. This new solution is on our roadmap and we’re hoping to offer it by the end of this year.

How does Silicon Labs fit into your product?

Right now, we’re using the Z-Wave 500 Series Module solution and we are using the Z-Wave 700 Series for our next generation product to be rolled out later this year. We’re also considering using Zigbee in the future for wireless, so we’re using a Silicon Labs Zigbee module as we figure out a potential software stack for a Zigbee-based application. All of the end nodes are controlled by Z-Wave; we don’t have any internal connections over Wi-Fi. The Wi-Fi is purely used to connect the hub to our cloud.

Why did you decide to use the Z-Wave hub?

Jeremy: We started with Zigbee, but the standards were not there yet, as the devices weren’t all interoperable. The decision to use Z-Wave was also driven by the cost of each product. Having the ability to work with something like Z-Wave right out of the box with standardized protocols was a big selling point, as well.

Where do you IoT going in the next 5-8 years?

Jeremy: We’re extremely focused on the user experience, and we knew early on that we didn’t just want to be remote control for the home. In that same vein, I think that’s where IoT is headed – the more interconnectivity among devices, the richer the home experience can be. We see this going beyond the home, where people can take the experience with them. The smart home experience isn’t just about building profiles around people within the four walls that they live in, but taking the experience everywhere they go in the living world, such as their car, workplace, hotels, and even vacations.

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 application and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

 

Introduction

There are different levels of safety to consider when developing a real-time system.

Safety Critical

• Systems whose failure may result in death/serious injury, loss or damage to property or environmental harm.
• Typically, has well defined specifications for product certification and release (e.g. DO-178, IEC 61508, IEC 62304)
• Usually an expensive and time-consuming process to release a product.

Non-Safety Critical

• System failures are not directly related to catastrophic events.
• Minimal or no certification required for product release.

Even though a majority of products may fall under the non-safety critical system category, it doesn’t mean a safety critical design pattern shouldn’t be considered when developing a real-time system. Designing an application using safety critical components can make a product more robust and reliable.

There are two properties of a system that are commonly considered in safety critical designs:

• Safety – System does not create accidents, injuries, loss of life or destruction of property.
• Reliability – System runs for long periods of time without error.

These two properties are not mutually exclusive. A system that is considered safe may fail as long as it is able to recover and operate in a manner that does not cause accidents; it is just considered unreliable. On the other hand, a system that can continue to run without error but operates unsafely is a reliable, but unsafe system.

There are many software architectural patterns that a developer can use to help improve a system’s safety and reliability. While the main focus of this article is on one specific pattern (Watchdog Pattern), these are a few other patterns you may come across when researching safety critical design:

• Dual Channel – Multiple channels perform the same operations and compare results
• Monitor-Actuator – Separate channels for actuators performing actions and monitors keeping track of the actuator
• Watchdog Pattern – Software or hardware component that requires signals from other parts of the system on a periodic basis.
• Safety Executive – Centralized coordinator to monitor system safety. Typically incorporates a watchdog, build-in tests, and monitor actuator or dual channel patterns.

This article will focus on implementing a watchdog pattern using a mix of software and hardware.

 

Hardware Watchdog

A standard feature on EFM32 and EFR32 microcontrollers is a hardware watchdog. The hardware watchdog is a timer that when enabled, constantly counts up. The watchdog timer has a user configured timeout value that the application is responsible for “feeding” (clearing) the watchdog counter before the counter reaches that value. If the watchdog reaches the configured time value, a system reset will occur. The assumption is because the application did not feed the watchdog in time, an error has occurred in the system and it must be reset.

 

The hardware watchdog pattern works well for super-loop applications or in RTOS applications where only one task needs to be monitored and a system-wide reset would not negatively affect other tasks in the system. Complications arise when you wish to ensure multiple tasks are running as expected. One way to solve this problem is to implement a software watchdog that is responsible for handling the hardware watchdog.

This is a simplified overview of the hardware watchdog timer available on EFM32 and EFR32. For more detailed on the EFM32 & EFR32 watchdog timers, Series 0 can be found here and Series 1 can be found here.

 

Software Watchdog

A software watchdog pattern is a safety design pattern that allows for the monitoring of multiple tasks in an RTOS application. It is typically used in conjunction with a hardware watchdog, but in cases where a hardware watchdog is not available, the software watchdog can be responsible for performing the system reset.

Micrium OS Kernel provides two different kernel services that can be used to implement a software watchdog: Event Flags and Message Queues. For applications that have 32 tasks or less, an Event Flag is an ideal kernel service to use due to the Event Flag being able to monitor 32 unique bits. For applications with more than 32 tasks to be monitored, either multiple flag groups are needed or tasks can send unique values via a Message Queue to periodically check in.

 

In the image above, each task is represented with a unique bit in the Event Flag Group. The Event Flag is configured to pend on almost all bits of the Event Flag Group and has a timeout configured. If every task posts to the Event Flag before the timeout value is reached, the Event Flag pend returns with RTOS_ERR_NONE, the software watchdog will feed the hardware watchdog and then call pend on the Event Flag again.

If one or more tasks do not post to the Event Flag before the timeout value is reached, the Event Flag pend will return with RTOS_ERR_TIMEOUT. Also, the return value of the pend call will tell you what tasks have and have not checked in. Then with that information the software watchdog can make the decision on whether or not it should feed the hardware watchdog or let it reset the system.

 

Implementing a Software Watchdog in the Kernel 201 Application

The rest of this article will refer to the Kernel 201 Dynamic Multiprotocol Application. It is recommended to download the project to follow along. There are three files related to the software watchdog implementation: lab.h, lab_main.c and lab_wdog.c.

lab.h

The lab.h file is the centralized location for the application’s configuration parameters such as task priorities, stack sizes, message structures and enums. More detail on lab.h can be found in the blog Kernel 201: Task Architecture & Communication.

#define  LAB_TASK_BLUETOOTH 0x01
#define  LAB_TASK_PROP      0x02
#define  LAB_TASK_LED       0x04
#define  LAB_TASK_BTN       0x08

 

The defines above can be found in lab.h and are used as unique identifiers for each task in the system that will be monitored by the software watchdog. Each value will represent a bit in the Event Flag Group bitfield.

 

lab_main.c

When Micrium OS Kernel is initialized and started in main(), its common to only create one task before calling OSStart(). This is typically done to allow for the statistics task to get a baseline reading of the system at idle before other tasks are created.

In many sample applications the first task created is called the startup task because it is responsible for creating the rest of the tasks in the system and “starting up” the application. This is a poor naming choice for a task as after the startup task creates the other tasks in the system, some examples delete the startup task. What many do not realize is calling OSTaskDel() does not free up any resources related to the task. If the application does not know to access the startup task's stack and TCB, that memory sits unused.

It is not recommended to call OSTaskDel() on startup tasks. A better solution is to use the task for monitoring the system or repurpose the task for another task in the system.

Instead of calling it a startup task, the Kernel 201 Application calls it a system task. It could also be called the watchdog task since the software watchdog will run out of the system task. After the application has been initialized and all of the other tasks have been created, the last call in the labSystemTask function is:

labWDOGTask();      // Run the WDOG task. This call does NOT return

 

Rather than creating a new task for the watchdog, the application uses the system task to run the watchdog.

 

lab_wdog.c

The software watchdog file is very straightforward with only three functions: labWDOGInit(), labWDOGTask() and labWDOGFeed().

labWDOGInit()

The init function initializes the hardware watchdog (but does not enable it yet) and creates the Event Flag for the software watchdog.

labWDOGTask()

The software watchdog task operates as follows:

while(1) {
    OSFlagPend(&labWDOGFlag,                  // Wait for all tasks to check in
                flags,
                LAB_WDOG_SYSTEM_TIMEOUT_MS,
                OS_OPT_PEND_FLAG_SET_ALL + 
                OS_OPT_PEND_FLAG_CONSUME,
                0,
               &err);
    if(err.Code == RTOS_ERR_NONE) {           // All tasks checked on-time.
        WDOG_Feed();                          // Feed the hardware watchdog.
    } else if(err.Code == RTOS_ERR_TIMEOUT) {
        while(1);                             // Trigger a reset. Logic can be set
    }                                         // here to ignore tasks that did not 
}                                             // check in on time.

 

The watchdog pends on the specified task flags as seen in lab.h, and the pend includes a timeout. If all tasks call a flag post at least once before the timeout value is reached, the OSFlagPend() call returns with RTOS_ERR_NONE, the hardware watchdog is fed via WDOG_Feed() and it loops around and starts the pend over again.

If one or more tasks fail to check in, the return value will be RTOS_ERR_TIMEOUT. In this example the code will then sit in a while(1) until the hardware watchdog resets the system. This would be the ideal location to either add logic to see what flags did or did not check in, and also to add a flag to persistent memory so when the system does reset, it can see on boot that it reset due to an error.

labWDOGFeed()

void  labWDOGFeed(CPU_INT32U task)
{
    RTOS_ERR err;


    OSFlagPost(&labWDOGFlag,          // Set the task's flag in the WDOG flag group
                task,
                OS_OPT_POST_FLAG_SET,
               &err);
    APP_RTOS_ASSERT_CRITICAL((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), ;);
}

 

The feed function is provided so all tasks do not need to have a reference to the Watchdog Event Flag. When tasks check in they just need to provide their identifier defined in lab.h. Since a flag group bit can only be 0 or 1, it does not matter if a task checks in once or multiple times each pend cycle.

Since every task is centered around a Message Queue, the timeout parameter on the message queue is set to a value less than the watchdog flag group to ensure that each task feeds the watchdog before the watchdog timeout.

 

Final Thoughts

One downside to this pattern is it does not work well with a low-power, battery operated system where you may want to sleep for longer periods of time than the hardware watchdog can handle. However, if power is not a concern the software watchdog pattern provides a simple way to ensure all tasks in an RTOS application are operating as expected. If you have any questions or comments, feel free to leave them below.

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

 

Thunderboard Sense 2 Kernel 201 Application

Hardware: https://www.silabs.com/products/development-tools/thunderboard/thunderboard-sense-two-kit
SDK Requirements: Gecko SDK Suite 2.5.5, Bluetooth 2.11.5, Flex 2.5.5, MCU 5.7.3, Micrium OS Kernel 5.6
SLS Project File: https://www.dropbox.com/s/8cupsgovf0f7odq/kernel201.sls?dl=0

 

Blue Gecko Kernel 201 Application

Hardware: https://www.silabs.com/products/development-tools/wireless/bluetooth/blue-gecko-bluetooth-low-energy-soc-starter-kit
SDK Requirements: Gecko SDK Suite 2.5.5, Flex 2.5.5, MCU 5.7.3, Micrium OS Kernel 5.6
SLS Project File: Coming Soon!

 

WebBluetooth API Application

Live webpage: https://kernel201.micrium.com

 

Electron Application

Coming Soon!

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 application and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

Task Architecture

The first step of designing any real-time system, before writing any code, is to identify all events the system will be responsible for. Listing out these actions will help identify what events may be grouped together in tasks and what actions will require their own task/s. There are a number of resources available that discuss different task modeling strategies. Some common strategies you may come across are:

• Signal event groups – Every event is put in its own task. Not efficient in large systems.
• Sequential events – Events that must be processed in order can be grouped together.
• Timing events – Events that occur on a periodic time base can be grouped together
• Interface events – All events associated with a particular interface
• Safety monitoring – Any safety monitoring events should be separated from any actuation tasks

For this application, these are the following events that must be handled and how they’ll be grouped into tasks:

• Bluetooth TX – labBluetoothTask
• Bluetooth RX – labBluetoothTask
• Proprietary Wireless TX – labPropTask
• Proprietary Wireless RX – labPropTask
• GPIO LED Control – labLEDTask
• RBG LED Control – labLEDTask
• Button 0 Read – labBtnTask
• Button 1 Read – labBtnTask
• Hardware Watchdog – labWDOGTask

labBluetoothTask
Silicon Labs’ Bluetooth stack already creates two tasks, Bluetooth and LinkLayer to handle the transmission and reception. The Bluetooth task provides callbacks for the user to implement to know when there is an event to process. The labBluetoothTask will handle those events from the Bluetooth task and pass that data along to the other tasks in the system. The labBluetoothTask will also receive data from other tasks in the system to transmit via Bluetooth.

labPropTask
Silicon Labs does not provide internal tasks for Proprietary Wireless (RAIL) as it does for Bluetooth, but it is important to group the RAIL functions together as they are not thread-safe functions. The labPropTask will handle all data received by RAIL and send it to other tasks in the system as needed. It will also receive data from other tasks in the system and send it out via RAIL.

labLEDTask
Since only the GPIO or RGB LEDs can be active at one time, it makes sense to group them together.

labBtnTask
The button task operates on a low priority polling interval. It could be switched to an interrupt based task but by leaving it as a polling task, it leaves open the option to add other polling events to the task in the future.

labWDOGTask
The watchdog task will implement a software based watchdog to control how the system feeds the hardware watchdog. It is important that this task have no other operations than handling the watchdog.

 

Task Communication

Now that the events have been divided up into their respective tasks, it is important to implement a consistent method for communication between tasks. There are again many different ways to implement task communication. Micrium OS Kernel provides Semaphores, Task Semaphores, Event Flags, Message Queues and Task Message Queues. While each of these kernel objects have various pros and cons, no one of these services is better than another; it just depends on the application and how it is using these kernel services.

For this application, each task (with the exception of the watchdog task) will be centered around a Task Message Queue and the entire application will use a sort-of layered messaging scheme, similar to the OSI model but much more simplified. The main loop of each task will pend on a Task Message Queue and wait for a message or timeout to determine its next action.

The image above shows the basic layout for all tasks in the system. The code snippet below shows some pseudocode for the task

void* p_msg;
LAB_Q_ID_e lab_q_id;

while (DEF_TRUE)
{
    p_msg = OSTaskQPend( LAB_WDOG_TASK_TIMEOUT_MS,     // Block the task until we
                         OS_OPT_PEND_BLOCKING,         //  receive a message
                        &lab_q_id,
                         0,
                        &err);
    do {
        if(err.Code == RTOS_ERR_TIMEOUT) {             // If we timeout, just feed
            break;                                     //  the watchdog task
        } else if(err.Code != RTOS_ERR_NONE) {         // Shouldn't occur, assert
            APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);
        }

        switch(lab_q_id) {
            case LAB_Q_ID_XXX_EVT:
                labXXXHandleEvt();                    // Handle a task event
                break;

            case LAB_Q_ID_MSG:
                labXXXHandleMsg((LAB_MSG_s*) p_msg);  // Handle a lab message
                labUtilMsgFree(p_msg);                // Then free the message
                break;                                //  back to the pool

            default:
                break;
        }
    } while(0);

    labWDOGFeed(LAB_TASK_ID_XXX);                     // Feed the watchdog after 
}                                                     //  every task action

 

By using the Task Message Queue, it allows a task to wait on three different types of events:

• Timeouts
• Events
• Lab Messages

Timeouts

The software watchdog wants every task to check in on a specified rate to show it has not gone out to lunch. By specifying a timeout value in the Task Message Queue pend, the pend call will return with RTOS_ERR_TIMEOUT if a message is not received in the specified time. If a task expects a message in a set time interval, logic can also be added to the error check for RTOS_ERR_TIMEOUT to keep track of how many timeouts we receive in a row.

Events

Some tasks may have a hardware interrupt or software timer callback they need to handle in addition to processing messages from other tasks in the system. The msg_size data field in OSTaskQPend() provides a 32-bit value that is used as an identifier field for this task design. When a task receives a message, it will have a switch statement to handle the value of msg_size. In this application, all message identifiers can be found in an enum called LAB_Q_ID_e.

When an interrupt or software timer callback wants to send a message to the task it is associated with, it will make a call similar to the one below:

OSTaskQPost(&labXXXTaskTCB,
             0,
             LAB_Q_ID_XXX_EVT,
             OS_OPT_POST_FIFO,
            &err);

 

It is important to note that the LAB_Q_ID_e value is specified in the msg_size field and not the void* field. All messages sent must have a valid identifier in the msg_size field where the void* argument is optional. In this case, the void* argument is set to 0 as there is no extra data to send.

Lab Messages

These messages are how tasks communicate with each other in this application. Rather than having the Bluetooth or Proprietary Wireless tasks spend time configuring PWM timers to drive the RGB LEDs, it makes more sense to send the LED task a LED command to be processed. This also allows us to handle wireless communication at a higher priority than changing the LEDs or polling the button states. The wireless tasks may be affected if responses are not sent out at specific intervals where if the system has to wait an extra 10ms to toggle the LED, the user most likely won’t notice.

The lab messages follow a layered model where every message has the same header, the header defines what else is to follow in the packet. This application provides utility functions for getting, sending and freeing messages (refer to lab_util.c). There are advantages to these utility functions that will be discussed a little later. When you get/free a message you are actually pulling from a memory pool of fixed block sizes. All messages, regardless of how much of the block they use, are the same size. In the case of this application, all messages are 32 bytes in size. This means that if a task needs to send or receive a message larger than 32 bytes, either the size of every block in the system must be increased, multiple messages must be sent or modifications must be made to the utility functions to allow for allocation and freeing of different size blocks.

typedef struct {
    LAB_MSG_ID_e id;
    LAB_MSG_TYPE_e type;
    void *p_data;
} LAB_MSG_s;

The struct above shows the lab message structure that all messages will start with. The ID field identifies what message will follow it and the type corresponds to if it’s a command, response, update or error message. The void* argument is used so you can cast the next layer to the end of the lab message struct.

LAB_MSG_s *p_msg;

p_msg = (LAB_MSG_s*) labUtilMsgGet();       // Get a data buffer to send a message
if(p_msg == DEF_NULL) {
    break;
}

p_msg->id = LAB_MSG_ID_LED;                 // Set the message id
p_msg->type = LAB_MSG_TYPE_CMD;             // Set that its a command message

When you wish to allocate a message to send, the code snippet above shows how you would use the labUtil function to allocate a message. The image below shows how the lab message fits into the allocated block.

After you configure the message ID and message type fields, you need to configure the next part of the block for the message ID you specified. For this example, let’s assume we’re changing the LEDs. LEDs are controlled by the LAB_LED_MSG_s struct. To accomplish this, you will cast the LAB_LED_MSG_s to p_data so when you enter information for the LED message, it goes into the correct location in lab message.

LAB_MSG_s *p_msg;
LAB_LED_MSG_s *p_led_msg;

p_msg = (LAB_MSG_s*) labUtilMsgGet();       // Get a data buffer to send a message
if(p_msg == DEF_NULL) {
    break;
}

p_msg->id = LAB_MSG_ID_LED;                 // Set the message id
p_msg->type = LAB_MSG_TYPE_CMD;             // Set that its a command message

p_led_msg = (LAB_MSG_LED_s*) &(p_msg->p_data);

p_led_msg->mode  = LAB_LED_MODE_RGB;
p_led_msg->color = LAB_LED_COLOR_GREEN;
p_led_msg->state = LAB_LED_STATE_BLINK;

The code snippet above shows how to cast the p_data argument to the LED message structure. Now when you modify the fields of the LED message structure it will be aligned in the message block as shown below.

Once the full message is assembled, the message needs to be sent to the desired task/s. Some messages may only go to one task where others may need to be sent to multiple tasks. The lab utility function for sending offers flexibility for sending messages. Using the labUtilSend() function as shown below, you pass the pointer to the message block just configured and the task/s the message should be sent to. 

labUtilMsgSend(p_msg, dest_task);  // Send the message to the specified destination

In the case where one message is being sent to multiple tasks, the send function will keep track of the number of tasks it was sent to. This allows each task to call the free function after its processed the message, but the memory block is not actually freed until all tasks that received the message free it. To free a message all a task needs to do is make the following call:

labUtilMsgFree(p_msg);   // Free the message back to the pool

It is the labUtilMsgFree function's job to determine when the message is actually returned to the message pool. If one task never calls free on the message it received, that block will never be freed and that memory will be lost so it is imperative that all tasks free all messages they receive, even if they receive the message in error. 

Final Thoughts

This wraps up the Task Communication and Architecture section of the Kernel 201 application. Moving forward the Bluetooth, Proprietary Wireless, LED and Button tasks will all be using this communication structure. If you have any questions about this post feel free to leave comments below.

This blog is part of the Kernel 201: Designing a Dynamic Multiprotocol Application with Micrium OS. The table of contents for this blog series can be found here.

Note: It is recommended to download the Kernel 201 application and have the code in front of you as you go through this blog post. The code can be downloaded on the Kernel 201: Project Resources page. 

Introduction

Micrium OS offers default configurations to allow a user to get started quickly. These configurations are useful for quick starts, test applications and instances where memory is not a constraint. It is important that all developers using Micrium OS do give some attention to the RTOS configuration as the defaults are not ideal for a released application.

To ensure the dynamic multiprotocol application starts off on a good foot, one of the first steps that will be taken is to configure Micrium OS. Most of the sample applications available in Simplicity Studio provide a good starting point, but this post will look a little more in-depth at the configuration that’s available.

Micrium OS Configuration Files

os_cfg.h

Note: Some example projects have already made modifications to os_cfg.h. The comments here are based on differences between the default os_cfg.h found in the Gecko SDK Micrium OS directory and this project.

This file provides all compile-time options for Micrium OS Kernel. It provides the ability to turn on and off almost all parts of the kernel. Typically, the default values are fine to start a project out with. In this project there are a few differences from the default config worth highlighting:

#define  OS_CFG_APP_HOOKS_EN        DEF_ENABLED
#define  OS_CFG_DYN_TICK_EN         DEF_ENABLED
#define  OS_CFG_PRIO_MAX            32u
#define  OS_CFG_TASK_DEL_EN         DEF_DISABLED

 

App Hooks

App hooks enable will turn on the callback functions (if one is defined) anytime the following events occur:

• Redzone Hit (if Redzone is enabled) – Occurs when a stack overflow is detected
• Task Create – Occurs after the task has been created but before OSTaskCreate() returns
• Task Delete (if task delete is enabled) – Occurs after the TCB is cleared and removed from the kernel but before OSTaskDel() returns.
• Task Return – Occurs if a task attempts to return
• Idle Task – Occurs at the end of the idle task while(1) loop
• Stat Task – Occurs after CPU usage calculation in the stat task
• Task Switch – Occurs right before a task is switched out
• Time Tick – Occurs right before a semaphore post to the tick task

The hook that is set up in most projects is the idle task hook. Since this hook is called from the idle task loop, it is an ideal time to enter a lower power mode. Right now the kernel can run from EM0, EM1 or EM2 (EM2 requires use of the LFRCO).

Dynamic Tick

Dynamic tick allows the kernel to adjust the tick rate as needed to minimize the amount of time the kernel has to wake from sleep. The images below show the advantage of using dynamic tick over a periodic tick.

Periodic Tick

Dynamic Tick

Priority Maximum

The PRIO_MAX setting controls the maximum number of task priorities allowed in the system. Micrium OS supports an unlimited* number of task priorities but there are advantages of having the value set to a smaller number.

If a system only has 10 tasks, there is an advantage to setting PRIO_MAX to 32 vs 64, 128, 256, 512 or some other very large number. The way the kernel’s scheduler looks for the next available task is it has an array called OSPrioTbl[] which is defined as follows:

CPU_INT32 OSPrioTbl[(((OS_CFG_PRIO_MAX - 1u) / DEF_INT_CPU_NBR_BITS) + 1u)]

 

Each bit in the PrioTbl corresponds to a task priority so since each row holds 32 bits, that’s 32 priority levels that can be checked in one go. If PRIO_MAX is set to 512, the kernel will potentially have to go through 16 rows before deciding to drop to the idle task. That’s a lot of extra overhead for task priorities that are not being used.

*Hardware provides the limitation, there is no limitation in software.

OSTaskDel

The OSTaskDel() should be disabled by default in almost all Micrium OS applications. Deleting a task only removes it from the kernel so it is no longer scheduled. It does not take into account any kernel objects associated with the task nor does it free up any memory associated with the task being deleted. There are very few situations where OSTaskDel() is needed.

 

common_cfg.h

The common_cfg.h file is used to configure the memory, string and clock modules. The defaults for string and clock are fine for this project, but since the goal of this project is to reduce the kernel’s footprint the memory will be adjusted.

By default the kernel uses an internal heap to allocate space for internal tasks and message queues. By making the following change to the heap size, it will turn off the internal heap.

#define  LIB_MEM_CFG_HEAP_SIZE                              0uL

 

If this was the only change is made to the project, the project would compile but fail immediately during runtime when OSInit() is called due to no memory being available. A change also has to be made in rtos_cfg.h to disable the use of the internal heap for internal tasks and message queues.

 

rtos_cfg.h

The rtos_cfg.h file controls three things:

• Assert configuration

• Memory usage configuration for internal tasks and message queues

• Logging

The assert configuration defaults to locking the system in a while(1) loop for debug and critical asserts. The debug asserts should be modified when going into production but for development it can be useful to leave the while(1) loop to find issues quicker.

The logging is an optional module that is not used in this project.

The Default Config configuration is what determines if the heap is used for internal tasks or not. By making the following change, it will require that a number of internal structures are externally configured. This will allow for the kernel to operate with the heap being set to 0.

#define  RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN               DEF_ENABLED

 

rtos_description.h

This file defines what Micrium OS modules are enabled. For this project only two defines are needed:

#define  RTOS_MODULE_KERNEL_AVAIL
#define  RTOS_MODULE_COMMON_CLK_AVAIL

 

A full list of available RTOS_MODULE options can be found in the Gecko SDK version of rtos_description.h.

 

Main Configuration

Once the changes have been made to the necessary config files, the desired kernel configuration must be made in the application. In this example, the file lab_main.c has the following kernel configuration.

Tick Task

The tick task is used to control the kernel’s system tick which is used for time delay calls and pend timeouts. In this application it is based off of the RTCC interrupt. The following configuration will define a stack for the tick task and set the config only if OS_CFG_TASK_TICK_EN is set in the os_cfg.h file. The stack size, priority and frequency of the tick task are all configured in the lab.h file.

#if (OS_CFG_TASK_TICK_EN == DEF_ENABLED)               // Tick Task Configuration
static CPU_STK TickTaskStk[LAB_OS_TICK_TASK_STK_SIZE];
#define TICK_TASK_CFG  .TickTaskCfg =       \
{                                           \
    .StkBasePtr = &TickTaskStk[0],          \
    .StkSize    = LAB_OS_TICK_TASK_STK_SIZE,\
    .Prio       = LAB_OS_TICK_TASK_PRIO,    \
    .RateHz     = LAB_OS_TICK_TASK_RATE_HZ  \
},
#else
#define TICK_TASK_CFG
#endif 

 

Idle Task

The idle task is the lowest priority task in the system. When the kernel has no other tasks to schedule, it will run the Idle Task. When entering the Idle Task, there is a hook function that can be implemented to allow the user application to enter a lower power mode. The following configuration will define a stack for the idle task and set the config only if OS_CFG_TASK_IDLE_EN is set in the os_cfg.h file. If the idle task is not enabled, when the current task finishes the scheduler sits in a while(1) loop until another action happens in the system rather than jump to a different task. When the idle task is enabled the stack size of the idle task can be found in lab.h. You can not set the priority of the idle task because it must always be the lowest priority task in the system.

#if (OS_CFG_TASK_IDLE_EN == DEF_ENABLED)               // Idle Task Configuration
static CPU_STK IdleTaskStk[LAB_OS_IDLE_TASK_STK_SIZE];
#define IDLE_TASK_CFG  .IdleTask =          \
{                                           \
    .StkBasePtr = &IdleTaskStk[0],          \
    .StkSize    = LAB_OS_IDLE_TASK_STK_SIZE \
},
#else
#define IDLE_TASK_CFG
#endif

 

Timer Task

The timer task is used to control Micrium OS Kernel’s software timers. The reason the timers operate in a different task than the tick task is the timer callback functions are made from the timer task, so it allows the timer callbacks to run at a different priority than the tick task if desired. The following configuration will define a stack and set the config only if OS_CFG_TMR_ EN is enabled in the os_cfg.h file. The stack size, priority and frequency of the timer task are all configured in the lab.h file.

#if (OS_CFG_TMR_EN == DEF_ENABLED)                     // Timer Task Configuration
static CPU_STK TimerTaskStk[LAB_OS_TMR_TASK_STK_SIZE];
#define TIMER_TASK_CFG  .TmrTaskCfg =       \
{                                           \
    .StkBasePtr = &TimerTaskStk[0],         \
    .StkSize    = LAB_OS_TMR_TASK_STK_SIZE, \
    .Prio       = LAB_OS_TMR_TASK_PRIO,     \
    .RateHz     = LAB_OS_TMR_TASK_RATE_HZ   \
},
#else
#define TIMER_TASK_CFG
#endif

 

Stat Task

The stat task is an internal task that provides such run-time statistics as overall CPU utilization (0.00 to 100.00%), per-task CPU utilization (0.00 to 100.00%), and per-task stack usage. The following configuration will define a stack and set the config only if OS_CFG_STAT_TASK_EN is enabled in the os_cfg.h file. The stack size, priority and frequency of the stat task are all configured in the lab.h file.

#if (OS_CFG_STAT_TASK_EN == DEF_ENABLED)               // Statistics Task Config
static CPU_STK StatTaskStk[LAB_OS_STAT_TASK_STK_SIZE];
#define STAT_TASK_CFG  .StatTaskCfg =       \
{                                           \
    .StkBasePtr = &StatTaskStk[0],          \
    .StkSize    = LAB_OS_STAT_TASK_STK_SIZE,\
    .Prio       = LAB_OS_STAT_TASK_PRIO,    \
    .RateHz     = LAB_OS_STAT_TASK_RATE_HZ  \
},
#else
#define STAT_TASK_CFG
#endif

 

Interrupt Stack

The ARM Cortex-M series has a separate stack for interrupts to execute out of. Micrium OS Kernel will configure the stack location during the OSInit() call, but a stack must be provided. The following configuration creates the interrupt stack and sets the necessary configuration. This is not an optional configuration, it is required of all Micrium OS Kernel applications.

static CPU_STK ISRStk[LAB_OS_ISR_STK_SIZE]; // ISR Configuration
#define ISR_CFG                  .ISR = \
{                                       \
    .StkBasePtr = (CPU_STK*)&ISRStk[0], \
    .StkSize    = LAB_OS_ISR_STK_SIZE   \
},

 

Message Pool

If message queues will be used in an application (this application makes heavy use of them) then a message pool must be defined. When messages are sent in either a message queue or task message queue, a message pool object is allocated to hold the data being sent (void* argument and message size argument). The message pool should have enough entries for every message queue entry in the application. For example, if you have 3 message queues each with 10 entries in them, you should have a message pool size of 30. The following configuration is used to specify the message pool size in this application.

#define  MSG_POOL_SIZE  (LAB_TOTAL_MSG_Q * sizeof(OS_MSG))
#define  MSG_POOL_CFG    .MsgPoolSize = LAB_TOTAL_MSG_Q, \
                         .MemSeg      = &MsgPoolMemSeg,

 

In addition to specifying the configuration, a memory segment and memory buffer must be allocated as follows:

static  MEM_SEG    MsgPoolMemSeg;
static  CPU_INT08U MsgPoolMem[MSG_POOL_SIZE];

 

And finally, in the main() before OSInit() is called, the memory segment must be created so the kernel knows how to access the memory buffer specified above.

Mem_SegCreate(          "Msg Pool Mem",         // Create the Message Pool segment
                        &MsgPoolMemSeg,
              (CPU_ADDR)&MsgPoolMem,
                         MSG_POOL_SIZE,
                         LIB_MEM_PADDING_ALIGN_NONE,
                        &err);
APP_RTOS_ASSERT_DBG((RTOS_ERR_CODE_GET(err) == RTOS_ERR_NONE), 1);

 

Putting it all together

You may have noticed that all of the configs are just #defines. These #defines are used to create one giant #define as shown below.

#define  OS_INIT_CFG_APP            {   \
    ISR_CFG                             \
    IDLE_TASK_CFG                       \
    TICK_TASK_CFG                       \
    TIMER_TASK_CFG                      \
    STAT_TASK_CFG                       \
    MSG_POOL_CFG                        \
    .TaskStkLimit    = 0u               \
}

 

Once the OS_INIT_CFG_APP define is put assembled with all of the task and memory pool configs, the define should be assigned to the global variable as follows:

const  OS_INIT_CFG           OS_InitCfg          = OS_INIT_CFG_APP;

 

This variable is externed by the kernel so it must be named OSInitCfg as this is what the kernel uses internally.

Final Thoughts

While it may appear a little complicated, the configuration of Micrium OS Kernel is very important to the success of an application and worth the extra effort. A misconfigured kernel can cause issues farther down the road so it is important to configure it correctly to start with. By removing the general purpose heap it allows the developer to have a full understanding of what's going on under the hood so there is no confusion about how the kernel is configured. If you have any questions or comments feel free to leave them below.

Introduction

When developing an application with a real-time operating system, developers have numerous design decisions to make when starting a project. These design decisions can greatly affect how a system performs, how easy it is to expand an application and even how well a system can tolerate failures.

The following blog series will take an in-depth look at designing a real-time operating system application in a dynamic multiprotocol system (Bluetooth + Proprietary Wireless). It will walk through configuring Micrium OS, discuss task architecture, look in-depth at the Bluetooth and Proprietary Wireless tasks, and look at some safety design patterns.

Table of Contents

Kernel 201: Configuring Micrium OS
Kernel 201: Task Architecture & Communication
Kernel 201: Implementing a Software Watchdog
Kernel 201: Bluetooth Task & WebBluetooth App (Coming soon!)
Kernel 201: Proprietary Wireless Task (Coming soon!)
Kernel 201: UI Tasks (Coming soon!)
Kernel 201: Blue Gecko Electron Application (Coming soon!)
Kernel 201: Project Resources

The goal of the application discussed throughout the blog series is to run the dynamic multiprotocol application on a Thunderboard Sense 2 board. There is a web application that will communicate over Bluetooth with the Thunderboard using the WebBluetooth API. The Thunderboard will also communicate to a Blue Gecko board via Proprietary Wireless. The image below shows the layout of communication.

More and more embedded systems rely on the use of Real-Time Operating Systems (RTOSs) to: satisfy real-time requirements, reduce time-to-market, simplify development, increase code portability, and simplify development. Despite its many benefits, an RTOS also has its drawbacks, such as introducing improperly assigned task priorities, stack overflows, starvation, deadlocks, priority inversions and other hard-to-find bugs.

In these three articles published on Embedded Computing Design, Jean Labrosse, distinguished engineer at Silicon Labs and Micrium founder, will look at tools specifically designed to help RTOS-based application developers uncover some of these elusive bugs, identify issues and offer corrective actions. These tools are readily available yet often unknown to embedded developers.

1. Uncovering Real-Time Bugs with Specialized RTOS Tools - Part 1
2. Uncovering Real-Time Bugs with Specialized RTOS Tools - Part 2
3. Uncovering Real-Time Bugs with Specialized RTOS Tools - Part 3

Technologies such as 5G, edge computing, AI, and the Internet of Things are enabling the 4th Industrial revolution, sometimes called Industry 4.0. The trends and advancements of Industry 4.0 are driving the growth of a market of IoT solutions referred to as the Industrial Internet of Things, or IIoT. 

Ross Sabolcik, Vice President and General Manager of IoT Industrial and Commercial Products, had the following to say about the IIoT:

Silicon Labs low-power wireless communications technologies are fit for a wide range of industrial IoT (IIoT) applications such as smart energy management, commercial and building automation, asset tracking, commercial and high-bay lighting, process automation and agriculture tracking. We support a wide range of wireless protocols including Zigbee, Thread, Bluetooth mesh, Bluetooth Low Energy, Wi-Fi and proprietary protocols. 

Our solutions address emerging technologies essential to progressing the IIoT, such as edge computing. Our wireless SoCs and modules include powerful Arm Cortex-M4 processors integrated into each device that can handle local control and analysis of data, combined with scalable memory options to accommodate the customer’s application as well as wireless over-the-air (OTA) updates. 

Another demand from the IIoT is having robust sensor solutions. Temperature is the most pervasive environmental metric that industrial system developers need to measure, and today’s designers expect exceptional power efficiency, accuracy and price/performance from their temperature sensing solutions. Silicon Labs’ temperature sensors provide a very power-efficient solution while maintaining accuracy across the entire operating voltage and temperature range so developers don’t need to compromise on performance.

Another concern relevant to the IIoT includes data security. Security from the end node to the cloud is a must-have capability to enable reliable and secure IIoT applications and to prevent automated factories from malicious intrusions and data leaks. All wireless SoCs and modules and non-wireless microcontrollers (MCUs) from Silicon Labs integrate sophisticated hardware cryptography supporting both for symmetric and asymmetric encryption. Silicon Labs’ wireless devices and MCUs also come with software to efficiently use advanced encryption technology, enabling secure communications, firmware updates and many other benefits.

Despite the progress of the IIoT, the eco-system is still taking shape. With support for multiprotocol connectivity, and field-upgradeable solutions, as well as simplified development experiences and reusable software, our products are poised to help the IIoT continue to grow and eventuate in widespread adoption.  

Wireless technology plays a major part in the Internet of Things (IoT) but deploying this technology can involve a good bit of programming. Applications must address a range of issues including features like secure over-the-air (OTA) updates.

In this Q&A, Silicon Labs’ senior product manager for Xpress devices Parker Dorris discusses some of the questions that come up when talking about the programming burden of wireless applications.

What are some wireless IoT applications that Silicon Labs is targeting?

We’re targeting Bluetooth Low Energy-enabled sensors, smartphone-controlled smart home devices, white goods, and machine-to-machine applications, especially those requiring the additional option of phone configuration and connectivity. We’re already seeing an extremely diverse mix of applications evaluating and developing with these zero-programming IoT solutions, and the common theme in these designs is a need for wireless connectivity without the steep learning curve. The wireless component just works, which enables companies to focus resources on the aspects of a design that will make the product innovative and successful
in the market.

What is zero-programming, and why is it important to IoT developers?

The goal of our Wireless Xpress portfolio is to lower the barriers of entry for IoT end node design by providing easy to use hardware and software solutions that require zero-programming. These Wireless Xpress module products are all about enablement in a few key respects.

First, because a developer is interfacing with Wireless Xpress through a high-level network coprocessor (NCP)-style interface called the Xpress command API, and communicating with a device that takes on as much responsibility for wireless connection and communication as possible, developers don’t have to become Bluetooth or Wi-Fi experts to get to market quickly.

While you don’t have to write code for these module devices, we expose configurable parameters to tweak performance features. Developers don’t have to learn the intricacies of stack APIs and getting a module to some configured state; they just set a variable. This command API feature helps developers avoid some of the more common challenge points that can snag developers new to a wireless protocol.

Wireless Xpress takes advantage of Silicon Labs’ Gecko OS, an intuitive, simple-to-use IoT operating system. Wireless Xpress devices also focus on enablement in the sense that because the device handles wireless-related responsibilities so comprehensively with the Gecko OS firmware running under the hood, developers don’t have to choose an MCU that will be able to handle low-level wireless maintenance, or granular monitoring through a lower-level NCP protocol. Developers can choose the MCU that’s right for their application, rather than choosing the MCU that’s right for their NCP.

What hardware platforms does Silicon Labs offer for IoT end node designs?

We’ve launched Bluetooth Xpress modules in PCB module and system-in-package (SiP) module options, called BGX13P and BGX13S, respectively. We also offer two zero-programming Wi-Fi Xpress modules, the AMW007 and AMW037.

What is involved on the software side to get a mobile app running?

For Bluetooth Xpress, we’ve launched the Xpress framework for both iOS and Android. Developing mobile apps can sometimes be a challenge for product developers, and developing a BLE-connected app is its own specialized skillset. With the Xpress framework, we abstract low-level mobile OS core Bluetooth APIs behind a few easy-to-use APIs.

This is really helpful to developers for two reasons. First, the Xpress framework handles all the Bluetooth-specific scanning and discovery, interrogation, connection and GATT table communication. For instance, to scan, you call startScan, and the framework delivers a list of discovered devices. To connect, you call connectToDevice, and the framework handles the rest.

Second, the framework looks largely the same for both iOS and Android, unifying an interface that really works quite differently between the two OSes. So if a developer learns to connect to Bluetooth Xpress in iOS, those same function calls are going to work identically in Android. For Wi-Fi Xpress, we’re offering a web app that is served by a Wi-Fi Xpress device and provides a RESTful API to control the module and access a file system.

What type of tools are available to developers to take advantage of Wireless Xpress?

One great thing about these module products is that the Xpress command API is human-readable, and so developers can evaluate the product and fully exercise features with a simple terminal program running on a PC.

We’ve launched two evaluation kits, the Wireless Xpress BGX13P kit and the AMW007-E04 kit, each offering a serial to USB bridge so access to the board looks like a COM port. For developers that want a more context-rich evaluation experience and a graphical interface, we offer the Xpress Configurator tool in Silicon Labs’ Simplicity Studio development environment. Xpress Configurator logically groups different configurable parameters, validates configurable settings, and displays documentation for each parameter. All of this configuration results in one or more Xpress commands getting sent to the Wireless Xpress module through a terminal interface built into the tool.

Developers have access to network management and mapping tools. The tools provide a high-level view of the system. The network analyzer tracks wireless node activity in real time proving insights for debugging and system optimization.

What about connecting to the cloud?

For Bluetooth Xpress, we offer over the air (OTA) support through the Xpress framework. If Silicon Labs releases a firmware update to Bluetooth Xpress, this signed, encrypted update can be pulled from our cloud with a single framework API. Wi-Fi Xpress products can access the cloud directly to receive firmware updates. Developers can also use this built-in cloud connectivity to perform device health checks in the field and retrieve other key, application specific metrics as well.