Silicon Labs
EFM8 Laser Bee

The EFM8 is Silicon Labs’ current line of 8051 microcontrollers. If you hear “8051” and think of a 1980s slow 12T microcontroller that comes in big DIP-40 packages, remove that image from your head. All 8051s I reviewed are 1T architectures that use pipelined instruction execution, and the EFM8 is no exception. Since there were three vastly-different 8051 parts I reviewed, I did a bit of an 8051 core shoot out in the main article.

Some of these EFM8 parts seem like re-badges of their later-generation C8051 parts, while some are obviously new designs.

These parts complement their EFM32 Arm products by offering some excellent power consumption figures — but unlike some power-friendly parts like the MSP430, EFM8 parts also have incredible value.

There are four families of EFM8 devices:

  • EFM8 Busy Bee (EFM8BBxx): mainstream features with the lowest price tag
  • EFM8 Sleep Bee (EFM8SBxx): designed for low-power, battery-operated products
  • EFM8 Laser Bee (EFM8LBxx): high-performance 72 MHz speed with an emphasis on analog capabilities
  • EFM8 Universal Bee (EFM8UBxx): basically a 48 MHz EFM8BB with USB connectivity

In fact, each EFM8 series has availability in this price range, which made selection difficult. I ended up with the Laser Bee — specifically, the EFM8LB11F16.

Here’s a rundown of the part:

  • 72 MHz 1T 8051 core
  • 16 KB of flash, 1.28 KB of RAM
  • 14-bit 900 ksps ADC, with two 12-bit DACs and two analog comparators
  • Two 8-bit auto-reload timers, plus four 16-bit auto-reload timers, 10 capture channels, and six 16-bit PWM channels
  • Two USARTs (one classic 8051, one modern), plus separate SPI and I2C peripherals
  • Four-channel configurable logic
  • 24- and 32-pin QFP and QFN package options — along with a 24-pin QSOP

The high core speed is the first thing that stands out. The EFM8 has 25 MHz flash memory, so running this part at full speed requires two wait-state configuration. Unfortunately, there’s no flash caching accelerator in the EFM8, so cycle efficiency drops substantially as you increase the clock speed.

Silicon Labs has a large customer base that needs compatibility with existing 8051 firmware, so — like the STC8 and N76 — these parts include traditional Timer0/Timer1/Timer2 modules, plus the bog-standard 8051 UART peripheral. That means T0 and T1 are basic 16-bit-counter/8-bit-auto-reload timers, and UART0 has no internal baud-rate generator.

Rathern than getting crafty like STC does, Silicon Labs has simply added seconary peripherals that are more modern — UART1 has an internal baud-rate generator and support for modern features like LIN break and sync detection, plus separate 8-deep TX and RX FIFO buffers.

The 14-bit 900 ksps SAR ADC is a total beast — it can select from 20 external pins on the package, along with VDD, the internal LDO, or the internal temperature sensor. There’s selectable 1.2, 1.65, and 2.4 volt precision references available.

It can be kicked off in software, or asynchronously from external pin interrupts, a timer overflow, a rising PWM signal (though no center-aligned synchronization), or from the configurable logic outputs.

The ADC has an accumulate-and-shift function (for averaging), supports automatic channel sequencing, has a window comparator, and has a psuedo-DMA feature that can store data direct to memory without processor intervention.

The DAC supports two channels of 12-bit voltage output that’s fully static — allowing operating when the core is asleep (or even under a reset condition if configured). Multiple DAC outputs can be synchronized together and can generate complementary waveforms. They can be switched between two output levels based on configurable logic or PWM input triggers.

All EFM8 parts are flashed and have on-chip debugging through the Silicon Labs C2 debug interface. All devices come pre-programmed with a UART bootloader (or USB bootloader in the case of the EFM8UBxx series), though this bootloader is simply stored in flash, and can be easily overwritten (inadvertently or not). There’s also an SMBus bootloader available — great when you’re integrating an EFM8 into, say, an embedded Linux design, or another high-end application-oriented system.

Development Ecosystem

Simplicity Studio includes a Launcher perspective that collects documentation, demos, and software examples — immediately filtered for the board you plug in.

Development Environment

When you’re working with the 8051, the best compiler in town is Keil’s C51. Most vendors toss up their hands and throw a debugging DLL at you to be used with µVision — which has poor text-editing capabilities when working with 8051s.

Not so with Silicon Labs. They built Simplicity Studio — the only Eclipse-based IDE provided by a manufacturer for use with an 8-bit architecture. Simplicity Studio still uses Keil C51 under the hood, but you get the excellent productivity enhancements and beautiful UI. They’ve had to highly customize it for use with Keil, but I can’t complain about any of their changes.

There’s a nice target selection pane in the project properties view, and you can tick checkboxes next to peripheral libraries you want automatically copied into your project. Why didn’t everyone else think of that?

All the documentation and sample code is built into the IDE, and it’s accessible in the “Launcher” perspective. Sample projects are cloned into your workspace, allowing you to modify them to your heart’s content. Simplicity Studio will even connect and identify your dev kits automagically, and optionally show you only the filtered documentation that’s actually relevant to the part you’re working with. Wonderful!

I have a small gripe about Simplicity Studio — it does not include Keil reserved words in its reserved word list. Users new to the 8051 will find annoying the extensive list of keywords Keil claims — including words like “data” — and Simplicity Studio does not provide visual indication when you use one of these non-standard Keil-specific reserved words. Since Keil will throw fairly cryptic errors when you do something like name a variable “data” this is a definite trap for young players.

Silicon Labs’ Simplicity Studio includes the built-in Simplicity Configurator for generating lightweight initialization code and ISR stubs.

Code Generator

Simplicity Configurator is the code-gen tool built into Simplicity Studio. Rather than being everything to everyone, Configurator only burdens itself with peripheral initialization — which it performs with efficient (but also well-documented) register-writes.

The code generator supports multiple “modes” — application states — that allows you to use the code-gen tool to build more complex projects that might enter and exit low-power states, or have different muxing throughout the course of execution. Each mode has its own set of configuration options, and enter_ModeName() functions are automatically generated that you can call as you need.

There’s a whole separate system — the peripheral libraries — that you can use to initialize peripherals, but also to work with them. An important concept for new users to learn is these are completely separate systems that have no dependency on each other. Just because you tick the “UART 0” box and configure the UART, you won’t automatically get the UART_0 peripheral driver. You can, of course, add the UART_0 peripheral driver to your project, but you can also work with the peripheral directly (or using your own peripheral library).

I like the flexibility this provides, though it also adds a bit of complexity — for example, it’s not always clear if you need to call the peripheral driver’s Init() function since the peripheral is already initialized by Simplicity Configurator. Perhaps SiLabs could update the documentation for the Peripheral Libraries to include comments for people calling these functions from within a Simplicity Configurator project.

SDK

The SDK is right where it needs to be — header files are well-documented, and SiLabs provides named bitwise masks for all registers — with built-in code documentation. The peripheral libraries are automatically copied into your project, and are nicely readable and filled with comments. This allows you to modify and manipulate them to suit your application — but for people getting started, they’ll cover all the basics.

Development Tools

Silicon Labs supports the EFM8 line of processors with a range of starter kits (STKs). Regardless of the EFM8 target, these all cost $30 — a bit pricier than other dev kits in this review, but also one of the most capable dev boards manufactured.

First of all, each of these dev boards comes with a J-Link On Board debugger. This is the Caddilac debugger used mostly by Arm parts, but smartly supported by the EFM8, too (through its C2 debug protocol).

What really stands out is that, ironically, the only dev board in this roundup with a USB 2.0 High-Speed interface isn’t one of the Arm Cortex-M0 parts — it’s this EFM8.

I hope Silicon Labs doesn’t mind, but I found their STK so effective at measuring current consumption that I ripped the EFM8 off one of them, and now use it solely as a time-series ammeter.

Piling on the features, Silicon Labs builds a custom energy monitor firmware into this J-Link — and this has turned into my de facto tool for measuring the power consumption of all my projects, not just my EFM8 parts. It’s basically a µCurrent GOLD built into a dev board — and has a huge dynamic range allowing logarithmic plotting of current consumption, from 100 mA down to the dozens-of-nanoamp range.

Because the energy monitor runs in a separate perspective, I actually have a whole second Simplicity Studio workspace set-up just for running this energy monitor — as soon as I launch it, it’s ready to go.

There’s one pitfall with these boards: they can debug external targets, but it’s somewhat clunky — rather than just put some physical jumpers on the board, Silicon Labs uses software-controlled muxes that can route debug signals to a 20-pin micro-header connector that I can’t imagine anyone finding particularly useful. There’s a three-pin unlabeled 0.1″ header on the corner of the board that routes the C2 signals externally from the target, so if you pop off the MCU, you’ve got a $30 USB 2.0 high-speed debugger with built-in power consumption measurements.

For those looking for stand-alone programmers, you can, of course, go with a J-Link (including the J-Link EDU and J-Link EDU Mini — built for hobbyists and students). But Silicon Labs also has the $35 USB Debug Adapter, which is a lot cheaper than a commercial J-Link you’ll need for professional work.

If you want to go even cheaper, there are USB Debug Adapter clones on eBay that work well (and have nicely labeled pins and more convenient pin-out organization) — and if you really want to hack something together yourself, you can build your own debugger, too. They sell the CF326-SX0261GM, which is a C8051F326 pre-programmed with the C2 debugger firmware — and it’s only $1.78 in single quantities.

Simplicity Studio has a beautiful and functional register view that allows you to interact with registers using names and drop-down lists — this saves a lot of time when tracking down problems — no datasheet required.

Debugging Experience

SiLabs provides a beautiful and stunningly productive debugging experience for an 8-bit microcontroller. You get full support for all the default Eclipse views — variables, expressions, memory, disassembly, breakpoints, and code views all work exactly as you would imagine.

The registers viewer, however, was probably the best one in the review. Registers are grouped by peripheral, and broken down into individual bit-wise or multi-bit-wise values. There are drop-down list with human-readable names of all the options. As you step through code, changed registers highlight red, so you can see precisely what changed in each debug frame.

I had no issues with skipped breakpoints — even with Keil C51 set to full-optimization mode — though sometimes breakpoints would hit on the line after I set them.

Flash loading with the J-Link-based debugger was really fast — about 3.2 seconds to load a basic program, and 4.2 seconds to completely fill the 16 KB of flash. Even the USB Debug Adapter clone managed good speeds — 3.6 seconds loading a basic program, and 5.5 seconds loading up the flash completely. Note that these times include loading flash and running to the main() breakpoint.

No other major 8-bit part beat it — and only the Infineon XMC1000 edged out under these times.

Performance

Bit Toggling

What should be a four-cycle job took eight on the EFM8LB1 — due to the 72 MHz core speed combined with 25 MHz flash access. That’s the Achilleas heal of the EFM8 Laser Bee’s performance.

Biquad Filtering

Keil has poor optimization strategies when it comes to math library calls — even if you instruct it to optimize for speed, it will never in-line these calls. Consequently, the EFM8 pays a heavy penalty on the biquad filtering when compared to other 8-bit parts — taking 272 cycles to execute a single iteration of the filter. Compare this to the 63 cycles the similarly-priced tinyAVR puts up. Again, the cacheless flash is of no help here.

However, the EFM8 powers through with brute force — its 72 MHz core simply overwhelms other parts, pulling in an impressive 265 ksps performance. The penalty it pays is in power consumption — a massive 14.15 mA — which places this at 176.2 nJ/s. Both the tinyAVR and megaAVR beat the EFM8 at the efficiency game (as did many of the Arm parts, too).

DMX-512 Receiver

But before you call the Laser Bee a bumbling brute with no regard to power consumption, take a look at the DMX-512 figures: by making use of the built-in FIFO in the UART and reducing the core to 1.531 MHz, the EFM8 was able to slide in far under most other 8-bit parts, using only 607 µA of current. This was not the lowest in our round-up, but the parts that were lower were either very slow 4T processors, or more expensive 16- and 32-bit parts that didn’t nearly match this in functionality.

Bottom Line

With their productive Eclipse-based IDE, J-Link debugging, and modern peripheral set, Silicon Labs wants you to forget you’re working on a 37-year-old microcontroller core, and they’ve largely succeeded. The EFM8LB1 is both the fastest 8-bit microcontroller I tested — and one of the lowest-power.

But here’s the killer fact: the EFM8 is the only 8-bit system on the market that has unrestricted, cross-platform, vendor-provided tools.

This is absolutely huge for hobbyists and students — and SiLabs sweetens the deal with low-cost dev kits and readily available $10 sanctioned clone debuggers, so you can get into the ecosystem without breaking the bank. Plus, from browsing around for the last few months working on this project, I think the Silicon Labs community is as useful and inviting as the Atmel and Microchip ones — which I can’t say about many other parts.

Professionals will be hard-pressed to find a line of 8-bit parts with the amazing analog features and power consumption that this part provides. Plus, if you’re building USB-connected gadgets, or ultra-low-power devices, the EFM8 has special-purpose chips just for you. I think these are obvious choices if you’ve got existing PIC16 or AVR projects in this pin range — though there’s a pretty low parametric ceiling that you’ll hit if you need bigger parts. SiLabs is not Microchip — it’s not important to them that they produce 15 million different products with 30-year commitments on all them. They specialize in this corner of the market, and they don’t try to do stuff they’re not good at. I’m totally fine with that.

The part isn’t perfect. I would love a future EFM8 to have a truer 1T design — in the style of the STC8 — which would allow better performance without resorting to such high clock speeds. A 72 MHz part really needs a flash cache/accelerator — otherwise, you simply don’t get expectedly good performance out of the core. I think the comms peripherals could use a bit of rework — like dedicated baud-rate generators for the SMBus and UART0 peripherals. And the STK boards need a better debug-out connection (just put the C2CK and C2D pins on 0.1″ headers and get on with your lives).

But overall, this might just be the most compelling 8-bit part you can buy today.

Comments (13)

The 20-pin debug header is a Cortex debug+ETM header. The manual implies that the on-board J-Link is crippled to only talk to EFM8 parts, but if that isn’t true you might be able to use it as a regular J-Link; or, it might be to make it easier for other JTAG probes to talk to it since it uses a common pinout.

A really n00b question. But does this part need an external crystal?

No, all the parts in my review have an internal oscillator. Some are better than others, though.

I wish I had known about this $9 accessory https://www.silabs.com/products/development-tools/mcu/32-bit/simplicity-debug-adapter-board that plugs into the weird 20 + 20 pin micro header connectors, converting them to more common 10-pin interfaces. Spent almost as much to make my own 20-to-10 cable!

Jay: I’ve been binge-reading your site since discovering it — thanks very much. One burning question:

> I found their STK so effective at measuring current consumption that I ripped the
> EFM8 off one of them, and now use it solely as a time-series ammeter.

I bought an EF8 Laser Bee for this exact purpose. Do you have more info on how to mod the board, and what settings are required for Simplicity Studio?

Hey Robert,
Just rip off the target MCU and you’re done. Anything you attach to the 3.3V rail will be monitored by the energy monitor tool.

Some of the newer Texas Instruments LaunchPad boards also have an EnergyTrace that works well, too, and you can use it for external targets without removing the target MCU. Just disconnect the jumpers on the board!

Jay:

> [The SLSTK20x0] has turned into my de facto tool for measuring the power consumption of all my projects…

Having stared at the schematics, is it correct to say that it’s turned into the tool for measuring power consumption for all your 3.3V projects? Or have you bypassed the 3.3V LDO as well?

I’ve left all the power circuitry intact. Most of what I work on is (roughly) 3.3V, so it’s usually suitable as-is.

Dear Jay,

thank your for the 1$ uC comparison, which I read with great interest. I learned, that I am somewhat spoilt by the Arduino toolchain ecosystem, that I can use on my Mac and which even includes recently STM and ESP32 support.

For a new project that I want to build (art installation) I need 256 uCs driving stepper motors. Based on your article I narrowed the selection down to SAM D10, the SL EFM8 or the ST STM8. The STC STC8 was interesting, too, but lost due to the only Windows based toolkit.

Performance and functionality wise, all of them seem to be more than ok.

I am worried about the development environment. I could not really figure out, if the development envs are running on Mac OSX. E.g. you stated positive remarks on the SL Simplicity Studio, but as compiler you mentioned the Keil C51 and that runs only on Windows, right?

Is there any recommendation you can give for such a project for a guy coming from the Arduino world of things? I don’t necessarily need fancy debugging: I use vim to code, Makefiles for gcc and printf()s for debugging and that did it for me for the last 8 years.

Thanks a lot for your insights!

Michael.

The SiLabs EFM8 stuff is fully compatible with macOS and Linux, too. They’ve cleverly packaged up Keil C51 with Wine to allow it to run. This is all done under the hood and you’ll never really have to think about it. I’ve done quite a bit of EFM8 development on my MacBook Air, so I have to qualms recommending it to macOS users.

As for actual parts, you should look at the EFM8BB1. Look at the prices from Symmetry Electronics; I think they can hit sub-$0.30, which is pretty impressive for U.S.-based parts.

Thank you very much, Jay, for taking the time to respond! I’ll have a look at this product line and your recommendation then!

Thanks again, Michael.

Hey Jay,

For flash caching the LB1 and any of the EFM8 parts running above 25MHz have a flash prefetch engine to grab future instructions. Unfortunately you have to manually enable this via the FLRT bit. It also only works on linear code so if you have a lot of jumps, interrupts, etc it is less useful but even then it greatly increases computational power. Did you have this enabled when you were doing some of the benchmarks?

10.3.2 Prefetch Engine The CIP-51 core incorporates a multi-byte prefetch engine to enable faster core clock speeds. Because the access time of the flash memory is 40 ns, and the minimum instruction time is 13.6 ns, the prefetch engine is necessary for full-speed code execution. Multiple instruction bytes are read from flash memory by the prefetch engine and given to the CIP-51 processor core to execute. When running linear code (code without any jumps or branches), the prefetch engine allows instructions to be executed at full speed. When a code branch occurs, the processor may be stalled for up to five clock cycles (FLRT = 2) or three clock cycles (FLRT = 1) while the next set of code bytes is retrieved from flash memory. When operating at speeds greater than 25 MHz, the prefetch engine must be used. To enable the prefetch engine, the FLRT bit field should be configured to the desired speed setting. For example, if running between 25 and 50 MHz, FLRT should be set to 1, and when operating between 50 and 73.5 MHz, FLRT should be set to 2. When changing clocks, the FLRT field should be set to the higher number during the clock change, to ensure that flash is never read too quickly.

Leave a comment