Official Blog of Silicon Labs

      • IoT Heroes Ali and Serge Deliver Wearables YOUR Way

        deirdrewalsh | 11/334/2015 | 12:37 PM
        Blocks IoT Heroes
        Some girls like diamonds. Others like pearls. My favorite jewelry is watches.  That's why I was so excited to interview IoT Heroes Ali and Serge, who make an amazing, modular smartwatch.  These guys arent just developing another wearable, they are revolutionizing IoT development and creating an app store for hardware! 
        So guys, please introduce yourself and your company. 
        Hi, we’re Ali Tahmaseb and Serge Didenko, the founders of BLOCKS Wearables. We’re building the world's first modular smartwatch. Each link in the strap of the watch has a unique function. The screen module already has all the functionalities of a normal smartwatch. 
        Cool. How did you come up with your idea? 
        We’re both interested in wearable tech. Ali focuses on gesture control, contactless payments and other business applications.  While Serge is interested in health, fitness and the sports applications of a smartwatch.
        What makes BLOCKS different than other wearables?  
        There's a wide range of possibilities for the sensors and functionalities that can be embedded into a smartwatch; however, due to limited size, high power consumption, and increased production costs, it is not feasible to put all these functionalities into a single smartwatch. Therefore, most manufacturers choose a few functionalities for their smartwatch, and the end user has to compromise on their ideal wearable.
        We give the power back to the users! We allow consumers to choose what's important for them in the form factor of modules. Were also very upgradable. Instead of purchasing new smartwatches as technology evolves, users can keep on replacing modules only.
        Are you going to allow other developers to build on top of the platform? 
        Yes! BLOCKS is an open-platform that provides developers a low-cost, low-barrier, and fast entry way into the wearable tech market. Developers can do more than create apps - they can create hardware modules. Just imagine an App Store for hardware!
        Also, BLOCKS is open-design. The top shells of modules are easily removable, so users can change the colors and materials on the go. We are already working with a number of jewelry fashion designers on premium shells.
        Awesome! Where can I get one? 
        You can pre-order your BLOCKS Smartwatch now on kickstarter. The prices start from $195 and it ships world-wide. We raised around $1,000,000 on kickstarter in only one week.
        It’s a big question, but in your opinion, what does the future of IoT look like?
        Interesting question indeed. The future of IoT lies in more sensors, usefully processed information, and seamless interaction with Internet of Things devices.
        See the BLOCKS overview video: 
      • Chapter 8.2: Communicating Asynchronously Between Devices: Configuring the USART

        lynchtron | 11/334/2015 | 08:34 AM



        In the last section, we learned about the USART, which is a very configurable communication peripheral that we will be using to connect our EFM32 to our personal computer.  In this section, we will instruct the EFM32 to configure this peripheral by only writing one line of code!  Simplicity Studio can take care of the minutiae of setting up the hardware peripherals in the EFM32 MCU so that you don’t have to be an expert on which pin maps to which available peripheral input or output and on which location. 


        Configurator Tool

        Up until now, I have picked my GPIO pins by looking at the Data Sheet and finding the function that I wanted and then cross referencing with the Starter Kit schematics to ensure that a pin was available with the peripheral function that I wanted to use.  Now, I will use the Configurator tool to simplify that process.  The tool will help me find the pin and automatically generate source code to get the pin properly configured.

        Go to your Simplicity Perspective view, which is the home screen with all of the tiles on it, and click on the Configurator tool.


        If the Configurator tile is missing from your home screen, make sure that your Wonder Gecko Starter Kit is detected on the left, or type the string “EFM32WG990F256” in the box that says “Enter product name” so that the Configurator shows up on the screen and is able to be opened.

        You will see a series of windows that confirm your Kit/Part selection to be used by the Configurator as it creates a new project for you, so pick a name that make sense like “8_Serial_Communication” and then just click Next and Finish.


        Simplicity Studio then displays the Configurator tool in the IDE.  You can always get back to this view by clicking on the Configurator icon in the upper right-hand side of the tool


        Click on the tab labeled DefaultMode Peripherals, and find USART0 on the list, and click the enable box:


        As soon as you enable the USART0 peripheral, you will notice a few things happen.  The Properties of USART0 panel opens automatically, the 8_Serial_Communication.hwconf file becomes marked with an asterisk, meaning that the file is unsaved.  Additionally, you will see two errors show up in the bottom Problems tab. 


        The Properties of USART0 panel is where you can configure exactly how you want the USART0 to operate.  For the case of an asynchronous serial port that runs at 115200 baud with 8 data bits, no parity and 1 stop bit, the tool did pretty well by picking a nice default that works.  The rest of the defaults seem to work well for our needs as well, so we will leave them alone for now.


        The 8_Serial_Communication.hwconf file is an XML file that Simplicity Studio is interpreting and modifying as you configure your device.  You can press the save button and then open this file that is located within your project.  It is an ordinary text file that contains the XML source code for the Configurator.  You can open it in a text editor and observe its contents, but there is no reason to edit it.  The important thing is that it gets saved as a simple file with your project so you can always return to move things around if needed.


        The errors that show up in the Problem panel are a good thing because they will lead you to the next step that you need to complete to configure the USART0.  Plus, if you ever try to configure a single pin for two functions, the Configurator should give you an error.  Expand the Errors (2 items) line and double click on the first error.  It will change the view of the bottom-right properties panel to a Peripheral Mapping panel in order to show you where the change needs to be made to fix the errors.


        Scroll down the Peripheral Mapping tab until you find USART0 and click the enable box to the left of the USART0 label.  This will instantly fix your two errors and give you four brand new errors!  That is still OK, because again, the errors are leading you to the next step.


        The errors that we see now are complaining about specific pins in the part not being configured in the correct mode to satisfy the USART0 operation.  If we tried to build the initialization code now, it wouldn’t work because the GPIO pins needed for USART0 still aren’t completely configured in the Configurator tool.  We could double click on these errors and fix the errors now, but before we do that, we have to make sure that these pins are the ones we want.

        First of all, I don’t need the CLK or CS signals for a serial port.  The USART supports many different communication standards, but I only need to pay attention to the RX and TX signals for my needs.  When I look at the pin breakout diagram for the Wonder Gecko Starter Kit in the User Guide, I don’t see PE11 and PE10 in the list.  I need to change the location drop-down which to the is right of the USART0 label to see if I can find some pins that are brought out to my testpoint pins on the Starter Kit.  By doing this, I find that location #5 works, giving me PC1 and PC0 for my TX/RX pair.  I click off the enable box for CLK and CS, since my serial port will not use those lines.

        Now when I look at the error box, I see two errors stating that PC0 and PC1 are not configured, and I can double click on those to bring up the Properties panel for each of those Port Pins.  The error tells me what Pin modes I need so I just pick the right mode for each of these GPIOs, and the errors vanish.  


        Next, I need to enable the HFXO as a clock source, since asynchronous communications can have a total of 5% error between both sides, and the crystal clock source ensures that our baud rate will be within this acceptable error range.  Go back to the DefaultMode Peripherals tab and select the HFXO.


        Unfortunately, no errors pop up in the Problems tab like before even though I am not done configuring the HFXO.  I need to click on the Port I/O entry in the Outline tab, then scroll until I find the HFXO pins and enable the checkbox.  But unlike the USART, I don’t need to enable the pin in the PortB part of the GPIO peripheral.  If I did that, it would give me some errors in the Problems tab that those pins need to be disabled in the GPIO peripheral.


        Save the file and the source code for USART0 will be generated automatically. This will generate a file in your src directory that is called InitDevice.c.  Open this file and you will find the function enter_DefaultMode_from_RESET() that contains everything needed to configure the USART0 for asynchronous serial operation.  Just drop that line into your main.c program and press the build button.  The tool even did you a favor and copied the em_ library .c files for CMU, EMU, and USART (included by InitDevice.c) into your emlib directory.  How nice.  Note that it didn’t add the GPIO em_gpio.c library file because it didn’t implement any of the GPIO API functions.  Instead, the Configurator uses global system defines for accessing the GPIO registers.  You will want to add the include statement for the InitDevice.h file at the top of your file.  It was automatically generated as well and is located in the inc directory.  That will keep the compiler from complaining that the enter_DefaultMode_from_RESET() function is implicitly defined.

        #include "em_device.h"
        #include "em_chip.h"
        #include "InitDevice.h"
         * @brief  Main function
        int main(void)
          /* Chip errata */
          /* Infinite loop */
          while (1) {


        If you examine the contents of the InitDevice.c file, you can see what it is doing:

        • Startup the appropriate clocks sources needed by the selected peripherals
        • Set up the HFXO connection to the CMU module
        • Initialize the USART0 including the ROUTE register to indicate the location and enable the GPIO pins inside the USART0 interface
        • Configure the GPIO pin mode for each pin used in the USART0 interface.

        When configuring peripherals manually, I will almost always forget step 1, to enable the clock.  It happens so often that I always know immediately what I did wrong.  Items 3 and 4 seem redundant and often lead to trouble when manually configuring peripherals.  It is sometimes (but not always) necessary to enable the pins for EFM32 peripherals inside the peripheral itself and then again in the GPIO peripheral as well.


        In the next lesson, you will learn about interrupts that enable the EFM32 USART to capture text characters sent across from your host computer and learn about the electrical signals behind the scenes as well as USART clock sources.



      • CES 2016 (NV)

        Siliconlabs | 11/328/2015 | 07:51 AM

        Location: Toscana 3709, Venetian Palazzo Hospitality Suite, Las Vegas, NV

        Date: January 6-9, 2016


        CES is fast approaching and we're looking forward to showcasing our Thread Networking solution with an array of Thread-connected LED lighting. The Thread lighting demo consists 20 individually IP-addressable Thread end devices and a border router to highlight end to-end IPv6 connectivity using CoAP. The network can be monitored and controlled from a web browser using any mobile device. You can also find home kit demonstration and sensors demo at our booth, so be sure to stop by. 



        learn more.png

      • Jumpstart Smart Home Application Development

        deirdrewalsh | 11/321/2015 | 10:06 PM

        Jumpstart Development


        I was at the airport recently, tumbling through a myriad of magazines while waiting for my flight. From Dwell to WIRED, seemingly every publication had articles talking about smart homes. The proliferation and fast growth of home automation and connected lighting applications is astonishing....and it's just the beginning.

        Lee Ratliff, principal analyst for connectivity and IoT at IHS Technology, forecasted that connected home device shipments will grow from 59 million units in 2015 to 193 million units in 2018, a compounded annual growth rate of more than 48 percent.


        According to Ratliff, to stand out from the rest, successful connected home products must be:

        • standards-based
        • easy to deploy by mainstream consumers
        • designed to work in real-world environments
        • able to solve specific problems with minimal complexity

        While that's clear, adding wireless connectivity to home devices is not as simple as it seems. Therefore, Greg Hodgson, senior director of IoT Solutions here at Silicon Labs, worked with his team to help minimize the complexity. His mission: make wireless design faster and easier so that developers can create simple, high-performing, battery-friendly devices. To that end, we just released new connected lighting, home automation and ZigBee gateway reference designs.

        This launch is the first in a series of turnkey IoT solutions from our company. The new reference designs include the hardware, firmware and software tools that you need to create interoperable, scalable, feature-rich connected home products. These cost-effective designs will significantly reduce the complexity of connecting ZigBee devices, such as lights, dimmer switches and door/window contact sensors, in a connected home network. 

        To order the references designs and for additional information, please visit

      • Chapter 8.1: Communicating Asynchronously Between Devices: Overview of USARTs

        lynchtron | 11/320/2015 | 11:52 PM


        In this chapter, we will open our embedded board up to exchange information with the outside world.  Up until now, the only link that we have used is the built-in USB programming interface on the Wonder Gecko Starter Kit and some GPIO lines for controlling a few discrete components. Now we will share data across a communication protocol.


        Our EFM32 has quite a few built-in communication standards.  It is quite the Swiss army knife.  We will begin learning about the simplest of these interfaces in this chapter before learning about more in upcoming chapters.  You can use these communication protocols to enrich your project by connecting multiple smart devices together and share information.  The IoT is all about connected devices, and this is where it begins.


        First, we will cover the basics of serial communication protocols, terminal emulator programs, UARTs, USARTs, and serial cables.  Then we configure the chip for USART communication using the Simplicity Studio Configurator tool, that takes care to make all of the connections and communication settings for the USART, through the GPIO block and to the outside world.  We will build an interrupt handler to let us know when there is data received on the serial interface and see what signals look like on an oscilloscope, to make sure that things are really toggling like we expect.  Finally, we will construct a print function so that we can use this newly acquired connection to aid in our debugging process.


        Materials Needed for This Lesson

        • CP2104-MINIEK USB-to-Serial Port adapter
        • Hook up wire
        • Terminal emulator software and a computer

        Communication Classes

        Communication is achieved between devices via three classes of communication methods:

        • Parallel
        • Synchronous Serial
        • Asynchronous Serial


        The parallel communication method is generally the fastest class.  In a future lesson, you will learn about parallel communication in order to transfer large amounts of data quickly to graphical displays.  When your peripheral is on the same PCB board as the MCU, a parallel interface makes a lot of sense if fast speeds are needed and pins are available.  But when your embedded system needs to communicate with other external devices, all of those conductors create complicated connectors and bulky, expensive cabling.  In the early days of the PC, all computers had a parallel port that allowed transferring large amounts of data form the PC to a peripheral, normally a printer.  The cables were never cheap or light..


        A serial communication method forces the transmitted data to march in a single-file line, as all of the data flows bit-by-bit one after another.  This is generally a slower form of communication but requires fewer wires between devices.  This type of communication can be transmitted in a synchronous mode, which means that there is a clock line to coordinate the bits at the other end, or without a clock, which is an asynchronous mode. I will be using and explaining asynchronous mode in this lesson.


        The large majority of your embedded system operates in a synchronous mode.  Nothing ever happens if the clock doesn’t toggle.  Therefore, the devices that utilize asynchronous signals must be able to bridge the gap between clocked and clock-less domains.  This presents some challenges in finding proper clock sources. 


        The standard that is most often used for asynchronous serial communication is the RS-232 standard, which is based upon the UART communication protocol.  More on this later.  This standard describes how devices asynchronously communicate information, including the voltages and optional flow control siganals.  It is not required to make use of this particular standard, but it is most common and the one that we will be using for this lesson.  However, just because there is a standard doesn’t mean that all systems will work well together.  The standard doesn’t specify how software should deal with the data that is transferred.  In addition, the RS-232 interface specifies a +5V and -5V as part of the electrical signaling and we will not be implementing that part, as both the EFM32 MCU and the USB-to-serial port adapter don’t use these voltages, but instead use 3.3V and 0V as the logic 1 and logic 0 values.  RS-232 also adds optional flow control signals such as the Request To Send (RTS), Clear To Send (CTS), to manage the bidirectional transmission of data between two systems, usually modems, and we don’t need all of that extra signals.  So what I am referring to as RS-232 here is really just the packet format and not much more.  This happens a lot in technology.  It’s hard to keep track of all of the nuances between different specs and even different versions of specs.  The people who make the components get confused at times too.  That’s why it’s so hard to get things to work together sometimes!


        Serial Interfaces and Terminal Emulator Programs

        In 80’s and 90’s, all computers shipped with a serial port that had a ridiculously large DB9 connector, by today’s standards, and implemented the full RS-232 standard.  Sometimes it was necessary to enter into the computer’s BIOS setup utility and turn them on, or assign them to a different address range or IRQ lines to not conflict with your groovy new drawing pad or speech synthesizer.  Those were the days. 


        Today, you will most likely need a USB-to-serial adapter to access this old interface.  You can use a breadboard-friendly CP2104-MINIEK breakout board for this task.  The drivers are available on the Silicon Labs website so that your computer will detect this breakout board.



        USB has supplanted RS-232 to be used for most peripheral needs, and wireless links are replacing those.  But, the lowly serial port is still used wherever a design calls for a cheap and easy way to get some rudimentary console-based access to a host system.  Embedded designers routinely choose serial ports for diagnostics and debug of heavyweight computers that otherwise have multi-GB interfaces.  When those beasts fail to boot up properly, the serial port can be the salvation to figure out what went wrong.


        Often, the data that is transmitted via an serial interface is ASCII text for human consumption or as commands to be sent to a device.  ASCII stands for American Standard Code for Information Interchange and is the binary code behind all of the text that makes up the alphabet, punctuation characters, and other miscellaneous characters.  But it is also possible to transfer information data over a serial interface in a pure binary format in order to program a part with new machine instructions, for example.  To interface with the serial port on your computer, you will need to find a suitable terminal emulator program.


        A computer terminal was widely used in the days before PC’s as the primary human interface to mainframe computers.  It had a keyboard, a display screen and just enough smarts to send and receive RS-232 data.  Today, since our computers are so much more capable than just displaying text and accepting keystrokes, you can download a program that emulates a terminal in a window on your computer.  This terminal will be the portal in which you will communicate with your embedded device.

        Windows users of any recent installation need to turn to external software to be able to access the serial port.  Putty and TeraTerm are two of my favorite free terminal emulators.  Download and install one of those now. 



        Note that Linux and Mac computers have a built-in terminal and a built-in serial port device at /dev/ttyX, in which X is the identifier of the serial port.  Serial input and output can be routed to the built-in terminal with just a simple command like:


         screen /dev/ttyUSB0 115200


        where ttyUSB0 is wherever your USB-to-serial port adapter is located, and 115200 is the baud rate, described below.


        Configure the following parameters in your chosen terminal emulator:

        • Baud Rate – The speed at which the serial port will transfer data. Default is 9600 baud, which means that electrical signals will wiggle high and low up to 9600 times per second
        • Data Bits – The number bits that make up a single packet on the interface. Default is 8 bits.
        • Parity – Whether or not to use make use of a parity bit, which offers some rudimentary error checking. Default is off.
        • Stop Bits – How many transitions at the end of the data packet indicate the end of the data packet. Default is one bit.

        The most customary settings going back decades for all of these settings is known 9600 8N1.  This means 9600 baud, 8 data bits, no parity, and 1 stop bit.  I will actually be using a faster baud of 115200, which is a more modern standard speed.  In fact, most implementations can now support non-standard speeds like 115201, etc. 


        Once you have a serial port adapter connected to your computer and a terminal emulator program up and running, it is time to put them to use and communicate with your MCU on the Starter Kit.


        USART Peripheral

        There is a very powerful Swiss army knife of a peripheral on the EFM32 MCU called a Universal Synchronous Asynchronous Receiver Transmitter (USART).  Aren’t you glad that I explained what those big words meant beforehand?  What that basically means is that the USART can universally handle just about any kind of serial transfer, whether that be synchronous or asynchronous, and it can receive as well as transmit.  The MCU USART hardware, as well the software libraries that are built on top of that hardware, are at your disposal to automate a lot of the data transmission process, allowing your software to do other things and make the programming easier.


        You don’t need a USART to make this happen at slower speeds of 9600 baud or so.  The serial interface is still around because it one of the simplest of communication protocols and can be designed completely in software in today’s modern embedded systems.  However, your resources are always limited, and it still takes some CPU time and energy to toggle GPIO pins to emulate a serial link in software.  It is better to use a USART if you have it and allows for much higher speeds like 115200 baud.


        We will configure USART instance 0 through the use of the Configurator tool in Simplicity Studio in the next section.



      • mbed vs mbed OS – what’s the difference?

        Alf | 11/315/2015 | 03:59 PM


        This week, I’m blogging live from Arm TechCon, an event designed to connect the hardware and software communities. All of the industry pundits, engineers and makers here have been buzzing about ARM® mbed™, so I wanted to provide some insight.


        You maybe wondering…what’s the deal? Is mbed hype or the next best thing? As an embedded engineer at Silicon Labs, I wanted to share my thoughts.


        So, what is mbed?

        First a little bit of background on mbed, which ARM created to simplify device development. In many ways, it’s similar to projects like Arduino. They both aim to simplify prototyping by giving you access to a library of hardware components and free, ready-made software. Additionally, mbed is compatible with all Cortex-M class processors.


        Besides the tools created by ARM, mbed also has an awesome community of embedded enthusiasts that share code publically. The availability of these free snippets allows you to easily get started or expand your project. In the community, you can also find a free, fully-featured online IDE, tightly integrated with a revision control system.


        All of the basic functionality outlined above is called ARM mbed 2.0. Recently, however, ARM launched mbed 3.0.


        ARM Community


        ARM mbed 3.0

        The biggest difference between ARM mbed 2.0 and 3.0 is the amount of software integrated into it. With 3.0, ARM is also bringing technologies like Thread, TCP/IP and cloud connectivity directly to the user. mbed 3.0 also includes an operating system (OS), which is why the term “mbed OS” is often used interchangeably with ARM mbed 3.0. Since the OS-part is a defining facet of mbed 3.0, it can be found on (note the change of .org -> .com at the end).


        mbed OS contains unique features that enable it to be a basis for low-power systems, which is critical for IoT applications. It includes a scheduler for making sure that tasks get their appointed run-time. It also includes a hypervisor, called uVisor (micro-visor), to separate different task so that user-tasks cannot compromise the security of the complete system. This capability also opens the possibility of running user-generated, or insecure code on the devices, as the uVisior will make sure that it only takes the resources it is granted and cannot access secure information. It also protects against attacks. If you have a complicated RF stack and if someone breaks into it, they will find it very difficult to gain access to the rest of the system.


        What’s in it for me?

        Using mbed 3.0 gives you access to a good scheduler and an excellent framework to develop cloud-connected devices. Part of ARM’s mbed 3.0 offering is integrating a solution for you to easily manage your cloud-connected devices. You can easily see how they are performing, upgrade their software, and check their status. With mbed OS this is already integrated, allowing you to seamlessly transfer data from the device to the cloud and aggregate it using one of ARMs cloud partners.


        So if you don’t want to spend time on all the nitty-gritty details of how to get your data from the device to the cloud or learn how to manage 10s of thousands of devices, ARM mbed is the way to go!


        In related news, today at the conference, ARM also introduced its new wearables reference design featuring mbed OS. The design incorporates a lot of advanced power saving features, which is enhanced by the power-management APIs that my peers at Silicon Labs have co-developed with ARM. These low-power mbed APIs now provide a foundation for all peripheral interactions in mbed OS.


        Want to get started?

        To easily get you started, we’ve created a small-form-factor version board for developing both wearable design and IoT nodes with mbed OS. Called Thunderboard Wear, this demonstration board features our Giant Gecko MCU, Bluetooth Smart connectivity and myriad sensors, enabling you to evaluate optical heart rate monitoring and a lot of other fun stuff!


        The board works seamlessly with mbed OS and the Simplicity Studio development platforms. For more details including pricing and pre-order form, visit


        Thunderboard Wear


        Give Feedback

        So, what are your thoughts about mbed? Please share in the comments below. I would like to hear from you. 



      • Meet IoT Hero Guido Burger, Maker Extraordinaire

        deirdrewalsh | 11/314/2015 | 06:48 PM



        I've been engaging with engineers on social channels since I built my first technical community in 2006.  Every once in awhile I come across someone so awesome, that I have to reach out and introduce myself.  That's what happened when I saw Guido Burger's content online.  He is an inventor and overall inspiration. Guido is the latest Silicon Labs IoT Hero and through this interview you'll understand why.  He has connected everything from a coffee machine to an Easter Egg. 


        Please tell me a bit about yourself.

        As far back as I can remember, I’ve been building and inventing new things while trying to explore the world of electronics. One of my first projects was an analog to digital converter for my Sharp Pocket Computer running BASIC… with that I was able to explore the physical world. Later, I hacked my dad’s plotter to make it a scanner. I followed these projects by reverse engineering items, exploring sensor protocols, and designing an ISA adapter card for my PC/XT.


        So, I’ve had Maker DNA from a very early age. I think it’s important for today’s kids to get the opportunity to explore the world as I did. And this is one of my motivations for being an active maker. I share ideas, concepts - even when they look crazy at first – in order to prove that even Makers can build and design their own fitness tracker or even smart watch.


        Years ago, this was only possible with access to a high-tech lab and tons of money for engineering. Today, a “pizza-oven“ is great for soldering SMDs! Smiley Happy


        Just check out this “rocket“ style DIY-smart watch.

         DYI Smart Watch


        What inspired you to join the maker movement? 

        In my professional life, I’ve worked on many M2M solutions..from connected harvest combiners to coffee makers installed on a train … to connected cars. All of these projects are now seen as being part of the rich world of IoT.


        IoT is more than just connecting a thing to a cloud – it can disrupt the way we do business or how consumers use a service. The world is changing fast, especially since Makers are now empowered to build even more complex things.


        What are some of the cool IoT solutions you’ve been involved in creating? 

        One of my recent hacks was a connected coffee maker. I took a $50 Nespresso machine and made it completely controllable by a smartphone.


        Connected Coffee Maker


        This leads to a new user experience. You can control a cheap machine by gesture (smartphone), while transmitting usage data to service providers (supplies, services). You can also use the smartphone app to change the coffee / water mix with a simple finger swipe.


        We could even take it one step deeper and change the brewing process. Why not make other drinks with the same machine… software defined drink maker?!? 


        How are you using Silicon Labs products today? 

        When I needed a BLE module to connect my things to the cloud or a smartphone I did some research and found the BLE112, which was interesting for me out of two simple reasons:


        1. it had great community webpage and project (open) to be a great starting point to build my own scripts for the BLE.Again, a fundamental competent to success is having things open and shared. This helps speed up innovation and adoption.


        2. it was one of the few modules that had pre-certification.


        Today, I am using BLE112 and more often the BLE113 because of its smaller footprint and already integrated memory for OTA updates, reducing the BOM and PCB size.  To combine BLE and Arduino capabilities, I designed the blueIOT board, which is available on tindie.


        blueIOT board


        This is now the foundation for most of my projects and also has gotten a great deal of traction in the market with many new projects developed by the community. For example, check out these 3D printed Easter eggs that hide themselves


        Smart Easter Egg


        In you’re opinion, what is the biggest barrier to wide-spread IoT development?  

        IoT brings together mechanical, electronics and software engineering. I remember back in the early years of connected cars there was always a battle between car IT and business IT … who will be in charge of the SW in the car? Should it be rugged or can it be updated anytime?


        The same is true for mechanical design. Even though there are 3D printers accessible to everybody, CAD is something you need to learn to make good mechanical designs. When I talk to students, they are always highly motivated to do projects, but the hurdle to understand all the various technologies is high and complex.


        Arduino and Raspberry PI for sure did a great job on making SW/HW coming close together and being available at no price to everybody. BUT - IoT is only providing value if you attach sensors and you understand the context of data created. Having a notion of what you could do/change based on the data being sensed is important.


        For example, as I stated, power consumption is very important for scale of IoT solutions. I spend a lot time in monitoring and optimization.  


        "A great amount of data is even reachable by Maker!"

        Screenshot 2015-11-10 17.17.51.png

        blueIOT with BLE112 - average power consumption during default BLE advertisement: 35,5 uAh with a 210mAh this will last close to 6000h on operation (or > 240 days) with little tuning (e.g. timing of advertisement). This can be much improved further!


        That’s why we designed in our small fab-lab the pico-Platinchen, which is already designed to carry the BLE113. It’s an all-in one sensor, Arduino-compatible, connected things platform, perfect for wearables or any sort for IoT projects demanding sensors. Now you can focus on the value and distributive thinking … instead of worrying about the underlying technology.


        I know it’s a big question, but what does the future of IoT look like? 

        Analysts are stating that every thing will be connected one day - will it make sense? Well, it has to provide some value to the users / consumers - or make a process smarter or more efficient. One thing people tend to forget is all these things will demand power to run and transmit data - energy efficient design and alternative technologies, like energy harvesting or solid-state batteries, will be important to drive the adoption further.


        "An important Maker slogan: Give it a try. It will work. Make it work but also understand (open it and look under-the-hood). This will be key for a bright future with IoT."


        Have a question for Guido? Comment below or tweet him at @guido_burger


      • October, 2015 Member Spotlight: vanmierlo

        Siliconlabs | 11/306/2015 | 07:17 AM

        We are featuring one of the Silicon Labs Community members who is active or new in the community on a monthly basis to help members connect to each other.


        Meet our October member of the month: vanmierlo



        Q: Congrats on becoming our featured member of the month! Can you introduce yourself to our community members? 


        My name is Maarten Brock and I am from The Netherlands. I work for a small engineering company in Eindhoven called Van Mierlo Ingenieursbureau, hence my account name and avatar logo. I have been programming since I was about 14 and went from Basic, via assembly and Pascal to C. I studied Electrical Engineering with a focus on IT. On the job I also learned to write VHDL.


        Apart from using C and assembly to program microcontrollers, I am also a developer of the Open Source Small Device C Compiler (SDCC). I have often used a SiLabs MCU to test on.


        Q: You have joined the community since 2002. What brought you to the community (previously 8-bit MCU forum) for the first time?


        I don't have a clue what my first post was about. I was probably looking for some answer for the C8051F020 that we had started using back then. Our company had previously switched away from the 8052 to 68HC11 and then we found this 8052 derivative with on-chip debugging and very affordable tooling. Quite a difference with the expensive yet fragile in-circuit emulators we had to use before. And soon after Cygnal (now SiLabs) opened a forum where users could meet and discuss the peculiarities they encountered. I have received good help on the forum and also learned a lot from reading other peoples' questions and answers.


        In another way of trying to help I sent my first patch to SDCC to add three C8051F header files in January 2004. A few months later I got developer rights and last year I found myself release manager.


        A few years ago our company felt the need to start using a low power ARM and went with the EnergyMicro EFM32 Gecko. They also featured a forum, which again helped me a lot. And again SiLabs bought it and since then my accounts are merged :-)


        Q: You have helped our community members to get their questions answered for many years. What motivates you to help them? 



        I found that it feels rewarding to help other people along. A good question often triggers my own curiosity and makes me find an answer. And when you think you have it, you might as well post it. It also feels a bit like an obligation: if you were helped for free before the least you can do is extend the same courtesy to the ones that follow.


        But sometimes people think you will help anyone for free and start sending private messages or emails. In such a case my answer is to pay my usual fee or take the question online. A private question with a private answer helps nobody but this one person where anyone with a similar problem could benefit from an answer in the forum.


        Q: What advice would you give to someone new to the community? 



        Search, read, don't be afraid to ask, but be prepared to do some work and provide enough details. The forum is not to get someone else to do your (home)work.


        Q: What pages do you usually visit in the community, and why?



        Almost all subfora. Well, I can't read Chinese so I skip those. And although we as a company are very interested in wireless we don't use SiLabs wireless just yet. And this subforum is so busy I can't really keep up. And with my focus on the forum I probably miss out on the blogs, training, and share posts.


        Q: Thanks for answering the questions. Any final comment?


        Thanks for electing me and for reading my story. And the only final comment can be: When will Simplicity Studio support SDCC for the 8051?