Official Blog of Silicon Labs

      • The Non-Linear Engineer: IoT Hero Michele Grieshaber on Being a Woman in STEM

        deirdrewalsh | 05/149/2015 | 04:35 PM

        IoT Hero - Michele


        A big part of the reason I joined Silicon Labs was the opportunity to work for Chief Marketing Officer and IoT Hero Michele Grieshaber. She possesses a strong passion for her work as an engineer, educator, marketing expert, and community leader.


        In honor of this week’s #ThankYouSTEMwomen conversation on Twitter, I sat down with her and discussed STEM, the Internet of Things, and the future of technology.  


        Why did you go into engineering?

        I was always asking questions and I wanted to get my hands dirty and understand how things work. So, some of my favorite trips with my family when I was younger were to science museums where you can test wind resistance and find out how lightning works. I would spend hours in our basement building cities out of blocks, and then creating stories about the people and the things that lived in that city.

        Engineering is really the perfect solution to having a split personality around science and creativity because the recipe for engineering contains both.


        Michele G Quote.jpgWhat technology or trend is most exciting to you today? 

        The most exciting thing that’s going on right now is the Internet of Things, and it’s because it has the power to make our lives better. All of us have a way to relate to the Internet of Things. I’m wearing one right now. These wearable devices tell me if I have enough steps in or if I have to go walk the dog again. If I’m extra-cranky one day I can look and see if I’ve actually had a good enough night’s sleep.


        What’s the best advice you can offer other women in STEM roles?

        Just be yourselves. Don’t be who you think people expect you to be—be who you are. Several of my professors would refer to me as the “non-linear” one because most engineers are linear thinkers, but that wasn’t something that really occurred to me. I’d still get the right answers on tests, but I’d just derive them a different way.


        What do you think the future holds?

        In this world, if we’re going to succeed in making this place better, we all have to come to the table with our own gifts. It’s those differences coming together that allow for real innovation to happen.



        Watch the 2-minute interview with Michele below.




        Who is a woman in STEM that you are thankful for?  Comment below. 

      • Controlling External Devices: Part 2: Build up an External LED Circuit

        lynchtron | 05/146/2015 | 02:35 PM


        You configured your Starter Kit to control external devices in the first part of chapter four, so now it’s time to learn how to create the LED circuit itself on the breadboard.


        LED Theory

        When you wrote code to blink an LED in the first lesson, you really just wrote software.  You didn’t build the LED circuit yourself.  We can learn from that lesson however because the circuit that we are going to build here is at our disposal.  We have the schematics!  In Simplicity Studio, from the welcome screen, you can click on the tile that says Kit Documentation.  When you open that tile, you will see an entry for the Wonder Gecko Starter Kit and the Schematics for the board.  In the section for User Interface on page two, you can see the LED circuit for the LED that you controlled during that first lesson.



        LED Circuit on the Wonder Gecko Starter Kit


        The bus on the left called UIF_LED[1..0] can be traced back to port E, pins PE2 and PE3 on the MCU.  (If you are curious, you can see that mapping on schematic page 3.)


        In this circuit, the Starter Kit designers placed each of the User LEDs in series with a current limiting resistor.  This resistor in series with the LED limits the amount of current that can flow through the entire circuit.  Without these resistors, there is the potential to deliver too much current that could burn out the LED.


        If you recall from the last lesson, we set the GPIO for the User LED to a high state to provide power to the LED.  The MCU didn’t create that voltage, it merely acted like a switch that we controlled through our software.  On one side of the switch was the LED circuit and on the other side was the source voltage for the MCU, which is 3.3V.


        Equivalent Circuit of MCU as Switch



        The maximum amount of current than can flow through this circuit can be calculated using Ohm’s Law:

        V = IR

        Where V = Voltage, I = Current and R = Resistance. 


        Since the MCU on the Starter Kit has a source voltage of 3.3V and we can see here that the resistors are 3k-ohm, by rearranging (remember algebra?) we can calculate the maximum current that can flow through this entire circuit is:


        I = V / R = 3.3 / 3000 = 0.0011A or 1.1mA

        The 1.1mA of current is a maximum value, as if the LED had zero ohms of resistance like a piece of hookup wire, which it is not.  The LED has its own internal resistance, so that limits the current flowing through the circuit even more.  For resistances in series with each other, they add up to create a bigger overall resistor between power and ground.  The resistor is just a protection device to ensure that the LED doesn’t take more energy than is necessary for an indicator light. 


        The LED has a polarity that is shown in the following figure.  In order to conduct electricity and emit light, it must be installed in the correct direction.  Nothing bad will happen if you put it in backwards, but it won’t light up.  In order for the LED to work, the anode has to be at a higher voltage than the cathode.  How much voltage?  The specs on each LED will tell you this in the forward voltage parameter but in general you will usually find that LED’s are in the range of 2V to 3.3V.  You could operate them with slightly less voltage than that, but you should not dim an LED by reducing the voltage.  We will cover the proper way to dim LEDs in the next lesson.  You can also drive them from higher voltages, but in order to do that without destroying the LED, you will need to use a current-limiting resistor.



        LED Schematic Symbol and Common Physical Device Polarity Markings


        Therefore, to simply recreate the first lesson on your breadboard with your own LED and resistor, connect pin PD14 from your newly soldered header strip on the Starter Kit to the first column on the bread board.  This will be the GPIO from the MCU that we will use to control the external LED.  Place a 3k-ohm resistor sharing row 1 of the breadboard with the MCU control wire and the other side of the resistor to column 4.  Install the single through-hole LEDs into the breadboard in columns 4 and 5, with the anode of the LED on column 4.  The anode is the longer lead on the LED and the one that needs to be closer to a higher voltage than the shorter lead, the cathode.  Connect the cathode column 5 of the LED to a pin marked GND on the Starter Kit.



        LED Orientation and Breadboard Connections


        Each column of holes on the breadboard connects all of the pins within that column together.  Components on breakout boards with their pins on the bottom usually straddle the center separator, and then connections are made between devices by connecting multiple wires to each column of holes in the bread board on either side of the separator.



        Breadboard Connection Diagram


        Now, your circuit is complete, and we have duplicated the circuit that is shown in the starter kit schematics, but we need to change the software to control a different GPIO than the one that is connected to the onboard LED.  We will cover that in the next lesson.



      • Smaller Batteries Enabled Through Autonomous Peripherals

        Siliconlabs | 05/146/2015 | 01:35 PM

        Autonomous peripherals make smart devices more energy-efficient and batteries smaller by keeping microcontrollers in sleep mode. Take a look at our customer success story to find out more.  


        Situation: A major consumer electronics brand wanted a smarter design for their next generation battery-powered consumer device. The challenge was to stay true to their feature rich product image, but get rid of the initial design with a large battery which made it look and feel bulky. A solution was needed to enable a stylish design with advanced features that did not sacrifice performance, battery life or functionality.





        Solution: The energy-friendly EFM32microcontroller (MCU) family from Silicon Labs solved the customer’s needs with its EFM32™ autonomous peripherals. These peripherals manage sensor inputs, thresholds and alarm triggers without the intervention of the main core. Circuits outside of the microcontroller which can perform complex operations on their own while the main processor core remains in sleep mode. The peripherals communicate over Silicon Labs’ unique peripheral reflex system so that the MCU can stay in sleep mode longer for even greater energy savings.



        Figure 1: The peripheral reflex system enables complex interactions while the MCU sleeps. 


        Learn more about the Peripheral Reflex System in this training video: 


        Benefit: The result is a smaller battery with dramatically lower energy consumption. The new, thin design with best-in-class battery life made advanced features possible thus enabling a better consumer design.





        Figure 2: Inside an energy friendly MCU


        To learn more about the  EFM32 microcontrollers with autonomous peripherals and other energy-friendly solutions, click here.

      • Rapidly Prototype Network-Optimized Universal Remote Controls

        lethawicker | 05/140/2015 | 04:25 PM

        ZigBee Remote Control

        The ZigBee Remote Control (ZRC) is a simple, non-meshing network optimized for User Interface products like remote controls. Both ZigBee Remote Control and ZigBee Home Automation devices use the same radio technology (IEEE 802.15.4); however, ZRC is designed to be a simpler network, requiring less system resources, resulting in lower cost solutions.


        You can use the ZRC for a number of different applications. It can be used for simple remote controls to control a single device, or more complex scenarios where it’s used to control not only different devices, but also different types of devices. An example of this would be Audio/Video devices and Home Automation devices. Let’s look at two applications for the ZRC.


        ZigBee Remote Control Network – In this case we have the ZRC remote control communicating with a Set Top Box (or any Audio/Video device). The remote is used to change channels, control the DVR, etc., but it can also be used for 2-way communication to enable features such as “find my remote” and downloading IR codes directly to the remote control for controlling legacy IR devices such as TVs.


        ZRC Architecture


        ZigBee ZRC / Home Automation Multi-Network Device – In this use case, we see two popular ZigBee applications, ZigBee Remote Control and ZigBee Home Automation, overlapping to allow communication from different networks. Through a ZRC/HA multi-network device, such as a Set Top Box, the user can also control HA devices from the ZRC remote control, for example, adjust the thermostat temperature, turn on/off lights and even get status messages directly on the TV. This extends both networks to provide a more complete user experience in the home.


        ZRC Architecture


        Find out more about our ZRC solution at


      • USB Bridge Delivers Legacy System Upgrade Without Risk

        Nari | 05/139/2015 | 07:54 AM


        If your system has a test port, a portable measurement meter from Silicon Labs can now add USB connectivity and minimize system changes without changing the original system or added risk! Take a look at our customer success story to find out more.  


        Situation: A handheld meter supplier needed to add USB connectivity to one of their most trusted products but did not want to alter the original design fear of tampering with the meter’s operation, accuracy or calibration quality. They needed a strategy that would minimize unnecessary risks for their customers.


        Solution: The answer to the problem was to connect a CP210x USB Bridge Device to the original system test pins. A small amount of programming firmware on the CP210x USB Bridge handles communications between the original legacy system and the host system, while the original meter design was left unchanged. This solution ensured that the meter would continue behaving as expected. 



        Figure 1. Onboard Solution using standard USB cable 




        Figure 2: Inside an energy-friendly USB Bridge


        Benefit: The supplier successfully added USB connectivity to one of their most popular systems without affecting the original design. Their customers were able to access measurement data over USB for further analysis without the risk and worry of a newly designed system.


        Want to know more about USB bridges? Silicon Labs offers a range of energy friendly bridging solutions. Click here to read in detail!

      • IoT Hero: Ben Stagg, Halo Smart Labs

        deirdrewalsh | 05/134/2015 | 05:33 PM

        IoT Hero, Ben Stagg


        Since joining Silicon Labs four weeks ago, I’ve been submerging myself in Internet of Things information. While it has been great learning about our IoT products and applications, I’ve found the people behind the innovation to be the most fascinating (and under appreciated) element.  Therefore, I’m kicking off a new series of interviews recognizing true IoT Heroes.  Today, I’m proud to feature Ben Stagg, CEO of Halo Smart Labs.    


        Ben, creating your own company is a big dream for many people. Why did you start your own business?  

        We created Halo Smart Labs to leverage technology to make people’s lives safer. This all really began as a response to the Joplin tornado that took the lives of 160 people in 2011. My father lives just outside of Joplin, and even with a warning from an old radio in the barn, he barely had enough time to make it to a neighbor’s cellar just as the storm was bearing down on them. My father was lucky that day, other people were not so fortunate. As my partner, Chad White, and I began developing concepts that could improve safety in severe weather events, we quickly discovered numerous other applications like smoke alarms, where technology could provide critical warnings and make the difference in someone’s life. After a house fire destroyed my mother’s home in 2013, we knew we were on the right path and Halo Smart Labs was born.


        Fascinating! So, what products are you developing?

        Most people don’t realize, that when buying a smoke detector they will have to choose what type of fire to protect their family from. Either a “flash fire” or a “smoldering” smoke fire, photoelectric and ionization sensors work and detect smoke in different ways. Since there is no way to predict which type of fire will strike, the National Fire Protection Association (NFPA) recommends a dual sensor approach for maximum protection. We actually took it one step further and included a carbon monoxide sensor as well.


        We are very proud to say that Halo is the only smoke detector to include technology to detect both fast and slow moving fires as well as CO in a single device. We also knew that in order for to communicate these different warnings we wanted to include a lighting ring. 


        Is this your first project aimed towards the Internet of Things?

        This is not my first M2M communication product; in the past, I built message and data distribution systems for companies large and small using various embedded platforms. However, this is our first product in what has recently been labeled ‘IoT,' and our first consumer product. 


        Cool.  What is the biggest thing you’re working on right now? 

        Right now, the biggest thing we are working on is our Halo smoke alarm and its introduction to the market on Indiegogo. We've been able to utilize the tools, resources, and partners like Silicon Labs to ensure the product meets our demanding standards. At the same time, it's up to our customers to help us align their needs with our features and functions. This campaign is exactly what we need to engage our customers on a scale relatively unavailable in test groups; it also ensures that we're giving people a product of genuine benefit to their lives.


        I'm always interested in learning about the inside of new products. Do you use any Silicon Labs technology?  

        Silicon Labs solutions are fundamental to many of the functions offered by HALO. We are leveraging Silicon Labs technology to allow Halo; the safest, smartest smoke detector on the market, to receive relevant local weather warnings and alert the user.  From the beginning, Halo was engineered to be a multi-radio device capable of supporting the communication standards found in the home automation sector today. Silicon Labs not only provided us with a solid design for adding Zigbee support to Halo, but their stellar development tools allowed us to quickly implement the design.


        Halo also uses an intelligent sensor algorithm that removes the irritating false alarms often associated with smoke alarms. Our team makes retrieving accurate data a top priority, and Silicon Labs digital humidity sensor plays an integral role in Halo’s sensor-driven logic, allowing our device to avoid the false alarms that have become the norm with today’s other smoke alarms.


        Now, I know this is a big question, but in your opinion, what does the future of IoT look like? 

        We're planning to continually focus on connected devices that represent huge values in our customers’ lives; particularly in areas of safety and security. While time will tell whether or not the novelty and convenience of applications of connected devices have a place in the way consumers engage IoT; we are certain that the fundamental human need to feel safe at home will remain the primary means for entry in the connected home.


        To learn more about the Halo smart smoke detector, check out the crowdfunding campaign



        I’m honored to share Ben’s story as my first blog in the Silicon Labs community, and I would love to hear from you.   Are you an IoT hero?  Do you know someone who is?  Feel free to nominate them by posting on this forum board


      • Controlling External Devices: Part 1: Working with Breadboards

        lynchtron | 05/134/2015 | 12:46 PM


        In the last lesson, you learned how to find signs of life from the MCU by blinking an onboard LED on the Wonder Gecko Starter Kit.  I could spend some more time exploring all of the onboard circuits, and I will cover more of them in upcoming lessons, but the real fun starts when you can control off-board components with circuits that you build yourself.  That’s the whole point of making things, right?  In this lesson, you will build your own LED circuits on a solderless breadboard and control those LEDs with pushbuttons on the Starter Kit. 


        I am purposefully keeping the projects rather simple for these first few lessons while you get accustomed to the embedded world.  This will make it easier to learn the basics before we ramp up the complexity in later lessons. 


        Materials Needed for This Lesson -- More info on the Maker's Guide Website

        • Solderless breadboard & hookup wire 
        • Through-hole LEDs (four at a minimum)
        • Miscellaneous through-hole resistors 
        • 12V battery pack, or alternatively, 12V power supply 
        • PN2222A NPN Transistor, 1 Amp Rating 
        • Soldering Iron and Solder 
        • 2.54mm Header Strips 
        • Multimeter, also known as a Volt-ohm meter (VOM) 

        Working with Solderless Breadboards 

        One of the tricky things about creating your own hardware project is that you first have to find your components, figure out what they need to function and figure out how to connect all of those components to each other.  It is not trivial, and there isn’t always a right or wrong answer.  The difference between software projects and hardware projects is like the difference between multiple choice tests and “show your work” tests.   It’s up to YOU to figure out how to wire those things together and keep things from melting. 


        Hypothetically, you could read about the requirements for the components that you have chosen, draw up schematics and design a Printed Circuit Board (PCB) to house your components, then wait a few weeks for those to be printed, assembled with components and delivered to you.   What usually happens next is that you find out that you have inadvertently connected your most important part backwards and now you must wait a few more weeks before you can try out your circuit.  While this arduous process is sometimes required for ultra-high-speed circuits, it isn’t usually necessary for most MCU-based projects.   


        There is a better way.  You can connect those components to each other with the help of a solderless bread board.  This has the benefit of giving you near-instant feedback about how your design works and lets you get working on the firmware while the PCBs are being manufactured. 



        Solderless Bread Board and Various Hookup Wire 


        The drawback to breadboarding your design is that you will end up with a tangled mess of wires, so use lots of colors and label and bundle your wires if it gets too hectic.  Keep in mind as you breadboard that it is not going to be as reliable as a properly-built PCB with shorter traces between components.  The objective at this stage is to ensure that you are connecting things together properly, but don’t expect a robust design. 


        Breakout Boards 

        Semiconductors have been shrinking in size constantly since their inception.  It used to be that you could order a “breadboard friendly” version of a chip that you wanted to use in your design with big pins, but not anymore.  In order to breadboard with the latest and greatest semiconductor technology, you will need to make use of breakout boards, which are boards that “break out” the very tiny pins (or in some cases balls) from Surface Mount Technology (SMT) components to a workable pin pitch – the distance between pins, usually 2.54mm or 0.1” – that will give you a way to connect them to your solderless breadboard. 



        Accelerometer Breakout Board with 2.54mm Pitch through Holes 


        Your Starter Kit is a partial breakout board.  It breaks out some of the pins on the MCU to 2.54mm through holes along the edge of the board and also houses other circuitry necessary to get the part to function and connect to your computer through USB.   


        You can visit sites like SparkFun and Adafruit, as well as Mouser, Ebay and Amazon to find breakout boards or evaluation kits.  However, they are not always available on the market and will cost more than bare chips.   



        Schmartboards 0.5mm SMT to 2.54mm Through-Hole Breakout Board 


        If you are brave and not afraid to learn new things, you can make your own breakout board.  You can create them with bare breakout boards from Schmartboard for many component package types.  You will need a fine-tipped soldering iron and perhaps a good magnifying glass or microscope to do the work.  The solder is already on the board and the SMT devices fit into grooves to help you line things up so all you need to do is heat up the pins and traces.  The benefit of this is that if you somehow destroy your component, you can just replace the component without paying for a whole new breakout board. 


        Build up an External LED Circuit 

        In order to use your Starter Kit with a bread board, you will need to solder 2.54mm through-hole header strips to the through-hole testpoints along the edge of your Starter Kit.  You will find that soldering is something you will have to learn how to do sooner or later, at least on these 2.54mm pitch connectors. Soldering at this pin pitch is considered to be a beginner’s skill.  Order some breakout boards and start practicing.  Just attach the 2.54mm through-hole headers to the holes on the practice breakout boards for now.  Then do the same to your Starter Kit.  I like to solder my 2.54mm through-hole headers so that the plastic strip and longer leads are on the top side of the Starter Kit as shown in the picture below.  For small breakout boards, I will solder the header strip to the bottom side of the board and plug them directly into the solderless bread board.   



        Be sure to use the header strips shown on the left and install the short leads in the holes in the board along the top edge of your Starter Kit, and then flip the board over to do all of the soldering on the back side.   


        TIP: The double-sided header strips shown on the right make good female-to-female adapters for your socketed breadboard wire.

        When soldering the pins, try to keep the solder on one side of the pin and the soldering iron tip on the other side so that the solder “flows” between the two.  You want to heat both pieces of metal that will be joined by the solder at the same time to ensure the best connection.  See the diagram below.  If you don’t get the round copper solder pad hot enough, the solder will ball up on the pin and it will not flow into the joint.  This is known as a cold solder joint. 



        Soldering the Header Strips to the Starter Kit 


        Repeat this procedure for the bottom row of through-holes and the jumper location labeled J100.  It is on the right side of your Starter Kit next to the pushbuttons.  There are five holes aligned vertically on the board. 




        Now your Starter Kit should be ready to go with header pins on all testpoint locations.   

        In the next lesson, you will learn about the LED theory needed to connect to external LEDs.



      • How Low Can We Go? Power Management APIs on the mbed Platform

        lethawicker | 05/133/2015 | 02:56 PM

        mbed Silicon Labs

        Rapid prototyping platforms like mbed have made it possible for countless people with brilliant ideas to design and develop the devices of their dreams, even without specialized skillsets. mbed has become a very capable software and services platform for IoT development, and supports a wide range of MCUs already. However, only Silicon Labs offers low-power MCUs.


        Why worry about low-power MCUs? If you’ve been working on the mbed platform, you know that there’s a distinct trade-off between the performance level of your MCU and the amount of energy it uses. Now, with low-power enabled MCU power-management APIs from Silicon Labs, you don’t have to compromise anymore. You get the same or greater power, without the energy drain on battery life that so often accompanies it. And that opens whole new vistas for creativity and development, especially in the IoT world. The battery life of your application can improve significantly, or maybe you want to swap out that big battery for a smaller one, in order to get the form factor just right. It is all up to you.


        How does it work? Technically speaking, new power management APIs developed in collaboration between ARM and Silicon Labs, allows mbed to determine the optimal energy mode the application can go to based upon the current peripherals in use, and this can dramatically reduce system-level energy consumption. Low-energy optimization is achieved by enabling I/O operations to be executed in the background and by allowing those operations to continue even while the MCU core is in sleep mode or during other processing tasks.


        Or you could just watch the video for a demonstration of how the new APIs reduce energy consumption and boost battery life.


        Why wait? Get started today and build the low-power IoT of the future!

      • 20 Years of USB—A History of the Humble Interface and A Peek into Its Future

        lethawicker | 05/133/2015 | 11:14 AM

        Okay, we don’t mean to scare you, but do you remember the bad old days, when the back of your PC looked like this?

        90s PC


        We do, too. But then USB came along, and within a few years everything was connecting to everything via a standard interface. These days even the built-in components of your laptop like your mouse and touchpad communicate to the main board through USB interfaces. How did the USB interface get its start? What’s next for it in this connected IoT age? Read ahead to find out.


        The history of USB and how it works

        In the mid-90s, the creators of USB saw a need to consolidate the pathways by which machines speak to each other (Machine to Machine or M2M). USB was so successful that today it is the default connection for everything from smartphones to mice to printers. Micro-USB and Mini-USB variants further expand the USB footprint. Under the covers of the PC, even the touchpad and built-in keyboard and other built-in peripherals of your laptop communicate with the device via USB.


        Let’s step back and examine how USB functions so that we fully understand the implications of the technology as we progress to our next topic. It’s all about devices and hosts. The host, like a PC, initiates communication and provides power, while the device, like a mouse or other USB-connected peripheral, replies to what the host requests.


        Perhaps one of the most useful aspects of the USB topology is its ability to provide power to a device. You know this if you’ve ever used a USB cable to charge your smartphone. How much power can you move over a USB interface? The standard is at least 100 mA of current, but it could take as much as 500 mA. Sounds like there should be no power issues at all, right? Unfortunately, because USB requirements depend so heavily on having a reliable main power supply connected to an outlet, like the PC itself. There’s where we run into problems with M2M interfaces like those in the Internet of Things.


        USB in the age of IoT

        There’s one big problem with USB when you’re using it for portable, battery-powered connected devices: it’s an energy hog. From the outset, when you’re working through your power budget, you have to make some hard choices to balance battery size and battery life. USB can blow through your power budget—but you still want to use USB because it’s a widely-adopted standard interface. You have a problem, and we have a solution.


        When examining the evolution of the USB interface, it’s clear that the next step is to make USB the universal and power-friendly solution for battery-powered devices. MCUs like Silicon Labs EFM32 Happy Gecko make the minute decisions necessary to reduce power consumption dramatically, enabling USB to penetrate markets where it has not yet succeeded to its fullest potential.


        Happy Gecko


        Download the full whitepaper, “The Past, Present and Future of USB,” to learn more about how to incorporate USB into your designs with no compromises.


      • Hello World Part 2: Create firmware to blink the LED

        lynchtron | 05/126/2015 | 05:23 PM


        In this lesson, you will learn how to develop code to blink an LED and the process of creating an embedded executable and transferring that executable to the Wonder Gecko Starter Kit.  


        Enable the GPIO Clock

        The first thing that we must do in our code before we can try to put voltage on any pin is to turn on the GPIO clock source.  By default, all clocks are disabled except for the HFCLK, which is the only one that is necessary to enable programs to run on the MCU, but doesn’t allow for many, if any,
        of the peripherals to function. 


        WARNING: If you try to use a peripheral whose clock source is not configured, nothing will happen.  Nothing BAD will happen, it just won’t do what you expect and the compiler will not complain at all.  You will sit there stumped for a while.   Personally, I forget to enable clock sources for the peripherals that I use all the time.  After a while, it becomes the automatic first thing that I check when things don’t work as expected.


        To enable the GPIO clock, we need to add the statement #include “em_cmu.h” file to our compiler directives section.  This will bring in the necessary Clock Management Unit (CMU) EFM32 library that makes our job easier.  We could get the job done by just using the definitions that are available in “em_system.h,” but there could be a sequence of events that must be completed.  The library team at Silicon Labs has already worked out the sequence of events in these support libraries, so I like to use them until I have a good reason to go a different route. 


        Note that whenever we add a .h file to our code, we have to add the rest of the library driver to our build environment.  The .h file is a header file, which pulls in function declarations and some definitions.  But some of the definitions only are found in the .c file, which is the implementation file.  The way to get the .c file for an emlib driver into your 3_Hello_World project is a bit complicated.  You will get used to it in time.


        The files that you will need are in C:\SiliconLabs\SimplicityStudio\v2\developer\sdks\efm32\v2\emlib\src if you are on a Windows computer.  For all other computers, the path of the files will be relative to the SiliconLabs install directory.  Just copy that whole thing into your explorer or finder window and bookmark it.  Then, whenever you need a library file, open this bookmark, find the file from within that directory and copy it into your emlib directory in Simplicity Studio.   In this case, we need the em_gpio.c file and the em_cmu.c file.  Select both of those and copy them into your emlib directory for the 3_Hello_World project.


        When you paste the files into emlib, Simplicity Studio will ask if you want to copy the files or link the files.  If you copy the files, you will freeze the files in time and they won’t ever change unless you change them.  If you link the files, your library files could be updated when you update the Simplicity Studio software.  I like to make a copy and then control when I get the update for an existing project.


        Here is the function call from the CMU that we need to add to our code to enable the GPIO clock.  Just drop it in right after the CHIP_Init() function call without a return assignment.  


        CMU_ClockEnable(cmuClock_GPIO, true);


        But how did I know that?  Well, this one is pretty simple because it shows up in all of the examples.  But if I didn’t already know that, here is how I could have found out...   Once again, the information is right there in the Simplicity Studio software.  Navigate back to the Simplicity Studio home screen by selecting the Simplicity perspective button at the top right hand corner of the IDE.  Then, select the “Software Documentation” tile.  I am omitting pictures since you should be familiar with what a tile looks like by now.   In the window that appears, you will scroll down to the Wonder Gecko section and click on the link “emlib Peripheral API for the Wonder Gecko family” and that takes you to an Internet page that details all of the available emlib functions:



        When you then click on the CMU_ClockEnable branch, you see all the gory details about what this function does:




        This tool is very useful to figure out what library functions already exist and their uses.  But now you look at that parameter list and you might think, what is a CMU_Clock_Typedef and how do I pass that into the function?  Easy.  Just click on the CMU_Clock_Typedef which is linked to a list of enumerations for the type.  You will see that cmuClock_GPIO is already in that list.  Since you have already included em_cmu.h at the top of your file, the enumeration is detected by Simplicity Studio and it gives it an italic blue style to indicate that it recognizes it as a known enumeration.


        Set a GPIO Pin High

        Now that we have enabled the clock, we are ready to turn on the LED.  You could once again look through the emlib API guide to find the “em_gpio.h” library (don’t forget to add the #include “em_gpio.h” to the top of your code in the compiler directives section) and find following function:


        GPIO_PinModeSet(gpioPortE, 2, gpioModePushPull, 1);


        Once again, the enumerations for gpioPortE and gpioModePushPull can be found in the em_gpio.h library header file or on the emlib API guide.  Don’t worry about what gpioModePushPull means.  We will cover that in the next lesson.  With this statement, we are instructing the GPIO peripheral to set the output mode of pin E2 to a push-pull driver, and to put that pin in a high state.  If you will recall, we read that one of the test LEDs was on pin E2 and was of type “active high” which means that we have to drive pin E2 high to turn on the LED.  So that is what we have just done.


        That’s it!  We are now ready to run our first program on the Starter Kit.


        Attach to the Starter Kit

        Plug in your Starter Kit via the USB cable and let your system detect it.  Since you have already installed Simplicity Studio in the first lesson, the drivers should be ready to recognize it and attach to it.  Next, open Simplicity Studio and create a “New Silicon Labs MCU Project” from the File menu.  Name the project “3_Hello_World” and Simplicity will open the emptyProject.c file for you.


        Your Wonder Gecko MCU on the Starter Kit can be powered by the USB cable or by a little coin battery to the bottom left.  You don’t need to use a coin battery for now, so make sure that the little switch is slid over to the right side.  If this switch is set wrong, the Starter Kit will be detected by your computer over USB, but you will not be able to program the MCU from Simplicity Studio.





        Build and Run the Executable

        Now, press the build button, which if you recall looks like a little hammer in the tool bar at the top of the screen.  The IDE will automatically save and build the emptyProject.c file with your new changes.  If all goes well, you should see things streaming by in the lower console “Build Console” until you see if it failed or succeeded.  Make sure to look back in the log every time and look for warnings as well as errors, because warnings are often just as bad as errors.  Always start with the first warning or error that happens in the Build Console by scrolling back to find it.  Read what it says and try to solve the problem.  Then rebuild until you get no errors or warnings.


        Now that we have built the executable, you are ready to transfer it to the Wonder Gecko and run it on the MCU.  To do this, press the Debug icon on the toolbar.  It is the one that looks like a little bug: 


        The Debug tool will first save your files, then build (again) and then transfer the executable to Wonder Gecko and leave your current execution line icon at the first line in the main() function. 


         NOTE: You do not have to first Build and then Debug your code, since the Debug tool will do both as part of its sequence, but I find that it is easier to find problems by building before debugging.  If there are build errors, the Debug tool will complain that it can’t transfer a file because it hasn’t be built yet.  In addition, the IDE will swap our Build Console with the Program Output Console, and so your will have to hunt around the icons to find the Build Console again.


        ALSO NOTE: Sometimes the build leaves files behind and needs to be cleaned.  If you find that things are inexplicably failing with odd errors, try the Clean option from the build menu and try building again.


        Let’s set a break point at line 30, that contains the CMU_ClockEnable() function.  To do that, right click on the space to the left of line 30 and pick “Toggle Breakpoint.”  Your screen should now look like this:



        You will see the Run, Pause, Detach, Reset, Step In, and Step Over icons at the top appear when Simplicity Studio automatically switches over to “Debug perspective.”  You can use them now.  First click the Run button.  Simplicity Studio will execute all of the lines up to line 30, leaving the current line icon on line 30, ready to execute that line.  From there, click on the “Step Over” button and you will see the current execution arrow move to line 31.  When you pressed the Step Over button, it executed the code on line 30, and only that line.  Inside the MCU, the GPIO clocks should now be alive and ready to execute line 31.  So press Step Over again, and voila! You should see LED0 light up on the Starter Kit!



        Providing LED Illumination on LED0


        If you have trouble, take a look at the source code available on the Maker's Guide web page.  The full source is available.


        Make it Blink

        But wait!  We can turn it on but the “Hello World” program requires that we make it blink.  So let’s do that.

        We need to turn the LED off and on, but if we do it too quickly, no human would be able to see the blinking.  You have to remember that the MCU can do things very fast, so fast that you can’t even see it.  You now live in a world of nanoseconds, microseconds and milliseconds.  So we will add some delay and then turn the LED off, then more delay and turn it back on, forever.  There are many ways to add delays and delays are one of the important topics of the upcoming lessons, so for now we will use a simple execution delay.  


        Make your main function look like the following:


        int main(void)
          /* Chip errata */
          CMU_ClockEnable(cmuClock_GPIO, true);
          /* Infinite loop */
          while (1)
                // Turn on the LED
                GPIO_PinModeSet(gpioPortE, 2, gpioModePushPull, 1);
                // Add some delay
                for(volatile long i=0; i<100000; i++)
                // Turn off the LED
                GPIO_PinModeSet(gpioPortE, 2, gpioModePushPull, 0);
                // Add some more delay
                for(volatile long i=0; i<100000; i++)

        When you execute the above code, your LED should be blinking nicely.  Here is what happens.  We add a delay by keeping the MCU core busy doing meaningless work with the for loop.  It is definitely the WORST kind of delay to use because it is not consistent across different processor speeds AND it wastes energy.  I am only using this for now because it is quick and dirty.  It is perfectly acceptable to do stuff like this during the prototyping stage.  The keyword volatile tells the compiler that the variable i might change outside the compilers control.  For instance, another MCU might be running on the same memory space and that the variable could change at any moment.  Depending on the build settings, the compiler might “optimize away” the repeated (useless) setting of i.  The whole line of instruction might not even show up in our executable.  By declaring it volatile, we tell the compiler not to mess with it and force the machine to execute the useless loop 100,000 times, which adds up to enough of a delay that the LED settles down and you see it as off for a split second.  That should give you a good idea of how many things this MCU can do in a single second.  If the compiler were to optimize away the setting of i, the for loop would not be in your executable and there would be no delay at all.  The LED would blink so fast that you wouldn’t be able to see it. 


        So this wraps up your first real embedded program.  Congratulations!  Consider yourself welcomed among the elite group of people who have ever written an embedded program.   Now go find someone right now and drag them over to your creation to show them your little blinky light.  But please try to use some big words like “compiled” and “volatile variable execution delay” etc., that you just learned so that you don’t describe it as just a blinky light.


        If you want to take this lesson further, figure out how you might speed up or slow down the rate of blink.  Can you make it blink three times and then pause for a few beats?  Can you blink it so quickly that the LED appears to be dimmed?  Can you make the LED glow brighter and brighter over time, like a sunrise?  You’ve got the tools now, using only the simple statements that we have studied so far.  Post your solution in the comments section.


        In the next lesson, we will continue the study of the all-important GPIO and other ways we can drive it, including an introduction to basic electronics and breadboarding.