I was interested in finding the cheapest flash microcontroller LCSC sells, and it turns out it’s not a crusty old 8051 or a PIC16 clone — and it’s not the WCH CH32V003 that the Internet is freaking out about — it’s actually an Arm Cortex-M0+ made by Puya, it’s less than 10 cents in moderate quantities, and it’s awesome.

Puya? They’re a flash memory company out of Shanghai that’s been around since 2012 — mostly making really low-cost SPI flash memory for IoT gadgets. While it may seem odd that the cheapest MCU is made by a Flash memory company, if you know a thing or two about chip design (which I don’t) you’ll know that it’s often the flash memory inside the part that’s the most expensive IP in the design. This is why so many fabless semiconductor shops don’t bother with it and just use external SPI flash or OTP memory (just look at any USB webcam controller, Bluetooth audio chip, or even the popular Espressif products).

Puya PY32 Selection Guide

Puya makes a range of ultra-low-cost Arm Cortex-M0+ parts in the PY32 series. There are three families in the series: the PY32F002A, the PY32F003, and the PY32F030. The families differ in memory, maximum speed, and peripheral inclusion, but they seem entirely progressive (e.g., firmware written for the PY32F002A should run on the PY32F003 and PY32F030). Regardless, all the parts are modern designs that use internal regulators and have an operating voltage range of 1.7 to 5.5V.

Unlike many other low-cost MCUs that only come in one or two (usually low-density) package options, the PY32 has nine different choices, ranging from a tiny 2×3 mm DFN to a full-sized 32-pin LQFP — along with QFN, TSSOP, and drunk-soldering-friendly SOIC packages.

I bought a ton of different PY32 parts from LCSC (just search for PY32). At the time of publication, prices have shot up quite a bit compared to when I first ordered these parts, but currently, the prices range from less than 8 cents up to $0.74 depending on the exact part, configuration, and quantity you’re buying.

If you want to avoid redoing some of the work I’ve done to get these parts going, I have a py32-template GitHub repo with a sample project you can clone and adapt to your needs.

The F002A is the base model; it clocks in at 24 MHz, has 20K of flash, 3K of SRAM, and comes in SOIC8/16, TSSOP20, and QFN16 packages — along with an odd 1mm-pitched ESSOP10 package. It has one advanced-control timer with 4 outputs (plus two complementary pairs for driving H-bridges), 1 low-power timer, 1 general-purpose timer, a 1 MSPS 12-bit ADC with 6 external channels, two comparators, a basic watchdog timer, and one SPI, I2C, and USART peripheral. And since this is a Cortex-M0+, you get an SWD debugging interface, a SysTick timer, and a nested vector interrupt controller (NVIC) bundled in.

The big thing the PY32F003 has over the F002A is DMA support, which is an unusual feature in this price range. The PY32F003 comes in 16K and 32K flash versions (with 2K and 4K of RAM respectively). In addition to the DMA, it adds three more general-purpose timers, a second USART, plus an “IR timer” (which is really just a NAND gate fed from TIM16 and TIM17 which can be configured to generate the carrier and data signals respectively). It also adds some reliability with a windowed watchdog (WWDG) and programmable voltage detect (PVD) brownout supervisor.

While the F003 advertises a 32 MHz operating frequency, its internal oscillator only runs at 24 Mhz. To get to 32 MHz, you’ll need an external crystal, which can cost more than half as much as the actual microcontroller does, and depending on the MCU package, can double the board area required to lay out the part.

The PY32F030 is the highest-end part in the lineup. It adds a 2x PLL that can run the core at 48 MHz off of the 24 MHz internal oscillator. The F030 also adds 32-pin QFP/QFN package support to get you up to 30 GPIO pins. In addition to the other capacities already mentioned, the F030 is also available in a higher-capacity 64K flash / 8K RAM version. The peripheral set between the F003 and F030 is identical, save for the F030’s built-in scanning LED matrix controller, which supports 4 8-segment digits.

What’s particularly strange is that the F030 has two different sets of pinouts. The F2 QFN and TSSOP 20-pin packages has three extra analog inputs, which the F1 package trades for 32kHz oscillator support. On the 32-pin package, the K2 version adds an extra GPIO pin in exchange for one fewer GND pin. I’m not sure of the rationale for trading GPIO pins for redundant power pins; maybe for better analog performance?

Are these STM32 clones?

While the PY32F030 family looks very much like an STM32F030, they are not compatible parts in any capacity. None of the parts appear to have complete pin compatibility, so they are not compatible at a hardware level. And the register offsets and interrupt vectors are different, meaning there is no binary compatibility for even very basic programs. While the peripherals are very similar to STM32 ones, there are subtle differences in the registers that will trip you up if you’re familiar with STM32 programming. These changes mostly appear to correct questionable decisions ST made in the first place; for example, the EXTI peripheral now contains configuration registers that allows you to route the correct GPIO bank to the EXTI signal you want (this was strangely located in SYSCFG on the STM32F030).

Development Experience

Overall, these parts are much easier to use than other parts in this price range, which often have poor English documentation, no code samples or peripheral libraries, or require vendor-provided IDEs and weird tooling.

Sourcing

You don’t need to buy these parts from weird Taobao links or AliExpress sellers — they’re available straight from LCSC. I initially designed my own breakout boards for these parts, but my friend Charles noticed Puya has $5 dev boards available too (which are really just breakout boards — they don’t even have a built-in debugger). Stock has been fluctuating a lot, as have prices, but they’re cheap enough to hoard for small-term low-volume projects.

Documentation and SDK

PY32 documentation is quite good. Visit Puya’s PY32 web page and you can download everything you need — just scroll horizontally all the way to the right and click on the “Datasheet” download (here’s a direct link that I’ll surely forget to update in the future). Notice this isn’t a datasheet, but a ZIP that contains all the PY32 resources (and yes, each product links to this same file on their web site). Inside, you’ll find English and Chinese datasheets and reference manuals, code samples, a Keil DFP that contains the flash algorithms you’ll need to be able to burn your code onto these parts with an SWD probe. The documentation is pretty good, but at the time of writing, only the PY32F030 contains an English reference manual. This isn’t much of a problem as you can use this same guide for all parts.

Compiling

Next to all the goofy low-cost 8-bit parts I’ve played with, boy, it sure does feel nice to be working on an Arm Cortex part. I fired up VSCode, pulled in the SDK, created a Makefile and launch.json config, and I was off to the races.

Well… not quite. Like most Arm parts from the East, Puya’s SDK has set them up for Keil MDK development. You can definitely go grab a free version of Keil MDK and get going immediately, but I wanted a VSCode / Cortex-Debug / GCC-based solution, which took a bit more fiddling. Using other GCC Arm Cortex project code I had laying around as a reference, I created GCC linker config and startup files for each part with a memory map and vector table based on the Keil linker config and startup files. With a bit more source-file mashing, I was able to pull in their STM32 HAL-like peripheral library and build a project.

Flashing

I really only use two debug servers these days: Segger’s J-Link GDB Server (obviously for use with their Segger J-Link) and pyOCD (which I use with low-cost CMSIS-DAP probes). To get pyOCD working, I tried searching for the Puya pack, but it’s not indexed in the repositories that pyOCD searches, so I had to manually install it. I extracted the PY32 DFP (which is just a ZIP file), then I copied the pdsc to pyOCD’s cmsis-pack-manager’s pack folder inside the Python distribution I’m using (mine was in LocalCache\Local\cmsis-pack-manager\cmsis-pack-manager). It’s important to rename the file to include the version number in it — Puya.PY32F0xx_DFP.1.1.0.pdsc. I then copied the original whole DFP file to the same directory, following the same convention as all the other packs use — copying it to Puya\PY32F0xx_DFP\1.1.0.pack.  After that, to rebuild the index file to include the new pack, I ran:

PS C:\> pack-manager add-packs Puya.PY32F0xx_DFP.1.1.0.pdsc

I checked that pyOCD could now find the pack:

PS C:\> pyocd pack find PY32
  Part          Vendor   Pack                Version   Installed
------------------------------------------------------------------
  PY32F002Ax5   Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F003x4    Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F003x6    Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F003x8    Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F030x3    Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F030x4    Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F030x6    Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F030x7    Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F030x8    Puya     Puya.PY32F0xx_DFP   1.1.0     True
  PY32F072xB    Puya     Puya.PY32F0xx_DFP   1.1.0     True

and then installed it:

PS C:\> pyocd pack install PY32F003x8

Getting J-Link support was actually less involved. Segger doesn’t have Puya PY32 support, but you can add custom device support by following directions here. I created a JLinkDevices\Puya\PY32 folder structure, then added a Devices.xml file:

<Database>
  <Device>
    <ChipInfo Vendor="Puya" Name="PY32F002Ax5" WorkRAMAddr="0x20000000" WorkRAMSize="3072" Core="JLINK_CORE_CORTEX_M0" />
    <FlashBankInfo Name="Internal code flash" BaseAddr="0x08000000" AlwaysPresent="1" >
      <LoaderInfo Name="Default" MaxSize="0x5000" Loader="PY32F0xx_20.FLM" LoaderType="FLASH_ALGO_TYPE_OPEN" />
    </FlashBankInfo>
  </Device>
</Database>

I then copied the FLM flash programming algorithm files out of Puya’s DFP into this folder. After doing that, I was able to see the device in J-Link’s target selection box, and everything worked flawlessly. I will note that you have to be on a relatively-recent version of J-Link for this to work, so make sure you’ve upgraded and actually have the correct version on your PATH.

Debugging

I tested both Segger Ozone and VSCode (via Cortex-Debug) and was a little disappointed with how little effort it took to get going. It’s a Cortex-M0+, so debugging worked without a hiccup. Breakpoints, reading memory, yada-yada. I will say that while I was working through some low-power code, I noticed the SVD files provided by Puya were missing the PWR peripheral, so I had to manually add it. The SVD files are very bare-bones, with no descriptions or enumerations for things, but they seem to be accurate. Again, when compared to other parts in this price range, there’s no contest.

In Use

On parts with unique peripherals, I try to play with everything a bit before casting judgment — just to look for gaping holes or big-time “gotchas” — but since these are STM32-like peripherals, you kind of know what you’re getting.

One big difference between this and the STM32F030 is low-power support. The PY32F030 parts advertise a typical low-power stop mode current consumption of 4.5 µA when using a 1.0V setting with the internal regulator, and I was able to get the part to drop down to 5 µA in my testing. Meanwhile, the STM32F030 uses less than half of that in stop mode, and in run mode always outpaces the PY32F030 substantially: it doesn’t have the low-power internal 32 kHz oscillator the PY32 does, but it doesn’t seem to need it — when powered with its internal 8 MHz oscillator it uses less than half the current as the PY32 running off its internal 32 kHz one (while running 250 times faster). All told, the PY32F030 does not live in the sub-microamp ultra-low-power territory that you can hit with more expensive parts, but we’re still talking about a microcontroller that can be powered for several years with a minuscule CR2032 battery.

Puya chose to nearly copy the STM32 peripheral register API, as well as the STM32 HAL library. When I started with STM32 years ago, I wasn’t particularly offended by STM32’s HAL library, but as I’ve used more parts over the years, I find it more and more annoying to configure and use. On a part with only 20K of flash, these HAL libraries can eat into quite a bit of space, so if you’re using this part for real projects, you may find yourself using lighter-weight peripheral libraries to save space.

What about the CH32V003 or STM32F030?

The elephant in the room is the WCH CH32V003, an entry-level RISC-V chip widely covered in the electronics press that may or may not be available for around 10 cents. While people mention buying these parts from WCH’s official AliExpress store, at the time of writing, it appears that they yanked the part, and I can’t find them anywhere on AliExpress for less than $2 per chip, though it’s on Taobao for about 25 cents each.

It’s hard to find a direct cross between the CH32V003 and the PY32. In terms of flash/RAM/peripherals, the CH32V003 is very similar to the entry-level PY32F002A, which can be had for less than 10 cents in fairly modest volumes (though for most projects, you’d need more pins and would opt for the 14-cent QFN16 version). The Puya part has more flash and RAM, while the CH32V003 has an internal 2x PLL that runs the core twice as fast. The CH32V003 also has DMA, which is especially important when working with high-bit-rate communications interfaces on these low-speed devices. If you move up to the PY32F030 to match the clock speed and DMA of the CH32V003, you’ve jumped up considerably to 30 cents or more, but you’re also getting a part with four times more flash and RAM, plus 3 more timers and another USART.

My biggest gripe with the CH32V003 is the tooling: it uses a goofy one-wire debug interface requiring a proprietary debugger and a hacked-together custom version of OpenOCD (a software I detest). I think most WCH users just use MounRiver, an Eclipse-based IDE that comes preconfigured for WCH CH32 parts. This software feels painfully slow compared to VSCode and Ozone-based workflows. Some of these issues are WCH-specific, and some are more broadly a problem with RISC-V — no pyOCD support, no Cortex-Debug support, and spotty J-Link support, too. I haven’t looked into higher-end RISC-V cores, so I have no idea what kind of support there is for instruction trace and other advanced debugging tools, but it just seems like the RISC-V development ecosystem has a long way to go before it achieves parity with Arm.

What about Arm competitors? It’s no surprise these PY32 parts are cheaper than the STM32F030, though the direct cross — the PY32F030 — really isn’t that much cheaper. You can get STM32F030F4P6s from LCSC for about 50 cents each in moderate quantity. These don’t have the flash or RAM or 5V compatibility the PY32F030 does, but you get better low-power support and a bit less pain in initial project set-up (especially considering the STM32CubeMX compatibility). The Puya parts, however, offer way more varied package options. I’m not a big fan of TSSOP and LQFP packages, so it’s nice to get similarly-spec’d parts in tiny DFN and QFN packages. And if you can sacrifice some performance, you can get into the PY32 for much less than an STM32F030.

Final Thoughts

A while back I wrote a large blog post on the Padauk PMS150; the post ended up so long simply because the ecosystem was quite different than modern development environments. There were several-hundred-dollar emulators and programmers you had to buy, a weird IDE that used a subset C dialect that often looked more like assembly, and OTP memory that meant that one mistake could send you to the soldering rework station to pop off and discard the MCU you just accidentally ruined. Unless you’re making products in super high volumes, it really doesn’t make much sense to invest in the tools, time, and effort to learn that ecosystem.

The Puya PY32 couldn’t be more different. The entire time I worked through this project, I kept forgetting that I was using a part that is 20 times cheaper than what I’m used to using. It has the same sorts of peripherals you’d expect to find on any NXP, ST, or Microchip Arm part you’d buy off DigiKey. It has good English documentation, full compatibility with the debug probes you already own, and you can use whatever software ecosystem you prefer — Eclipse, Vim, VSCode, Embedded Studio, Keil, IAR, or nearly anything else.

Bottom line: the Puya PY32 ecosystem is just plain boring — and that’s a good thing.

The post The cheapest flash microcontroller you can buy is actually an Arm Cortex-M0+ appeared first on Jay Carlson.

At the same time, there’s been a lot of buzz online in the past year or so about electronics workspaces. With so many people working from home during the pandemic, everyone’s been sharing the gear they’ve been using, what their office setups look like, and how they like to manage things. Since several people have asked me to talk about workflow, I thought I’d throw my hat in the ring. This post will discuss my office design, my workflow, and all the gear — big and small — I use to juggle different projects.

Evolved Spaces

Our workspaces reflect who we are and what we care about, so they evolve over time. You’re going to acquire new gear, get rid of tools you don’t use, upsize, downsize, and twist and turn. I was digging through old photos to try to come up with some examples of my previous set-ups, and it really brought back some memories. I also realized it took me a long time to realize what was working for me and what wasn’t.

My real foray into electronics started toward the end of my undergrad career in 2010 when I was living in a bit of a party house. My DMX lights, amplifiers, and other gear seemed in constant need of repair; this was the first time that I really connected the abstract material we were learning in EE classes to real-world applications. This was also when I started building little circuits on protoboard (one of the first projects I remember was an XLR balanced line receiver for an amplifier to remove hum). These circuits required nothing more than a soldering iron and a computer to look up datasheets. Eventually, I snagged an oscilloscope, function generator, and linear power supply. I was set.

Back then, programming terrified me. My only embedded systems experience was an assembly-based class I took a few years prior taught mostly on a blackboard, along with a giant 68HC12 development board that was chained to a Windows 95 PC in a lab. Like many of my EE classes, I nearly failed it; I clearly remember leaving that class thinking I could never do any programming. I’d stick to analog circuits, thank you very much.

The problem was that I kept hitting a glass wall with little projects I wanted to do at home. I remember wanting to build sound-activated lights, a little RF remote control thing, and tons of other little projects, but it seemed like everything required a microcontroller. I started tip-toeing into embedded systems. Based on suggestions from forums online, I started dorking around with PIC16 and PIC18 parts, using a PicKit clone and a pirated copy of the CCS toolchain. You may laugh, but keep in mind that I had never heard of Arduino (nor had most people at the time), I had never done any C programming, and I had no social network of mentors to learn from.

This is when I started experimenting with different workspace setups. I threw together a computer out of old parts and set that up on my bench as my electronics workstation. It was old and slow, but totally passable for basic MCU development.

I started a master’s program after graduating that winter. I was working in a fantastic lab on campus with a great setup (and deep pocketbooks to buy any new gear I wanted). I was totally enthralled by the experience and rarely went home before 10 or 11 pm. My workbench at home started gathering dust. In the spring of that year, I bought a house. Looking for a cozy, clean look, I didn’t even think to move my then-dilapidated workbench into my new home office — I moved it into the garage, out of sight, knowing I’d rarely use it.

When I started taking on consulting projects a year and a half later, I dusted the bench off and moved it upstairs into my home office. Instead of a dedicated bench computer, I ran long DVI and USB cables from my main desktop. Over time, I acquired better gear and started narrowing more into my current specialty of intersecting embedded hardware and software. My analog kit started moving further away, out of sight, replaced with more monitors, more USB hubs, and more computer-related peripherals. This is essentially how I operated for the next six years until I bought my current home, which proved to be a good time to take a step back and re-evaluate the best way to set things up.

Workspaces are not one-size-fits-all

Scrolling through responses to Chris Gammell’s tweet soliciting workspace inspiration, the first thing I noticed is how utterly different everyone’s set-ups are. Same thing with Arturo182’s request. There are classic analog electronics workbenches, like this one from @Mind_of_Bob:

There are people with elaborate setups to assemble large batches of PCBs, like @talldarknweirdo’s setup:

Plus many with lots of built-in storage and mechanical capabilities, like @lacavedly has:

What an “electronics workspace” means to you really depends on what “electronics” means to you.  This may seem obvious, but I get lots of questions from people asking about how many desks they need, or which scope they should buy, or which function generator they need, or which power supply to get, or whether they should get an Analog Discovery 2, 3D printer, bigger monitor, or any number of other gear. 

Establishing Modalities

If you’re thinking about redoing your space, the first thing to think about is how much time you spend in each modality in your office. Is your computer a thing you just use to look up datasheets on, or do you sit in front of it 24/7? Are your soldering station and oscilloscope the two most important things you use? This will help you inform how things should be arranged with respect to each other. While you’re thinking about this, you might want to consider:

• The type of projects you work on. If you’re designing a lot of analog audio projects, you might need a signal generator, scope, high-quality bipolar supplies, variac, isolation transformer, distortion meter, and other specialized analog test equipment close to you all the time. If you’re doing ultra-low-power embedded, you’ll replace most of that with a logic analyzer, BLE/LoRA packet sniffer, and some sort of source measurement unit (SMU). Totally different gear.
• The level of mechanical integration. If you’re doing turn-key proof-of-concept prototyping, you might spend a lot of time in front of a 3D printer, laser cutter, or needing ready access to lots of hand tools to build and assemble prototypes.
• Whether you’re assembling PCBs or not. There are tons of electronics hobbyists that really focus on breadboarding circuits and repairing gear — they really don’t do much PCB assembly. And building up quantity-of-five runs is quite different from building up larger batches, where it makes sense to invest in stencil printers, pick-and-place machines, and large reflow ovens. Where will those be set up in relation to other stuff in your office?
• The amount of firmware engineering you do. Whether you actively use your computer while working on projects is going to drive your computer choices and office layout. 

Building My Priorities

For me, I’ve narrowed it down to a few things:

Computer-centric workflow

 I’m an embedded electronics engineer, not a technician. I spend most of a prototype’s design lifecycle in front of a computer, reading PDFs, searching for supplies, designing PCBs, coordinating and designing mechanical CAD stuff, writing firmware, and communicating with others on my team about these designs. My computer needs to be the main attraction — it needs to be extremely powerful, and I need a massive amount of monitor space to stretch out and multitask.

Processor-heavy PCB bring-up

I work on processor-centric designs at the intersection of hardware and software, so 95% of the time, I’ve got PCBs that I’m futzing with while they’re attached to my computer. That means I need a soldering iron, multimeter, and logic analyzer right next to my computer at all times.

This was the biggest problem I had with my old office: my computer was completely disconnected from my bench. Eventually, I hacked around this issue a bit with a couple of extra monitors, but window management was a pain in the butt and I just wasn’t as productive as I could have been.

An interesting corollary: since I work on processor-heavy designs, it also means I really don’t need a lot of specialized analog test gear — at least right next to me at all times. If my oscilloscope broke, it’d probably be a couple of months before I even noticed. This is something very particular with the projects I work on; if I were more of a pure embedded software engineer, I could handle having my soldering setup on the other side of the room. If I mostly built guitar pedals, I’d probably want way more test gear and way less computer to bring my boards up.

Juggling multiple projects

I always have way too many projects on my desk that are completely unrelated. I need to be able to tear down and set up projects quickly. I also need ample work surfaces so I can keep multiple projects set up concurrently when possible.

Small-batch assembly

I build very small volumes of prototypes when it’s convenient — usually no more than 3-5 boards. For assembly, I need some minimal computing access, along with a massive amount of desk space to lay parts out, paste up boards, place components, and reflow things.

Good artwork plus unobstructed views outside

I have a lot of glass in my office, and I don’t want anything obstructing my backyard view. I also want to have enough visible wall space to be able to display more artwork than I had at my old house. I never want to feel like I’m working in a warehouse or a lab in some hidden bunker.

Desk Layout

I’ve settled on an L layout. This layout is great for unimodal workspaces (where you spend most of your time doing one thing) since you can maximize the work area you have without having to move your chair. To design an L area for unimodal work, start in the corner by placing your most-used components and work areas (for me, that’s my computer, soldering/development area). Then, slowly branch outward in either direction as you place equipment you use less and less frequently.

There are a few implementation-specific details I’d like to discuss, but first, here’s a picture of the setup:

I built the computer desk out of walnut-veneered plywood with a steel telescoping square-tubing base that I cut and welded together. While it’s a motorized sit/stand desk, I almost never use it in the standing position. The desk is absolutely massive: it’s 34″ deep and 80″ wide. The extra depth accommodates tripods and light stands behind my monitor and gives me some hidden storage behind my filing cabinet under the desk for speaker amplifiers, EQ, and other pieces of equipment. It also gives me plenty of desk space — even in front of my clunky laser printer. My biggest issue with this left area of the desk is the inefficient use of space — the vertical monitor and filing cabinet form a wall that prevents me from easily interacting with anything to the left of my computer, so it’s typically where I just stash stuff temporarily.

The electronics bench is melamine-veneered particle board from Home Depot that I mounted into painted steel component shelving from Menards. To build this, you’ll need 36″ x 30″ end frames plus beams that come in 48, 72, or 97″ lengths. This shelving is fantastic — I use it in my garage, in the basement, and in my office. The desk is 30″ deep, which is about perfect. I wouldn’t want any less than that, but if it were any deeper, I’d be reaching too far over stuff for it to be comfortable.

The corner of the L is typically dead space; in my case, it’s perfect for test gear which tends to be really deep. I keep the gear at a near-45-degree angle and stagger the equipment into two groups.

Next is my “product area” — basically, it’s the area where my current project lives. I have access to mains power (with a variac, too), ethernet, USB, and HDMI. It’s where my soldering station and hot air gun usually live. I have an inspection microscope and wide-field overhead camera for sharing my work over video conferencing.

By the way, this sounds like a silly thing to mention, but you really do need a “product work area” — I’ve seen plenty of desk setups where people seem to forget that they need to actually, like, you know, work on things that occupy space. I have approximately 20″ depth for projects (this is important!), and when the desk is clean, almost 7 ft of linear space.

To the right of the product work area is the PCB assembly area. I have a separate monitor that clones my right-most desktop, along with a mouse and occasionally a keyboard. This area is where my vacuum pen and hot plate live — along with my rarely-used reflow oven. Having enough space allows me to assemble new boards even while I have a project set up.

An underrated aspect of my office that few people notice: I have two chairs — a Herman Miller Aeron as well as a National Aurora. These are very different chairs. The Aeron is more ergonomic and breathable, but the Aurora is more plush and luxurious. If I’m working for long stretches of time, I alternate between them to reduce pressure points. Having a second chair is also handy when I’m collaborating with friends or colleagues. Good-quality office chairs can last 20-30 years (or more) with very little maintenance, and sometimes you can get them heavily discounted from your local commercial office furnishing company if they have excess inventory of an older model they’re trying to get rid of. You really shouldn’t buy cheap plastic chairs at big-box stores; they’re just going to fall apart and end up in the landfill in a few years’ time.

Fast Context-Switching

I have to juggle tons of projects simultaneously, which means I have to constantly context-switch. The faster you can context-switch between projects, the more efficient you are.

My big realization last year was that keeping my office clean was (on the face of it, at least) diametrically opposed to fast context-switching. If you want your office to be clean, all your projects need to be neatly filed away, and all your tools need to be in drawers somewhere, out of sight. To switch between projects, you’d tear down your old project, put everything back in a box, file the box away, then set up the new project and start working on it. 

But it just takes way too damn long to set projects up. You’ve got to grab all the PCBs, displays, and extraneous components, plug them all together, find your debugger, re-build that custom wire harness to connect to it, open up the PCB design files to remember which test points were what, route those out to your logic analyzer, and reconnect all the USB cables for that junk. That can easily take 15 minutes or more of time, every time you’re switching projects.

One solution is to stop trying to keep your office clean and just leave everything set up all the time. Been there, done that. While that makes it fast to context-switch, once you are switched into the right project, your productivity drops substantially since you can’t ever find what you’re looking for (since everything is sprawled out, everywhere). It’s also rather embarrassing to appear to be calling from a pig stye whenever you hop on a Zoom call with colleagues.

Instead, I set out to invest in equipment and accessories to remove as much friction as possible when context-switching while still letting me keep my office clean.

Project Tray System

The first thing I invested in was a project tray system. This lets me keep projects set up, ready to go. Projects still have a box assigned to them to store bare PCBs, parts, and other odds and ends — as well as completed projects (since I don’t quite get as much density with the trays).

I bought this food service 10-tier sheet pan rack plus a couple dozen lunch trays and they work great. I’m setting up a similar system at work right now with a few full-size trays for larger projects. You can opt for ESD-safe trays if you’re one of those people.

Making project trays useful

Project trays are only useful if you use them properly. Don’t move old versions of boards into boxes once you’ve built up new revisions — they should both be on separate trays so you can sanity-check things if necessary. You’ll really want to invest in all the cables and adapters necessary to keep everything hooked up at all times. Almost all of my trays have a 4-port USB 3.0 hub glued to them which allows me to connect power, debug probes, USB-to-serial converters, and any other gadget I need. All of that stuff lives on the tray for the lifespan of the project, so you’ll need to have a lot of duplication.

These Sabrent 4-port USB 3.0 hubs have individual power switches for each port, which is a total necessity for embedded development — you can quickly power-cycle your boards, debug adapters, and USB-to-serial converters. I really should have checked about volume discount pricing, since I own dozens of these between my home office and work. Unlike a lot of USB hubs, I’ve never seen one of these fail.

USB-to-serial converters are the standard mechanism for interacting with embedded Linux projects as well as some bare-metal systems, so grab a few four-packs of these FT232RL modules so you can keep everything wired up as you’re moving between projects. They have selectable 5V / 3.3V logic levels and break out all the special flow/control signals you’ll never use.

Additionally, since I do a lot of embedded Linux work, I have an ethernet switch on my desk — almost like a USB hub — ready to plug into. This lets me connect multiple projects simultaneously without fiddling with cabling under my desk. Since the switch connects to my home network, my projects can automatically pull DHCP leases and gain Internet access with no special configuration. This is much easier than trying to connect projects directly to your computer.

You could grab a small 5-port unmanaged gigabit switch for most casual work where your project’s networking stack already works without issue — but if you’re bringing up boards with buggy network stacks or you’re trying to benchmark specific performance criteria, spend the extra money on a managed switch like the 5-port Netgear GS305E or 8-port Netgear GS308E.

These switches have a web-based user interface that lets you configure several networking features — the most relevant to me is port mirroring. This feature duplicates the network traffic sent and received on one or more ports and sends it to a separate monitoring port that you can attach to your computer and view through something like WireShark. This gives you a ton of insight into the raw Ethernet frames sent and received by your embedded project.

And finally, it’s nice to have a three-channel HDMI selector sitting in front of an HDMI capture card so you can route any video sources from embedded projects to your computer for recording, streaming, or just for display. Even if you’re sitting right next to it, it’s still nice to have a window in the corner of your monitor with your embedded project’s output video instead of having to hunch over and look at a separate LCD screen all the time.

If you take some time to invest in the little stuff, it really goes a long way. For example, Saleae sells extra sets of test leads, so you can keep everything wired up with the correct channel order, and all you have to do is plug in the bus connector and load a project-specific preset in the software. You can buy packs of multi-colored USB cables so you can easily figure out which port goes to which device. I went really nuts and bought slim Ethernet cables and slim HDMI cables, and I love having them around.

Other Organization Tools

Wall Storage Bins

I have a wall full of storage bins that goes back to my college days. They used to contain every single IC, transistor, and passive I owned, but these days, I only file away stuff that I find myself using all the time. It’s where I keep all my breadboarding parts, along with popular connectors, voltage regulators, transistors, and other ICs.

The bins aren’t sorted by category; instead, each bin has an incrementing number associated with it, and I have a database on my computer that will tell me the location of anything. The advantage is that I always know exactly what I have and where it is, but the disadvantage is I can’t really just walk up to the wall of parts and know where something is, since everything is sorted numerically. Everything has to be looked up or memorized. I’m not sure I would do it the same way if I had to do it again.

The reason why I stopped filing everything away in the wall of bins is that my BOMs started getting heavily specialized when I started working professionally — if I didn’t switch to storing parts in project boxes, the wall bins would grow uncontrollably. I’m putting a hard stop on buying more bins — I don’t want my office to turn into a warehouse. 

Closet and tool chest

I have a modestly-sized tool chest that contains various hand tools, electronic component design kits, and other odds and ends. My closet is the central repository for project storage, SMD components, and all those dev boards, programmers, debuggers, and other odds and ends I’ve accumulated over time. I just use cheap plastic boxes from Target for most of the project storage.

Mechanical Office

I’m really focused on my main office in this post, but another trick I have up my sleeve is that I actually have a whole second office in my basement that’s geared toward mechanical work. This is where my 3D printer, CNC mill, and more mechanically-focused tools live. This space is more optimized for larger, long-term projects that don’t fit in my standard tray system. I have an old crappy soldering station and simple power supply down there, so I can do the bulk of my electronics work upstairs and then just transport the tray downstairs for integration when needed. It’s not perfect, but it could be worse.

The main gear I use

A desktop computer

I am absolutely perplexed by the number of laptops I see on people’s workbenches. For electronics development, desktop PCs are a total no-brainer. I encourage anyone serious about embedded engineering to build or buy a desktop for their office area. A basic $800 desktop computer built around something like a last-generation 65-watt Ryzen 3700X is about 30% faster than the top-of-the-line mobile CPUs found in the newest, most expensive laptops money can buy((Here, we’re considering code compilation benchmarks and cinebench scores)), and if you splurge on a high-end desktop or workstation-class processor, your computer will literally be an order of magnitude faster than most laptops available on the market.

It’s really just a matter of physics: a thin-and-light 13″ laptop has a ~15W processor, while a heavy-duty 15″ laptop has a ~45W processor. Meanwhile, desktop computers usually start with 65W CPUs, and can go up to 220W for the highest-end parts. Desktops have better long-term reliability, and because they’re so easy to upgrade and expand, can be useful for 10 years or longer.

My computer is the most important tool in my office, so I didn’t skimp — I built a desktop around a Threadripper 3970X and 64 GB of RAM((I’ve read that my system can’t run RAM at maximum speeds if I move up to 128 GB, and I rarely exhaust my capacity)). With this setup, I can recompile a (light-weight) Linux kernel in 30-60 seconds and create an entire Buildroot-based rootfs in 15 minutes, so it’s been a measurable boost in productivity for my embedded Linux-based projects.

Lots of monitor space

Designing a PCB usually involves simultaneous access to a device datasheet, reference schematics/web posts, PCB/schematic capture software, and potentially an IDE or sample code. I think four 1080p workspaces is about the minimum I need to be productive; otherwise, I find myself bouncing between windows and tabs way too often.

My current setup pairs an LG 43UN700-TB 43″ 4K monitor with a vertical BenQ 27″ QHD display, along with an old 22″ 1080p display I have on the side. I have an additional 1080p display on my electronics area that is cloned with this display to use as a reference when I’m assembling boards.

If you’re looking for something a bit less intense, two of my favorite setups to start with are either a single large-format 40″ 4K monitor, or two 27″ QHD displays and a smaller 1080p vertical one. Avoid monitors that require high-DPI scaling (basically any 4K monitor smaller than 40″) or ultrawide displays (which cost way more than just buying two HD or QHD displays).

Cartridge-style soldering station

I absolutely adore cartridge-style soldering stations, and will never go back to the dark ages. There’s a lot of gear I can recommend that you don’t buy, but this is one spot you should treat yourself to some luxury. I have an older JBC compact station, more or less equivalent to the CD-1SQF Compact Precision model. When I pick up the handle, it immediately comes out of hibernation and heats up to 350C in less than 4 seconds; put it back in the holder and it reduces to 135C. After prolonged inactivity, it will automatically turn off altogether, returning to hibernation. Try to score one off eBay like I did — it was right around $100.

Streaming-based logic analyzer

I love using my Saleae Logic Pro 16 for board bring-up since it works more like a digital/analog DAQ than a traditional logic analyzer. If you’re working through power sequencing issues on complex boards, you’re going to run out of channels quickly when using a scope; here’s where the Saleae shines: you can capture analog voltages from -10 to +10 V on each of its 16 inputs, along with all the usual digital logic analyzer stuff. It’s fun to wire the probes up to all the voltages, oscillators, and UARTs on your board and watch everything ramp up when you apply power.

Saleae also makes an 8-channel version which is a few hundred dollars cheaper. I think you’ll have to look at the projects you’re working on and your hourly rate to decide which one makes more sense. I’ll say that my projects tend to leak over into 9-16 channel territory only about 5% of the time, and usually, it’s more out of convenience than necessity. Also of note: if you’re a student they offer half-off pricing on all their products.

The analog capabilities really help offload many of the duties typically relegated to oscilloscopes. I know this is bound to trigger some folks (no pun intended), but if you have a Saleae Logic, I really don’t think you need a scope for a lot of day-to-day development. I took all these pics of my office before realizing I actually don’t even have a scope on my bench right now (instead, I’m in frequency-domain land via a Siglent SSA 3021X Spectrum Analyzer). You should buy a scope when you start doing a lot of power electronics/motor control, or if you’re doing very sensitive analog work or PDN diagnostics for EMC issues, but otherwise, you might be surprised how little you use it.

Speaking of analog capabilities, Saleae gets compared to Analog Discovery a lot, but they’re totally different tools. The Analog Discovery 2 is a built-down-to-a-price scope/spectrum analyzer/network analyzer/logic analyzer educational tool designed as a low-cost way to get students started thinking about this stuff. Since AD2 is not a streaming analyzer, you have to kind of know what you’re expecting to see so that you can set up triggers properly, and there’s an extremely limited buffer.((OK, I think there is some sort of live streaming mode, but it’s limited to something like 1 MSPS, and it’s digital-only)) Other than the logic analyzer capabilities, it’s a pretty crummy scope (30 MHz bandwidth, very limited voltage input range), and the 10 MHz spectrum/network analyzer is for stuff like audio-frequency applications, not RF. That’s all fine — it’s an educational tool after all. There are some other bells and whistles with respect to programmable digital I/O and SDK interfacing that might make it useful for a professional to own, but it’s definitely not a stand-in for other tools.

USB Hubs

This may seem silly to mention, but it’s probably my most-used tool. I have two main USB hubs — an Anker 7-port hub for my “office” side, and a 7+3 port hub from Sabrent for my electronics side. Anker hubs are extremely popular, but I’ve found that the 7+3 port model consistently dies after about a year (I’ve gone through several of them at home, in the lab, and at work), so I’d avoid that model.

Workflow

Next, I’d like to show how all of this stuff fits into a typical embedded hardware project where you’re assembling a PCB and bringing it up. I’ll also share some additional tools and accessories I use in my office.

Paste Stenciling

To build up a board, I plant myself squarely in the middle of my electronics bench for most of the process. I love that JLCPCB ships used sacrificial material as a backing board for their full-size stencils; I reuse this material to build jigs to align the solder stencil. I use my inspection camera to look at how ridiculous my solder paste job is before moving to the next step.((I usually convince myself it’s “good enough” and then end up regretting it after cleaning up shorts for the rest of the night.))

I used to have my inspection microscope directly attached to my workbench’s 1080p monitor, but changing inputs on it was a hassle, and now that I’m on video calls all the time I use a capture card to be able to share my work with others. Now, everything goes through OBS so I can get a live feed on my monitor, as well as stream it over Zoom, Slack, or Hangouts using VirtualCam.

Tools

• Magnetic goose-kneck sewing machine lamps, which stick to the front of my bench and provide controlled lighting.
• An autofocus HDMI-output microscope kit with a 0.5X optic (helps increase working distance).
• USB HDMI capture dongle allowing me to display, stream, and capture the microscope’s output on my computer.
• Alcohol. Isopropyl for cleaning and ethyl for drinking (though you could really go either way on this).

Placement

Next, I place parts on the board. I fly out my inspection camera to check alignment on critical parts, but otherwise, my monitor has my design up so I can reference things as I place parts. I have roughly 50 standard-value passives and discretes on reels that I use all the time; this saves a ton of time since I never have to worry about stock.

Tools

• SMD-VAC-HP foot-operated vaccum pen, but just buy a cheap aquarium pump one from Amazon or eBay and hack in a foot pedal.
• Cheap USB mouse to control computer
• Silicone mat to work on
• SMD reel holders

Reflow

Next is the reflow process. I use a hot plate (plus hot-air for double-sided boards) for almost all my hand-assembled boards. If it’s too complicated to hot-plate, I probably don’t want to hand-assemble it in the first place. At this point, the component trays go away and the microscope is still flown out. I pull out my hot plate and fume extractor, put the boards on the cold surface, and turn it on until the board reflows. I then set the board on the silicone mat — the insulative abilities reduce the thermal shock on the board. Then there’s a final visual inspection and clean-up with the soldering iron.

Tools

• Solid-surface cast-iron hot plate. I recommend getting some sacrificial aluminum to set the boards on.
• Cheap hot-air station. I like that the heating element and fan are in the handpiece, making the cabling less bulky.
• Soldering flux fume extractor. Not totally necessary, but makes visually inspecting your reflowing boards more comfortable.

Bring-Up

Once I do a quick visual inspection, I’ll test the board for shorts and if that looks good, I’ll use my power supply to slowly bring up the board. If all the rails look good, it’s time to get the board on a tray and start the firmware work. Most of this is pretty typical: I use debuggers, logic analyzers, and TTL serial adapters — coupled with vendor or third-party IDEs, text editors, and toolchains — to scaffold out firmware and develop the project.

I want to point out one atypical tool I use quite a bit: my overhead camera. I collaborate a lot with folks, so an overhead camera is really useful to share project progress and record demos. I like having it mounted to a boom arm, allowing me to easily fly it in and out and position things perfectly. The camera I use has 10x zoom and autofocus which helps me keep the camera out of my way while still getting nice, tight shots of projects. Everything is routed through OBS, which allows me to stream, capture, or just view the feed. I also love being able to take quick screen grabs and share with friends or on social media platforms to show people what I’m working on. I get way better-looking shots than with my smartphone, and it’s actually faster.

Tools

• Siglent SPD3303X-E triple-channel linear power supply. Nice to have, especially for analog work, but I could easily get by with a much-cheaper single-channel DC/DC model.
• Rigol DM3058E multimeter. Cheap for a bench meter and doesn’t get lost or run out of batteries — plus it has basic data-logging capability and good precision. If I hadn’t been in such a hurry, I would have snagged something used off eBay, though.
• Overhead HD-SDI camera (basically a no-longer-manufacturered generic version of this)
• Modified microphone suspension boom arm to support camera
• BlackMagic HD-SDI capture card for said camera
• Luke Cavagnac acrylic on hardboard painting

Conclusions

This setup works great for me, and I hope if you have similar workflows, you can apply some of what I’ve learned in your own work. Take a step back, look around, and think about the environment around you and how it influences the work you do. Your workspace probably reflects your own natural evolution as an engineer, but there’s no need to wait and leave it up to random happenstance (like I did for the better part of my career).

Instead, spend some time and consciously think about your workspace as a problem unto itself to solve; invest in furniture, equipment, and accessories to better align your space with the work you’re doing and I think you’ll end up with a place you’ll love to live and work in.

The post Here’s how I juggle embedded projects (home office/workspace tour) appeared first on Jay Carlson.

Full disclosure: Padauk sent over a programmer plus two ICEs for me to use in this review, so long as I covered shipping. In hindsight (after seeing my UPS bill that month!), it would have been a lot cheaper to just buy the dev tools myself, so I can’t recommend ordering straight from them if you live in the United States, as they exclusively use UPS. I purchased several different Padauk MCUs from LCSC.com, which is not an official Padauk distributor.

The Padauk microcontrollers — especially the 3-cent PMS150 and newer PMS150C — are all the rage these days. I first heard of the part via a @mikelectricstuf tweet. Dave Jones of the EEVBlog did a brief (for him) video looking at the Padauk stuff, and then a pair of videos using the Padauk ICE and programming an OTP part. SDCC recently got support for the Padauk “pdk14” and “pdk15” architecture, there’s a free open-source programmer, and several blog posts (including a neat comparison of other low-cost parts) and forum threads have hit the Internet.

The parts, of course, date back much further. Padauk was founded in 2005 (and filed patents in 2005 and 2006, describing their Field Programmable Processor Array technology, which we’ll discuss later). I’m not sure the English-speaking world became aware until at least 5 years later: Hector Martin noticed the datasheets for the Padauk parts ripping sections out of the Microchip PIC datasheets way back in 2011, and Kyle Machulis did some early investigating into these parts used in the MyKeepon.

Some of the write-ups have been a little loose on technical details, and few seem to be interested in determining which sorts of applications these parts are suited for — mostly dismissing the parts as novelty items. I wanted to dive a bit deeper into the ecosystem and figure out where you should and shouldn’t use low-cost parts like these, so I’ve spent some time in the last few weeks exploring.

I built a couple cute projects with them — a NeoPixel SPI bridge adapter, as well as a small bike light controller. You can check out my project code on GitHub.

Padauk Ecosystem

The Padauk ecosystem comprises:

• Different microcontrollers ranging from 6 to 26 I/O, with 512 to 4096 words of program memory and 64-256 bytes of RAM — all with the same 16 MHz main oscillator.
• A proprietary, extremely light-weight IDE.
• Various versions of programmers — each capable of programming all the Padauk devices.
• Various versions of two ICEs — one for the single-FPPA parts, and one for the multi-FPPA parts.

Here’s a big table I built that has all the parts, plus some electrical specifications that might help your selection process: ((The groupings and color codes match the official selection guide PDF. Note that the PMS (commercial) line is also available as PMC (industrial). Though their operating ranges differ, they are otherwise identical. ))

Parts in bold-face are parts I evaluated during this review. Specifications in bold-face are best-in-class.

There are a few interesting take-aways:

No comms peripherals. The Padauk microcontrollers have an interrupt controller, at least one timer, sometimes an ADC, comparator, and/or PWM controller, and… well, that’s it. One of the first things I noticed about these parts is all UART, I2C, and SPI communication you’ll need for a project has to be implemented in software.

Multiple “processing-unit” design. Higher-end Padauk parts — like the PMS2xx, PMC2xx, and PGC2x — have two “processing units” in their “FPPA” while the unreleased PGC4xx will be a 4-FPPA design. I put “processing units” in quotes for reasons explained later. It looks like they have had legacy 8-core designs (like the MCS11) that are no longer carried by distributors.

Flash and OTP options. Most modern western-designed MCUs use flash memory for program storage. This is convenient for us developers, but it’s kind of silly when you consider that most embedded devices have no mechanism for firmware updates. Flash memory is expensive and finicky to implement at a process level. Typical low-voltage-programmed flash memory is less immune to damage than the high-voltage OTP-programmed memory (which, itself, is less immune when compared to true mask ROM).

Middling low-power capabilities. Any low-cost 8-bit MCU in 2019 needs to target ultra-low-current battery-powered applications (where other parts can’t compete), but the Padauk series as a whole doesn’t fare well compared to other vendors. Across their entire line, 1 MHz run-mode current consumption varies from 450 – 1700 µA when operating at 5V. Note, however, that the newer parts are actually quite good — the PMS150C uses about 300 µA at 3.3V, which is similar to the exceptionally low-power EFM8SB1 that uses about 270 µA when running at the same speed. Sleep current is below 1 µA with the oscillators stopped, which should be good enough for most battery-operated applications.

Poor battery support. Not only is the current consumption rather high on older parts, but the minimum supply voltage is, too. All microcontrollers should be 1.8V-friendly, but most Padauk MCUs bottom out at 2.2V — only the newer PMS152, PMS154C, and PMS171B are rated for 1.8V operation, and only the PMS154C can run full-speed at 1.8V. Most parts need at least 2.5V for full-speed operation, while some — like the two-FPPA PMS parts, 12-bit PMS parts, and the MTP flash-programmable parts — need 3.5 or even 4V. This means many Padauk-powered gadgets will die long before their batteries do.

Flexible pin-count. Many Padauk parts are simultaneously available in 8-pin, 16-pin, and sometimes 18-20 pin packages. While high-pin-count ARM MCUs are often available in ~80-ball CSPs and much, much larger 100- or 144-pin LQFPs, I haven’t seen many other 8-bit MCUs offered in package sizes with such stark differences in pin count.

Inflexible packages. While most Padauk datasheets advertise SOT, SOP, QFN, and sometimes MSOP, I wasn’t able to find packages other than SOP and SOT available from Padauk distributors (official and unofficial), so I think the QFN and MSOP packages are only available on request. It’d be nice to have widely-available 15-20 I/O chips in a 3×3 or 4×4 QFN. 16-pin SOIC packages are massive, so they rarely make it into my designs.

Architecture

All Padauk MCUs have what appears to be an identical architecture. They use an accumulator-based machine where all instructions — other than jumps, call, ret, and ldtab — are executed in a single cycle. The instruction set is somewhere between a mid-range and enhanced mid-range Microchip PIC16 — it supports indirect loads and stores from an arbitrary memory location, but not with a literal offset or automatic incrementing. Translation for programmers: you can use pointers to dereference memory, but your pointer arithmetic has to be done to the pointer’s memory location first, and using separate instructions that will incur cost. For example, to walk through an array, it will take at a minimum three cycles — two to dereference the pointer, and one to increment the pointer’s value.

Like the PIC16, there’s just a single interrupt vector. Interrupts are automatically disabled before the ISR executes, and re-enabled afterwards. Unlike the PIC16, the stack is located in main RAM, so you don’t have to worry about deep call stacks. The Padauk parts use a 2T architecture where the PIC16 uses a 4T — that means a Padauk part running at 16 MHz (the maximum frequency) will execute a maximum of 8 MIPS (125 ns instruction cycle), which is equivalent to a PIC16 running at 32 MHz.

The instruction set is optimized for traditional low-end 8-bit fare: there are dedicated instructions to set, clear, and compare individual bits in both peripheral and memory locations give you rock-steady timing performance (and efficient ROM usage) when writing bit-bang code. There’s also dedicated instructions to load and store the 16-bit timer value in a RAM location in a single cycle — neat!

Peripherals

There’s only a few peripherals to select from:

• Clock system with 16-MHz and ~70 kHz internal oscillators
• 16-bit timer
• Watchdog timer
• One or two 8-bit timers*
• 11-bit PWM generator*
• VDD/2 LCD bias generator*
• Analog comparator*
• 8 or 12-bit ADC*

* available on some models.

GPIO

GPIO pins are the meat and potatoes of any MCU, and because these Padauk parts have so peripherals, you’ll be using GPIO pins even more than usual.

GPIO input pins have selectable pull-up resistor (nominally 100k at 5V). GPIO input pins have a 2V threshold voltage when running at 5V (and 1.5V when running at 3.3V).((The cheapest logic-level converter I could find is $0.05 each in volume, so yes, it’s cheaper to program a Padauk PMS150C to be a logic-level converter than to just buy a logic level converter)). Leakage current isn’t specified in the datasheet, but from my observations, it’s extremely low — low enough not to affect power consumption in sleep mode in a meaningful way.

In general, GPIO output pins can be configured globally for normal or low drive strength. Normal drive will source 12 mA at 5V and 5 mA at 3V. Low drive will source 3.5 mA at 5V and about 1.5 mA at 3V. Sinking current is 15 mA at 5V and 5 mA at 3V for normal drive strength, and 5 mA at 5V and 2 mA at 3V for low drive strength. Each MCU appears to have a single open-drain pin (PA5 — reset) which can sink almost twice as much current as the other GPIO pins (but obviously can’t drive the pin).

By default, a change-in-value on any GPIO pin will wake up a sleeping Padauk part, but you can disable wake-up on specific pins if you’d like.

Clock System

All Padauk MCUs have a clocking system that supports an external crystal, along with a 16-MHz high-speed internal oscillator and a low-speed internal oscillator. Depending on the part, the nominal value of this oscillator ranges from 24 – 93 kHz. For example, the PMS150C has an IRC frequency of 62 kHz, while the PMS271’s is 24 kHz, and the PFS173 is 93 kHz. ((I can’t, for the life of me, figure out why the IRC frequencies vary chip to chip. There seems to be no rhyme or reason to intentionally do this; I wonder if the designers simply threw in whatever they could fit in the remaining area, spun some samples, and figured out what they had come up with. I know oscillator design can get finicky, so that’s the only explanation I could come up with.)) Padauk seems to be a bit inconsistent with this nomenclature; you can set SYSCLK to a maximum frequency of IHRC/2 (8 MHz). Or, you can set SYSCLK to ILRC — but when you set it to ILRC, it doesn’t run at 63 kHz, as indicated in the datasheet, but rather half that (31.5 kHz). I assume some datasheet ILRC ratings are for the actual ILRC oscillator, and some datasheets rate them for the effective speed the system runs at when sourced from one of these oscillators (which is half).

These oscillators are designed to be extremely low-power and low-cost; Padauk provides no specification for the performance of the oscillators prior to calibration, but I wouldn’t be surprised if it were 10-15% error, or worse. However, once calibrated, the oscillators are good to 1% under constant voltage and temperature (which makes sense if you know anything about RC circuits).

Padauk has an ingenious solution to this problem: their in-circuit programmer will actually measure and calibrate each MCU during the programming process. You just have to insert a macro in your code to trigger this process — something like this:

.ADJUST_IC SYSCLK=IHRC/2, IHRC=16MHz, VDD=3.3V, Bandgap=On; 

16-bit Timer

The 16-bit timer is a simple up-counting, non-reloadable counter. Its clock source selection is independent of the CPU clock, and can also count from one of two GPIO pins. It has a divide-by-1, 4, 16, or 64 prescalar, and an overflow interrupt. The timer’s value can be read and written to from software, and… that’s it.

Watchdog Timer

All Padauk parts have a watchdog timer clocked from the internal low-frequency oscillator.

8-bit Timer

Many (but not all) Padauk parts also have one or two 8-bit timers that have an auto-reload (period) output-compare mode as well as 8- or 6-bit PWM. The 8-bit timer has the same prescalar and input settings as the 16-bit timer, but can also take an input from the optional analog comparator (useful for counting threshold-exceeded events), as well as from a few GPIO input complements (letting you count rising- or falling-edge events). The timer also has a divide-by-1 to 31 integer scalar to give you a bit more control over the period.

You’ll want as much prescalar control as you can get, since, when the timer is in PWM mode, you’ll have a fixed period of 256 (0 to 255) — preventing fine-grained control over frequency. Luckily, this isn’t usually an issue with PWM applications. There’s an interesting Code Option bit that you can flick on to disable the PWM output whenever the comparator output goes high (useful for, say, current-limiting H-bridge motor drivers).

11-bit PWM

Some Padauk parts feature a 3-channel 11-bit “SuLED” PWM generator designed specifically for RGB LED control. Padauk introduces this feature on the 4-cent PMS152. The 8-pin version of this chip has just enough pins to implement an SPI daisy-chained RGB LED controller, so I wouldn’t be surprised if we saw applications like that. This peripheral also has selectable complementary outputs, a /2 to /128 prescalar, and an adjustable period register, too (if you don’t need all 11 bits of resolution).

ADC

There are 8- or 12-bit ADCs available on several Padauk parts. The input mux seems wide enough to allow all — or almost all — pins to function as analog inputs, though I didn’t check every chip and package.

You can choose from an external pin or internal VDD reference, and there’s also a 1.2V band-gap you can measure, but you can only use the bandgap as a reference on 12-bit ADC parts. These higher-end parts also have a 1/4 VDD measurement input which — when coupled with the 1.2V bandgap — makes measuring battery life a breeze (why don’t more microcontrollers have this feature?).

Multiplier

Some Padauk parts have a hardware multiplier. It’s kind of weird — it’s both an instruction set extension, but also a memory-mapped peripheral that must be loaded with data. You load the values you want into it, perform the mul instruction, and get the values out. The compiler has no idea how to use it, so this is all done by you, manually. It’s extremely goofy.

Sleep

The Padauk parts have two low-power instructions — stopexe (wait-for-interrupt, basically) and stopsys (clock-power-down sleep). I love how simple it is to do low-power on these parts; every GPIO input pin is, by default, a wake source, so anytime you’re in a busy loop waiting for something, you can just throw a stopsys instruction in there and you’ll get instant power-savings. Wake-up time is configurable as 32 or 2048 ticks of the oscillator, so as fast as 2 µs. It’s not clear to me why you’d ever configure the system for slow wake-up, as there doesn’t seem to be any advantages, but it’s an option, too.

FPPA — A Multi-Core Microcontroller?

Some of the Padauk parts feature what they call an FPPA — Field Programmable Processor Array. Without ever looking into the details, people incorrectly tout this as a multi-core microcontroller. It’s obviously a cute play on “FPGA” — but it’s also a complete misnomer, as it is neither field-programmable, nor a processor array. You see, not even the flash-based Padauk parts support the self-programming functionality needed for in-field firmware updates, and even more confusingly, this thing doesn’t actually have more than one processor. Instead, this part has what I would call a multi-context processor design.

Multi-what?

While an MCU’s CPU has access to ROM, RAM, and peripherals, it does its work using internal registers. For the Padauk part, these registers store which program memory location the CPU is executing (Program Counter), a pointer to the current stack value (Stack Pointer), the source and destination of arithmetic operations (Accumulator), and the state of the CPU’s operations (Flag Register).((This architecture is sometimes called an accumulator-based machine, and it contrasts with architectures that have many working registers.))

A CPU’s context is simply the current state of all these registers. While this may seem strange to believe, if we copied the context of a CPU at one instant in time, and dumped it back into the CPU later on, the CPU would appear to pick up right where it left off — since it would start executing the same program memory instruction, with the same stack pointer, and the same data in the accumulator. So if we want to preserve the context of an execution cycle, we just need to save these registers.((Incidentally, this is what happens when interrupts execute — the context is saved, the CPU executes the ISR, and then the context is restored.))

Going back to the Padauk’s FPPA feature, each FPP is just a bag of CPU registers — program counter, stack pointer, accumulator, and CPU flag register — that represent the context of the CPU. The CPU takes turns executing each context for one clock cycle before switching to the next.

Why would we want to have multiple CPU contexts?

We usually only think about saving and restoring a CPU’s context when we’re dealing with interrupts, or if we want to run a multi-tasking system that allows us to run multiple functions “simultaneously.” ((of course, we can’t actually run multiple instructions concurrently, because we only have one CPU. However, if we constantly switch between the CPU contexts for two different tasks, it will appear as though they are executing simultaneously.)) Having multiple FPPs lets you switch context quickly — the FPPA feature is basically like a hardware-based time-slicing RTOS.

Let that sink in for a moment, and consider the ramifications: An 8-cent part like the PMS271 lets you build a preemptive multitasking system with a 4 MHz context-switching speed. If that doesn’t sound impressive, consider that most RTOS projects found in the wild are running on 100 MHz ARM Cortex MCUs and don’t have a context-switching (tick) speed much faster than 1 kHz.

Ok, but why would you need or want this capability?

Let’s back up. Recall that none of the Padauk parts have communication peripherals, so if you need SPI, I2C, UART, 1-Wire, or any other communication interface, you’ll have to do it in software. This has some definite advantages: comms peripherals take up valuable silicon and often go unused. It’s hard for IC vendors to figure out what to stuff in MCUs — will customers need an SPI master? Two UARTs? I2C slave support? A separate I2C master and I2C slave? By moving everything to software, you can implement just the comms peripherals you need for your application, without having extra junk laying around.

This raises a problem, though: bit-banging a communication interface is tedious and imprecise. Sure, it’s easy if that’s the only thing your part is doing — but if it’s managing a PID control loop or calculating HSL values to PWM to an RGB LED, it’s going to be hard to get the timing correct for any communication you may need.

This is where the Padauk FPPA comes in handy: you can dedicate an FPP core to, say, a UART transceiver, and it can process incoming UART data and transmit responses back without having to worry about anything else.

Specialized Instructions

While this is certainly better than doing everything on a single core, anyone who has written software-based bit-banged peripherals before knows that getting accurate timing is a headache. Think about the number of instructions it takes to test a bit and jump out of a while() loop once the bit gets set or cleared. Or think about the tediousness of trying to write cycle-accurate delay() loops.

Padauk has a solution. These are the only MCUs I’ve seen that, at a hardware level, support wait and delay CPU instructions. You can delay for up to 256 cycles with a single instruction, and you can also delay until a bit is set (wait1) or cleared (wait0). These instructions remove the latency, unpredictability, and code size bloat you’d encounter when doing conditional loops.

This makes implementing cycle-accurate communication interfaces a cinch.((Note that the neither of these instructions are available on single-FPP devices, and the delay instruction is only available on some of the multi-FPP ones)).

To sweeten the deal even more, Padauk has a code-gen tool built into their IDE that does all the work for you — just tell it you want a UART receiver operating at 9600 baud, or an I2C slave device, and it will generate the code for you.

In many ways, the FPPA approach is actually better than having dedicated hardware peripherals: you can implement the number and type of peripherals you actually need, there’s no unused comms peripherals laying around, and because the peripherals are implemented in software, you can implement arbitrary protocols, or do goofy things that wouldn’t otherwise be easy.

I saw Anders Nielsen’s blog post about driving the WS2812B with a Padauk PMS150C, and was inspired to write a little SPI-to-WS2812B converter using one of these 2-FPP parts — specifically the PMS271. This will make WS2812B LED strips behave like APA102C strips.

Development on the Padauk

In-Circuit Emulator (ICE)

Many people scoffed at the one-time programmability of the Padauk parts (even me), but after using the entire ecosystem for a few days, I totally get it — and I’m starting to wonder why you don’t see more In-Circuit Emulator (ICE) tools anymore, because it makes perfect sense for stuff like this.

For the uninitiated, an ICE is essentially a special-built system that pretends to be your target microcontroller — running code full-speed, with all peripherals available — but also has all the debug circuitry and communication channels necessary to communicate with your host computer.

You wire the ICE into your product where the microcontroller would go. With the large SOIC packages common with Padauk parts, I could imagine soldering breadboard wires to the SOIC pads of my product PCB, and connecting the wires straight into the ICE.

I’m using the plural form because Padauk has different ICEs for different microcontrollers. I tested out both the 3S-I-003 (for multi-FPPA parts), and the 5S-I-S02B (for single-FPPA parts).

The 3S-I-003 is large, with lots of unnecessary LED indicators, and requires a separate 9V wall-wart in addition to the USB connection. It looks like it can simulate parts with up to 5 full GPIO ports (40 I/O total). They have a push-button permanently wired to PA0, and a transistor-controlled LED attached to PA1.

The single-FPPA 5S-I-S02B ICE is much smaller than the multi-FPPA one, and seems to run fine without a 9V power connection. Both ICEs have removable HC49-packaged crystals and nicely-labeled I/O.

Once I started using the ICEs, I realized they didn’t feel much different than using a traditional microcontroller dev board. The Padauk ICEs have high-speed USB interfaces; once connected, they load the program into RAM inside the emulator IC, which keeps download times quick.

And this is when I really started wondering why other low-pin-count vendors don’t provide an ICE. If you’re developing an application with a part that only has a few I/O pins, why would you want to spare even a single one for debugging? Let alone the three or four that many architectures require?

All the sudden, the OTP nature of the Padauk parts became a bit of a non-issue. You sit in front of your computer, ICE in hand, and work through your project. You code, build, test, code, build, test, code build test…. and once you get things where you want them, you pull up the programmer, program your OTP part, solder it to your real board, and see your hard work pay off.

There are a few gotchas when using Padauk ICEs — they don’t perfectly emulate each MCU correctly, so be sure to read the MCU datasheet for notes about using the ICE. One issue I noticed that wasn’t mentioned in the datasheet is the ICE doesn’t appear to emulate the various ILRC frequencies of the Padauk parts — from the table above, these vary from 24 to 93 kHz. For my “bike light” test project, I had all my delays dialed in nicely for my emulator, but when I programmed a PFS173 with the firmware, it was strobing much more quickly. But when I programmed a PMS150C, it behaved identically to the ICE, so I suspect the ICE’s ILRC frequency is around 62 kHz. Another issue with using an ICE is that there’s no way to get power consumption figures. For more complex projects, you may want to use one of the Padauk flash parts, or buy an SOIC ZIF socket to allow you to iterate your code using the actual MCU.

I will say that — like everything else about this ecosystem — everything is optimized for low-cost, high-volume products that have very simple firmware. I could imagine the flash parts would be useful in more complex projects, where you may want to do quite a bit of testing and firmware development in-situ — here, flash memory is a nice thing to have. Just remember that you’ll be giving up PA3, PA5, and PA6 if you want to be able to do in-circuit flash programming of the MTP parts.

Padauk 5S-P-003 Programmer

This Padauk programmer feels like a typical production programmer you’d see at a manufacturer. It’s got a programming socket, a big “PROGRAM” button on it, and a 16×2 character LCD that keeps track of good / no-good count as you program them. You can use the programmer while attached to your computer, controlled with a GUI tool, or you can disconnect it and use the programmer in a stand-alone mode. I found programming speeds to be incredibly fast — less than a second.

Mini C Compiler

Before I actually pulled the trigger on my Padauk order, the scariest part about the ecosystem was the compiler. I definitely had some fun with compilers while working on the the $1 Microcontrollers series, so when I noticed that Padauk’s “Mini C” compiler didn’t support function arguments, return values, for() loops, and many other common C expressions, I became really nervous.

But here’s the thing: when you’re working on a part with no peripherals, 1K of program memory, and 64 bytes of RAM, you’re probably not going to the moon (that would require 70K of program memory and 2K of RAM). And here’s a thought: would you really even want those features? Wouldn’t you prefer an IDE that lets you get to be a bit more specific with what you want the MCU to be doing?

I discovered this while working on my SPI-to-WS2812 converter. When I first need a for() loop, I wrote:

int i = 7; 
while(i >= 0) {
   ...
   i--;
}

This works, but it’s not nearly as cycle-efficient as using one of Padauk’s handy macros:

.FOR i, <7,6,5,4,3,2,1,0>
  ...
.ENDM

When the compiler encounters these macros, it does a source-level replacement of “i” in the content of the block with each value — copying-and-pasting the entire block.

This gives you immense flexibility to hand-tune things. I anticipate most Padauk projects will have ample program memory space for doing this sort of macro expansion, but if you need to pack things in tighter, you can convert your “compile-time” loops to “run-time” loops.

There are many other macros the compiler supports, many of which would be extremely challenging to try to write using traditional preprocessor commands and a “dumb” C compiler. For example, you can delay an arbitrary number of clock cycles like so:

.delay 1100;

The neat thing about this macro is that it will get compiled into different instructions depending on the constant value specified; if the delay value is small, the compiler will simply insert the appropriate number of NOPs (or the CPU’s actual delay instruction, if supported). Once the parameter gets larger, the compiler will create a traditional software loop that counts down the correct delay value. The compiler knows how many cycles each instruction takes, so this generated code is cycle-accurate.

I can hear you exclaiming “on a real microcontroller, you’d just use a timer!” — which is utter nonsense. Timers are only accurate when there’s no CPU involved (PWM generation, output compare toggling, input capture, etc). Timers become inaccurate once you start polling a timer register (which can take plus-or-minus a few cycles depending on things like the CPU’s pipeline or flash memory wait states) or waiting on ISRs (which can have 30 or more clock cycles of latency, and the exactly latency is usually indeterminate). If you want to belch out a really accurate digital waveform, or measure one, this is a great platform for doing that.

Getting Closer to the Metal

Once you get past basic blinking, you’ll quickly realize how limiting the compiler is. Other than the macros — which come in handy — the rest of Mini C is pretty weird and cerebral.

The Mini-C compiler is interesting in that it forces you to understand your architecture and what you can and can’t do on it. You’ll get a compilation error if you try to write a line of code like this:

int b = *(ptr + i);

Why? Because your MCU does not have the ability to do indirect addressing with offsets (constant or otherwise). The compiler wants you to tell it precisely what you want to do. Maybe you want to do this:

ptr += i; // wipes out the old value of ptr, but it's fast
int b = *ptr;

Or maybe this:

int newPtr = ptr + i; // uses a new memory allocation and is slower
int b = *newPtr;

Both of these have trade-offs. The more you develop in Mini-C, the more you’ll start to realize exactly how much performance, code size, and RAM usage you’re used to sacrificing every day, just to make your software a bit briefer to write.

Performance testing

I wanted to put the Padauk PMS150C through its paces with my usual Biquad Filter Test.

When it was all said and done, the part clocked in at 21.73 µs per sample — that’s 46 kHz — which was as good or better than much more expensive parts in my $1 round-up, and perfectly acceptable for many applications.

But it was definitely not easy getting there. The C code I used for those original MCU tests looked something like this:

volatile int16_t in[25];
volatile int16_t out[25];

const int16_t a0 = 16384;
const int16_t a1 = -32768;
const int16_t a2 = 16384;
const int16_t b1 = -25576;
const int16_t b2 = 10508;

int16_t z1, z2;
int16_t outTemp;
int16_t inTemp;

void main()
{
	while(1) {
		_pa = 2;
		for(i=0;i<25;i++)
		{
			inTemp = in[i];
			outTemp = inTemp * a0 + z1;
			z1 = inTemp * a1 + z2 - b1 * outTemp;
			z2 = inTemp * a2 - b2 * outTemp;
			out[i] = outTemp;
		}
		_pa = 0;
	}
}

The Padauk code looks like this:

WORD in[11];
WORD out[11];

WORD z1, z2;

WORD pOut, pIn; // these are pointers, but aren't typed as such

int i;

void	FPPA0 (void)
{
	.ADJUST_IC	SYSCLK=IHRC/2		//	SYSCLK=IHRC/2

	PAC.6 = 1; // make PA6 an output
	while(1) {
		PA.6 = 1;
		pOut = out;
		pIn = in;
		i = 0;
		do {
			*pOut = (*pIn << 14) + z1;
			z1 = -(*pIn << 15) + z2
				+ (*pOut << 14)
				+ (*pOut << 13)
				+ (*pOut << 9)
				+ (*pOut << 8)
				+ (*pOut << 7)
				+ (*pOut << 6)
				+ (*pOut << 5)
				+ (*pOut << 3);

			z2 = (*pIn << 14)
				- (*pOut << 13)
				- (*pOut << 11)
				- (*pOut << 8)
				- (*pOut << 3)
				- (*pOut << 2);

			i++;
			pOut++;
			pIn++;
		} while(i < 11);

		PA.6 = 0;
	}
}

There’s several things going on. First of all, don’t bother including <stdint.h> — it doesn’t exist. You’ll be using “WORD” for 16-bit numbers, “BYTE” for 8-bit ones, “EWORD” for 24-bit, and “DWORD” for 32-bit. I think int is 8 bits (??) on this architecture.

Starting in FPPA0() — the equivalent of main() — you’ll see that, indeed, Padauk has no for() loops. You may think it would make more sense to replace with a while() loop, but there’s a huge gotcha: the Padauk compiler cannot access memory with an offset determined by a variable; in other words, if i is a variable, you cannot access the ith element of myArray by calling myArray[i]. There are two ways of accessing array elements: using the aforementioned .FOR macro, or by walking through it by incrementing a pointer, as shown above.

While a macro .FOR would be faster, I quickly ran out of ROM space, since the entire contents of the function will be duplicated multiple times. I also tried calling the filter code through a function to reduce the ROM requirements, and it was similar in performance.

As for the filter function itself, you’ll see that all the multiplies have been replaced with shift-adds. The Padauk part does not recognize the * operator for multiplication; trying to use it to multiply two variables together results in a syntax error. No, I’m not joking.

Now, on some level, this makes sense since the PMS150C has no hardware multiplier — having said that, this is the kind of stuff you want your compiler to do for you.

And even when you move up to a Padauk part that does have a hardware multiplier, like a PMS132B or PMS134, the compiler still doesn’t recognize the operation.

What about the multiplier?

By the way, for those keeping score, the hardware multiplier helps quite a bit: the PMS134 can process each sample in 14 µs, for a sample rate of 70 kHz. To put that into context, at this point, we’re obtaining about half the math performance of an 8 MHz Microchip megaAVR — pretty impressive for a 7-cent chip ((OK, the PMS134 is closer to 10 cents, but the PMS132B has similar specs — minus a few peripherals — and should be able to hit the same numbers)).

Should you switch to SDCC?

Wouldn’t it be nice if you could use a standards-compliant compiler, like SDCC, to target the Padauk parts? That would solve all these problems, wouldn’t it?

I don’t know — I didn’t try it. Why not? Because I honestly have no idea how you’d develop code on one of these parts with SDCC in a useful fashion. There doesn’t appear to be a way of loading an arbitrary binary into the ICE through the Padauk IDE software, and even if you could, there would be no way of getting the Padauk IDE to set breakpoints and inspect variables unless it knew how memory was mapped back to source code.

To this end, there’s really no good way to iteratively develop code using SDCC — the only way would either be to blow through hundreds of OTP parts or use an expensive MTP (flash) part. Either way, you’d lose all ability to debug, which is critical for tiny parts like this. If you’re a maker/hobbyist used to the printf() route on your AVR, think for a minute how many resources will be consumed with a single call to that function on one of these parts. Also keep in mind you have no UART…

Padauk FPPA IDE

OK, I kind of like ghetto IDEs — one of my favorite underdogs from the $1 Microcontroller series was the Holtek HT-IDE 3000. Padauk’s FPPA IDE makes the Holtek one look like Visual Studio 2019.

This thing is lean, mean, and suuuuuper basic. But it totally gets the job done, and if you hate it, you can go use your favorite text editor instead. Here’s what to expect with it, though:

• 3.9 MB download. The IDE is free, and there’s no registration.
• Half-second build times. The compiler is statically linked as library call instead of a separate executable, and the compilation process itself is trivial.
• 1.3 seconds to launch a debug session. The Padauk ICE communicates using a Cypress high-speed USB 2.0 interface, and it shows. Starting and stopping debugging, setting breakpoints, stepping through code, and inspecting memory felt like I was debugging a PC app locally — not an embedded system.
• Light and Dark themes: Just go to Help > Color to switch. Then ponder the menu location for that feature.
• No code completion. You won’t get a lot of IntelliSense-like features here, but there are plausibly-useful tooltips that appear when you hover over symbols, and you can go to definitions of (some) things, too. A smattering of macros have hard-coded help links to them — anything that’s underlined has instant help available.

Test Projects

In addition to the performance evaluation above, I built two test projects to evaluate what the overall experience is like to develop on these parts.

The source files for these projects are available on GitHub.

NeoPixel SPI adapter

I wanted to try out the dual-FPPA functionality found on the PMC2xx and PMS2xx parts, and since I just got done talking about how great it is for communication, I thought I’d create a NeoPixel SPI adapter built around the PMC251.

The firmware takes a 480 – 510 kHz SPI signal (data and clock only) and outputs it as a WS2812B-compatible pulse train. There is a one-byte (16 µs) latency, which should be fine for most applications.

This part is around 7 or 8 cents, depending on if you get the 8-pin or 14-pin version (either will work for this project).

Because of the flexible logic input thresholds on the Padauk parts, this implementation should work down to 3.0V logic levels or lower, which the WS2812B wouldn’t natively support if you tried driving it directly (for 3.3V interfacing, Adafruit recommends using a 74HCT125 logic-level converter, which is substantially more expensive than this Padauk part).

The biggest problem I ran into was the ~9 µs timeout of the WS2812B. The fastest SPI signal I could reliably receive was about 460 kHz, but this introduced too much delay while waiting for the next byte. I tried increasing the SPI frequency to 500 kHz, but I would start losing bits when I was running the system at the normal 16 MHz frequency of the chip (which is really 8 MHz for the instruction clock, which is really 4 MHz for the instruction clock for each FPP).

I was able to trim some code down to tighten things up, but the real breakthrough was when I remembered I could nudge the system clock up or down with a single line of code, and the Padauk programmer would calibrate this into each part. I raised the clock to 18 MHz, which allowed me to reliably receive SPI traffic up to 510 kHz. This provided a 6 or 7 µs window between transmitted bytes that the NeoPixels seemed to be able to handle.

The dev tools worked well — once I had the code working on the ICE, I popped a fresh PMC251 onto a breakout board, threw it in the programmer, flashed the image, moved it over to my breadboard, and everything just worked.

Bike Light

This is a simple project that uses a tactile push-button switch to toggle on or off a blinking LED, potentially as a bicycle light. While many people might implement this project using a slide switch and a 555 timer, this implementation has substantially fewer BOM lines as well as a much lower BOM cost.

In the GIF above, I’m flashing a single LED, however, the MCU will blink all pins on port A the same — on SOT23-6 devices, you can use up to 3 LEDs, while SO-8 packages will blink up to 5 LEDs.

This project was mostly designed as a practical test of the sleep power modes of the Padauk parts. In sleep mode, the PMS150C sips on just 350 nA when powered from a 3.3V supply. Considering this includes the leakage current from the nternal pull-up on the GPIO input pin used for the push-button, this is pretty impressive. A CR2032 battery could power this thing in sleep mode for 10-15 years — the limiting factor would be the self-discharge of the battery itself.

Closing Thoughts

The Padauk parts are nearly perfect for a set of specific, targeted applications. They should not be considered general-purpose microcontrollers that are drop-in replacements for other more expensive parts, but rather, extremely optimized parts that you reach for when you really want to show off your engineering chops and get BOM cost down to a minimum. Anyone who thinks these parts are terrible doesn’t understand (or at least value) how to design embedded systems properly.

So what are the usage cases to avoid? Basically anything where you need a whole lot of math, a whole lot of comms, or a whole lot of analog.

Because any comms you need will be done in software, it is unlikely you’ll be able to run a receiver at bauds faster than about 500 kbps. But for 100 kHz I2C, transmit-only UART, and slower SPI, I had no problems. In fact, compared to other MCUs, doing everything in software was downright easy, since there’s no peripheral configuration registers to consult in the datasheet.

The compiler is great for efficiently shuffling bits around, but it’s really restrictive for any sort of signal processing duties. It has no math library, so you’ll be writing routines for anything more complicated than addition and subtraction. Still, forcing yourself to use it definitely offers some bare-metal learning outcomes. SDCC support for these is interesting, but without tie-ins with the vendor tools, it’s more of a novelty than a useful tool right now.

If you’re not building large quantities of a product, remember that spending hundreds of dollars on ICEs and programmers will bump up the per-unit cost of development. Hobbyists, hackers, makers, and people working in small shops building one-offs will likely only find these parts amusing — but for engineers designing products in volume, I couldn’t find any reason not to consider these parts for a wide range of simple applications.

The post What’s up with these 3-cent microcontrollers? appeared first on Jay Carlson.

I’ve been very quiet on the internet lately — I bought a new house, I’ve been working on a ton of projects, and I’ve been (happily) swamped teaching in the Electrical & Computer Engineering department at my university this year.

In the fall, I taught an Advanced Embedded Systems special topics elective, and this spring, I taught the Introduction to Embedded Systems course.

I wanted to write up a few notes explaining how I changed our Embedded Systems class this semester to help others interested in Embedded Systems education.

What is Embedded Systems?

When you think about it, Embedded Systems is one of the strangest classes in an Electrical Engineering curriculum. Most classes taught to freshman and sophomores focus on applying analysis techniques to pre-designed systems:

• Calculate the current going through resistor
• Determine the output impedance of the amplifier
• Find the 3dB frequency of the low-pass filter
• Determine if the given system is causal

At the junior/senior level, students are asked to design/evaluate systems.

• Design an operational amplifier circuit that amplifies a microphone with a 4.7 kOhm output impedance by a factor of 100, and provides an output impedance less than 100 ohms.
• Design a buck converter that can supply a 5V 1A load from a 12V input.
• Design an FSK communication system that can operate at 22 Mbps with a BER of 10^-4.

Embedded Systems isn’t well-grounded in fundamental concepts; rather, it often serves as the application of all the above concepts into real-world systems. And it’s not because embedded systems are the end-all/be-all of electrical engineering  — rather, because embedded systems are the simplest real-world examples of these fundamental principles of EE.

Also, while we teach students how to design embedded systems, designing this stuff is more about following the Design Process — not using a formula to select the optimal bias resistor value for an amplifier (which is what most EE students think of when they think of “design”).((In many ways, the Design Process is much more abstract and challenging than typical EE design problems. It’s also much more wishy-washy, which makes many professors uncomfortable teaching it.))

Embedded Systems is messy; messy means memorization.

It is the practical application of fundamental skills where things get messy. That means embedded systems are messy, and Embedded Systems is a messy course. If you think about it, the messier something is, the more that learning outcomes will fall under recall and recognition — rather than analysis and evaluation.

That may seem counterintuitive — shouldn’t messy, complex systems yield (or even require) higher-order Bloom’s stuff? No, quite the opposite.

Think of a microcontroller blinking an LED attached to a GPIO pin. If we used analysis-oriented cognitive processes instead of “lower order” thinking, we couldn’t blink an LED attached to a GPIO without applying  KVL/KCL, Ohm’s Law, and nonlinear models of transistors. We’d have to do this for every transistor in the microcontroller. Otherwise, we would have no idea if it would “work” or not.

Of course, we don’t use bottom-level analysis techniques to blink an LED. Instead, we teach students to memorize that a push/pull GPIO output cell will attempt to drive a pin to VDD or GND depending on the GPIO’s register value. We teach students to memorize that GPIO pins can only supply a certain amount of current, so you can’t drive large loads. We teach students to memorize that if their GPIO pin doesn’t work, they probably forgot to make it an output. We teach students to memorize that each GPIO pin is part of a GPIO port, which is controlled by a single register. We teach students to memorize that some MCUs allow you to read and write individual bits in registers, and some architectures don’t, and some only let you modify bits in some registers, but not others. We teach students to memorize the names of the GPIO registers for their specific MCU, and we teach students to memorize the steps necessary to compile, assemble, program, and debug their software.

All of these are abstractions — which are good. Abstract reasoning is good. But let’s not forget that abstract reasoning relies on a ton of memorization and recall. As soon as you abstract something out of your mental workspace, you have to remember how it works.

Embedded Systems education should use pedagogical approaches that are proven winners when it comes to recall-oriented learning.

Matching the Pedagogy with the Learners

Alright, so we’ve established that any practical Embedded Systems course will be heavily rooted in recall, recognition, understanding, and application. And design/evaluation work in Embedded Systems is generally less concrete than in our circuits classes. We need to take these ideas and form a pedagogy that also links up with our students.

In the Electrical & Computer Engineering department at UNL, Embedded Systems is taught at the Sophomore level. Sophomores are old enough to have good relational reasoning ability, but many are too young to have a fully developed prefrontal cortex necessary for proficient high-order abstract reasoning.

From a course scaffolding perspective, sophomore ECE students have taken a one-hour-a-week C programming course, where they seemed to learn to do little more than malloc() character arrays on a UNIX server and print them. These students have not (nor will ever) take a computer architecture course, and they won’t take a digital logic design class until their junior year.

As an educator, I have to be cognizant of this when planning learning outcomes and pedagogy for the course. Here’s what I came up with:

• Use a reverse classroom approach, with online interactive reading assignments. These are the gold standard for low-order learning tasks in modern education circles. This approach allows us to cover a huge amount of content in a short time, so we can get students caught up on architecture, programming, and digital logic at the same time they’re doing embedded development.
• Use project-based learning for higher-order learning. Having students practice conceptual topics with real hardware is critical to seeing how these topics apply to real-world embedded engineering, and it gives students the opportunity to practice the design process.
• Use regular in-class quizzing as a summative assessment. These quizzes are the primary grade component for the students’ official records.

Online Reading Assignments

I experimented with a traditional lecture format when I taught Advanced Embedded Systems last year, and it was extremely inefficient at handling the learning outcomes of the class.

For my Intro course last semester, I decided to use a reverse classroom. Reverse calssrooms are not where students teach the instructor (though that’s cool too!) — but rather, where students do “classwork” (learning) at home, and “homework” (practicing their learning) in class.

A lot of reverse classrooms have instructors record lectures and post them online for students to watch, and then bring questions to class. Instead, I generally use interactive reading assignments that I create on our university’s LMS.

Before each lecture, students work through the assigned reading and answer the built-in questions. In class, we often review the results of the reading assignment to see which questions students bumped on the most. We go through questions students have about the assignment, and then we spend the remainder of class time reinforcing these topics with peer learning exercises, demonstrations, other group work, and tons of question-and-answer time.

For what it’s worth, certain lectures — especially on electronics circuits — demanded a true lecture-style reading assignment, so I ended up creating a few Khan Academy-style videos.

I really try to avoid introducing new material in lectures — more progressed students fall asleep, and emerging learning struggle to keep up. Instead, the reading assignments provided an amazingly efficient way for students to achieve learning outcomes.

The interactivity is key: Over-confident students who would otherwise brush through a reading — skimming over important details, only to be punished on a homework or quiz — are forced to re-read and think about details they omitted when they are asked questions about the material. By interspersing questions in between content instead of having students fill out separate quizzes, the questions serve as a speed bump that forces students to avoid rushing through material.

Plus, when students are finished with their reading assignment, they get instant feedback on their learning progress. This feedback cycle is critical to learning; many students would bring questions to class that were based on reading assignment questions they missed.

This is the whole goal of a reverse-classroom approach; we get to reinforce and strengthen learning in the classroom, instead of trying to do this outside of the classroom.

Course Roadmap: Top-down, JIT, and Corkscrew Learning

We spent our first week block-diagramming real-world embedded systems — mostly focused on consumer electronics products the students see in their own lives. The reading material presented very high-level explanations of a microcontroller, an IC, a circuit board, the basic peripherals inside the microcontroller, and how these things are generally tied together.

You may be surprised how little material students must learn before they can start making good-quality predictions about how products are designed. Two lectures in, students were block-diagramming ovens, gaming controllers, calculators, and electric drills.

Sure, their ovens had heating elements directly attached to DACs, and their electric drills neglected a forward/backward switch, but I was amazed at the early models students constructed in their brains about embedded systems. They know that buttons are hooked up to GPIO pins. They know that many displays require a display controller to sit on a communications bus, and they know that, as one student said, “I2C is cool because you can put multiple sensors and things on it.” Not bad for the first week of class!

Traditionally, instructors of this course presented material bottom-up, topic-by-topic. First, an introduction to binary. Then, a C programming review. After that, GPIO. Then ADCs. Then timers. Then UART/SPI/I2C. Et cetera.

This is extremely convenient for the instructor — they can work out all the learning outcomes relevant to each topic, and pound them out methodically.

Instead, I’m a big fan of JIT (just-in-time) learning, and what I call the corkscrew approach: circling back around through the same material, over and over again, each time digging deeper and uncovering more details (and exceptions to the rule, in the case of embedded systems).

As an example: I wouldn’t feel comfortable graduating a student from my course without them being able to explain output impedance of a GPIO pin. However, I don’t need them to have mastery of this to turn an LED on or off, or as a pre-requisite for operating a UART. We can cover a “first pass” through GPIO, then move onto other peripherals and, later on in the semester, circle back around to output impedance.

So how do you know when to provide instruction for a topic? We do most everything just-in-time (JIT). By the third week, we hadn’t covered conditional statements or binary operators in C, but we’ve worked through pointers (including a challenging reading assignment problem). Why? Because their first GPIO assignment will require that they can modify memory using C programming. And that’s about all it will require. We didn’t get to output impedance until we discussed PWM, since so many PWM applications students consider involve driving high-power loads.

But JIT doesn’t just describe the order of topics; I use it to provide real-time feedback on reading assignment questions. I will often configure our LMS’s “wrong” answers to provide additional instruction to students who misunderstood a concept. That way, answers aren’t simply “wrong” — there’s a learning component built into the question itself. Students are eager to complete the reading and get immediate feedback on what they have and haven’t mastered. This JIT feedback is so much more powerful than traditional paper-and-pencil formative assessments, where the students may get their quiz back a week or more later, with nothing more than a grade and perhaps the correct answers circled.

Don’t avoid details

One fault I see with some embedded systems curricula is to strive for affective engagement by simply throwing in the towel and converting their classes into something that would belong at a makerspace. They end up with course material that has very little relevance to the actual learning outcomes for the course, and instead focus on things like hobby servo motors, 3D printing, and driving WS2812s with Arduino libraries. This is fun stuff to play with — I encourage my students to take up electronics as a hobby. But this stuff doesn’t belong an embedded systems classroom, where we have so little time to cover such a huge amount of information.

I think a lot of instructors end up equating “top down” with “stay out of the weeds” — that’s simply not true, though (otherwise the word “down” would not appear in “top down”).

Because of all the harsh sentiment expressed about “the dirty low-level details” my initial gut feeling was that students would get excited about the high-level stuff and snooze during the low-level details. However, something quite different ended up happening in the classroom.

In the third week of class, I introduced GPIO (and, really, the concept of memory-mapped peripherals) to my students by typing out the bare op-codes of a “blinky” program in the hex editor programming tool, uploaded the code to an 8051 MCU, and ran it in front of the class. I expected quite a bit of snoozing, but instead, many of them were absolutely enthralled.

I could see that the material clicked in their brains instantly. They finally put the pieces together that we had been talking about: all compilers do is turn C code into these primitive machine instructions, and a GPIO port is just a register sitting in memory space somewhere. They know there’s no such thing as a “set pin high” CPU instruction, since they saw nothing but “MOV” and “JMP” instructions.((Here, the 8051 was super useful — the fully orthogonal instruction set let me write an entire blinky program in something like 5 bytes of code. There’s nothing wrong with doing classroom demos using microcontrollers other than the one found in the lab kit — in fact, it can help strengthen learning.))

When a student came to me later that week, unsure of why her breakpoint was “broken” in the lab she was working on, I reminded her to look at the disassembly view, and she quickly noticed, “oh weird, the compiler didn’t emit any instructions for that line of code. No wonder.” Those sorts of realizations don’t usually happen in the third week of an embedded systems class because instructors are afraid of diving into the deep end.

Learners need a concrete understanding of how these systems work at all levels to feel comfortable and confident. They like the details, and they can even get excited by them — just as long as they’ve been primed to see how these details come together to create amazing outcomes.

Us more experienced folks are better at abstraction; we can comfortably and confidently use systems that we don’t fully understand. We have to fight the urge to teach topics that way.

Project-Based Learning

In addition to reading assignments, there’s a project-based learning (PBL)  component to my course. This is somewhat comparable to traditional “lab assignments” found in other Embedded Systems courses (and I even refer to them as “labs” in class), but they end up serving different goals and function differently in a pedagogical sense.

The old labs for the class were weighted strongly enough that I’d consider them summative assessments: students were expected to show up to lecture, learn how to use their microcontroller by staring at the lecture slides while the instructor went over things, and then demonstrate their achievement by programming the lab, writing a report, and turning it in for credit.

These labs, which used Arduino, were things like:

• Use Serial.print() to experimentally determine the size of various data types.
• Time a GPIO pulse with a logic analyzer or oscilloscope to estimate how many clock cycles it takes to write a value to a port.
• Read a UART character, “encrypt” it using a shift cypher, and send it back to the computer.

I don’t know how other universities handle embedded labs, but I found these to be very bizarre — they have an oddly experimental/investigative tone to them; they seem to view the microcontroller as a black box, whose properties we can discover only through experimentation ((This may seem similar to other classes in an undergraduate EE curriculum, though it’s missing a big point — in those other classes, students calculate what a property should be, and then experimentally verify. It reinforces to students that we can form models of systems that help us predict behavior without having to actually observe the behavior experimentally.))

Students leave the class thinking the only way of seeing how quickly a UART interrupt can work is by trying it and timing it with a scope.

To make matters worse, the labs are often extremely prescriptive (with literal step-by-step instructions that guide the student precisely through every task), yet ask complex questions that aren’t explored in lectures or lab material. Sadly, these questions often represent the kernel of what the lab is about — they’re the stuff the student should leave the class understanding.

For example, in their lab reports for the GPIO lab, students are expected to  explain why wiggling a GPIO pin in a while() loop does not produce a 50% duty cycle. That’s how the question is framed. This requires them to have a high-order understanding of cycle-by-cycle timing of machine instructions without having ever looking at a disassembly of their C source code, or taught about computer architecture.

I’ve never graded those labs, but I’d imagine I’d see very poor-quality answers from the students.

Revising the Lab Kits

When I started thinking about what I would change about the class, one of the first things to go was the Arduino platform it was taught with.

I honestly have no idea why Arduino is used as much as it is in EE / CS embedded education programs, since it has such poor alignment with most learning outcomes for these classes:

• Difficulty accessing dev environment internals: how do I view the assembly code output from Arduino? Or the hex file that will get programmed? Can I control how variables are placed in RAM, or configure the linker or compiler optimization settings in any manner?
• Difficulty accessing hardware internals: there’s no debugger. It’s insane to teach an embedded systems course with a platform that does not allow you to set breakpoints or inspect or modify memory.
• Strange, non-standard C preprocessor secret sauce: “void main()”? Nah. Call functions without declaring them first? Sure. Wait, what headers are included by default? Who knows. Students leave the course thinking that DDRB, Serial.print() and uint16_t are all reserved words in C that you can use anywhere.

My other (more pragmatic) issue with the Arduino platform is the nonstandard tooling. There are tons of MCUs students will encounter professionally. These generally all work the same: you write software in C, and then you compile it, getting some sort of hex file. You use a debugger or a programmer to communicate with the MCU and load the program code into the flash memory of the microcontroller, and then you run it. Most of the time, you have a debugger attached that can set break points, inspect memory, and receive trace data. The Arduino Uno ecosystem is not representative or similar to any other microcontroller ecosystem, so it seems like a bizarre choice.

With the Arduino out, it was time to go MCU shopping. I approached the course as yet another engineering problem: you need to pick the right part for the job.

Microchip PIC16

For the project-based learning component of the course, I selected the PIC16F18446 + MPLAB Snap debugger. This is not a microcontroller I would generally use in my professional work, so why teach this course around the PIC16?

• DIP package allows students to breadboard their MCU to remove any “black box” concerns that come with dev boards
• Simple peripherals
• Extremely easy-to-read datasheet with step-by-step directions to configure peripherals
• Low-cost ($15) debugger
• Free IDE that runs on Windows, macOS, and Linux
• Decent IO viewer in the IDE that allows students to interact with peripherals (and potentially see why their code isn’t working)
• Toolchain supports bitwise operations with fluent syntax (RB5 = 1 sets pin RB5 high, without touching other GPIO pins)
• Peripheral code-gen tools built into the IDE
• Lots of breakpoints (3? 4?) compared to other PIC parts

I looked at literally every MCU I reviewed in the round-up, and I think I made the best decision. Many deal-breakers to consider:

• The Texas Instruments MSP430 LaunchPad FET doesn’t seem to work in macOS. I find the MSP430 datasheets to be far too cerebral, and the clock architecture is a bit too complicated for beginners.
• The Silicon Labs EFM8 ticks off almost all the checkboxes above, but you can’t do any GPIO operations without enabling the Crossbar, which is confusing for students new to memory-mapped I/O. No DIP package either means I’d have to have students solder SOICs onto adapter boards, or use old-stock C8051 parts.
• The clock system and power gating on most Arm parts is way too complicated for students new to MCUs to understand, so that excludes a huge number of parts.
• Other MCUs often don’t have dev environments for macOS or Linux. Any student serious about embedded systems needs to have a Windows computer (for the CAD software alone), but our department doesn’t have specific computer guidelines, and students get mixed messages from other instructors in the department that work outside of the embedded systems field.

For what it’s worth, the PIC16F18446 is not without its problems:

• Programming and debugging speed is atrocious. This isn’t an MPLAB Snap problem — it’s just the PIC16. Students learned to be a bit more methodical when they were developing: measure twice, debug once.
• Peripheral Pin Select is clunky and error-prone for beginners. My students quickly learned of the spectrum between “easy” and “flexible” — while I like that students can route any function to any pin, there are a few gotchas that can be maddening to figure out. For example, when programming the MCU as an SPI master, you have to route the SCK pin as both an output from the MSSP peripheral, and also as an input back into the MSSP peripheral.
• ANSEL is mis-named. Why would you have to modify a register named “Analog Select” if you want to use a GPIO pin as a digital input? Well, because, “ANSEL” doesn’t really mean “enable analog” — it means “disable the digital input buffer.” At least the PIC16 doesn’t use backwards GPIO data direction values like the AVR.
• Weird interrupt syntax. Students struggled to understand why you had to write “__interrupt()” — which looks like a function — as a modifier to their ISR. Students would often declare a function with this name, and end up with bizarre code compilation errors.
• IO View is broken half the time. If you want to inspect peripheral registers in MPLAB X, IO View seems like a good place to do it. Unfortunately, in my experience, its values often get frozen. There’s nothing worse than students not being able to trust their tools.

New Format

In my class, each lab has an experimental component and a PBL component.

Experimental Component

The experimental component is where students learn how to use a peripheral or microcontroller component. As an example, let’s look at the GPIO lab. I didn’t mind the existing idea — time GPIO values with a scope to infer instruction timing — but we reworked the problem to make it a bit more realistic, while adding more thorough analysis built into the lab.

In the real world, you always know how many cycles it takes for an instruction to execute (it’s clearly printed in the datasheet), but it’s relatively common to make oscillator configuration mistakes that cause your MCU to run at a speed different than you think it should be running at.

As a result, I had my students write C code to toggle a GPIO pin, and then look at the disassembly output and step through the instructions with their debugger. They calculated the number of cycles their code should take to execute, and then compared it with the actual execution time to determine the clock frequency of their microcontroller.

By walking them through each component of this in a prescriptive manner, they practiced reading datasheets to look at instruction timing, calculated how many cycles their loop would take to execute, captured experimental data, and fit their calculations to the data.

PBL Component

Additionally, each lab has a project-based learning (PBL) component, which chips away at a semester-long design project.

I’ve seen a wide variety of embedded projects used in instruction — many of which fall into the category of “small toy robots” — and I wanted to find something that felt like a commercial product that a student would go out and buy. I had students program a commercially-available DMX light, pictured above.

I was inspired by watching Big Clive’s teardown of the light fixture. The light fixture lets students program almost all the important peripherals on their MCU:

• GPIO inputs for push-button switches
• I2C for the 4-digit 7-segment display driver
• Timers/PWM for the main LED array
• ADC for the microphone
• UART for the DMX receiver

These light fixtures are very inexpensive — we bought a class set of them from eBay for something like $7 each.

I did a quick respin of the control board design — swapping out the Nuvton N76 with the same PIC16F18446 we used in the lab kit — but kept everything else the same.

It worked really well. Students were given the light fixtures at the beginning of class and they were essentially paperweights, containing a simple demo firmware image that lit each color when you pressed a button. By the end, they were fully-functional DMX lights — complete with extra features and capabilities the students designed and implemented on their own in the last few weeks of class. One of my students uploaded a YouTube video illustrating how these projected turned out.

There was a lot of other learning that was happening undercover; students had to disassemble and reassemble their light fixture whenever they wanted to program the board. They got into the habit of how everything goes together, and what cable plugs into what. They saw that there’s nothing magical inside a plastic enclosure for a product, and they started building confidence — feeling like they were a lot closer to being able to design this stuff than they ever thought before.

Summative Assessment

I do not use projects/labs for summative assessment. Students need the freedom to work with others (and me and my TA) on the projects since a lot of reinforcement happens while they’re working on things. Plus, projects and labs focus on different orders of learning than the reading assignments do, so if you use the labs for summative assessment, you’re testing students over material they have yet to be formatively assessed on, which is unfair to them, and prevents the instructor from providing learning interventions before the assessment.

As a result, it makes more sense to use the PBL component as additional formative assessment in conjunction with the reading assignments — both covering different areas of learning. If you’re shaky on formative versus summative assessment, all you need to know is that formative assessments serve as diagnostic tools that students and instructors can use to evaluate learning along the way. Summative assessment is used to evaluate achievement.

At the end of the day, I have to assign a grade to each student in my class, and I want that grade to ultimately reflect achievement — not effort.

As a result, I designed several small tests that I administered in class roughly every two weeks. These summative assessments had roughly 10 short-answer and multiple-choice questions on them; they were always conceptual in nature, so students with good understanding of the material could complete them in as much time as it took to write out the answers.

Students who couldn’t complete them immediately generally had much worse scores, so there’s not much point in giving students more than 10-15 minutes to finish. Even so, I allow students as much time as they’d like to complete the assessment, just so students don’t feel unfairly treated or rushed.

Wrapping Things Up

It was an eye-opening year teaching both of the Embedded Systems classes, and we’re about a month away from kicking off the fall semester, where I’ll be teaching my Advanced Embedded Systems class again (which, itself, will be completely different than last time around).

Teaching isn’t complicated; it can be approached just like an engineering problem — broken into small pieces and thought out. Once the pedagogy is working, it’s fun to dial things in and optimize your course. As an example, if I teach my Intro class again, I’m going to be thinking about how I can minimize the amount of one-on-one time students had to spend with me in office hours to be able to work through the material; there’s a lot of JIT intervention papers I’ve been reading, and I have tons of ideas floating around.

I’d love to hear what other instructors who teach Embedded Systems do in their classes — there’s far too few published studies on Embedded Systems education, and few instructors block about this stuff. Let’s get the conversation going!

The post How I Teach Embedded Systems appeared first on Jay Carlson.

While Segger tried to build a debug adapter that can be everything to everyone, they made some engineering decisions that are well-intentioned, yet somewhat annoying:

• No 3.3V output to power your target. Even though 99.9% of MCUs you hook up to this thing are going to run off 3.3V, the only voltage output Segger provides is a software-switchable 5V supply (that no vendor IDE allows you to easily enable).
• You must feed the IO voltage level back into VTref. This allows the fancy logic-level converters to operate at the proper voltage for your target — which 99.9% of the time is running off 3.3V.

If you have two wires and a soldering iron, this is easily remedied, though.

We’re going to pop off the high-side switch controlling the 5V supply, and repurpose that pin to carry 3.3V from the internal regulator. We’ll route this to the NC across from VTref so we can bridge it with a standard 0.1″ jumper. Here’s the game plan:

I tried this on my personal EDU version of the J-Link, but this should work great on other J-Link models (which mostly share identical hardware).

Start by prying open your J-Link by targeting the flexures on the side (don’t bother popping off the rubber feet or sticker on the bottom — there’s no screws under there).

Resist your urge to feel angry that you blew lots of money on a microcontroller and some 15-cent level shifters.

After you crack open the J-Link, you’ll notice a 3.3V regulator on the right (supplied from USB VBUS). You’ll notice a transistor in a high-side switch configuration in the top-left next to the screw.

Simply pop off that transistor (we don’t want to inadvertently back-feed the 3.3V regulator with 5V!), and solder a wire from the regulator to the connector:

Next, flip the board over, and connect pin 19 to pin 2:

Put it back together, install a jumper, and use your silliest-looking chicken-scratch handwriting to label your accomplishment:

Once it’s done, you won’t be needing that bench supply anymore — just wire up your debugger to your target and go!

Notes: You can always switch back to an arbitrary VTref by removing the jumper. I didn’t take the time to try to identify the 3.3V regulator, but given its SOT-23 package, I wouldn’t pull more than 100 mA from it without inspecting the package for overheating. If you have an older model with an 1117 regulator on it, you’re good to 800 mA. In any case, use your brain, and remember this hack offers no overload current protection, and if you were to accidentally back-feed this with something other than 3.3V, at best, you’d fry the regulator, and at worst, you’d fry the $3 MCU that turns your $300 debugger into a paperweight.

Happy JTAGing!

The post Make your J-Link less annoying with this two-wire 3.3V power hack appeared first on Jay Carlson.

Background

There are two common mechanisms for debugging code on a bare-metal MCU platform: on-chip debugging, and tracing. On-chip debugging (OCD) is a powerful technology that lets your computer control execution of the core, set breakpoints, and read/write registers, memory and flash data. Tracing is much simpler — messages are printed to the computer that tell the developer where the MCU is, and what it is doing. If you’ve used an Arduino before, you are no doubt familiar with tracing, as it’s your only option for finding problems in your code.

While I end up using OCD with almost everything I work on, tracing is extremely useful when you’re interested in studying how your system is behaving in situ; while you can certainly set a breakpoint, wait for the MCU to hit it, and then inspect the value of variables, this will grind the entire platform to a halt, which could have huge ramifications for any time-critical code.

Tracing is traditionally done through a hardware UART on the MCU; a TTL-level USB-to-serial adapter transfers the data to the computer, which displays it on a terminal. But this requires dedicating an entire (and often the only) UART to this purpose. On a small pin-count MCU, it’d be nice if we could print trace messages using the same interface we debug with.

This is not a new idea; in fact, part of the ARM Cortex-M SWD debugging interface specification is SWO — Single-Wire Output — which can be used to print trace messages while the MCU is running. Lower-end ARM cores also have semihosting, which is a similar (but much slower) mechanism.

This project mimics the SWO/semihosting idea, but my implementation targets the EFM8 and newer C8051F MCUs from Silicon Labs, which uses the Silicon Labs C2 interface for debugging. Having said that, it should be extendable to Microchip/Atmel’s debugWIRE and ICD debuggers as well.

Implementation

The overall method can be summarized as:

• Set aside some XRAM at an agreed-upon location.
• The EFM8 writes trace strings into that XRAM using sprintf().
• The EFM8 writes a final byte to the location which contains the number of bytes to read (called the flag).
• The debugger periodically polls the flag until it is non-zero. When it is, it reads that number of bytes, resets flag to zero, formats the data it read as an ASCII string, and displays it.
• The EFM8 waits for the flag to be reset to zero before repeating this process.

To implement this on the host side, I created a WPF application that calls into the slab8051.dll backend used by Simplicity Studio to communicate with C2 debuggers.

Most of the API calls were originally from the SiUtil.dll file mentioned in AN117, which is a publicly-available DLL designed for users to integrate into their own production software. Unfortunately, the DLL hasn’t been updated in quite some time, and Simplicity Studio uses a newer debugger firmware version than the SiUtil.dll file supports. Every time you use SiUtil.dll to connect to a debugger, it will download the old firmware image to the debugger. Simplicity Studio will automatically upgrade it back to the latest version — and these two programs will continue to fight over the adapter forever.

Instead, I stumbled upon the slab8051.dll interface that Simplicity Studio uses, and used IDA to decompile it to understand how the DLL is called into. By using the same DLL that Simplicity Studio uses, my application plays nicely with any running instances of Simplicity Studio (though obviously, you can’t use the app while there’s a debug session underway, as only one program can connect to the debugger at a time).

Caveats

Polling rate. Right now, the polling delay is hard-coded to 20 ms. Since the target has to be halted whenever the flag is polled, you want to ensure the MCU has plenty of time to do what it needs to do (suggesting a slow polling rate). At the same time, the longer this delay is, the longer it takes when the MCU does want to send a message to the host. A more efficient method would be to use some sort of multi-message buffer, so that the MCU wouldn’t have to be polled as often.

Intrusive connection. The MCU will be restarted whenever the debugger first connects; sorry, this is how the Silicon Labs API works — there’s no way to attach to a running target.

Interrupts Interrupted. Memory can’t be read or written to while the MCU core is running, so the software will halt the core before doing any reads/writes. This will certainly have implications with respect to interrupts/etc.

EFM8 Code

The code on the MCU side is extremely basic, and could be wrapped up into a macro. Here’s the example:

uint8_t xdata printData[255] _at_ 0x000; /* array at xdata 0x000 */

int main (void)
{
  int i, size;
  enter_DefaultMode_from_RESET();

  while (1)
  {
    i = 0;
    while(1) {
      size = sprintf(printData, "Hello, world #%u!\n", i++); // print "Hello, world #0 (etc)
      printData[254] = size; // tell the computer how many bytes to transfer
      while(printData[254] != 0); // wait for the computer software to reset our flag
    }
  }
}

WPF App

I wrote a quick WPF app that demonstrates this functionality, while exposing a few configuration parameters (buffer length, and start address). The source code for the app (along with example firmware) is available on GitHub, along with binaries.

Future Work

Interestingly, while looking through the decompiled DLL, I discovered that it’s actually the DLL’s job — not the debugger itself — to halt the target before reading/writing memory. I’m planning on modifying the DLL to see what happens if I try to read/write data on the MCU without halting it first.

I haven’t investigated debuggers for other 8-bit MCUs like the PIC, AVR, or STM8, but if they have a publicly-available API that allows you to read and write to memory, I’d imagine you’d be able to do the same thing. I have an AVRDragon, PICKit, and ST-Link debugger laying around — I hope I can find some down time to experiment on these other architectures.

This hack is less useful on ARM, since many ARM MCUs have SWO — but there’s definitely still some advantages when dealing with low pin-count devices (since SWO requires a separate pin). Also, I don’t believe SWO is available on the Cortex-M0 MCUs, so I suspect there’s some space there for a mechanism like this.

Try it out and leave a comment!

GitHub Repo

Pre-built Binaries

The post Printf-style EFM8 trace messages using a C2 debugger connection appeared first on Jay Carlson.

In fact, unlike the weirdo architectures used in early MCUs, a 1980s-era 8051 is plenty modern to be programmed by current tools. In this post, we’re going to use completely modern tools (an Eclipse-based IDE running in Windows 10, a recent compiler, a USB programmer) to program a vintage-1980 microcontroller. All we’ll do is make it blink an LED inside a timer interrupt, but there’s enough going on that you should be able to develop some intuition around what has and hasn’t changed in the last 40 years.

First, a bit of a disclaimer: we’ll actually be programming the EPROM version of the 8051, called the 8751. Why? An actual 8051 has no on-board programmable flash memory; we would have to wire in a separate EPROM chip, or order mask-programmed versions from Intel. Unfortunately, the 800-number I found in the datasheet for Intel’s microcontroller division seems to have been disconnected.

Erasing with Light

Note that the 8751 is an EPROM — not an EEPROM —  device. This means that we program it electrically, but we erase it using UV light. There’s a small, sapphire window that exposes the die to light. If you recover these devices in the field, they’ll typically have a piece of tape over the window.

These ceramic / sapphire packages were very expensive, so you’ll only see these chips in boutique applications, or for engineering development and testing.

I found a UV light box specifically designed for erasing EPROM on Amazon. Dial it in for “2” (does that mean “20 minutes”?) — either way, it seems to work fine.

Development Environment

I’ll be using Simplicity Studio from Silicon Labs as an IDE. It’s a modern, Eclipse-based tool that runs well in Windows, Linux, and macOS. Simplicity Studio is used to develop firmware for Silicon Labs’ modern EFM8 and EFM32 MCUs, along with their wireless portfolio.

Since the EFM8 is an 8051-compatible MCU, Simplicity Studio will work perfectly. Simplicity Studio uses Keil C51, the industry-standard 8051 compiler. C51 is a bit archaic in terms of language support — Keil chose to implement C90, and has never gone back to update the compiler to the C99 or C11 standards. If you’re coming from a more modern compiler, such as gcc, you might be in for a bit of a shock the first time you try to declare a variable in a for() loop — and don’t forget that Keil C51 has a ton of reserved words not part of the C spec; if you use them for variable names, you’ll get strange and unhelpful error messages. No biggie — it’s not like anyone has ever declared a variable named “data” or anything like that.

My Keil grievances will have to wait for another day. We’ve got an LED to blink!

Developing the Code

We’ll fire up Simplicity Studio, create a new MCU project, and choose the EFM8BB10F8G. We’ll use this part because it’s the closest thing to a “stock” 8051 that Silicon Labs makes. Because this is a newer part, Silicon Labs offers a Simplicity Configurator file for it, which we’ll go with. This will help save a lot of time during development, since we can let the computer do the thinking for us. I selected an SOIC-16 package, but it’s largely irrelevant; we’ll be blinking an LED hooked up to P1.0, so I couldn’t really care less about which physical pinout Simplicity Studio thinks we’ll be using, as every package should have this pin bonded-out. Be a bit careful with some pins, though, since Simplicity Studio will quietly generate code that disables pins not present on the physical package (to save power).

Simplicity Studio is going to give us some grief for not disabling the watchdog timer, or enabling the crossbar. Little does it know that we’re just leaching off of it to build us a hex file for a 40-year-old MCU we bought off eBay.

Let’s configure Timer 0 to be in Mode 1 (16-bit counter), and start it:

Now let’s head over to the Interrupts peripheral, enable Global Interrupts, Timer 0 Interrupt, and make sure “Generate Interrupt Functions” is enabled:

Once you’re done save the hwconf file by hitting Ctrl-S. This will automatically generate all the initialization code, as well as the interrupt stubs.

Now we actually have to write a bit of code in our Interrupts.c file:

[cpp]
SI_INTERRUPT (TIMER0_ISR, TIMER0_IRQn)
{
P1_B0 = !P1_B0;
TCON_TF0 = false;
}
[/cpp]

A lot of the 8051’s SFRs are bit-addressable, which makes this a breeze. No, there’s no compiler trickery going on — that code is going to get compiled into CPL (complement bit) and CLR (clear bit) instructions.

You may be wondering how we’re using a GPIO pin without making it an output first. Unlike other architectures, the 8051 defaults to a quasi-bidirectional I/O scheme; if we write a 0, the pin will sink as much current as it can; if we write a 1, the pin will float up to VDD, via internal pull-up resistors. And if you want to make a pin an input, write a “1” to it to pull it up, and then read from it as usual. It’s an elegant, ingenious default that I’ve grown to love over the years.

We built the program. It’s 49 bytes long (this includes all the C startup code, timer init code, etc). Gotta love CISC architectures!

Programming the 8051

I bought one of these TL866A MiniPro universal programmers on Amazon. It seems to do the business, and supports a wide range of devices. The official software is Windows-only, but there’s an open-source *nix-friendly command-line utility. I selected the Intel 87C51, and did a Device > Read to ensure the MCU was erased:

Looks good. Let’s program it:

Good to go!

Hooking It Up

Alright, now it’s time to put the MCU on a breadboard and see if it works. Here’s a pinout of the chip:

Few funny things to note:

• Reset (RST) is active high, not active low as it is on modern MCUs. Use a pull-down resistor to ground on the pin.
• No internal power-on-reset circuitry; you’ll need to use a big capacitor — like a 10 uF — hooked between the reset pin and 5V. This will briefly assert the reset signal when the chip is powered on.
• External access enable (EA) must be tied to 5V (i.e., de-asserted) for the MCU to execute code from internal EPROM memory; otherwise, it will attempt to execute code from the external memory bus.
• There’s obviously no sort of internal oscillator on this chip; build a crystal oscillator or ceramic resonator circuit, and attach it to XTAL1 and XTAL2. I used a 6 MHz crystal; much faster, and your blinking LED will give you a seizure.
• Recall that the LED is attached to P1.0 (pin 1) — make sure to wire it in an open-drain (sinking) configuration; i.e., the anode should be wired to 5V, and the cathode should be wired to the MCU pin (through a resistor).

Here’s a video of the results of my breadboarding:

Wrap-Up / Why does this work?

It may seem perplexing that I can take a hex file meant for a modern, 3.3V MCU from 2017 and dump it on a 40-year-old MCU made by a different company — all without altering a single bit or doing any sort of trickery. Did I leave out some steps? Not at all; that’s just the nature of the 8051. We can get away with this because an “8051-compatible” MCU is simply an extension of the original architecture; not a reworking of it. In other words, the EFM8 has the same Timer0 as the original 8051 does; its Timer0 is at the same base address, and has the same configuration registers to configure it to do the same things. The EFM8 has the same GPIO port structure, with the same GPIO registers at the same GPIO addresses.

So if you program the EFM8, are you working with an obsolete dinosaur? Not at all! The EFM8 extends the original 8051 by adding a ton more timers and PWM capabilities, plus more than a dozen channels of 12-bit ADC conversion. Some EFM8s have 12-bit DACs, USB functionality, and can run at up to 72 MHz. Silicon Labs has completely pipelined and optimized the original 8051 core, too, so an EFM8 runs dozens of times faster than an 8051 running off the same clock speed. Oh, and it’s really, really, really low power.

The 8051 is probably the only true cross-manufacturer MCU architecture. Anyone who’s done ARM programming is grimacing right now. You probably thought that ARM Cortex-M programming would be great to learn, since so many manufacturers build ARM Cortex-M microcontrollers. What everyone forgot to tell you is that ARM Cortex-M is just a core; the moment you want to actually do something with that microcontroller, you’ve got to access GPIO, UART, SPI, I2C, Timers, and all sorts of other peripherals — and all of these (alright, almost all of these) are manufacturer-specific. So every time you switch to a different ARM microcontroller, you get to learn an entirely new set of peripherals. This is simply not true with the 8051.

It’s what makes it a great architecture to learn — in 1980, or in 2017.

The post Blinking an LED with an original 1980s Intel 8051 microcontroller appeared first on Jay Carlson.