Scope Part 2 – Let’s Pick a Microcontroller

daniel Oscilloscope, Projects

Picking out a microcontroller is a bit of an arcane art; the requirements are often hazy, the process is full of pitfalls, everyone’s got a different opinion, and it usually feels like the only way to succeed is to have done it before and gotten it to work. This is so much the case that people tend to stick with whatever manufacturer/part family they’ve worked with before – check out the (often very fervent) discussions between the two biggest camps for hobbyists, the Atmel AVR group (if you’ve heard of Arduino, this is a superset of that) and the Microchip PIC group, and that’s now the same manufacturer (Microchip acquired Atmel in 2016)!

I’ve picked out a processor already (yes, you guessed it, it’s something I’ve used before), but let’s walk through some of the considerations here, both for this project in particular as well as any project in general. But first – what is a microcontroller? What’s a microprocessor? What’s the difference?

The “micro” in microprocessor just means small and, as far as I know, it’s an arbitrary designation on some processors and controllers. In fact, while I’ve heard of “just processors” (no micro) like the many parts Intel makes for desktops and laptops, I’ve yet to hear of “just controllers.” From a very high-level point of view, a processor (micro or not) is a chip that will run code – it has several “subblocks” inside of it that help it do it, like a small amount of memory (L1/L2 cache, registers), the Arithmetic Logic Unit (ALU – how the processor “does math”), hook-ups for external memory and other interfaces, and many other things that I’ve since forgotten. A microcontroller is a chip that has a microprocessor inside of it as well as other internal blocks, the nature of which depend on the specific controller (some examples: ADCs, DACs, more internal memory, LCD display controller, analog comparators, …). Having these blocks to hook up to can be quite handy, as we’ll see in our project.

High-Level Considerations

Here’s a list of some common microcontroller specifications to get us started:

  • “Speed” – How “quickly” the internal microprocessor runs – typically measured in instructions per second (or more coarsely by the CPU clock)
  • Internal memory – How much ROM and RAM the microcontroller has internally in its caches as well as for general use – if it has enough of it, we might get away with not having an external memory chip
  • “Modules”/interfaces – Internal ‘components’ the microcontroller has, like ADCs, DACs, etc. or interface hook-ups like supporting Ethernet or USB
  • Architecture – This is a high-level way of describing how the microcontroller is “organized” inside (in terms of how things are connected internally and how time intensive it is to perform certain tasks, like reading a byte from memory). I include “how many bits” are in the processor in here as well, for example, a 32 bit ARM processor vs a 16 bit MIPS processor. This also determines the maximum amount of memory the microcontroller can interface with.
  • Power usage – How much power the chip consumes (this is usually specified under “normal load”, in some sort of “sleep” or “suspended” mode, and under “maximum load”). This is a very important spec. for battery-powered products that want to last as long as possible before needing to be recharged.
  • Footprint – What the chip pinout looks like physically – this affects the layout as well as the solderability (assuming we’re putting the board together ourselves)
  • “Tools” – This list is very important (perhaps the most important consideration if we’re working on a project by ourselves)
    • Programmer – Do we need to buy a programmer that connects to a computer to “write” the code to the chip? How easy is it do so?
    • Utilities – Does the manufacturer provide header files and basic functions for each of the microcontroller “modules” or do we need to write everything ourselves from the datasheet?
    • Evaluation board – Does the manufacturer provide a design (schematic and layout files as well as a board you can sample or buy) that they’ve “blessed” as being good? It can be incredibly useful to have a model to emulate.
    • Websites – Is this chip often used by other hobbyists? Can we find helpful websites with examples and/or forums where we can ask questions if we get stuck with something? This is a very important consideration, especially if we’re planning on doing this project alone (that is, without the help of a friend that’s done this or something very similar with the same microcontroller).

Let’s think about what requirements we need for this project in particular, in the same order as above (if you haven’t read part 1 of the series, consider giving it a quick glance before continuing):

  • Speed – There’s nothing from the design point of view that requires the microcontroller to be extraordinarily “fast” if we implemented the sampling hardware as we discussed in part 1 of the series. That said, we’d still like to processes those samples quickly once we’ve gotten a trigger and send them off to the display to create a “responsive system”, and that’ll require some quick thinking. If our maximum sampling frequency is 50-60 MHz, let’s try to pick something at or above 100 Megainstructions Per Second (MIPS) to keep up with this. This is very much a number that I pulled out of nowhere (there’s nothing magical about “2 instructions per sample”), but consider that we don’t need to optimize for power consumption or anything else that would increase with the speed of our processor (other than cost), since this will just be a bench-top oscilloscope; so let’s see if we can find an affordable 100 MSPS chip to use.
  • Here’s a list of helpful modules:
    • TFT display controller – An internal module that generates the right clock signals for driving the LCD-TFT displays that are common in embedded systems. This is highly preferable to a much slower SPI-based (Serial Peripheral Interface, a very common interface in almost all controllers) display that we’d be forced to use without the built-in display controller.
    • Internal ADC – We’re not going to find very many internal ADCs that can sample at 50+ MSPS (yes, amazingly, some exceptions do exist). Even if the internal ADC is fast and everything we could ever want, we’re not going to find a microcontroller with an “oscilloscope triggering logic block” like what we discussed on part 1. However, an internal ADC (even if it is slow) will be useful for debugging and writing the code while we’re still working on our external sampling hardware. As I alluded to in the project page, we can also use the development board’s internal ADC to debug our oscilloscope design.
    • Internal DAC – It’d be nice to generate some analog signals on the development board that we can then look at with our scope to test it (for those of us who don’t own function generators).
    • Internal memory – This is more of a “wishlist” item, but ideally we have enough memory that we don’t need any external chips (except for the signal samples as we discussed in part 1 and the display memory)
    • Plenty (say, about 40) of IOs that we can break out into header pins for when we make mistakes
    • At least one of each SPI and I2C interface because we’re likely going to need them for something (even if it’s just for an on-board temperature sensor)
  • Architecture – I don’t think we have to be picky on this one. I’ve used (and liked) ARM processors in the past, but I’m happy to try something new, too. And we don’t have to worry about interfacing with large amounts of memory, either.
  • Power usage – We’re not running this off a coin cell battery, so we’re again not super picky; but it’d be nice if it didn’t heat up like bonkers. Let’s try to keep it at or below a Watt.
  • Footprint – Something we can solder without the use of a reflow oven or heat gun – this disqualifies all BGA or QFN packages, for example.
  • Tools
    • Programmer – I want to be able to program this from a computer’s USB port (please no RS-232 port requirement). If I have to buy a programmer, I’d like to spend less than $50 on it.
    • Utilities – I’ve started a project before with just a datasheet and written the assembly code to interface with all the registers. I’d rather not do that directly again, and I don’t think that would be the most instructive use of our time (maybe on another, smaller project). I want good header files and cross-platform support for writing and compiling the code. I’m OK with using a “manufacturer sanctioned” IDE to write the code so long as:
      1. I don’t have to pay for using the IDE
      2. The fact that I’m not paying for the IDE doesn’t restrict me (for example: can only compile projects <32KB in size; yes, I’m looking at you, Keil)
    • Yes, I want an evaluation board, and I plan to use it heavily for developing the initial code as well as debugging my own board.
    • Some amount of support would be nice for this project, but I think not crucial. It’s one of the only things on this list I’d be flexible compromising on.

So what are we going with?

I decided to use ST Micro’s STM32F429 (datasheet) microcontroller. I like the STM32F4 series quite a bit; I used several of these on a project at college where a group of us tried (and failed) to build an electric car. The MCU worked well, though! Here’s what it has going for it, in the same order as above:

  • 180MHz max CPU clock, 225 MIPS. We can get a lot done with this chip!
  • Helpful modules:
    • 1 or 2MB (depending on the exact model) of integrated Flash memory for storing code. Way more than what we need.
    • 256KB internal RAM – probably sufficient. How many variables do we need, anyway?
    • LCD TFT controller and parallel interface (this only comes with the STM32F429 version – the STM32F407 and STM32F427 MCUs are more general chips without the LCD stuff)
    • 3 12-bit, 2.4 MSPS ADCs – not bad at all for a debug tool; we can make two channel scope to debug our real scope.
    • 2 12-bit DACs – excellent
    • A bunch of IOs (how many exactly depends on which model you get, but at least 40 of them, given the smallest package is 100 pins)
    • SPI and I2C
  • 32-bit ARM processor and a good DMA controller to interface to external memory if we need it (we will at least need some SDRAM to store the data for the LCD pixels)
  • At 270mA max current draw, the total maximum power consumption is 3.3V * 0.27m = 0.9W, right about our target. But I don’t think we will hit this maximum number, as we won’t always be working the processor to its fullest.
  • The BGA packages are a no-go, but the LQFP packages are OK to hand-solder
  • Tools
    • The ST-Link programmer is just $20, but even better, the eval board comes with that functionality out of the box (you program it through a simple micro USB connector). And according to people online, we can rewire the eval board to program our own custom board! That’s great news.
    • ST provides extensive header files and examples for this family. For every module (e.g. for the display on the eval board), ST provides example code for interacting with it in one big package called STM32CubeF4. There is a free, open-source IDE called SW4STM32 built on top of Eclipse we can use on Windows or Linux for compiling, linking, and locating the code, and we can program the chip directly from there.
    • The eval board for this MCU is called 32F429-Discovery and it comes with a display and everything! To give you an idea of how relevant this board is our project, check out this video of a homemade scope project running on the eval board itself!
    • This family of processors has a decent following online. As an example, check out STM32F4-discovery. At the very least we will probably be able to get answers to our basic questions.

Curious for more?

Sorry for throwing a bunch of specs and text at your face. In the next few posts you’ll be able to see the microcontroller in action (I’ll walk you through how I set up my computer to program it and quite a few examples with it) and hopefully that’ll justify the choice far better than the wall of text above. It should also be a little more exciting.

However, if you somehow really enjoyed this and are interested in reading more on this subject, check out this excellent comparison of sub-dollar processors. If you’d like to dig more into the specifications above and what they mean in terms of how the processor works internally, consider going through this free book/online course on computer architecture and ARM assembly programming on Raspberry Pi. Finally, if you’ve really got a lot of time, you might want to read Michael Slater’s excellent (if slightly outdated as it is a “classic”) textbook Microprocessor-Based Design (to the best of my knowledge that is not an affiliate link, I recommend you get the cheapest used version you can!).