This is a five part series on the SPI communication protocol.  In the first section, we learned all about SPI and how to make a SPI flash breakout board from a bare chip.  In this section, we will connect the SPI flash to the EFM32 Starter Kit and then write some code with the help of the USART library to fetch the JEDEC ID from the register on the part.  We will continue to rely on the Spansion flash chip’s spec to accomplish this.

Flash Chip to MCU Connections

The SPI bus requires either three or four wires, depending on the mode. 

I will demonstrate the use of SPI using the four-wire mode, which is more common in my experience than the three-wire mode.  The EFM32 USART supports the three-wire mode and calls this mode Synchronous Half Duplex Communication.  In that case, the MISO line is not used and the MOSI line becomes a bidirectional signal.  You can read more about it in the Reference Manual.

In SPI terminology, a SPI device can be a master or a slave device, at any given moment in time.  The USART peripheral in the EFM32 can be configured as either one.  One device has to be the master and the other a slave for a single SPI transaction.  We will configure the MCU as master since the MCU is driving the interaction with the flash chip.  We might someday configure the MCU as a slave if we have another MCU in a system and intend to share information between the two of them.  But we could configure our USART in the MCU dynamically to be a slave on one cycle, then a master on the next cycle.

The Master In Slave Out (MOSI) terminology is an improvement over the RX/TX nomenclature of the serial port connections.  Now, a master device’s MOSI output pin connects directly to a slave’s MOSI input pin, and MISO pin to MISO pin.  This is great, because the connections are made between like-named, or at least similarly-named pins.  Unfortunately the Data Sheet tables for the USART pins don’t specifically list MOSI/MISO, and you still need to know to map the USART TX pins to MOSI and the USART RX pins to MISO.  This information is covered in the Reference Manual for the USART peripheral.  In addition, some devices don’t use the MOSI/MISO naming and instead use SDI, DI, SI, etc. for an input.  If you can find the one that says input, attach that to the master’s MOSI and you will do fine.

The flash chip breakout board has additional signals that must be attached to your Starter Kit.  The first thing to look for are the power and ground connections.  Whenever you are connecting your MCU to an external device, you need to take a look at the voltage requirements in the spec for that device.  This is listed in the Electrical section for the Spansion chip.

The Supply Voltage (also known as Vcc and sometimes called Vdd) requires between 2.7V and 3.8V.  Sometimes you will find chips that require 1.8V or 2.8V, which would then need an external power supply to be provided.  In this case, the chip can be powered directly from the Starter Kit’s 3.3V supply pins that are labeled as 3V3.  Connect the signals as shown in the table below.  We are using specific pins of USART1 location 1 for the SPI signals, since those are brought out to pins on the Starter Kit, and just any old GPIO’s for the other signals.

SPI Software Configuration

Now that everything is wired up, it is time to communicate with the flash memory chip from the MCU with software.  You can use Simplicity Configurator to configure the part like we did in the last lesson, or manually configure your USART to connect to the SPI signals CLK, CS, MOSI (TX in the USART) and MISO (RX in the USART).  I will demonstrate how to do it manually for this chapter.

There is a decision to be made about the clock mode when configuring the clock signal in the USART software setup.  With SPI, very little is set in stone.  It is up to the chip designers to determine exactly how the electrical signals should operate.  The USART provides configuration registers that handle the polarity and phase in order to work with all devices.  These are referred to as CPOL or CLKPOL (depending on the chip) for the clock polarity and CPHA or CLKPHA for the clock phase.  The clock polarity can be set to either 0 or 1, which determines the idle state of the clock line.  The clock phase can also be 0 or 1, which determines whether data is latched on the rising or falling edge of the clock signal.  This gives four possible choices for clock modes 0 through 3, which make up the four clock modes.  There are diagrams in the Reference Manual that describe all four modes. 

All that really matters to us at this point is that we pick the right mode for the Spansion chip.  If we look in the spec for the Spansion flash chip, we see that it can operate in either clock mode 0 or clock mode 3. 

When configuring the CS line, there is a decision to be made about whether or not the USART peripheral will control the CS line automatically, known as AUTOCS, or if the software will explicitly control the CS line to the slave SPI device.  We will need to control the CS line explicitly, because if we were to pick AUTOCS mode and fail to feed the USART the two bytes of data fast enough, the USART-controlled CS line will go high in the middle of the above waveform, and the device will essentially forget all about the command we requested.  We need to drive the CS line low for the entire time as shown in the diagram.  The AUTOCS mode is better used when we are sending bytes to the USART through another hardware mechanism rather than software.

We will leave the SPI bus frequency at the default of 1MHz.  The table in the Spansion spec states that the chip supports SPI bus frequencies up to at least 44MHz, but you should be aware that the maximum that the EFM32 chip can reach is about one half of the HFPER clock frequency.  With the default HFRCO clock setup, that means it can only reach about 7MHz. Plus, our breadboard setup is more likely to see noise that could cause glitches at higher frequencies.

void usart_setup()
{
      // Set up the necessary peripheral clocks
      CMU_ClockEnable(cmuClock_GPIO, true);
      CMU_ClockEnable(cmuClock_USART1, true);
 
      // Enable the GPIO pins for the USART, starting with CS
      // This is to avoid clocking the flash chip when we set CLK high
      GPIO_PinModeSet(gpioPortD, 3, gpioModePushPull, 1);         // CS
      GPIO_PinModeSet(gpioPortD, 0, gpioModePushPull, 0);         // MOSI
      GPIO_PinModeSet(gpioPortD, 1, gpioModeInput, 0);            // MISO
      GPIO_PinModeSet(gpioPortD, 2, gpioModePushPull, 1);         // CLK
 
      // Enable the GPIO pins for the misc signals, leave pulled high
      GPIO_PinModeSet(gpioPortD, 4, gpioModePushPull, 1);         // WP#
      GPIO_PinModeSet(gpioPortD, 5, gpioModePushPull, 1);         // HOLD#
 
      // Initialize and enable the USART
      USART_InitSync_TypeDef init = USART_INITSYNC_DEFAULT;
      init.clockMode = usartClockMode3;
      init.msbf = true;
 
      USART_InitSync(USART1, &init);
 
      // Connect the USART signals to the GPIO peripheral
      USART1->ROUTE = USART_ROUTE_RXPEN | USART_ROUTE_TXPEN |
                  USART_ROUTE_CLKPEN | USART_ROUTE_LOCATION_LOC1;
}

All of that work and we still don’t have anything that we can test to see if we did it right.  We still need some code to actually initiate a SPI cycle and we need to find a destination for that cycle that will yield a meaningful result to prove that the SPI command worked or not.  For this purpose, I turn to identification registers.  The chip designers of SPI parts will usually give you a softball register that always returns a non-zero fixed value to let you test basic connectivity and signs of life.  In this case, that register in the Spansion SPI Flash is the JEDEC ID at address 0x9F.  It actually has three distinct, non-zero fixed values that it can return one after another.  So we can test to make sure that we find the first value, then expand our test case to make sure that we find all three values.

#include "utilities.h"  // Re-used from earlier lesson for delay function
 
#define JEDEC_ID_CMD    0x9F
 
int main(void)
{
      CHIP_Init();
 
      usart_setup();
 
      setup_utilities();
 
      delay(100);
 
      uint8_t result[3];
      uint8_t index = 0;
 
      GPIO_PinModeSet(gpioPortD, 3, gpioModePushPull, 0);
 
      // Send the command, discard the first response
      USART_SpiTransfer(USART1, JEDEC_ID_CMD);
 
      // Now send garbage, but keep the results
      result[index++] = USART_SpiTransfer(USART1, 0);
      result[index++] = USART_SpiTransfer(USART1, 0);
      result[index++] = USART_SpiTransfer(USART1, 0);
 
      GPIO_PinModeSet(gpioPortD, 3, gpioModePushPull, 1);
 
      // Check the result for what is expected from the Spansion spec
      if (result[0] != 1 || result[1] != 0x40 || result[2] != 0x13)
      {
            DEBUG_BREAK
      }
 
      while (1)
            ;
}

Execute the code shown and break in on the while loop.  You should see a value of 1 in the result array at the 0 position.  This proves to a 1/254 chance that we are reading the register that we think we are reading.   Had this register’s default been zero or 0xff, we could not be sure that we were reading the right register because 0xff is the default state of flash memory at reset and zero is the usual default state for most configuration registers.  But since the default value for this Manufacturer ID is 1, we can be confident that this SPI driver is beginning to work.

You should notice something funny going on in this code.  We read a single value from the USART_SpiTransfer function and don’t do anything with the return value, then we read another value before storing the return value.  That is because a four-wire SPI bus is ALWAYS bidirectional.  When a master drives a cycle out on MOSI, the slave is required to drive something on MISO for every clock edge, even on the first clock.  But since the slave doesn’t even know what is being asked until after that first clock, the slave device will either send back a useless value, or sometimes slave devices will use this first bit time as a chance to send back a status message.   You have to examine the SPI chip’s spec to find out what it will do.  Once the command from the first bit time is latched and processed by the slave, it can respond with the necessary information on the second SPI transfer.

The code verifies that all three values from the JEDEC ID command are as expected, which gives us near certainty that we have indeed read from the Flash SPI device properly and the USART driver is working well so far.

In the next section, we will take a look at these SPI waveforms on the oscilloscopes and learn about more advanced SPI topology.

PREVIOUS I NEXT

This is a five part series on the SPI communication protocol.  In the first section, we learned all about SPI and how to make a SPI flash breakout board from a bare chip.  In this section, we will connect the SPI flash to the EFM32 Starter Kit and then write some code with the help of the USART library to fetch the JEDEC ID from the register on the part.  We will continue to rely on the Spansion flash chip’s spec to accomplish this.

Flash Chip to MCU Connections

The SPI bus requires either three or four wires, depending on the mode. 

I will demonstrate the use of SPI using the four-wire mode, which is more common in my experience than the three-wire mode.  The EFM32 USART supports the three-wire mode and calls this mode Synchronous Half Duplex Communication.  In that case, the MISO line is not used and the MOSI line becomes a bidirectional signal.  You can read more about it in the Reference Manual.

In SPI terminology, a SPI device can be a master or a slave device, at any given moment in time.  The USART peripheral in the EFM32 can be configured as either one.  One device has to be the master and the other a slave for a single SPI transaction.  We will configure the MCU as master since the MCU is driving the interaction with the flash chip.  We might someday configure the MCU as a slave if we have another MCU in a system and intend to share information between the two of them.  But we could configure our USART in the MCU dynamically to be a slave on one cycle, then a master on the next cycle.

The Master In Slave Out (MOSI) terminology is an improvement over the RX/TX nomenclature of the serial port connections.  Now, a master device’s MOSI output pin connects directly to a slave’s MOSI input pin, and MISO pin to MISO pin.  This is great, because the connections are made between like-named, or at least similarly-named pins.  Unfortunately the Data Sheet tables for the USART pins don’t specifically list MOSI/MISO, and you still need to know to map the USART TX pins to MOSI and the USART RX pins to MISO.  This information is covered in the Reference Manual for the USART peripheral.  In addition, some devices don’t use the MOSI/MISO naming and instead use SDI, DI, SI, etc. for an input.  If you can find the one that says input, attach that to the master’s MOSI and you will do fine.

The flash chip breakout board has additional signals that must be attached to your Starter Kit.  The first thing to look for are the power and ground connections.  Whenever you are connecting your MCU to an external device, you need to take a look at the voltage requirements in the spec for that device.  This is listed in the Electrical section for the Spansion chip.

The Supply Voltage (also known as Vcc and sometimes called Vdd) requires between 2.7V and 3.8V.  Sometimes you will find chips that require 1.8V or 2.8V, which would then need an external power supply to be provided.  In this case, the chip can be powered directly from the Starter Kit’s 3.3V supply pins that are labeled as 3V3.  Connect the signals as shown in the table below.  We are using specific pins of USART1 location 1 for the SPI signals, since those are brought out to pins on the Starter Kit, and just any old GPIO’s for the other signals.

SPI Software Configuration

Now that everything is wired up, it is time to communicate with the flash memory chip from the MCU with software.  You can use Simplicity Configurator to configure the part like we did in the last lesson, or manually configure your USART to connect to the SPI signals CLK, CS, MOSI (TX in the USART) and MISO (RX in the USART).  I will demonstrate how to do it manually for this chapter.

There is a decision to be made about the clock mode when configuring the clock signal in the USART software setup.  With SPI, very little is set in stone.  It is up to the chip designers to determine exactly how the electrical signals should operate.  The USART provides configuration registers that handle the polarity and phase in order to work with all devices.  These are referred to as CPOL or CLKPOL (depending on the chip) for the clock polarity and CPHA or CLKPHA for the clock phase.  The clock polarity can be set to either 0 or 1, which determines the idle state of the clock line.  The clock phase can also be 0 or 1, which determines whether data is latched on the rising or falling edge of the clock signal.  This gives four possible choices for clock modes 0 through 3, which make up the four clock modes.  There are diagrams in the Reference Manual that describe all four modes. 

All that really matters to us at this point is that we pick the right mode for the Spansion chip.  If we look in the spec for the Spansion flash chip, we see that it can operate in either clock mode 0 or clock mode 3. 

When configuring the CS line, there is a decision to be made about whether or not the USART peripheral will control the CS line automatically, known as AUTOCS, or if the software will explicitly control the CS line to the slave SPI device.  We will need to control the CS line explicitly, because if we were to pick AUTOCS mode and fail to feed the USART the two bytes of data fast enough, the USART-controlled CS line will go high in the middle of the above waveform, and the device will essentially forget all about the command we requested.  We need to drive the CS line low for the entire time as shown in the diagram.  The AUTOCS mode is better used when we are sending bytes to the USART through another hardware mechanism rather than software.

We will leave the SPI bus frequency at the default of 1MHz.  The table in the Spansion spec states that the chip supports SPI bus frequencies up to at least 44MHz, but you should be aware that the maximum that the EFM32 chip can reach is about one half of the HFPER clock frequency.  With the default HFRCO clock setup, that means it can only reach about 7MHz. Plus, our breadboard setup is more likely to see noise that could cause glitches at higher frequencies.

void usart_setup()
{
      // Set up the necessary peripheral clocks
      CMU_ClockEnable(cmuClock_GPIO, true);
      CMU_ClockEnable(cmuClock_USART1, true);
 
      // Enable the GPIO pins for the USART, starting with CS
      // This is to avoid clocking the flash chip when we set CLK high
      GPIO_PinModeSet(gpioPortD, 3, gpioModePushPull, 1);         // CS
      GPIO_PinModeSet(gpioPortD, 0, gpioModePushPull, 0);         // MOSI
      GPIO_PinModeSet(gpioPortD, 1, gpioModeInput, 0);            // MISO
      GPIO_PinModeSet(gpioPortD, 2, gpioModePushPull, 1);         // CLK
 
      // Enable the GPIO pins for the misc signals, leave pulled high
      GPIO_PinModeSet(gpioPortD, 4, gpioModePushPull, 1);         // WP#
      GPIO_PinModeSet(gpioPortD, 5, gpioModePushPull, 1);         // HOLD#
 
      // Initialize and enable the USART
      USART_InitSync_TypeDef init = USART_INITSYNC_DEFAULT;
      init.clockMode = usartClockMode3;
      init.msbf = true;
 
      USART_InitSync(USART1, &init);
 
      // Connect the USART signals to the GPIO peripheral
      USART1->ROUTE = USART_ROUTE_RXPEN | USART_ROUTE_TXPEN |
                  USART_ROUTE_CLKPEN | USART_ROUTE_LOCATION_LOC1;
}

All of that work and we still don’t have anything that we can test to see if we did it right.  We still need some code to actually initiate a SPI cycle and we need to find a destination for that cycle that will yield a meaningful result to prove that the SPI command worked or not.  For this purpose, I turn to identification registers.  The chip designers of SPI parts will usually give you a softball register that always returns a non-zero fixed value to let you test basic connectivity and signs of life.  In this case, that register in the Spansion SPI Flash is the JEDEC ID at address 0x9F.  It actually has three distinct, non-zero fixed values that it can return one after another.  So we can test to make sure that we find the first value, then expand our test case to make sure that we find all three values.

#include "utilities.h"  // Re-used from earlier lesson for delay function
 
#define JEDEC_ID_CMD    0x9F
 
int main(void)
{
      CHIP_Init();
 
      usart_setup();
 
      setup_utilities();
 
      delay(100);
 
      uint8_t result[3];
      uint8_t index = 0;
 
      GPIO_PinModeSet(gpioPortD, 3, gpioModePushPull, 0);
 
      // Send the command, discard the first response
      USART_SpiTransfer(USART1, JEDEC_ID_CMD);
 
      // Now send garbage, but keep the results
      result[index++] = USART_SpiTransfer(USART1, 0);
      result[index++] = USART_SpiTransfer(USART1, 0);
      result[index++] = USART_SpiTransfer(USART1, 0);
 
      GPIO_PinModeSet(gpioPortD, 3, gpioModePushPull, 1);
 
      // Check the result for what is expected from the Spansion spec
      if (result[0] != 1 || result[1] != 0x40 || result[2] != 0x13)
      {
            DEBUG_BREAK
      }
 
      while (1)
            ;
}

Execute the code shown and break in on the while loop.  You should see a value of 1 in the result array at the 0 position.  This proves to a 1/254 chance that we are reading the register that we think we are reading.   Had this register’s default been zero or 0xff, we could not be sure that we were reading the right register because 0xff is the default state of flash memory at reset and zero is the usual default state for most configuration registers.  But since the default value for this Manufacturer ID is 1, we can be confident that this SPI driver is beginning to work.

You should notice something funny going on in this code.  We read a single value from the USART_SpiTransfer function and don’t do anything with the return value, then we read another value before storing the return value.  That is because a four-wire SPI bus is ALWAYS bidirectional.  When a master drives a cycle out on MOSI, the slave is required to drive something on MISO for every clock edge, even on the first clock.  But since the slave doesn’t even know what is being asked until after that first clock, the slave device will either send back a useless value, or sometimes slave devices will use this first bit time as a chance to send back a status message.   You have to examine the SPI chip’s spec to find out what it will do.  Once the command from the first bit time is latched and processed by the slave, it can respond with the necessary information on the second SPI transfer.

The code verifies that all three values from the JEDEC ID command are as expected, which gives us near certainty that we have indeed read from the Flash SPI device properly and the USART driver is working well so far.

In the next section, we will take a look at these SPI waveforms on the oscilloscopes and learn about more advanced SPI topology.

PREVIOUS I NEXT

Location: ExCel, Royal Victoria Dock, 1 Western Gateway, London, the United Kingdom
Booth: #282
Date: March 15-16, 2016

3/15, 11 am; Making the Right Connection: Understanding Wireless Protocol Options for the IoT

Presenter: Anders Pettersson, Senior Product Manager - Silicon Labs

The show overview video from 2015:

With more than 200 speakers, the conference programme will deliver more comprehensive and in-depth information than any other wearables event.

In the expo hall, visitors will be able to see some of the latest and most innovative products in the Crunchwear Zone, as well as viewing wearable technologies and smart gadgets from some of the biggest names in technology.

The (G) Force is Strong with these RGB LEDs

Customizable RGB LEDs are finding their way into all kinds of devices, particularly gaming applications where the trend has gone from enabling customizable light patterns to actually being incorporated into game-play. That’s all fun and games, but check out what happened when we paired our Blue Gecko BGM111 Bluetooth Smart Module with a 3-axis accelerometer on a custom board with the BLED112 Bluetooth Smart Dongle.

To show multiple Bluetooth devices in a set-up, we've configured these mini kits to use g-force to control Bluetooth-enabled lighting boards. The lighting reference designs are using both the lighting reference boards are Bluetooth peripherals, while the PC with the BLED112 dongle is configured as a Bluetooth central device. 

By monitoring the XYZ axis, the sum determines the color of the LEDs. The lighting reference boards have firmware capable of receiving the LED colors and information is sent from either the keys or the accelerometers which emulates the keys in this application to the PC.

When the PC receives information, it turns on or off the corresponding LEDs:

1 G (the board is laying still) is translated to no keys pressed.

>1 G (added acceleration in any direction) is translated to the blue key is pressed.

<1 G (reduced acceleration, like a free fall) is translated to the red key is pressed.

Today we’re going to look back at your favorite videos from the community, so pour yourself some coffee and clear your schedule.  

The top 5 viewed videos last year were:

Tyson Tuttle’s Embedded World Opening Keynote

EFM32 Zero Gecko Starter Kit

Timing Tutorial

8-bit EFMB 8051 Overview

Simplicity Studio Overview

Tell us about what your favorite videos were from last year!

When the milk system in the coffee machine (a Jura GIGA X8c Professional) decided to break down, the entire office was in distress. In order to get the coffee machine, and everyone else, working again Torkil and I went on the path to debug and fix this prized asset.

After a long debugging session (a couple of minutes) it turns out that the problems was caused by a misalignment of the milk container and the things that will suck the milk up from them:

So, as you know, everything around this office can be fixed using the EFM32. You can see here how we did that:

The chips we used are the EFM32GG990F1024 that come in the handy BGA112 packaging.

And with the fix in place, you can now see the milk-sucking-thing aligns slightly more out of the machine:

Debugging and fixing done, time to try it out:

And alas! It works, Torkil enjoying his well deserved cappuchino:

Can the Internet of Things tug at your heartstrings? After my interview with Tommy Cunningham, co-founder and COO of NFANT Labs LLC, I know the answer is “yes.” He shared insights into his new company, which focuses on improving the outcomes and lives of neonatal infants through wirelessly connected medical devices. This interview is VERY timely since my sister-in-law is literally in labor as I write this! 

Tell us about yourself and your company.

I have a background in biomechanics, and am the co-founder of NFANT Labs. We’ve come a long way in a short amount of time. We basically built the organization from just two researchers and an idea, bootstrapping with next to nothing to start; every dollar we spent was important. In less than two years, we’ve performed clinical research, secured funding, designed and produced the product, brought on staff, and obtained FDA clearance. Needless to say, it has been a real roller coaster ride.

How did you get the idea for the nfant® Feeding Solution?

Back in school, when I was working on my PhD, I would meet with clinicians who had great ideas but didn’t know how to build anything. By the time I graduated, I had about 10 different projects under my belt, and had learned how to work on a low budget.

One of the project ideas came from eventual co-founder Dr. Gilson Capuluto, who proposed creating a device to measure tongue strength during infant feeding. Currently, deciding exactly when it is safe to begin oral feeding and determining how to best advance an infant’s feeding is based on a caregiver’s professional experience and trial and error. We set out to build a device that would help determine when NICU infants are ready to transition from tube feeding to bottle- or breastfeeding based on objective data. This is a really important step because babies can’t leave the hospital until they demonstrate this feeding ability. Many infants might know how to feed, they just don’t have the lingual strength and coordination to accomplish the task. The thought was to build a tool that could first diagnose strength and coordination deficiencies before clinicians intervene.

There was another device on the market that did something similar, with a pacifier, but it was complex, costly, and cumbersome. After listening to feedback from doctors and nurses, I learned that these huge, wired machines were not targeting what the market wanted. What was needed was a small, wireless device that fit into the workflow of hospital clinicians and gave them bedside, actionable data during actual feeding.

We also recognized that while lots of people talk about connecting health metrics, nobody was actually doing it in the NICU, or really anywhere in the hospital, for that matter. The key to the future of medical technology is to take any dumb medical device, make it smart, make it wireless, and push physiological data to a mobile device and the cloud for analytics.

How are you using Silicon Labs products today?

We started out in an unconventional way. The initial design criteria that I gave our engineers was, “Here’s the Bluetooth module I want to run our board. Let’s design around this for our first prototype." We didn’t want to be endlessly breadboarding with wires hanging around because the NICU is already a very scary environment. It’s stressful. You are often dealing with life or death situations, and anything that looks intimidating is bad news. Designing initial prototypes for manufacturability from the start was risky, but it turned out to be critical to our rapid success on many fronts.

We kicked the tires on a lot of options, but finally went with the BLE113, which was proven and had a great reputation.

I intentionally chose components and sensors that were both mass produced and cutting edge to get the best technology at an affordable price. That made our product less expensive to produce. We were able to launch it at a fraction of the cost, and adopt a more flexible, analytics-driven business model than I think our industry had seen.

What was your biggest hurdle bringing your product to market?

The most intimidating factor was that we were blazing a trail. We were bringing something entirely new to the market in a highly regulated industry filled with entrenched practices, bureaucracy, complicated business processes, and painstaking evaluation practices. Despite the challenges, we pushed from concept to FDA submission in a matter of months, and emerged with clearance nine months later. As you can imagine, EMC compliance testing was vigorous during this process. We are fortunate and relieved to have gone with such a proven technology stack.

What’s the next milestone on your horizon?

We’re already seeing immediate value with the product at bedside with real-time biofeedback. It’s helping clinicians do the important work of navigating infants home safely and effectively.

The long-term goal of the company is to build a connected NICU that will help these medical professionals figure out how to iteratively improve treatments for their patients. Clinicians have to rely primarily on personal experience to know what to do. We are breaking down those silos and capturing many parameters to build predictive models to act on. Leveraging insights gained from our technology, clinicians will be able to enhance their daily medical practice with data-driven evidence.

This is a great example of Internet of Things. How would you define Internet of Things?

IoT leverages great technologies, like low-energy Bluetooth, to acquire data from a device, capture and push that information to the cloud, and then make sense of it.

In some cases, that’s all hype. Today, people can capture data on just about anything they want. But to be useful, they need proper constructs or else they’re just collecting data for the sake of it.

We set out to conquer an issue: an infant's inability to feed. We stream physiological data to a mobile app and capture clinical parameters surrounding that data to help us create context. Aggregating and analyzing this data in the cloud and pushing back down for clinical interpretation will shift the standards of modern medical technology.

What does a more connected world mean to you?

The more connected we are, the more patients we can help.

By providing a means for data-driven decisions, we are empowering clinicians, patients, and even payers; everyone will benefit. This is the true essence of an evidence-based practice of medicine. We’re providing just that.

Learn more about Tommy and NFANT Labs on their website: http://bit.ly/1WrEY9z.

For more information about the BLE113 Bluetooth Smart Module, and to purchase the Bluetooth Smart Development Kit, click here. 

Silicon Labs turns twenty this year, so over the course of 2016 we’ll be taking a look at how we got here, where we’re going, and meet some of the employees, partners, and customers that have helped shape the company over the last two decades.

In our second part of this series, we’ll take a look back the company’s first half-decade and see how the seeds of innovation were sown.  

Silcon Labs’ story began in the 1980s, when a group of engineers bonded at Austin-based startup Crystal Semiconductor. In the largely digital semiconductor world, Crystal was focused on the rarest and most difficult type of electronic circuitry design – mixed-signal, which takes analog signals like sound and radio waves and converts them into finite digital numbers.

Dave Welland, who was the first Crystal employee, had an especially strong relationship with Nav Sooch and Jeff Scott, who had also worked together at AT&T Bell Laboratories. When Crystal was acquired by digital-focused Cirrus Logic in 1991, the three began looking for new mixed-signal design challenges, which would give them control over their own destinies. In early 1996, the siren song of entrepreneurship grew louder, and after months of weekend brainstorming sessions and a long lunch that ended with a coin toss sealing their decision to start a company, the group resigned from Crystal.

1996 – Silicon Labs is born

The team began tearing products apart, looking for components that could be replaced with computer chips or integrated circuits. The first opportunity they found was on a modem card. In the early days of dial-up Internet, every modem was required by law to have a DAA, or direct access arrangement. The DAA protected the phone line from electrical power surges and acted as a translation mechanism between the computer’s digital language and the phone’s analog signal. But existing DAAs were a mess of bulky components, and the team believed they could create a smaller, less expensive, and more elegant version on an integrated circuit. They continued to disassemble everything they could get their hands on, so it didn’t take long to unearth another promising opportunity with the radio frequency (RF) synthesizers found in cell phones. These synthesizers, which assigned a frequency (or channel) to each incoming call, were clunky, and the group felt they could do better.  

1997 – Austin Ventures invests $5 million in first round of funding

In March 1997, Silicon Labs secured a $5 million investment from Austin Ventures based on the DAA for modems and the RF synthesizer for cell phones. Sooch became chairman and chief executive officer, Scott became vice president of engineering, and Welland became vice president of technology.

While diversification was their long-term goal, their immediate objective was profitability. It would take time to solve the design challenges that came with building an RF synthesizer in CMOS, so they threw most of their resources into the DAA. Their timing was perfect. The PC industry was transitioning from hardware modems to software modems, which created a perfect target for getting Silicon Labs’ products to market quickly.

1998 – The DAA goes from prototype to profitability in less than two years

Scott led research and development on the DAA with a team of new hires that included many Crystal alumni, such as Silicon Labs’ current CEO, Tyson Tuttle. As with all of Silicon Labs’ core technologies since, the team implemented the DAA in CMOS to ease the further integration of digital functionality in future derivatives as communications products continued to get smaller, less expensive, and more feature-rich.

Silicon Labs’ DAA was revolutionary because it was one-fifth the size of the existing solutions, cost half as much, and was programmable, which allowed users to customize it with their local language and standards. Previously, the industry required that a different version of a modem be built for each country. Silicon Labs’ revolutionary approach allowed a single modem to work worldwide.

Modem manufacturers PC-Tel and 3Com were Silicon Labs’ first customers, and units began shipping in April, just one month after the product was introduced. Based solely on the success of the DAA products, Silicon Labs achieved profitability in 1998 and reported $5.6 million for the year.

Silicon Labs’ DAA captured about half the v.90 modem market by 2003, and the modem products we’re selling 20 years later are still based on the DAA’s technology. That’s a remarkable feat in an industry where things often become obsolete within two years, and it speaks to our ability to identify and design for very specific markets.

1999 – The world’s first CMOS radio-frequency (RF) synthesizer chip

Because the DAA chips provided financial stability, Welland led a core Silicon Labs design team in building the world’s first CMOS radio-frequency (RF) synthesizer chip for cell phones. At the time, all of the RF chips on the market used a bipolar process. It was clear that redesigning the RF in CMOS could essentially democratize the mobile phone, making it much easier and cheaper to produce.

The RF synthesizer was an immediate hit when it went on the market in late 1999. Samsung was its first customer. The chip cost less than options offered by competitors, and because it fit nearly 80 components – including the functions of several bulky metal-can, voltage-controlled oscillator (VCO) modules – onto a single chip, it also saved handset makers valuable space.

Silicon Labs continued to diversify its portfolio of wireless, wireline, and optical products to add to the DAA’s powerhouse performance. The company generated nearly $47 million in revenue in 1999.

2000 – One of the year’s strongest IPOs

In March 2000, Silicon Labs raised $99 million with an initial public offering. It was listed on the NASDAQ as SLAB, offering 3.2 million shares at $31 each with an overall valuation of $1.2 billion.

The IPO more than repaid Silicon Labs’ venture capital investors, and still allowed the three founders to keep 45 percent of the company. It was a huge achievement for a company that had spent only $6 million to become profitable to go public, and also a huge win for the founders to retain such control.

Next time we’ll compare the technology landscape of 1996 with that of today. You can read the previous post in this series here.

If concrete could talk, what would it say? Giatec knows. Its smart concrete technology is developing IoT for the construction industry, which means enhanced safety and sustainability for the rest of us. With this advancement, I've chosen their CEO to be this month's IoT Hero! 

Please introduce yourself and your company.
My name is Aali Alizadeh. I am the CEO and cofounder of Giatec, which develops innovative testing solutions for the concrete industry. We provide concrete quality control tools for pre-construction, and accurate condition assessment devices for post-construction for companies in more than 30 countries. Giatec is rapidly growing its market share as a leading knowledge-based concrete testing company.

How did you get the idea for smart concrete?
We started with stand-alone testing equipment to evaluate the properties of post-construction concrete. We quickly learned that the main challenge in the construction industry is having efficient quality control during construction. Limited time and resources make it difficult to get laboratory test results to the contractor on a job site, so we began working on real-time analysis methods. This led us to the idea of placing fully embedded wireless sensors in the concrete itself, and mobile-based applications for data analysis. We wanted to develop the simplest and most effective method of communicating with the concrete, hence smart concrete!

Our first generation smart sensors monitor the temperature of concrete, from its fresh, beginning stage through to its hardened end stage. A mobile app analyzes the data to estimate the concrete’s real-time compressive strength and evaluate its temperature history. This critical information helps contractors determine formwork removal time, optimize concrete curing, and allow loading on the structure.

What has been the biggest revelation you’ve had in IoT development?
In the past, wireless concrete sensors were not adopted because they were not designed with the end-user in mind. The construction industry had been rather slow to adopt IT technology, largely due to its inherent reliance on sophisticated tools, advanced software packages, complicated installation, etc. Our goal was to make IoT as simple and reliable as possible to get buy-in from the conservative construction industry. That is why we used Bluetooth communication protocol and an intuitive mobile app with very simple steps to install the sensor, connect to it and see the end results in real-time. We were optimistic, and, happily, the final IoT product we developed was well-received. Within a few weeks of launching the product, we implemented the SmartRock sensor in various projects, from Ottawa’s light rail to high-rise structures in Chicago.

How are you using Silicon Labs products today?
Silicon Labs’ Bluetooth microchip is the heart of the SmartRock sensor. Special modifications to the design of the enclosure made it possible to get a Bluetooth signal out of concrete, a solid, wet material. This is a great advantage that allows for mobile-based data communication and analysis. We worked closely with Silicon Labs engineers to design the final product with optimized properties and performance.

In your opinion, what does the future of IoT look like?
Soon IoT is going to be a natural part of our daily lives. In the construction industry, we are getting closer to designing completely smart concrete. This will involve adding a smart multi-sensor in the concrete at the batching plant, like an aggregate in every concrete truck that goes to the job site. Customers won’t have to install a sensor; they’ll only have to download a mobile app. Smart concrete end-users will be able to to obtain all the data on its quality, history, strength, etc. during delivery and pouring. They will also be able to monitor the properties of the hardened concrete over the service life of the structure. This will enable the end-user to report damages, corrosion, cracks, vibrations, etc. The full cycles of IoT-based smart sensing with cloud communication will help us better evaluate the state of smart concrete infrastructure and ultimately address safety and sustainability issues in the concrete industry.

To learn more, watch the recorded webinar “Developing Bluetooth Smart Applications with Blue Gecko Modules."

For more information about the Blue Gecko BGM111 Bluetooth Smart Module, and to download a Starter Kit, click here. 

We’re going to start with the top five mbed-enabled EFM32 kits of last year. 2015 was the year when mbed turned energy friendly as ARM and Silicon Labs provided the community with ARM mbed power management APIs for embedded developers creating battery-operated, low-energy products for the IoT.

We picked the top 5 popular EFM32 platforms based on how many times imported into the mbed online compiler last year:

EFM32 USB-enabled Happy Gecko
EFM32 Giant Gecko
EFM32 Zero Gecko
EFM32 Wonder Gecko
EFM32 Leopard Gecko

Click here to learn more about  mbed, mbed OS and EFM32.