Sensors for a Song
Huge growth in the smartphone market has had the side effect of dramatically lowering the cost and shrinking the size of the sensors used those in those phones. Several chip vendors have come out with small development boards containing a variety of these tiny, low-cost sensors. In this article, Brian takes a close look at one such solution: the Thunderboard Sense 2 from Silicon Labs.
Working in the Chemistry Department of Dalhousie University, I spent much of my time developing scientific instrumentation. Virtually all such projects involved sensors of one type or another. Many chemical measurements involve temperature, and temperature sensors were generally the least expensive. Most other sensors, however, were costly—particularly those that covered wide ranges or were particularly accurate. When designing projects for teaching labs, I had to consider that students were not always careful. Sensors would get broken regularly, so picking ones that were not too expensive was essential.
In the last 10 years, two trends have markedly decreased the cost and increased the availability of sensors, including certain types of sensors that were previously found only in the military or the aviation industry. These two trends are the commercialization of MEMS (micro-electromechanical system) technology, and the rapid growth of smartphones.
MEMS technology involves placing one or more mechanical structures, in a miniaturized format, on a die like that found on a conventional semiconductor IC. This microscopic mechanical structure can be used to convert the parameter that you are trying to measure into a tiny mechanical movement. That movement typically is then converted into a change in resistance or capacitance. Sensors such as accelerometers and pressure transducers convert this mechanical movement directly into electrical signals.
Currently, many other sensors are available that use technology like MEMS technology. They measure the chemical composition of gases present in the air we breathe, using tiny chemically-active structures that convert the presence of specific elements or compounds into electrical signals. In both of those previously mentioned sensor types, it makes sense to incorporate some form of a dedicated microcontroller (MCU). That’s so you can perform any necessary signal processing on the same die as the sensor itself.
FUELED BY SMARTPHONES
As smartphones became ubiquitous and more feature laden, it became necessary to include sensors that could handle these new features. Sensors, such as an accelerometer are used to flip the orientation of your smartphone’s screen, depending upon how you hold it. Proximity sensors are embedded in the phone to let the operating system know when you have brought the phone up to your face. While I am not too knowledgeable on smartphone design, I’m pretty sure that there also are MEMS gyroscopes, magnetometers and air pressure and temperature sensors built into mid- to high-range smartphones.
The combination of MEMS technology and the economies of scale provided by huge smartphone sales numbers have led to a dramatic drop in prices for sensors used in either smartphones or consumer electronics in general. The only downside of this—at least for DIYers—is that these sensors are now so physically small that it is impossible for us to mount/solder them to either a PCB or Vectorboard.
The first solution to this handling problem came in the form of “breakout boards”—small PCBs with a particular sensor mounted on it, along with a header footprint—usually on 0.1” centers—to connect to. These were introduced early on by companies such as Adafruit and Sparkfun. These breakout boards tend to be significantly more expensive than just the sensor device itself. That said, the cost of producing a populated breakout board is reduced somewhat by the fact that the manufacturers buy the sensors in bulk, whereas you would have to pay much more when buying only a single sensor device. Figure 1 shows a variety of such sensor breakout boards.
THUNDERBOARD SENSE 2
I’m always on the lookout for new development boards that contain interesting devices and features. Often, semiconductor manufacturers will produce development or evaluation boards containing an up-and-coming MCU or other chip, and sell it for less than market value. The purpose is to entice engineers to use this new device in a mass-produced consumer product.
Recently, I came across a tiny board made by Silicon Labs called the Thunderboard Sense 2. It’s been around for a few years, but I only discovered it after I started using the Mbed IDE with Arm MCUs made by STMicroelectronics (ST). The Mbed IDE is an online (browser-based) tool that incorporates an Arm compiler, editor, download facility and other features. It is very easy to use, much like the Arduino environment. It provides a reasonably consistent syntax and driver library for Arm MCUs made by many different manufacturers. This simplifies the scaling up of a project. For example, you might start out using a low-end M0 Arm family, but want to advance to the M3, M4 or M7 Arm families. With Mbed, this scaling-up process could even occur using Arm MCUs from different manufacturers.
When you start using the Mbed IDE, it takes you to either a device list or a development board list. The supported development boards are displayed using a photo of the board plus a features list. That’s how I discovered the Silicon Labs Thunderboard Sense 2. What I like about this board are the following features:
1) It contains a whole lot of sensors, many of which are so small that I wouldn’t be able to mount/solder them in place on my own board.
2) It contains an Arm Cortex M4 MCU, which is quite powerful but can run on low power. A CR2032 coin battery socket is included on the board.
3) It contains a built-in device programmer/hardware debugger.
4) Its I/O pins are brought out on 0.1” headers.
5) It has Bluetooth capability.
6) It only costs about $20.
Figure 2 shows the board layout, from both sides, as it appears on the Mbed Boards page. The Bluetooth capability wasn’t something I was specifically looking for in this board. I have done Bluetooth projects, but my interest in this board was linked more to its large number of onboard sensors. What I had in mind was using this board basically as a tiny sensor co-processor board. I planned on interfacing it to a main MCU board via a standard UART serial link. This approach had three advantages. I could use sensors that were too small for me to mount myself. I wouldn’t have to worry about the different I/O interface methods used by each sensor (such as I2C and SPI). And the cost of this board isn’t too much more than a breakout board for just one sensor alone.
The only possible complication I could see with this approach concerned the programming of the board. Specifically, I would need a driver library for each sensor, and I would have to be able to write my own application program. Because the Thunderboard Sense 2 was Mbed-compatible—and I had been using the Mbed IDE recently for ST’s MCUs—I thought that writing program code for it would not be too difficult. Also, the Mbed Boards page for the Thunderboard Sense 2 contained a sample program that claimed to measure all the onboard sensors, which it then sent out serially. Things looked good, so I ordered a Thunderboard Sense 2 to try out.
First, let’s look at all the sensors present on the Thunderboard Sense 2.
1) CCS811 Indoor Air Quality Sensor. Made by ams, this measures both CO2 concentration and Volatile Organic Compounds (VOCs). Not that long ago, I used a similar ams sensor: the IAQ-CO. See my articles “Using iOS Devices for Data Acquisition and Control – Parts 1 and 2” (Circuit Cellar 321  and 322 , April and May 2017). At that time, this sensor, alone cost about $40.
2) BMP280 Barometric Pressure Sensor. Made by Bosch, this sensor measures barometric pressure in the 300 to 1,100 hectopascal (hPa) range (corresponding to altitudes of -500 meters to +9,000 meters with respect to sea level). Since the pressure sensor is somewhat temperature-dependent, a temperature sensor, accurate to 0.1˚C is included in the device. The device also contains an IIR filter with user-selectable coefficients to filter out short-term pressure variations.
3) Si1133 Ambient Light and UV Sensor. This sensor is made by Silicon Labs. It measures both ambient light and UV Index. The UV Index is a number related to the intensity of sunlight, weighted according to the CIE erythema action spectrum. Basically, this tells you how long you can stay out in the sun before sustaining skin damage.
4) Si7021 Humidity and Temperature Sensor. This is also made by Silicon Labs. It measures relative humidity in the range of 0-80% with accuracy of ±3%. I used a breakout board containing this sensor in a dehumidifier controller featured my article “Dehumidifier Revamped for the IoT Era” (Circuit Cellar 356, March 2020) .
5) Si7210 Hall Effect Sensor. Also made by Silicon Labs, this sensor measures magnetic field strength with a full-scale range of 20mT.
6) ICM-20648 6-Axis Inertial Sensor. This is made by TDK Invensense and features a 3-axis accelerometer, a 3-axis gyroscope plus an embedded temperature sensor. All the other sensors use an I2C interface, but this one uses SPI.
7) ICS-43434 MEMS microphone. Also made by TDK Invensense, this is a digital microphone and is interfaced using an I2S interface.
Considering that the Thunderboard Sense 2 contains an Arm Cortex M4 MCU with Bluetooth capability, a Segger J-Link programmer/debugger, an 8 Mbit SPI flash memory plus all these sensors, it is a pretty good bargain for $20.
I noticed that the board’s schematic and BOM show that an ICM-20948 is used, not an ICM-20648. This is a more versatile Inertial Motion Tracking device, with an additional compass and Digital Motion Processor. However, the driver library provided by Silicon Labs for this board (part of the Simplicity Studio development suite), as well as the library contained in the Mbed demo program, are written for the ICM-20648. Looking at the device through a magnifying glass, I was barely able to make out the label, but confirmed that it’s the ICM-20648 device mounted, as claimed in the User Guide for the Thunderboard Sense 2.
When you get a Thunderboard Sense 2, it comes with firmware pre-installed. This firmware communicates entirely via Bluetooth Low Energy (BLE) to an application on your smartphone or tablet. Silicon Labs provide apps for both iOS and Android, which demonstrate all the sensors on the Thunderboard. I have both an iPhone and iPad, so I downloaded the free iOS app provided by Silicon Labs. This app worked perfectly. You’ll see a spinning circle displayed for a second or so until it finds the Thunderboard, at which time you’ll see its device number and a bar graph showing its RF signal strength. At that point you choose between three Dashboards: Motion, Environment and I/O. Figure 3 shows screen captures of this app, in various modes (I/O mode not shown).
I’m a very cautious person by nature, and I was interested to know whether I would be able to restore this pre-loaded firmware to the Thunderboard, after I had downloaded a program of my own from the Mbed IDE. During development, it’s always useful to be able to revert to a known, working state when things seem to be going downhill! In the next section, I’ll outline what I learned about both the Mbed IDE and Silicon Labs’ Simplicity Studio IDE. You need to have some understanding of both IDEs to use the Thunderboard Sense 2.
MBED VS. SIMPLICITY STUDIO
If you do MCU development for a living and plan to spend years using MCUs by one specific company, then you are well-advised to spend the significant amount of time it takes to conquer the steep learning curve of that manufacturer’s custom development toolchain or IDE. Once you master it, you’ll be able to utilize that MCU family at the highest levels—including the ability to do complex real-time debugging.
However, the Arduino IDE has little or no support for many of ST’s STM32 Arm development boards or the Silicon Labs Thunderboard—both of which I was interested in. I started using the multi-platform Mbed IDE after spending many frustrating hours trying to use ST’s STM32Cube IDE. Both it and the Silicon Labs Simplicity Studio IDE are Eclipse-based IDEs. Even though I have mastered Cypress Semiconductors’ Creator IDE for its Arm PSoC MCUs, as well as the Visual Studio/Visual Micro IDE (for MCUs supported by Arduino), I found both the STM32Cube IDE and Simplicity Studio very difficult to use.
The Mbed IDE supports Arm MCUs in the Cortex M0, M3, M4 and M7 families, made by 14 different companies—the most common of which are ST, NXP Semiconductors, Nordic Semiconductors, Maxim Integrated and Silicon Labs. The Mbed IDE runs completely as a web-based application from your web browser. I use it with Firefox, and have also tried it on Microsoft Edge on my PC. It also runs on Mac computers. Just for fun, I’ve tried it on a Raspberry Pi Model 3B+ SBC and it works just as well on it. The reason that the Raspberry Pi works as well is that all the editing/compilation/linking/ storage functions are performed on the cloud, by Mbed server(s).
You don’t have to worry about backing up your code as you develop your program, because it is stored automatically on the Mbed server. You don’t even have to worry about maintaining earlier versions of your code—in case you make some subtle mistake and your latest version stops working. Mbed has a Commit function, which can save as many earlier versions of your project as you want. Since the Mbed IDE works on the cloud, you need to sign up for a free account to use it. Signing up for an account is easy, and once you have, whenever you access the Mbed site, browser cookies will bring up your workspace automatically.
Once you choose the development board you are using, Mbed will automatically set up its build procedure for the specific MCU found on that board. It will also load a configuration file that defines what GPIO lines are used on that board for things like buttons and LEDs. And, if you search for example programs within Mbed, once you load that example, the proper build configuration for that MCU will be selected automatically. As a nice added touch, a small icon displaying the active development board is shown at the upper right corner of the screen.
It’s great to see a simple button called Compile that you just click on when you want to build your code. In contrast, both the STM32CubeIDE and Simplicity Studio have an involved process of picking the device, choosing certain build parameters, deciding if you want to compile it to be flashed to the device or in a debug mode. In the case of Simplicity Studio, you must also choose among many different operating system frameworks that will form the underlying framework of your code. As a newcomer like myself, you would have no idea which of these is the right one to choose.
As you work with Mbed, you will start to accumulate different programs you’ve written, plus examples that you have tried out. These will all be stored on the Mbed server and will show up in a window called Program Workspace. Each project shows up as a single entry, and there is a hierarchical structure that you can expand to see all the files and library folders included in that project.
Figure 4 shows part of my workspace, with the first entry partially expanded to show the included folders and other items. To work on any particular project, just click on the main.cpp icon, and it will bring up this code section into the large editor window in the center of the screen. If you then click on the Compile button, it will build that code and prompt you to select where you want to locally store the binary file on your PC. I could rant on about how hard it is to do something simple like this in either STM32CubeIDE or Simplicity Studio, but suffice it to say it is much more difficult than this in either of those IDEs.
The Mbed IDE depends heavily on right-clicking on different elements to expose relevant actions you can take, rather than having a large toolbar or menu structure. So, for example, if you right-click on the My Programs icon at the top the file structure shown in Figure 4, you will be given the choice of New Program, Import Program, Find in My Programs (exhaustive word search throughout everything) and Refresh.
If you pick New Program, it will first guide you through a board selection, so that it can configure everything for your chosen board. Choosing Import Program will allow you to pick a program using an import wizard, or allow you to enter a URL, if you have a specific GitHub repository in mind. The import wizard allows you to type in a search phrase, and it will search the Mbed database for programs that fit that description.
There are many such programs—some by the MCU manufacturer itself, but many submitted by Mbed users. The Mbed program provides a specific function to allow users to readily submit their programs to this database. As a caveat, you should realize that, given the diverse source of these programs, you will run across some that do not meet your expectations or may fail to work completely. Mbed also provides a utility that allows you to save all the source code for your project into a ZIP archive, for local safekeeping or distribution to others.
Unlike “C” programs that are developed using STM32CubeIDE or Simplicity Studio, Mbed handles its “core” libraries much differently. Programs written using the former IDEs will require you to use the #include directive to include many different libraries that are needed to do even the most basic functions. Mbed, in contrast, just adds a “gear” icon (“mbed”) to your project. This is a large, pre-compiled binary file containing the standard Mbed language elements that are shared among nearly all of the supported MCUs. For example, if you want to send something out the UART port on your MCU, you just use the Serial class. You don’t have to go looking for whatever libraries are needed to use the UART port, and then #include it in your program.
Doing GPIO operations is a simple matter with 8-bit MCUs under Arduino. It is a complex operation on Arm MCUs, and it is only handled by the STM32CubeIDE/Simplicity Studio using a separate Configuration Tool. These tools produce files containing many code sections that you must insert into your program code—and in the right places! In contrast, Mbed uses the “DigitalOut,” ”DigitalIn” language used by Arduino, which is much easier to understand. Simply put, they abstract away the low-level register details, which vary from one MCU to another, and replace them with a higher-level set of universal GPIO statements.
External driver libraries are an important part of any non-trivial program. Adding them to your program in the Mbed IDE is simple. You just right-click on the project’s icon in the Program Workspace window and select Add Library. You then enter a search criterion, and you’ll see a list of available libraries in the Mbed database. Here again these come from diverse sources, so treat them accordingly. You should try to include the MCU family designation in your search criteria, which will narrow down the list to those libraries that were written for the MCU you are using. Although Mbed tries to make all its supported boards work the same, there are so many different peripheral chips/displays and so on mounted on all these boards that you need to find device driver libraries that match your board if you expect things to work.
PROGRAMMING IN MBED
Since the Mbed IDE runs totally as a web-based app, you might wonder how you go about programming the flash memory on your MCU. I have used other online IDEs in the past that required you to load a special USB driver file, after which the web-based app was able to program the MCU via its USB cable to the PC. That works, but it can be tricky if you are not using the same browser that is specified by the developer of the IDE. Mbed’s programming method is simple. When you compile an Mbed program, you will see a prompt asking you where you want the resulting binary file to be saved locally. In Firefox, this is the Downloads folder.
On Mbed-compatible MCUs, the MCU itself contains an MSD USB profile driver. MSD stands for mass storage device. So, as soon as you plug your development board into a PC, it will show up as a USB flash drive. Along with this MSD capability and part of its boot code is a flash programmer routine. Whenever you transfer your program’s binary executable file to this USB flash drive, it will write the contents of this code to the MCUs flash memory. Therefore, to program the device, all you do is drag/drop the binary file from the Downloads folder to the USB flash drive that corresponds to your MCU development board. In the case of the Thunderboard Sense 2, this shows up as TB004 (the board’s model number is SLTB004A).
If you examine the file contents of your new Thunderboard’s USB flash drive, it will contain a Readme file explaining what format files it accepts and other information. There are also a few HTML files which, when clicked on, will take you to the Mbed site at the Thunderboard Sense 2 Feature page. I had plenty of recent experience with this Mbed programming procedure after doing some projects using STM32F469 and ‘F746 development boards. After flashing many program variations, some of which did not work properly, I never “bricked” an MCU (that is, wiped out its internal bootloader).
I was therefore quite surprised when I was unable to program my new Thunderboard Sense 2 board using this method. The board itself was working fine. It was running its pre-installed demo program and connecting to Silicon Labs’ iOS demo app on my iPhone. When I tried to drag a binary file to the TB004 flash drive, it did not display the normal window showing the progress of the file transfer (which only takes a few seconds but was certainly visible with my STM32 dev boards). Instead, the TB004 drive icon disappeared for a second and then reappeared. Examining the files on the TB0004 drive showed a new FAIL file that wasn’t there before. The content of this file was simply a message stating that it could not connect to the MCU properly.
Before receiving the Thunderboard, I had downloaded the Simplicity Studio application from the Silicon Labs website. This is a huge program (2-3GB, as I recall) and when you start it for the first time, it will spend even more time going through a lengthy update process. I now figured I would have to learn enough about Simplicity Studio to use it to flash the board—since the normal Mbed drag-and-drop programming routine wasn’t working.
FLASHING THE THUNDERBOARD
There are no special USB drivers that you must load with Simplicity Studio to connect to the Thunderboard Sense 2 board. While the Thunderboard’s firmware also includes a Serial port profile, a different profile (likely HID) is used for programming and debugging the board. At start-up, Simplicity Studio will look for any Silicon Labs boards that are plugged into a USB port on your computer. Note that Silicon Labs makes the CP2102 USB-to-UART bridge device that is present in many USB-UART bridge cables and also on ESP32 DevKitC boards. So, if you happen to have any of these plugged into your PC, they will show up in Simplicity Studio, and you might get confused about which device to choose. In Figure 5 you can see my Simplicity Studio screen showing two CP210x USB to Serial bridges I had plugged in, as well as the Thunderboard Sense 2, which shows up as a J-Link device.
The launch screen for Simplicity Studio has several tabs for Getting Started, Documentation, Compatible Tools and so on. These are all essentially empty—even after you have plugged in your Thunderboard and it has shown up in the Debug Adapters window as shown in Figure 5. Nothing will appear in these tabs until you have expanded the J-Link Silicon Labs entry, as shown, and clicked on the Thunderboard Sense 2 (BRD4166A).
The downside of this feature is that I couldn’t examine how Simplicity Studio worked until I had my Thunderboard in hand. I generally like to look over a development board’s documents in advance. In this case, they don’t show up until you have the board plugged in. These resources are present among the thousands of files that get downloaded when you install Simplicity Studio, but are well-hidden within the complex folder hierarchy used.
All I really needed from Simplicity Studio at this point was the ability to flash the board with the binary file produced by Mbed. In Simplicity Studio, you must select the Compatible Tools tab, and select the Flash Programmer utility, as shown in Figure 6. This is easy to use, except for one thing. When you select “bin” as the file type (that’s what Mbed produces) and then click on the Browse button to navigate to your file, you won’t find it! The browse function uses the “.hex” extension as its file filter, regardless of what you pick on the Flash Programmer screen. So, you must also change this filter.
Once I flashed it as I described, I had no problem getting my Mbed program to work on the Thunderboard Sense 2. Also, once this Mbed-produced firmware has been loaded, it is then possible to flash any further changes (or other Mbed programs) using the normal Mbed drag/drop method described at the end of the last section.
On Mbed’s Thunderboard Sense 2 Feature page, they include a few Mbed demo programs. Besides the usual “Blinky” program, which is trivial, they included a sensor demo program. I figured that this demo would do all the “heavy-lifting,” containing the driver libraries needed for all of the sensors. I just planned on tailoring it somewhat—where it used the USB-Serial port, I really needed to have it send data out over a conventional UART port to be compatible with an MCU used as Master. Also, I’d implement a small command structure to control the sensor readings taken.
Unfortunately, the demo program did not work at all after I had flashed it to the Thunderboard’s MCU. Instead of sending the sensor data out the USB-Serial port, all that happened was a tiny, green LED flashed in a bit of a pattern. It almost looked like the pattern you see when you connect up an LED to a UART transmit line and there is data flowing. However, from the schematic, I could see that this green LED was just hooked up to a GPIO line as a user-driven LED.
Luckily, I had already seen such behavior when programming my two STM32 development boards. It is not readily found in Mbed’s documents, but there is an error protocol that Mbed uses. I don’t know if it exists across all Mbed-compatible MCUs, but it is present on the STM dev boards I use, and also on the Thunderboard Sense 2. The way that this error protocol works is quite different from anything I have seen before and merits some explanation.
On all Arm MCUs, the internal peripherals must be connected to the device’s GPIO pins through some form of multiplexer or MUX. There is some versatility as to which GPIO pins can be used, but you can’t pick any pin of your choice. Also, some of the peripherals can be configured to perform different functions. The Silicon Labs Gecko MCU on the Thunderboard does not have any SPI ports. Instead it has four USART blocks—some of which can be configured as SPI ports, rather than their default UART function.
From past experience, I’ve generally found that if one tries to assign a peripheral to a GPIO pin that the MUX cannot connect it to, the compiler itself will issue an error message to this effect. Similarly, if you try to configure a peripheral to do something that it can’t do, the compiler will have problems accessing the correct registers to implement this configuration, and a compiler error will also be issued.
In the Mbed system, things don’t work that way. Such pin/port configuration errors are not issued by the compiler. Instead, at runtime, when the MCU tries to do an invalid operation such as this, it will issue the error message, itself. This comes in two forms. First, it will send out an error message via the MCU’s “main” Serial port (in this case, the USB-Serial port). The second indication will be that it flashes an LED on the board in a specific pattern. Because the demo program I had loaded to the Thunderboard was supposed to send out readings from all its sensors via the USB-Serial port, I had a Serial Terminal app opened on my PC. Figure 7 shows the error message—an SPI port problem.
To make a long story a bit shorter, when I looked at the demo code, I noticed that all the sensors use the I2C protocol, except the ICM-20648, which uses SPI. The person who programmed this demo uses the Mbed SPI class for the ICM-20648 driver library. I’ve used this SPI class on STM32 MCUs with no issues. However, there is a problem with the SPI class library for the EFR32MG12 Mighty Gecko MCU on the Thunderboard. Since the code for this class function is hidden in the Mbed “core,” I didn’t have access to it, or its source code.
Since Silicon Labs displays its copyright at the head of this demo program, I contacted them rather than Mbed. Its representative wasn’t at all familiar with Mbed, but he pointed me to the ICM-20648 driver code that Silicon Labs uses for its demos, written for Simplicity Studio.
While I have yet to figure out how to write a Thunderboard program using Simplicity Studio, I was able to port the SPI driver code over to the original Mbed demo program and patch that in to the original ICM-20648 driver routines. After doing that, the program works fine. The code that I provide with this article has my working ICM-20648 driver routines included. The code is available for download on Circuit Cellar’s article code and files download webpage. I’ve sent the working code to Silicon Labs, and am hoping that they correct the Thunderboard Sensor Demo program on the Mbed Thunderboard Page.
As mentioned in the last section, I re-wrote all the ICM-20648 routines to get them working. Whereas the original ICM-20648 driver code was in the form of a C++ class library, when I made the modifications to it, I converted it into a set of standard function calls—all of which are at the end of my main.c file. There are many register definitions involved with the IMC-20648 Inertial Measurement Unit (IMU)—all of these have been placed in the IMC20648.h file.
My program code first tries to discover, then initializes, all the on-board sensors (except the microphone, which I ignore). The IMC-20648 must be calibrated before any of its readings can be used. They are completely unusable without this. The calibration routine expects that the Thunderboard is sitting flat on a surface and is not in motion. Although I perform a calibration during the program initialization (Line 143), this may not be a time when it is positioned as mentioned earlier. Therefore, I provide a calibration command (P) to perform it at whatever time the user wishes. During initialization, messages are sent back to the host to indicate success or failure of this process, on a sensor-by-sensor basis. I’ve set the serial baud rate at 115,200 (but it could be changed at Line 43 to some other value).
After initialization, the program enters a command loop. To obtain measurements from all sensors, the following two commands must be sent:
1) T xxxxx. This sets the interval between measurements in milliseconds. While it will accept any value, it takes some time for all the sensors to read their respective values and send them to the host serially.
2) G This starts the readings.
An S command will stop the transmission of the readings. All commands must be followed by a “Carriage Return.”
The Thunderboard contains four rather bright RGB LEDs, two of which are on the top of the board. I have included commands to turn on/off the RGB LEDs on LED0 (on the top of the board near the USB socket).
The Thunderboard contains a 20-pin expansion header that includes several standard GPIO lines, and a UART port and an I2C port. The UART port that I use to connect to the host MCU is on lines PF3 (Tx) and PF4 (Rx). I haven’t written a driver the I2C port. It uses a different I2C port than the ones used by the on-board sensors. However, I have written routines that control four of the GPIO lines high or low individually. These are pins EXT3, EXT5, EXT7 and EXT9. The commands are shown in Table 1. Only the T command has a parameter, which must be preceded by a space character.
Many development boards are available today for reasonable prices. Whether you want to spend a lot of time learning the development tool suite provided by the manufacturer is probably a bigger consideration than board cost. I was pleased to discover the Mbed online IDE, which makes it a lot easier to develop with Arm devices from many different vendors.
After I became comfortable writing Mbed code for both the Silicon Labs Mighty Gecko and ST’s STM32 MCUs, I went back and spent more time studying both the STM32CubeIDE and Simplicity Studio. I needed to use some of the utility programs in these packages, such as the Flash Programmer utility in Simplicity Studio. However, for ease of writing code, I still found Mbed to be a much easier package to use.
I haven’t explored the Bluetooth capability of the Thunderboard Sense 2. When I loaded the Thunderboard Sense 2 demo project (which is the code that is preloaded on the board when you get it), it first presents you with a GATT configurator tool. I couldn’t find references to the sensor driver routines in the main.c file. Hundreds of dependency files are needed for this demo, so it’s hard to know where to look for them.
For my modest Bluetooth link needs, I’ll stick to the ESP32 for now. It’s easy to modify one of the ESP32-Bluetooth Arduino examples to suit my needs.
 and  “Using iOS Devices for Data Acquisition and Control – Parts 1 and 2” (Circuit Cellar 321 and Circuit Cellar 322, April and May 2017).
 ” Dehumidifier Revamped for the IoT Era” (Circuit Cellar 356, March 2020).
Thunderboard Sense 2: Silicon Labs
Mbed Online IDE:
https://Ide.mbed.com [This takes you to a login screen]
ams | www.ams.com
Bosch Sensortec | www.bosch-sensortec.com
Espressif Systems | www.espressif.com
SEGGER Microcontroller | www.segger.com
Silicon Labs | www.silabs.com
STMicroelectronics | www.st.com
TDK Invensense | www.invensense.tdk.com
PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JANUARY 2021 #366 – Get a PDF of the issue