The objective of this blog is to show you the steps necessary to add the Micrium OS File System to an EFM32GG11. I'll be focusing on RAM Disk as the storage media while we wait for an SD card example project to become available.

Baseline Project

Since the Gecko SDK currently ships without a stand-alone Micrium OS File System example, we will start with the 'micriumos_usbhmsc' project for the SLSTK3701A_EFM32GG11. The convenience of selecting this project as a baseline is due to the fact that the Micrium OS File System is present as a requirement from USB-Host Mass Storage Class, which is what that example demonstrates.

Start by connecting your SLSTK3701A_EFM32GG11 to the PC and launching Simplicity Studio, then click on File -> New -> Project...

Select Silicon Labs MCU Project and click Next >

Since you already have your board connected, it should all be auto-detected. Leave everything by default making sure that there's an SDK selected, then click Next >

Now select Example - Create a working example for the part. and click Next >

In the search bar, type "SLSTK3701A_micriumos_usbhmsc", then select it and click Next >

Pick a name for your project, in my case, I named the project "SLSTK3701A_micriumos_ramdisk". Make sure you select Copy contents so that we can edit the example files freely. After that, click Finish.

Try to build the project and flash it to make sure that it is functional, remember, this will be our baseline for what's coming next...

Configuration Files

We will now need to modify the project configuration files in order to include Micrium OS FS RAM Disk as part of our build.

For that, start by expanding the Includes section in the Project Explorer panel, then expand the configuration folder as shown in the image below. After that, double-click on rtos_description.h to open it in the editor.

As soon as you try to edit rtos_description.h, you'll be presented a Warning indicating that you are editing an SDK file. Click on Make a Copy so that we can edit this freely in our workspace without affecting other projects in the SDK.

Add the following #define in rtos_description.h to indicate Micrium OS that you want to use the File System RAM Disk implementation:

#define  RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL

 

Editing the Example Files

At this point, your application is able to create a RAM Disk using the Micrium OS File System. However, we want it to do some more. Let's now perform a simple file read and write. For that, copy the ex_fs_file_rd_wr.c and .h example files located at:

C:\SiliconLabs\SimplicityStudio\v4\developer\sdks\gecko_sdk_suite\v2.3\app\micrium_os_example\fs

 

Paste the two files in your workspace folder, at the same level of ex_fs.c, etc. In my case, this would be:

C:\Users\<user>\SimplicityStudio\v4_workspace\SLSTK3701A_micriumos_ramdisk\src

 

To make use of the read/write example that we just copied, we have to include its header file in the include section of ex_fs.c:

#if  (defined(RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL))
#include  <fs/include/fs_ramdisk.h>
#include  "ex_fs_file_rd_wr.h"
#endif

 

Notice that I included the example header within the RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL section in case you want to exclude the RAM Disk from your project later on then this also gets excluded.

Finally, let's add the call to Ex_FS_FileRdWr(). You can do this in Ex_FS_Init() in ex_fs.c right at the end of the "FORMAT RAM DISK" section as indicated by the code comments.

#if  (defined(RTOS_MODULE_FS_STORAGE_RAM_DISK_AVAIL))
    {
        FS_BLK_DEV_HANDLE  blk_dev_handle;


        blk_dev_handle = FSBlkDev_Open(FSMedia_Get("ram0"), &err);
        APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

        FSCache_Assign(blk_dev_handle,
                       Ex_FS_DataPtr->CachePtr,
                       &err);
        APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

        FS_FAT_Fmt(blk_dev_handle,
                   FS_PARTITION_NBR_VOID,
                   DEF_NULL,
                   &err);
        APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

        FSBlkDev_Close(blk_dev_handle, &err);
        APP_RTOS_ASSERT_CRITICAL(err.Code == RTOS_ERR_NONE, ;);

        Ex_FS_FileRdWr();
}
#endif

 

Running the Example

You can now build your application and flash it on the board. Before running it though, open a terminal application to view the VCOM output from the EFM32GG11 VCOM port.

Since we based this project out of the USB-Host Mass Storage Class example, there will still be USB-related code executing, hence why you'll see those messages in the terminal output.

Once you start running, the File System will be initialized with a default configuration, as well as the RAM Disk as specified by Ex_FS_RAM_Disk_Cfg in ex_fs.c.

Further on, the RAM Disk gets formatted as a FAT volume and one partition is created.

Lastly, the read/write example essentially writes some known data to a specified file, then the data from the file is read and verified for integrity.

If everything ran correctly, you should see the following on your terminal output:

*** MicriumOS USB-host Example. ***
FS Example: File rd/wr on 'ram0'...OK


*** MicriumOS USB-host Example -----> Init done. ***

>> Ex_FS_MediaOnConn(): Media 'ram0' connected!

 

Notice the string "FS Example: File rd/wr on 'ram0' ...OK" indicating that the read/write demo ran fine on our RAM Disk.

We hope to have a part 2 of this blog which would be based on an SD card instead of the RAM Disk. For now, this will be good enough to get your hands dirty with the Micrium OS File System.

Over and over, customers tell us they want a wireless link to just work so they can move on and focus on the application they're designing. This week, we delivered on this challenge with the introduction of Wireless Xpress, which gives designers the freedom to go from out of box to prototype within a few hours – versus months – with no software development necessary.

Wireless Xpress provides a configuration-based development experience with everything developers need, including certified Bluetooth® 5 Low Energy (LE) and Wi-Fi® modules, integrated protocol stacks and easy-to-use tools supported by the Silicon Labs Gecko OS operating system.

The new solution simplifies wireless development and eliminates the daunting task of working in numerous and complicated wireless development interfaces. Today’s IoT development teams are often burdened with importing numerous stacks of software, dealing with hundreds of APIs and complex RF integration obstacles, along with writing hundreds of hours of code. Because of these complexities, wireless development is hard to come by, and IoT companies often need to outsource the development, an extremely costly and time-intensive process that slows down time to market. Wireless Xpress removes the need for wireless development since we’ve already done the work for you.

Then there’s cloud connectivity – an onerous challenge for design teams to build from the ground up.  Wireless Xpress provides instant cloud connectivity and has built-in firmware updates, along with the ability to retrieve updates and push them out to devices in the field. This functionality removes the need for our customers to pay for subscription-based services to ensure these updates are managed.

Wireless Xpress addresses all of these challenges head-on without a big stack. We take on as much firmware responsibility as possible, with all configuration occurring in the Gecko API.  Wireless Gecko is not codeable, but configurable, freeing designers from the headache of wireless design by getting it all in one box.

 

Putting Application First, Versus Network

Another challenge solved by the new solution, and especially beneficial for low-power applications, is MCU processing constraints. An MCU in a typical wireless design is handling all of the network processing demands versus application needs, creating a situation where customers are often paying more than they need for an MCU. Wireless Xpress offloads the embedded host processing from the MCU and handles processing demands inside the package, reducing the processing performance required and optimizing the chip-set. With Wireless Xpress, you can use a bare bone 8-bit MCU for applications that would have otherwise needed a 32-bit because of RAM, flash, etc. demands.

 

Support Down to the Silicon

With the Wi-Fi and Bluetooth modules, Silicon Labs is able to go all the way down to the silicon to find a problem. When you look at other pre-programmed modules on the market, what you find is module vendors are not SoC designers – the silicon in these products is from other companies. Therefore, in the support structure, problems tend to be punted to the underlying silicon vendor. This structure really goes against the ease of use experience. Wireless Xpress gives customers one point of contact for wireless design, making it much easier for support and troubleshooting. It’s our silicon – we control every part of the flow, giving us the advantage to optimize design better than anyone on the market.

Our Bluetooth and Wi-Fi modules are pre-programmed, pre-qualified and are pin for pin compatible with our portfolio of products. And they all run through the Gecko Xpress API, which we have already tested to ensure its reliability and flexibility. We’re taking care of the wireless interface on behalf of the customer and giving them back the 3-6 months it would take to build all of the connectivity from scratch.

So many of our customers seeking wireless connectivity are long-standing, established companies in markets that don’t have the in-house resources nor budget to invest in wireless connectivity talent – these companies’ main agenda is to make exceptional products for their markets. Wireless Xpress gives these companies the opportunity to obtain the wireless expertise they need in one package – giving time back to the developers to worry about their own customer needs – instead of complex wireless scenarios that demand too much time and money.

Wireless Xpress is the latest culmination of our strong customer relationships – we listen and design accordingly. Stay tuned as Silicon Labs continues to deliver the IoT solutions designers want to get innovative and high-performing products to the market as fast as possible.

Learn more at silabs.com silabs.com/products/wireless/xpress. 

 

We’ve recently been made aware a phishing scheme targeting our customers. Phishing, as you probably know, is a cybercrime that involves perpetrators sending e-mails disguised to look like legitimate correspondence from reputable companies. These “phishing” expeditions can be very clever and are designed to get unsuspecting e-mail users to reveal sensitive information. In this particular case, the phishing e-mail was sent inquiring about outstanding amounts due to Silicon Labs.

If you’ve received a similar message, or any e-mail asking you to redirect your payment terms to an alternate account, DO NOT RESPOND. Rather, please contact your Silicon Labs Accounts Receivable department.

We have well-established processes for remittance of payments and changes in policy will be communicated through established, trusted means.

 

Introduction

Micrium OS Network collects run-time statistics, error counters and buffer usage information that are optional during compile-time since they require additional code and memory.

Application developers may want to analyze these run-time metrics for various reasons:

 

Verify Performance

The protocol statistics allow you to verify the performance of your network application by looking at reception and transmission speeds.

 

Detect Errors

Error counters allow you to debug run-time problems such as low memory conditions, slow performance and packet loss.

 

Optimize Memory Usage

The buffer statistics allows you to optimize the memory usage and since the examples in Simplicity Studio are configured for general purpose and may have more buffers than necessary, these metrics can help you optimize the memory usage for your specific application needs.

 

Monitor Network Connections

The sockets list screen allows you to see the state of your incoming and outgoing network connections, including the IP addresses, port numbers and the protocol.

 

 

How to Enable the Micrium OS Network Run-Time Statistics

To enable run-time statistics within Micrium OS Network a few macros need to be defined to DEF_ENABLED as follows.

Run-time Statistics Counters

These statistics are related to the network protocol and interfaces. You may want to analyze statistics counters to verify the performance of your network application on a per interface basis. To enable them, edit the file net_cfg.h and set the following macros to DEF_ENABLED as shown below:

    #define  NET_CTR_CFG_STAT_EN                                DEF_ENABLED

 

Run-time Error Counters

Micrium OS Network maintains run-time counters for tracking error conditions within the Network Protocol Stack. You may want to analyze error counters to debug runtime problems such as low memory conditions, slow performance and packet loss. To enable them, edit the file net_cfg.h and set the following macros to DEF_ENABLED as shown below:

    #define  NET_CTR_CFG_ERR_EN                                 DEF_ENABLED

 

Network Statistics Pool configuration

These statistics are related to data buffers. You may want to analyze these statistics to optimize the memory usage of your network application. To enable them, edit the file net_cfg.h and set the following macros to DEF_ENABLED as shown below:

    #define  NET_STAT_POOL_BUF_EN                               DEF_ENABLED

    #define  NET_STAT_POOL_ARP_EN                               DEF_ENABLED

    #define  NET_STAT_POOL_NDP_EN                               DEF_ENABLED

    #define  NET_STAT_POOL_IGMP_EN                              DEF_ENABLED

    #define  NET_STAT_POOL_MLDP_EN                              DEF_ENABLED

    #define  NET_STAT_POOL_TMR_EN                               DEF_ENABLED

    #define  NET_STAT_POOL_SOCK_EN                              DEF_ENABLED

    #define  NET_STAT_POOL_CONN_EN                              DEF_ENABLED

    #define  NET_STAT_POOL_TCP_CONN_EN                          DEF_ENABLED

 

Internet Group Management Protocol (multicast) layer configuration

    #define  NET_MCAST_CFG_IPv4_RX_EN                           DEF_ENABLED

 

 

How to Analyze the Micrium OS Network Run-Time Statistics

To access these run-time statistics, you can either watch the arrays and variables from your IDE's watch window or call some APIs from your application. However, that quickly proves to be impractical. Instead, you can use uC/Probe, a tool that is integrated in Simplicity Studio that allows you to watch these statistics live in a series of pre-built screens as shown in the following image:

 

 

Installing uC/Probe

uC/Probe can be installed and integrated in Simplicity Studio by following the next steps:

• Open Simplicity Studio
• Click Help from the top menu
• Select the option Update Software from the Help menu
• Switch to the Tools tab
• Scroll-down and press the button Install next to the option Micrium uC/Probe

 

 

Opening uC/Probe

To open uC/Probe launch a Debug Session for your project and press the button uC/Probe located on the top toolbar of Simplicity Studio as shown below:

 

 

Associating uC/Probe to your Embedded Application

Typically uC/Probe will launch and open your project’s ELF file in the Symbol Browser as shown in the image below:

However, if the Symbol Browser is empty, then you need to press the button ELF and locate your project’s output file typically located in your toolchain’s output folder. For example:

• GNU: PROJECT_LOC/GNU ARM vx.x.x - Debug/MyOutputBinary.hex
• IAR: $PROJ_DIR$/[Project Name]/Exe/MyOutputBinary.out

 

 

Including the Micrium OS Network Screens

uC/Probe is a Windows tool that lets you associate a virtual indicator and/or control to any of your embedded application’s global variables, and then display the variables values live in a dashboard.

However, for the run-time statics maintained by the Micrium OS Network stack, a series of screens are already designed and configured to display said statistics.

To include the screens, follow the next steps:

• Locate the Workspace Explorer on the top left corner of uC/Probe.
• Click the button Insert Screens
• Select the option Micrium OS Net (TCP/IP)

 

 

Watching the Run-Time Statistics Live

To start watching the run-time statistics live, ensure that your embedded application is running and press the button Run located on the top toolbar of uC/Probe as shown in the following image:

 

Conclusion

To ensure the highest level of performance possible, it makes sense to start your Micrium OS Network based application by defining as many buffers as possible and then use uC/Probe and its interface and pool statistics data screens in order to refine the number after having run the application for a while. For example, a busy network will require more receive buffers in order to handle the additional messages that will be received.

 

 

 

 

Overview

Micrium has a long history of providing very reliable kernels as seen with uC/OS-II and uC/OS-III, both still sold and used in many products today. Micrium OS Kernel is no exception to this and one common trait seen across all of these kernels is they are extremely configurable. A common question developers ask when evaluating real-time kernels is what is the kernel’s footprint for RAM and ROM. Micrium OS Kernel does not have a set number for RAM or ROM but instead a general range: 6-24KB ROM and 3-4KB of RAM. The reason for this is every part of the kernel, with the exception of the scheduler, can be enabled or disabled through a number of configuration header files.

Micrium OS Kernel by default uses an internal heap to allocate memory for its internal data structures and internal task stacks. The heap provides a simple, convenient way to allow a user to get a kernel project up and running quickly. The drawback to using the heap is there may be some RAM allocated to the heap that ends up not being used. This article will cover how to modify the Giant Gecko Series 1 Starter Kit (SLSTK3701A) Micrium OS Blink example to disable the internal heap and statically allocate memory for the internal data structures and task stacks. Nothing covered in this example is specific to the Giant Gecko Series 1, so these steps can be taken on any Micrium OS Kernel project.

Note: The file that is being modified, ex_main.c, is available for download at the bottom of this post.

Creating the Micrium OS Blink project

These steps assume Micrium OS Kernel is already installed in the most recent SDK version of a Simplicity Studio install. If it is not, go through the Update Software wizard for the Giant Gecko Series 1 to install all of the necessary packages.

 

Go to File -> New -> Project… to bring up the new project wizard. Select Silicon Labs MCU Project and click Next.

Set the board to the EFM32GG11 Giant Gecko Starter Kit board. This should trigger the Part and SDK to be set. If it does not, set the part as shown above and choose the most recent version of the SDKs.  Note: Micrium OS Kernel must already installed before this step. 

Select Example and click Next. 

Search for the Micrium OS Blink project and click Next. 

Select either Link Libraries or copy sources or Copy contents. It Is important that the ex_main.c file is copied into the project so modifications can be made. Click Finish and the project will be loaded into the Simplicity IDE.

Modifying the configuration files

Starting with the blank Micrium OS Blink project, expand the micriumos_blink/cfg folder as shown above under the Includes folder. This folder has all of the Micrium OS configuration files.

#define  LIB_MEM_CFG_HEAP_SIZE  0uL

The first step is to set the Micrium heap to zero. In common_cfg.h there is a #define for LIB_MEM_CFG_HEAP_SIZE. This value defines the size of the Micrium OS heap and should be changed to 0. After setting the heap value to 0, the project would still compile without error but would fail to run as the memory allocation would fail during OSInit().

If presented with a warning similar to the above, select Make a Copy. Any edits made to header files in the SDK would affect all future Micrium OS projects.

#define  RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN  DEF_ENABLED

After disabling the heap, Micrium OS needs to be set to disable the default configurations for all internal data structures and task stacks. Open up rtos_cfg.h and locate the #define for RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN. Change it to DEF_ENABLED to disable the default configurations. At this point, compilation of the project will fail due to a number of InitCfg structures not being set.

Configuration Structs

The rest of the code for this walk-through will be written in ex_main.c. There are three structures that must be defined: OS_InitCfg, Common_InitCfg, and PlatformMgr_InitCfg. These structures are used internally in Micrium OS and by setting RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN to DEF_ENABLED, the default configs for these structs has been removed and must be implemented by the developer.

OS Config Structs

struct  os_init_cfg {
    OS_STACK_CFG         ISR;
    OS_MSG_SIZE          MsgPoolSize;
    CPU_STK_SIZE         TaskStkLimit;
    OS_STACK_CFG         IdleTask;
    OS_TASK_CFG          StatTaskCfg;
    OS_TASK_CFG          TickTaskCfg;
    OS_TASK_CFG          TmrTaskCfg;
    MEM_SEG             *MemSeg;
};

The OS_INIT_CFG structure defines all of Micrium OS Kernel’s runtime configuration. It contains the stack config for all of the internal tasks (Idle, Tick, Timer, Stat), as well as the interrupt stack and an internal memory segment for internal kernel objects. The TaskStkLimit parameter will be set to zero as it is no longer used, but remains for backwards compatibility with previous versions. If an internal task has been disabled in os_cfg.h, that task’s configuration can be omitted from the OS_InitCfg.

struct  os_task_cfg {
    CPU_STK             *StkBasePtr;
    CPU_STK_SIZE         StkSize;
    OS_PRIO              Prio;
    OS_RATE_HZ           RateHz;
};

The OS_TASK_CFG structure is used to configure the Tick task, Statistics task and the Timer task. Each task will need a stack size and memory allocated for it, a priority set and the rate that the task will run at. Its important to remember that the stack size is not in bytes but stack units which are set to the width of the CPU (32 bits in this case); so a stack size of 128 stack units results in a 512 byte stack. Also, the timer task and stat task can not have a rate higher than the tick task due to being based off of the OS tick rate.

struct  os_stack_cfg {
    CPU_STK             *StkBasePtr;
    CPU_STK_SIZE         StkSize;
};

The OS_STACK_CFG structure is used for the Idle task and the ISR stack. Neither task has a priority (idle task defaults to the lowest priority, ISR is for interrupt context only) or rate associated with the task, so it only contains the stack size and location.

Common Config Struct

typedef  struct  common_init_cfg {
    MEM_SEG             *CommonMemSegPtr;

#if (RTOS_CFG_LOG_EN == DEF_ENABLED)
    COMMON_CFG_LOGGING   LoggingCfg;
    MEM_SEG             *LoggingMemSegPtr;
#endif
} COMMON_INIT_CFG;

The COMMON_INIT_CFG struct is used during the init of the common module. Typically the CommonMemSegPtr is set to DEF_NULL and logging is disabled. For this example, this will also be the case.

Platform Manager Struct

typedef  struct  platform_mgr_init_cfg {
    CPU_SIZE_T  PoolBlkQtyInit;
    CPU_SIZE_T  PoolBlkQtyMax;
} PLATFORM_MGR_INIT_CFG;

The PLATFORM_MGR_INIT_CFG struct is used for the initialization of the platform manager module. This module is used to describe hardware capabilities of peripherals such as network interfaces, USB interfaces or file systems.  Normally the platform manager pulls in memory from the heap but for a kernel-only project no memory is needed so the number of blocks can be set to zero. Unfortunately even though the platform manager is not used in a kernel-only project, a configuration is still required.

Configuring Micrium OS Blink

Using the information covered in the previous section, this part will cover how to configure ex_main.c in the Micrium OS Blink project to use these configuration structures.

Kernel Config Defines

This section covers only using #defines to set configurations. Since all internal tasks are configurable these defines will check to see if the tasks are enabled before adding them to the overall OS config.

//////////////////////////////
// Micrium OS Configuration //
//////////////////////////////
#define  TICK_TASK_RATE_HZ                  1000u
#define  STAT_TASK_RATE_HZ	                 100u
#define  TIMER_TASK_RATE_HZ                   10u
#define  MSG_POOL_ELEMENTS                     5u

/////////////////////
// Task Priorities //
/////////////////////
#define  TICK_TASK_PRIO                        0u
#define  TIMER_TASK_PRIO                       4u
#define  STAT_TASK_PRIO                        5u
#define  EX_MAIN_START_TASK_PRIO              21u

//////////////////////
// Task Stack Sizes //
//////////////////////
#define  TICK_TASK_STK_SIZE                  128u
#define  STAT_TASK_STK_SIZE                  128u
#define  TIMER_TASK_STK_SIZE                 128u
#define  IDLE_TASK_STK_SIZE                  128u
#define  ISR_STK_SIZE                        128u
#define  EX_MAIN_START_TASK_STK_SIZE         512u

The first step is to set some defines for the kernel configuration. This includes the task stack sizes and priorities, the internal task rates and the message pool elements.

• Task priorities can range from 0 to OS_CFG_PRIO_MAX (defined in os_cfg.h) with 0 being the highest priority.
• The task stack sizes are specified in stack units which correspond to the width of the CPU, not bytes, so it is important to remember that a stack size of 128 stack units is actually 512 bytes.
• The rates for the tick, timer and stat task are specified in hertz. Typical tick rate for the tick task is 1000Hz, typical timer task rate is 100Hz and typical stat task rate is 10Hz.

////////////////////////////////
// Message Pool Configuration //
////////////////////////////////

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

The next section to define is the message pool configuration. The message pool is used for the message queues and the number of message pool elements should always match the total number of queue entries in the entire system. For example if there is one OS Queue that has 10 entries and one OS Task Queue with 20 entries, MSG_POOL_ELEMENTS should be set to 30 to guarantee there is enough entries available for all of the message queues.

/////////////////////////////
// Tick Task Configuration //
/////////////////////////////
#if (OS_CFG_TASK_TICK_EN == DEF_ENABLED)
#define  TICK_TASK_CFG                  .TickTaskCfg =                        \
                                        {                                     \
                                            .StkBasePtr = &TickTaskStk[0],    \
                                            .StkSize    = TICK_TASK_STK_SIZE, \
                                            .Prio       = TICK_TASK_PRIO,     \
                                            .RateHz     = TICK_TASK_RATE_HZ   \
                                        },
#else
#define  TICK_TASK_CFG
#endif

/////////////////////////////
// Stat Task Configuration //
/////////////////////////////
#if (OS_CFG_STAT_TASK_EN == DEF_ENABLED)
#define  STAT_TASK_CFG                  .StatTaskCfg =                        \
                                        {                                     \
                                            .StkBasePtr = &StatTaskStk[0],    \
                                            .StkSize    = STAT_TASK_STK_SIZE, \
                                            .Prio       = STAT_TASK_PRIO,     \
                                            .RateHz     = STAT_TASK_RATE_HZ   \
                                        },
#else
#define  STAT_TASK_CFG
#endif

//////////////////////////////
// Timer Task Configuration //
//////////////////////////////
#if (OS_CFG_TMR_EN == DEF_ENABLED)
#define  TIMER_TASK_CFG                 .TmrTaskCfg =                         \
                                        {                                     \
                                            .StkBasePtr = &TimerTaskStk[0],   \
                                            .StkSize    = TIMER_TASK_STK_SIZE,\
                                            .Prio       = TIMER_TASK_PRIO,    \
                                            .RateHz     = TIMER_TASK_RATE_HZ  \
                                        },
#else
#define  TIMER_TASK_CFG
#endif

The Tick Task, Stat Task and Timer Task all use the OS_TASK_CFG structure so using the values defined from the Micrium OS Configuration section above, their declarations are fairly similar. The only variable not yet covered in these structs is the stack pointer. The stack pointer variables will be declared a littler farther down in ex_main.c, right now this is just #defines to be included later on.

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

///////////////////////
// ISR Configuration //
///////////////////////
#define  ISR_CFG                       .ISR =                                 \
                                       {                                      \
                                           .StkBasePtr  = &ISRStack[0],       \
                                           .StkSize     = ISR_STK_SIZE        \
                                       },

The idle task and ISR configuration both use OS_STACK_CFG. Similar to the ones using OS_TASK_CFG, these configs use the stack size defines from the Micrium OS Configuration section above and the stack variables will be defined later on.

////////////////////////////////
// Micrium OS  Configurations //
////////////////////////////////
#define  OS_INIT_CFG_APP            {                                \
						                ISR_CFG                      \
							            IDLE_TASK_CFG                \
							            TICK_TASK_CFG                \
							            STAT_TASK_CFG                \
							            TIMER_TASK_CFG               \
                                        MSG_POOL_CFG                 \
                                        .TaskStkLimit = 0u,          \
                                    }

#define  COMMON_INIT_CFG_APP        {                                \
                                        .CommonMemSegPtr = DEF_NULL  \
                                    }

#define  PLATFORM_MGR_INIT_CFG_APP  {                                \
                                        .PoolBlkQtyInit = 0u,        \
                                        .PoolBlkQtyMax  = 0u         \
                                    }

Using the #defines for the message pool, internal tasks and the ISR stack, the OS_INIT_CFG_APP define can be set. As mentioned earlier the TaskStkLimit can be set to zero as it is no longer used.

The COMMON_INIT_CFG_APP define only has one variable, CommonMemSegPtr defined. The other variables in the struct are only enabled if the logging module is enabled. Since no modules in common need memory for this application the MemSegPtr will be set to DEF_NULL to signal it is not in use.

The PLATFORM_MSG_INIT_CFG_APP define is similar to COMMON_INIT_CFG_APP, the two fields in it can be set to zero as its not needed for this application.

Kernel Config Variables

Now that the defines have all been set, the stacks need to be created and the config defines need to be set to the necessary variables for Micrium OS Kernel to pull them in.

//////////////////////////
// Micrium OS Variables //
//////////////////////////

#if (OS_CFG_TASK_IDLE_EN == DEF_ENABLED)
static  CPU_STK  IdleTaskStk[IDLE_TASK_STK_SIZE];
#endif

#if (OS_CFG_TASK_TICK_EN == DEF_ENABLED)
static  CPU_STK  TickTaskStk[TICK_TASK_STK_SIZE];
#endif

#if (OS_CFG_STAT_TASK_EN == DEF_ENABLED)
static  CPU_STK  StatTaskStk[STAT_TASK_STK_SIZE];
#endif

#if (OS_CFG_TMR_EN == DEF_ENABLED)
static  CPU_STK  TimerTaskStk[TIMER_TASK_STK_SIZE];
#endif

static  CPU_STK  ISRStack[ISR_STK_SIZE];

#if (MSG_POOL_ELEMENTS > 0)
static  MEM_SEG    MsgPoolMemSeg;
static  CPU_INT08U MsgPoolMem[MSG_POOL_SIZE];
#endif

const   OS_INIT_CFG             OS_InitCfg          = OS_INIT_CFG_APP;
const   COMMON_INIT_CFG         Common_InitCfg      = COMMON_INIT_CFG_APP;
const   PLATFORM_MGR_INIT_CFG   PlatformMgr_InitCfg = PLATFORM_MGR_INIT_CFG_APP;

The stack variables will only be created if the tasks are enabled in os_cfg.h. If the task is enabled, the size is pulled in from the configuration above. The ISR stack is always created because its needed in every Micrium OS project. The message pool is only created if it is needed.

The OS_INIT_CFG, COMMON_INIT_CFG and PLATFORM_MGR_INIT_CFG structs MUST be named OS_InitCfg, Common_InitCfg and PlatformMgr_InitCfg. This is due to the RTOS_CFG_EXTERNALIZE_OPTIONAL_CFG_EN define set in the rtos_cfg.h. Micrium OS uses variables by these names to initialize the modules and if they are not defined in the user application, there will be compilation errors as the internal default config has been removed by the define in rtos_cfg.h.

Inits in main() and includes

After setting up all of the necessary variables for the config structs, two more changes must be made. 

#include  

The ex_main.c file needs to have the platform manager header file added to its list of includes. A compilation error will occur without this extra include.

int  main (void)
{
    RTOS_ERR  err;

#if (MSG_POOL_ELEMENTS > 0)
    Mem_SegCreate(          "Msg Pool Mem",                     /* Create the Message Pool memory 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);
#endif

    ...
}

The last change that needs to be made to ex_main.c is the addition of a Memory Segment Create. The OS config only allocates space for a memory segment. When the application starts up, its necessary to make a call to Mem_SegCreate to create the memory segment BEFORE the OSInit call is made. OSInit uses the memory segment and if it has not been initialized the application will fail to run.  

Building the new Blink project and comparing results

After all of these changes have been made to the Micrium OS Blink project, the project can be built by right clicking on the project name and selecting Build Project as shown above. 

Default Micrium OS Blink project RAM/ROM usage

Micrium OS Blink project RAM/ROM usage after adding external configuration

After building the project the console window will show the final sizes for RAM and ROM. As seen in the images above, the RAM usage is reduced from 24KB to just under 19KB simply by moving the internal tasks from the heap to the external config instead. 

The default RAM usage in this project is rather high to begin with because it includes SEGGER's SystemView code and the application task stack size is very large for such a simple project (currently set to 512 stack units/2048 bytes). To further reduce RAM usage in this project its possible to:

• Disable internal tasks that are not needed via os_cfg.h.
• Disable SEGGER SystemView code via os_cfg.h and os_cfg_trace.h
• Shrink the Main Start Task Stack Size 
• Reuse CSTACK after the OS has started up

The ex_main.c file is attached to this post and feel free to ask any questions in the forum below.

Recently, we had the chance to talk to Jim Stratigos, founder and CTO of Cognosos, an IoT start-up that has solved a big problem for automotive car dealers and auction operators. Fleet lots such as these – along with vehicle processing centers - can span hundreds of acres, across multiple locations, and can hold anywhere from 1,000-25,000 cars on-site at any given moment, creating significant challenges in locating and tracking these valuable assets. Cars are moved regularly for reconditioning, repairs, test drives, or to get ready for auctioning. Up until now, lot operators used expensive and often unreliable asset tracking technology such as RFID or Wi-Fi, or spent hours trying to manually locate cars throughout the day. Cognosos has completely changed the experience by creating an IoT wireless inventory tracking solution, allowing users to do quick searches online or on smartphones and see in real time the location and movement history of any car on the lot.

Jim explains below how the idea came about, what his team has learned since launching 18 months ago, and shares new solutions the company plans to tackle in the near future.

 

 

How did Cognosos get started?

In 2012, in the days before IoT, my two co-founders and I were looking at wireless sensor networks. We saw a lot of academic research in this area, yet few commercial deployments. We had some ideas to make the transition from the lab to the real-world happen. One of the research areas of interest to us was software defined radio (SDR), which has been used in radio astronomy for decades. We realized we could apply the same technology to real-world problems, such as extending the range and battery life of wireless networks. With this idea in mind, we reached out to Georgia Tech (Jim is an alumni and has mentored university start-ups).  We started working with the Smart Antenna Research Lab within the School of Electrical and Computer Engineering at Georgia Tech. We helped the group raise some grant funding to research how to use SDR and cloud-based signal processing to make wireless networks go further and have longer battery life.

 

Tell me a little bit about SDR – how does this solve range issues?

The nice thing about SDR is that it allows the physical layer of a wireless communications channel to be totally determined by software; therefore, it provides engineers with a clean slate without being constrained by silicon. That’s why this approach was attractive, we were able to pick frequencies, for example, with superior outdoor propagation, we could design our own modulation and coding formats, etc. with the intent to optimize all aspects of the performance. Basically, it gives you a platform to write your way into a physical wireless layer without having to develop custom chips. At the same time, an SDR-based wireless network can be very robust to interference and achieve an order of magnitude higher channel utilization than common wireless technologies.

 

Did you have a business solution in mind for the technology? Was there a specific problem you saw in a particular market, or did the application come later?

It came later. We were aware of a general class of problems facing agriculture, energy management, waste management, and water management, which all seemed to be a fit for low-cost wireless sensor networks. But it wasn’t clear five years ago which one would be commercially viable. We had the good fortune of having some really smart people, yet not much money, but we were able to rapidly prototype potential applications and show them to potential investors and customers. We were told over and over again that it looked interesting, but it was not really important. So we eventually pivoted and discovered there was a real need in the automotive industry to use wireless sensor networks to actually find cars. As you know, it’s normal for early stage companies to pivot, and we certainly did. We moved away from a broad “we can do anything wireless business model,” and went after a specific problem in a specific industry.

 

Why did you select the automotive industry?

It was a need articulated by our first customer, Manheim Auctions, a division of Cox Automotive. They came to us with the problem of losing cars. We assumed people were stealing them, but they explained it was the sheer amount of cars in one place combined with the fact that they had to be moved regularly for repairs, auction lane placement, etc. Most of the larger companies like Manheim have been trying all kinds of technologies to solve this problem, such as bar codes, RFIDs and even Wi-FI tracking and cellular systems, yet none of them were cost-effective or could scale. Here was a problem we didn’t even know existed.

 

What type of business impact feedback are you hearing from customers?

One customer told us recently that the typical 3-4 hours it took to locate a set of cars was reduced to 30 minutes. We have a lot of great data saying its reducing costs and improving the customers’ experience. We are also branching out into other markets where knowing the location of high valued assets is critical to driving customer satisfaction and reducing costs.

 

When you were developing the platform, were there any unforeseen design challenges?

One of the things that stood out to me is our use of GPS to find the location of the car. Everyone knows GPS receivers demand a lot of power, and we are dealing with battery powered devices, so you don’t want to leave the receiver on any longer than you have to. We naively thought early on that all we had to do was turn the receiver on, get the location, and you’re done.  It’s actually much, much more complicated than that. Because of this issue, we ended up writing sophisticated algorithms to take the GPS data from the receiver and determine when it was accurate enough to turn off the receiver. 

 

Tell me about the device itself. How simple is it for the operator to get up and running, and what’s the day-to-day interaction with the equipment?

We put a lot of effort into making it as simple as possible because our customers are not engineers. The user simply scans or types in the VIN number of the car, SKU/unit number, or description into a smart phone, and the car will show up on a map with instructions on how to get to it. Our RadioTrax device is placed on the visor of every car on the lot. It sends a sub-GHz radio message using our patented wireless technology that includes the GPS location of the car any time the car moves by using an accelerometer to detect motion. The devices are also upgradeable over-the-air – we have a unique OTA firmware update technology that simplifies the challenge of updating the firmware. We can do thousands of devices at once.

From an installation standpoint its very simple – our gateways are as easy to install as a router and connect to a simple roof-mounted antenna . We either use our own staff or contract third-party installation groups – some of our customers have even done the installation themselves.  

We have both web and mobile applications, which is paramount because the interface is all the customer is going to see.

 

What’s your experience with Silicon Labs’ Flex Gecko?

In the early days, all of our prototypes were conventional wireless devices with a separate MCU, separate transceiver, drivers, etc. Then we became aware of the Silicon Labs Leopard Gecko, which has a transceiver and an MCU in the same package. When you’re in this business, anything you can do to reduce the number of components and the cost of device, you jump on. Certainly following the introduction of the Flex Gecko product line was an opportunity for us to further reduce the size, cost and complexity of our devices.

Silicon Labs’ level of support has been excellent. It’s important when you’re a small shop like us to work with a vendor like Silicon Labs who is willing to give you the support that you need - answer questions, jump in when there is a problem identified, get the samples you need quickly - that’s critical.

 

What are some other applications you are interested in pursuing?

When it comes to tracking assets outdoors, there are a number of other sub-verticals similar to automotive. For example, imagine any large outdoor area on hundreds or thousands of acres maintaining valuable things with wheels on them, such as construction sites, airports, ports, etc. We also see plenty of opportunities for our technology to be deployed indoors, such as buildings, retails, sports arenas and healthcare facilities.

 

What do you think IoT holds for companies managing large amounts of assets? Do you think IoT could manage large scale equipment as a subscription service?

It’s definitely coming. One of the trends we see emerging is the IoT industry encroaching on what was traditionally the RFID market. For example, RFID technologies scan equipment into a job site, but it can’t tell the operator where the tool is actually located on the site.  The IoT curve is heading in the right direction, thanks to Moore’s Law and efforts from companies like Silicon Labs who integrate more and more functions onto a single silicon die. 

Introduction

In this month’s post, I will review a basic, but sometimes overlooked, best practice necessary for making proper output clock measurements. 

Those of you familiar with our clock IC evaluation boards know that we generally AC-couple our input and output clocks and provide separate SMA RF connectors for each polarity of the differential clock signal.  This is the most flexible approach in terms of being able to immediately connect output clocks to single-ended 50 Ω inputs on test equipment such as frequency counters, oscilloscopes, phase noise analyzers, spectrum analyzers, etc. The AC-coupling capacitors keep us from attempting to impose a DC bias on test equipment inputs and vice-versa. 

Here’s the best practice rule:  Both polarities of differential output buffers should be terminated when making measurements. This include the polarity that is not being measured.  What are the consequences for not doing this?  That is the subject of this article, The Case of the Half-terminated Differential Output Clock.  

 

Example Phase Noise Measurement

First, let’s work in the frequency domain.  Consider the phase noise plot below. It is from OUT0 of an Si5345 evaluation board for these 2 cases annotated in the screen capture.

1. OUT0B is routed to a 50 Ω oscilloscope input. This is the properly (fully) terminated case.   
2. OUT0B is routed to a 1 MΩ oscilloscope input. This is the half-terminated case.

The output format is 2.5V LVDS AC-coupled with the nominal frequency set to 161.1328125 MHz based on the current CBPro sample plan.  The board is actually in Free Run mode just to minimize the bench set-up.

In the first case, the 12 kHz to 20 MHz RMS phase jitter measured 89.512 fs.  This curve was saved in memory.  In the second case, the 12 kHz to 20 MHz RMS phase jitter increased to 124.16 fs. That’s not bad but the relative increase is about 39%. That is a significant impact.

 

Example Oscilloscope Measurements

Next we’ll work in the time domain.  Consider the oscilloscope plots below. The top trace is OUT0 assigned to channel 2, OUT0B is assigned to channel 3, and the common mode (CM) voltage is computed as f1. Note that since we are on the far side of the AC-coupling capacitor, we aren’t measuring the DC value but rather the noise represented by the average value of AC-coupled OUT0 and OUT0B.  (The difference in scales here is to accommodate the half-terminated case and is not relevant to the calculation.)

In this first screen capture, both oscilloscope inputs are set to 50 Ω. The waveform shapes look reasonable and the CM noise is about 38mVpp on average.

 

In this second screen capture, the only difference is that OUT0B’s input has been set to 1 MΩ. Now both waveform shapes are larger and distorted.  Further, the CM noise has increased to about 344 mVpp on average.  This is almost an order of magnitude increase in CM noise.

Note that in these experiments, the time domain measurements are much more striking than the frequency domain measurements.  The phase noise differences might even have been glossed over in automated testing.  A good argument for a lab bench to have both types of instrumentation! 

 

Root Cause

Why is terminating only half of the output clock having such an impact? We don’t need to know all the details of the buffer’s design but a simplified model will provide some insight. Consider the figure below.

Components in the left hand side box are internal to the IC and illustrate a simplified model of a CML or Current Mode Logic driver that can be made compatible with several swing formats.  The AC-coupling caps are usually on the EVB and the load resistor R shown here is typically 50 Ω as for test equipment. Transmission lines are not illustrated but PCB traces and coaxial cable can all be assumed to be nominal 50 Ω.  (The AC coupled load terminations can also be regarded as 100 Ω differential across CLKP and CLKN where the center-tap CM voltage is GND.)

Some notable features include the following:

1. Current source Ibias sinks continuously.  To first order, current is switched through one of the input NMOS transistors when turned fully on depending on the input signals.
2. The internal termination resistors Rint are normally ~ R or perhaps 2*R to save current.
3. Common mode voltage Vcm is sensed at the center-point of 2 resistors Rcm. The value of these resistors is usually >> R, for example on the order of kΩ.
4. An op amp drives the Bias network so that the sensed Vcm is equal to Vref.
5. Each output voltage swing is based on Vsupply minus the voltage drop swing across Rint as the current changes.

The driver is symmetric and designed for specific DC biasing over expected terminated operation. DC-coupled loads would need to have a common voltage exactly equal to Vcm in order to not impact the intended bias.  This is why we need to AC-couple to instrument loads.

However, even if we are AC-coupled, if we don’t have symmetric loads, then the driver will be imbalanced and the result is that the output common mode voltage Vcm will be modulated which can impact biasing and operation.  In this particular case the CM feedback circuit is clearly unable to keep up. The performance of the measured terminated half-circuit is degraded by the operation of the unterminated half-circuit.  

 

Crosstalk

Half-terminated differential outputs can even impact neighboring output driver performance in subtle ways. In this experiment, we continue to work with an Si5345 EVB as before.  The phase noise plot below is for OUT0 set to nominal 161.1328125 MHz as before with OUT0B terminated.  Adjacent channel OUT1/OUT1B is set to nominal 2 times that or 322.265625 MHz. Both polarities are properly terminated. The 12 kHz to 20 MHz phase jitter measured 94.32 fs averaged over 5 sweeps. Spurs are depicted in dBc so we can see the details.

 

The next phase noise plot is for OUT0 again, under previous conditions, except this time neighboring output OUT1B is unterminated. There is not a significant increase in phase jitter. However, we have clearly introduced 2 new spurs above the powerline frequencies region as annotated below.

These were identified in the instrument spur list as 140.374 kHz at -104.874 dBc and 4.90 MHz at -108.235 dBc. There is no obvious mathematical relationship yet this is a consistent result for this board and configuration. For wireless applications interested in the reason for every spur we can at least attribute these to the adjacent channel’s improper termination.

 

Termination Options

There are a number of termination options for our evaluation boards, and similar application boards, depending on what’s available at your bench.  These include:

1. Use a differential limiting amplifier or balun to convert a differential clock in to a single-ended clock.
2. Connect each polarity in to a 50 Ω instrument input.
3. Terminate each unmeasured polarity using an SMA 50 RF load termination.

If one is attempting to make careful measurements on a 12 output evaluation board that could call for 24 – 1 or 23 SMA terminations. That’s a fair number. So what to do?

One approach is to just make sure that the nearest channel output clocks to the measured clock are terminated. That cuts the quantity down quite a lot. The other is to use RF pads or attenuators as described in the next section.

 

Attenuators as Lab Expedient Terminations

In our lab we have many multi-channel clock EVBs which can consume a large quantity of terminations during testing. If a lot of us are working in the lab simultaneously, we can’t always terminate every clock exactly the way we would like.  So another approach is to use a high value RF pad or attenuator as a lab expedient termination.

Commercially available attenuators are PI attenuators made up of a 3-resistor network. That is, the resistor network resembles the Greek letter "pi".  The first resistor R1 is shunted to GND, followed by R2 in series, followed by another R1 shunted to GND.

Using an online calculator such as at https://www.microwaves101.com/calculators/858-attenuator-calculator we can calculate the R1 and R2 values and the resulting effective Rload assuming no connection past the attenuator. The table below lists the effective load using 6 dB, 10 dB, and 20 dB terminations.

You can see that for increasing attenuator values the effective impedance looking in to the attenuator alone increases.  By 20 dB attenuation it’s an almost perfect termination. This can be very handy at times.  The results using this technique are indistinguishable from purpose-built terminations.

 

Conclusion

I hope you have enjoyed this Timing 101 article. I’ve given you some insight as to why it’s a best practice to terminate even unmeasured differential outputs.  And provided a tip for using an attenuator as a lab expedient termination if necessary.

As always, if you have topic suggestions, or there are questions you would like answered, appropriate for this blog, please send them to kevin.smith@silabs.com with the words Timing 101 in the subject line. I will give them consideration and see if I can fit them in. Thanks for reading. Keep calm and clock on.

Cheers,

Kevin

 

Below are the other Timing 101 articles:

Timing 101: The Case of the (Apparently) Jittery Jitter Attenuated Clock

Timing 101: The Case of the Ouroboros Clock

Timing 101: The Case of the Jitterier Divided-Down Clock

Timing 101: The Case of the Split Termination

Timing 101: The Case of the PLL’s VCO High Pass Transfer Function

Timing 101: The Case of the Spurious Phase Noise Part I

Timing 101: The Case of the Spurious Phase Noise Part II

Timing 101 The Case of the Cycle-to-Cycle Jitter Rule of Thumb

Timing 101: The Case of the Discrepant Scope Measurements

Timing 101: The Case of the Half-terminated Differential Output Clock

 

 

 

 

 

 

 

 

This summer, Silicon Labs had more than one hundred students participate in our global internship program, in offices around the world - from Finland to Singapore to the US and beyond. Eleven of those interns were a part of the team in Boston. We’re excited to share a day in the life of our Boston interns, shining the spotlight on applications engineering interns Anusha Datar and Matt Hagan, as well as high school intern John Mikulski.

 

 

 

 

As engineering interns, they often began their mornings working on a variety of projects. John’s focus this summer was creating Fuzz Tests with the Java simulator. Anusha spent her time working on the Zigbee 3.0 trust center replacement. Her favorite part of the internship was having “a great opportunity to learn and grow in terms of both (her) technical and personal professional development,” and “getting a lot better at ping pong.” Check out her Knowledge Base article in our community to review her findings on different trust center replacement methods.

 

 

During lunch, the interns often explored nearby Boston attractions, or simply lounged on the comfortable office furniture. While they didn’t have a favorite restaurant, they tried many new places throughout the city, which was a cool experience. Like their Austin counterparts, they enjoyed competing in friendly games of ping pong. Conveniently, there was also a pinball machine located in the open space that they enjoy playing with as well.

 

 

Throughout the summer, interns, new college grads (NCGs), and managers participated in teambuilding activities. During one afternoon trip, interns and NCGs took a trip to Fort Warren, a historic fort on Georges Island.

 

 

During their walking tour, they stopped to explore and pose for group photos in front of the island’s most famous landmarks, including the Guard House where fort security was managed during the Civil War. 

 

 

At the end of their trip, everyone gathered near the island pier and wharf area where they enjoyed the scenic views of the surrounding islands and the Boston Harbor.

 

 

There were often evening activities as well. They joined Silicon Labs employees who participated in the Boston J.P. Morgan Chase Corporate Challenge, benefiting Boston Children's Hospital. This was the 15th year in a row we’ve participated, and we had record attendance this year with 31 Silicon Labs participants! The interns also had opportunities to participate in health and wellness and volunteer activities, so they could give back to the community.

 

Sinduja Vijayakumar joined Silicon Labs in August 2017 as an application engineer in Singapore. Her role allows her to develop software, test products, and work with her fellow validation team members to identify and tackle issues. Sinduja looks forward to coming into the office every day because she can discover something new and interact closely with other smart engineers. “I love to see the great work of my team in the products that we produce.”

 

 

She enjoys learning from everyone and everything around her, so being a part of a team that communicates and works well with each other is something she appreciates. “I am always able to ask members of my team a question and get great answers from them.” Doing the right thing is something that Sinduja values, and she says it is what connects her with Silicon Labs the most. “I see, on my team and in the company, we all do the right thing, and it helps us design great products for our customers.”

 

When asked what she would like to have with her, if stranded on a deserted island, Sinduja answered, “Something to write on and a pen.” She said she would use it to make a map and find her way home.

 

Thank you, Sinduja, for working hard and being a team player. We’re happy to have such an amazing engineer on our team!

 

Several years ago, we had the chance to talk to Rich Morris, the founder of Broodminder, a start-up company based in Madison, Wisconsin. Rich created a rugged IoT device to help backyard beekeepers raise more healthy bee hives.

As evidenced by numerous studies over recent years, bee populations have been on the decline for the past two decades. As pollinators of numerous crops, honeybees are averaging more than 33 percent population loss per year. Most experts conclude the loss is caused by a variety of factors, including pesticides, habitat loss, and disease.

Three years ago, Rich took matters into his own hands and raised nearly $30,000 to start his company with an Indiegogo campaign. An avid beekeeper and electrical engineer for more than three decades, Rich created a temperature and humidity measuring system using the Silicon Labs BLE113 Bluetooth Smart Module to measure the overall health of a hive. The following year they added a smart hive scale to the mix.

Hive temperature is critical – a healthy hive where bees are brooding generally maintains a temperature of 95 degrees Fahrenheit. If the temperature variates much in either direction, it typically signifies there is something wrong with the queen. Monitoring bee hives using Broodminder’s IoT technology makes it possible for beekeepers to keep tabs on the bees without disrupting brooding (larvae and bee development) or honey production. If the temperature data reflects problems, the beekeeper can intervene by replacing the queen, add more bees, or whatever else is required to maintain a healthy hive. The device also alerts beekeepers when the honey-flow process starts, creating a mechanism where they can begin servicing the hives for honey at the appropriate time.

Up until this point, if a beekeeper needed to obtain this data, they had to open and/or take apart the hive, which disrupted the brooding and honey-making process, and posed a risk to the hives’ bee and honey yields.

New Hive Monitor, Half the Cost

Broodminder has sold close to 6,000, $65 internal temperature hive monitors and 3,000, $179 hive scales, enabling thousands of beekeepers to improve the brooding process without dismantling the hive.

This month, Broodminder is launching a new version of the product focused exclusively on temperature measurement at half the price of the original. Broodminder built the new product using the Silicon Labs Blue Gecko BGM11S SiP Bluetooth module, which Rich explained was crucial in allowing the product to be built more cost-effectively thanks to the SiP’s size, price point, and ease of use. Cost is especially important because Broodminder’s manufacturing is entirely local and the company only uses components from the Madison area.

Beekeepers Unite in the Cloud

One of the key benefits of the Broodminder device is it connects to smart devices via Bluetooth, so users can quickly acquire data from their hives and publish the data to the cloud, creating a public database of hive diagnostics. Data is sent to the cloud by either the beekeeper’s cell phone or a dedicated hub created using the Silicon Labs Bluegiga BLE121 module, helping beekeepers track, maintain, and improve the health of bee populations.

Rich said his team is now just starting to find important data patterns among hive owners in the cloud, and he’s optimistic about the future. He says citizen scientist backyard beekeepers are generating and sharing increasing amounts of data at their public domain site BeeCounted.org, and he believes the next step for beekeeping cloud data will be applying AI technology to improve hive outcomes.

Regardless of the future, Broodminder has already made an impact in improving hive habitats, and it’s exciting for Silicon Labs to see our technology applied to environmental conservation.