The STC15W is the newest generation of low-cost 8051-derivative MCUs made by STC in Beijing. This is a modern, 1 clock/machine cycle 8051 that’s the closest competitor to the Silicon Labs C8051/EFM8 parts, in terms of core design and peripherals.

For this experiment, we selected the IAP15W4K61S4, which is the top-of-the-line device they make (still well under $1, even in single quantities, if you shop around – though on eBay or Ali Express, expect to pay $1.30 or so).

The ’4K61 features:

  • 35 MHz single-clock-per-machine 8051
  • 4K of RAM, 61 K of flash memory
  • Five modern timers; each of them supports 16-bit with auto-reload, gating, and divider operations.
  • Two standard 10-bit CCP PWM channels, plus a novel 6-channel, 15-bit PWM module with programmable dead band that would be perfect for three-phase AC induction or BLDC motor control – that’s 8 channels of PWM total.
  • Four independent UARTs; one of them with a weirdo shift-register synchronous I/O mode
  • SPI peripheral
  • 8 channels of 10-bit ADC

This chip shares the same base 8051 peripherals that all 8051-style MCUs share (including the EFM8BB1, also reviewed). This means you get handy quasi-bidirectional GPIO, 8051-style UARTs with no internal baud rate generator (lame), and timers. Lots of timers. STC was a little more aggressive with their 8051 modernizing; they completely eliminated the 13-bit timer mode that was used (I’m told?) by the 8051.

STC has no problem hacking the architecture a bit to introduce new features while preserving code compatibility, though. For example: the timer reload registers are actually exposed as the *same* address as the timer’s value registers; they’re just only accessible when the timer is not running. So the timer’s state essentially sets which “page” to use when accessing, say, T0H, and T0L. Kind of a gross hack, but it’s totally serviceable, and with five timers, it reduces the number of SFRs by 10.

Flashing & Debugging

The STC15W line – like all their other parts – uses a ROM-based UART bootloader you’ll use for all of your computer-to-STC15 interactions. I’m not sure it’s even ROM-based, since even if your device doesn’t actually have a UART peripheral, (like the STC15W100-series), you still use the “UART” to program it. It seems like some of the STC15W MCUs can actually use the TX and RX pins as D+ and D- pins, and run a built-in USB bootloader – but I didn’t have a 24 MHz crystal handy to try this.

The bootloader will send out a character on cold-boot

If you’re on Windows, you’ll be using the STC ISP utility (available in Chinese and English-ish). If you’re stuck on *nix (or are otherwise an open-source nut), stcgal is a Python-based open-source STC programmer that I haven’t tested, but you should.

There’s no proprietary debugger with the STC system

The debugging experience on the STC15 is extremely old-school, and like nothing else we’ve looked at in this article. Rather than have dedicated, on-chip debugging hardware, STC has developed a firmware image of a “monitor” program; this is essentially a specialized firmware that will take over a serial port, periodically check in and ask for commands from the computer it’s attached to, and essentially “monitor” the user’s firmware image.

stc-isp-15xx-v6.86C_2017-07-16_20-48-00
The STC ISP programmer connects to the MCU over UART to reprogram it. As you can see, the app has no shortage of buttons and checkboxes.

Development Environment

Almost all modern MCUs have a flash peripheral that allows reprogramming the entire code space. This is useful for persistent configuration storage, in-application updates, or bootloader stuff… and not much else at all, realy. Given the complexity of the flash peripheral, it’s surprising how ubiquitous it is, even among the lowest-cost, most memory-constrained MCUs.

With STC, this is seen as a “developer peripheral” and is only available on the highest-end configuration of each device, with a specialty designator (IAP15W… versus STC15W…). It’s important to understand that I’m not claiming the non-IAP chips can’t be reporgrammed (of course they can); I’m just saying that they can’t be reprogrammed from within the user’s firmware; they can only be reprogrammed by booting into the factory ROM bootloader mentioned previously.

Since so few applications need in-app-programming, and the most common application of IAP is persistent configuration (easily handled by the built-in EEPROM that almost all STC15W parts have), this may not seem like a big deal, but there’s a catch:

The STC part has no on-chip debugger, so the only way to debug your code is by flashing a monitor program onto the chip, which is essentially software that emulates an on-chip debugger by using the peripherals already on the chip. The most important peripheral the monitor program needs is the flash programming peripheral, as this is how it can update code from the computer while running.

This monitor program is a very old-school way of doing debugging that was quite popular in the 1990s, but honestly, I had never used it before I started playing with the STC parts. The real downside of the monitor program is that it slows down your user code quite a bit.

STC doesn’t provide a stand-alone development environment (which is probably a good thing), but they have a small ISP program that hooks in with Keil C51 quite nicely. The ISP program is ugly, and some of the English translations have garbled up the UI, but if you can look at it from a utilitarian mindset, I think you’ll actually like it. Why?

  • UI is littered with checkboxes and buttons that do *everything* imaginable.
  • Tab after tab after tab of the cutest little utilities imaginable. UART code-gen tools; timer calculators; header file generators; built-in code examples; buttons for automagically programming the proper monitor firmware image onto your device; a device selector tab that’s much snappier than any web-based I’ve seen from ST or Microchip or Atmel… the list goes on.
  • Good, fast batch programming support (which is good, since you probably won’t be ordering these chips pre-programmed when you go into small-volume production).
  • Programming speed seems as zippidy as downloading code to an ARM chip over JTAG with a $500 Segger J-Link.
  • As soon as the ISP program notices you’ve rebuild the project in Keil, it will automatically upload the new firmware to your IC.

is the environment I’d recommend you do your work in. This is not Eclipse, and is not trying to be Eclipse. It’s spartan and basic, but runs super snappy on even the oldest computer you have laying around. Keil is the only tool you’ll be able to use to debug your code, but the editor is so basic, I’ll sometimes just use a stand-alone text editor, especially If I’ve got a lot of hacking to do.

Power Consumption

Haha, you’re joking, right? It doesn’t appear that STC has designed for power consumption at all. 4-6 mA in run mode (not terrible, given its performance), but idle mode is only 1 mA, and its “power-down” mode (with everything shut off, no RAM retention, and no wake-up sources other than reset) is rated at 0.4 uA – no, we didn’t misspell “nanoamps”. The EFM8 can run an RTC to wake up the core out of sleep for about that much power.

Summary

Things to like about the STC15W

  • Wide range of products from 8-pin half-a-kB flash chips, all the way up to 64-pin monsters.
  • Very inexpensive; if you’re comfortable to with Ali Express or Taobao, you shouldn’t have to pay more than $1 for *any* of these MCUs – even in single quantities.
  • No proprietary programmer; all device flashing and debugging is done through a UART.
  • DIP packages widely available for every single model they make.
  • Funky internal R/C oscillator promising 0.3% accurate, 1% temperature drift operation, and reprogrammable continuously from 5-35 MHz.
  • Essentially fully specified across a wide operating range from 2.5 to 5.5V means one device can drop into 3.3V and 5V projects with no change in performance (other than power consumption)
  • Easy-to-understand datasheet with relatively good English, and mounds of example code

Things we’re missing

  • No true on-chip debugging
  • Specialty In-application flash programming (IAP) versions of the chips are more expensive and come in fewer package options.
  • No I2c peripheral on any chip they’ve ever made. Many true 8051ers would roll their eyes and call it unnecessary; truth be told, the quasi-bidirectional pin I/O of the 8051 makes writing a software big-banged I2c far more intuitive on the 8051 than any other platform we evaluated.
  • Spotty ADC coverage on lower-end / smaller-package devices: you have to get up to the 16-pin-minimum STC15W401AS before you get an ADC.
  • Any semblance of low-power operation.

Verdict / Who’s It For

The STC stuff is hard to justify committing to if you’re a professional engineer that’s working on an expensive, long-term, mass-produced project — no English-based forum/community; zero tech support; no errata / app notes (other than what’s built into the datasheet); no US-based distributors. I used my private consulting email address to request a quote for 1000/10,000 units of a few parts, and they never got back to me. These people won’t even sell me their chips, let alone support them.

Having said that, I’m actually having an awfully hard time coming up with reasons not to recommend these chips to hobbyists, makers, hackers, and students, who generally don’t care about long-term availability, ultra-low power-consumption, or traditional distributor connections.

I like that you can buy DIP packages – from 8-pin to 40-pin – for less than a dollar, and put them on a breadboard with a $4 CH340 USB-to-serial converter, and that’s all you need. I actually really like the monitor program; it gets people who are new to microcontrollers thinking about how such a program is operating (sniff the 115200-baud traffic if you’re curious!). Keil doesn’t have nearly any bells and whistles, but it *screams* on my 15-watt i7 Surface Book, which I can’t say the same about Eclipse-based IDEs – it should work well, even if you’re using an older computer.

I think hobbyists and *nix people — who all seem allergic to IDEs and on-chip debugging — will enjoy the platform, too; they can grab a copy of stcgal and sdcc, and start plugging away. Or if they’re on the fence about their OSS persuasions, I know for a fact that Keil C51 runs great under Wine, as this is how Silicon Labs was able to make a totally cross-platform Simplicity Studio IDE that uses Keil C51.