Where to Start

You’ve got to start somewhere. I spent years on the periphery, reading magazine articles and obsessing about recording equipment before I had the realization that I wanted to learn how to design it myself. I’d been to school a couple times before, so I went with what I knew.

School?

Call it old school, but I went to school (it was old; Thomas Jefferson started it) to study electrical engineering. To me, there is no complete substitute for serious education when it comes to a difficult technical subject, like electronics. While there are many exceptions, people I’ve worked with in the field, without a rigorous academic degree, often have gaps in their knowledge stemming from the fact that they haven’t been exposed to the underlying theoretical bases. For example, it’s one thing to understand that adjusting a capacitor’s value will adjust a filter’s frequency and another to anticipate the effect of coupling between parallel traces on a PCB caused by unwanted capacitance. Applied Electromagnetics is not an easy subject. There’s just no way I would’ve learned it on my own. Most people who don’t go the school route will probably never learn it either and they’ll lack a fundamental building block of electronics knowledge. What they’ll be lacking is a piece of the problem solving repertoire required to work quickly and effectively. There are many other similar subjects. That said, I have met truly exceptional engineers who have never attended a day of formal engineering education. What these people seem to have possessed was both an undying commitment to learning the art and the benefit of a strong mentor.

Many people just don’t have the opportunity to attend a traditional engineering school, and for them, we are at the dawn of a new day. Massive Open Online Courses (MOOCs) are just getting started. You can take an MIT introductory electronics class for free. You can also take a large number of programming classes from a number of MOOC providers. However, to get the most out of it, you’ve really got to apply yourself. You don’t get the benefit of being motivated by an interested professor or by the need to get the most out of your education dollar. If you’re going to go this route, you’ll need to be your own taskmaster to make sure that you truly learn the subject.

Books?

Even if you were able to get a formal engineering education, you’ll always need books to learn new things. I’m working, albeit slowly, to make some of the things that I learn available for free. But, the serious engineering masters seem to broadly require a fee for their knowledge, the price of their book. You can’t blame them for monetizing their knowledge, but it confines the best engineering writing to textbooks. You can scour the web and find tidbits, like mine with examples that show you how to build something, but some of it isn’t written very well (sorry) and a lot of it is just copying an implementation. With the latter, you’ll never understand how it really works, only how to build this example. You can copy it, but what happens when you incorporate it into a larger system and the behavior changes? The best method is to start from the basics and build on them. Old-fashioned books are still the best source of complete information on electronics design from the ground up. By far, my favorite book of all time on the subject of fundamentals of electronics is The Art of Electronics. It’s got all the basics covered and it’s written in a more prosaic, less jargon and math focused way that is rewarding for the rookie reader. It’s pretty old though and won’t help you with embedded systems development. For embedded programming, I got some miles out of Michael Barr’s book Programming Embedded Systems. There are many books about embedded hardware development, but most of what I know on this subject, I learned by doing.

Hands-On

I was able to build solid knowledge foundations in school, but I feel like most of what I really deeply learned came from working, building, and doing. The good news is that the maker movement has produced a wide array of hands-on starter kits and tools. If you don’t know Arduino, you should. It is by far the easiest way to get started with embedded electronics and with the wide availability of shields, hardware extensions, it’s a great way to learn. It’s also a convenient medium for quick development, even used by “serious” professionals to make prototypes. Last year, the Raspberry Pi came out featuring some serious embedded hardware.  If you’re more interested in higher-level embedded software development, particularly with Linux, it could be the way to go. There are quite a few of these pre-built embedded foundation systems available and more and more all the time. There seems to be an emerging hardware battle for systems built around ARM microcontrollers. It’s a good time to be a nerd.

On the hardware side, there are many vendors of quality introductory electronics kits. Most people know about Adafruit and Sparkfun, both of whom sell quality novice electronics kits. Find a kit that does something that interests you. Build it. Then, understand how it works. Modify it. Make it do something else. Make it work better. 

Smart People

Beginning in electronics can be scary, but there’s no better antidote to that than knowledge. I catch myself, when speaking to someone who wants me to work on something I haven’t yet and don’t understand, with a moment of internal panic. I have to reassure myself that, with enough effort, this too I can learn. There’s no shame in the answer, “I don’t know.” In fact, it’s often the best response because it presents a learning opportunity. Finding smart people with the answers is a great thing, particularly if they’re willing to share them. I often find that nerds are so happy to find someone interested in what they do, they’ll gladly spend some time to teach it to you.

Go Forth

Building and making is a profoundly human endeavor. It satisfies our desire to create. No matter which way you decide to go about it, it’s important just to start. Without taking that first step, you’ll never understand it. If you need encouragement, just let me know…

There are a number of problems with this standard approach. One, this is a heavily manual design process. Assuring the accuracy of the timing throughout the development process, as new features are added, can become a headache. Two, some processor time is guaranteed to be wasted. Not all tasks take the same amount of time to run; some less, some more. When short tasks are handled, the processor will be idle for potentially useful periods of time. If a task grows to the point that it can no longer be safely completed within the time between samples, i.e. the sample period, the timing of the audio generation may be compromised. Neither problem is desirable. As they say, there must be a better way. And there is. It called an RTOS.

What is an RTOS?

An RTOS is a Real-Time Operating System. It’s “Real-Time” because it’s primary concern is that events happen when they should, not in clock cycle, microprocessor-time terms, but in Real Time. Instead of manually managing the task timing, the RTOS handles running the tasks at a designated time and frequency. Tasks in an RTOS environment can be assigned priorities, ensuring that higher priority tasks have bulletproof timing. Any task of higher priority can preempt any lower priority task. Once the higher priority task runs, the system returns to the lower priority task.

For a synthesizer, this works great. Inputs can be checked and processed and the interface generated with relative freedom while still guaranteeing that the audio stream is extremely consistent and artifact free.

Let’s look at what makes up an RTOS a little closer. I’m familiar with FreeRTOS, which is what I’ve been using on my latest projects. As it’s name suggests, it’s free. There are many others. FreeRTOS just happened to be the one that worked well for me. So, my examples will be based on what I’ve developed using FreeRTOS. If you’d like to use my FreeRTOS files, you can download them at the bottom of the page.

Tasks

There’s quite a bit going on behind the scenes with an RTOS, but, you don’t have to pay too much attention to the man behind the curtain. You also don’t have to deeply modify code to convert it to run in an RTOS environment. You do have to write it in an RTOS specific way, and that is to divide it into tasks and register them with the RTOS. Software is traditionally divided into tasks anyway, so the transition is fairly easy. Let’s take an example.

Suppose we need to blink an LED at a constant rate. If this task were written in standard C, in an oversimplified fashion, the function might look something like this:

void LEDBlinkTask(void)
{
  static uint8_t u8ledIO;

  /*Toggle the I/O pin*/
  u8ledIO ^= 0x01;
}

This function would be called in an endless loop with some timing associated. In the simplest situation, the microcontroller wouldn’t have anything else to do during the time in between toggling the LED and a timer would be used to stall the processor until the correct time arrives.

while(1)
{
  wait(1);//wait one second
  LEDBlinkTask();
}

That’s pretty simple and it’s not much more complicated to configure a timer with an interrupt that sets a flag whenever necessary to avoid the problem of idling the processor. The timing would suffer a little if the processor was still busy with other tasks too long after a flag was set, but it could suffice, particularly in this situation.

while(1)
{
  if(u8LEDBlinkFlag == TRUE)
  {
    LEDBlinkTask();
    u8LEDBlinkFlag = FALSE;
  }

  //do other stuff...
}

This method is fairly common, particularly in applications where the timing is not critical. And even if it were, the required code could be run inside an interrupt handler directly. The timing of that function would be pretty accurate, although the length of time to enter an interrupt does vary. An RTOS offers a simple solution to this problem. Let’s examine what an RTOS version of the LED blink code would look like.

void vTaskBlinky(void *pvParameters)
{
   while(1)
   {
     LEDBlinkTask();
     vTaskDelay(1000);//time to delay in milliseconds
   }
}

It looks suspiciously similar to the while loop because it’s just as simple, yet it’s vastly superior. With this simple routine, the RTOS inserts this routine into the schedule with the specified delay and goes about it’s business running other things. Note how the code is contained inside an endless loop inside the task. In an RTOS environment, all the tasks contain infinite loops. Also, note that the delay is specified in millisecond increments. These increments are called ticks, or time slices, whose length is specified rather simply in a configuration file. A useful length of time in a synthesizer is the sample rate, which gets to the point of having accurate audio output timing. A tick rate of the length of the time between audio samples synchronizes the process, but we also have to be certain that the synthesis routine runs predictably at exactly that time. The mechanism for certainty is priority.

Priority

Each task in an RTOS system is given a priority. Any task with a higher priority preempts any task of a lower priority. The priority is assigned when the task is registered with the system. It can also be changed later and there are advanced mechanisms which allow a tasks priority to temporarily change. A little more about that later, but for now lets look at how a task’s priority is set, at least in FreeRTOS.

xTaskCreate(
  vTaskBlinky,/*Function Name*/
  (const signed char *)"LED Handler",/*Handle*/
  70,/*Stack Depth*/
  NULL,/*Task Parameter*/
  3,/*Priority*/
  NULL/*Task Handle*/
);

There are a few parameters being passed to the xTaskCreate function that I haven’t mentioned, and won’t dig into, as they access more advanced RTOS features, but there you can see the priority being set. In FreeRTOS, a lower number equates to higher priority. This task has a priority of 3 and this system has a maximum priority of 5, a variable set in the configuration file. So this task preempts tasks of priority 4 and 5 when it needs to run and can be preempted by tasks of 0,1, and 2 priority when they need to run. When this task or any other is preempted, the RTOS saves the task’s state, stops processing it, moves to the higher priority task, and later will return to this task at exactly the point it left off.

One important fact to note is that priority zero is reserved for the idle task. The idle task is run whenever no other task needs to be run. Although we’re trying to avoid idle time with the RTOS, the idle task must run occasionally to clean up memory usage. You can, although it’s not wise, assign a task to priority 0 along with the idle task. It just can’t be a total processor hog, not allowing the Idle Task to get it’s job done.

Complications

If you’re a sharp embedded thinker, you may see that not everything is totally rosy in RTOSland. Despite the serious benefits of an RTOS, there are some complications. You could imagine a situation where a task of lower priority is preempted by a task of higher priority right in the middle of calculating some critical value. Then, not knowing any better, the higher priority task may try to access the result of the lower priority task’s operation before it’s actually calculated. This is a problem of data integrity which could compromise the entire system. Fear not though, the good RTOS people have foreseen this problem and have provided a solution.

Mutexes

A mutex, short for mutual exclusion, allows the lower priority task to block the higher task’s access to the critical data until it has finished its calculation. Typically, the mutex conveys a mechanism of priority inheritance, wherein the lower priority task inherits the higher priority tasks priority level until the mutex is released by the formerly lower priority task. Basically, a mutex can only be “held” by one task at a time. The lower priority task “takes” the mutex preventing anyone else from taking it. When the lower priority task is finished with the data, it “gives” the mutex, thereby allowing the mutex to be taken by another task.

The implementation of this type of data control can be one of the more difficult aspects of dealing with an RTOS for a novice. In one instance, I had a task which updated LEDs based on a menu system. The LEDs were connected to shift registers via a SPI bus. The LED task was low priority because I didn’t need to update the LEDs all that often and when I did, it wasn’t critical that it happened in nanoseconds. The SPI task is high priority because it’s transmitting in the MHz frequency range and I couldn’t allow for pauses or interruptions in the transmission. So, the LED task was writing variables indicating LED state which the SPI task would send to the shift registers. Unfortunately, the SPI task occasionally picked up a value which was an intermediate number in a calculation. This was visible on the LEDs with occasional short flickers. So, I created a mutex which prevented this corruption and all was well.

More Features

Queues

There a number of other critical features of RTOSes which make them worth using. We already discussed how events could be scheduled to run based on time, but they can also be scheduled based on the availability of some data or input. Microcontrollers can spend a lot of time just checking if some event has occurred or if some data has been received. With an RTOS, much like waiting for a time, the microcontroller can freeze a task until some input or data needs a response. The device for implementing this feature in an RTOS is called a queue. A queue is a bank of memory which can be filled and emptied by tasks. One task or interrupt can send information to another task. This allows for communication between tasks and allows the tasks to use data when it’s appropriate.

Semaphores

A semaphore is a feature which allows tasks to be synchronized. It is taken and given like a mutex, but does not involve protecting data. One task can inform another that it’s time to run and vice versa, a task can wait to run until another has. I have used this feature in a number of ways, but a good example is how I synchronize my sequencer. If I have eight tracks, I’ll have eight semaphores and one synchronization routine. The central routine notifies each track that its time to start back at the beginning. Here’s what the code for the synchronization routine looks like:

for(;;)
{
  if(++u8sixteenthNoteCount == NUMBER_OF_SIXTEENTH_NOTES_PER_LOOP)
  {
    u8sixteenthNoteCount = 0;
    u8currentStep = 0;
    xSemaphoreGive(xSemaphoreTrack1Sync);
    xSemaphoreGive(xSemaphoreTrack2Sync);
    xSemaphoreGive(xSemaphoreTrack3Sync);
    xSemaphoreGive(xSemaphoreTrack4Sync);
    xSemaphoreGive(xSemaphoreTrack5Sync);
    xSemaphoreGive(xSemaphoreTrack6Sync);
    xSemaphoreGive(xSemaphoreTrack7Sync);
    xSemaphoreGive(xSemaphoreTrack8Sync);
  }

  vTaskDelay(TICKS_PER_SIXTEENTH_NOTE);
}

Pretty simple, n’est-ce pas? The synchronization routine is the highest priority and the tracking routines are below it, a necessary arrangement because they may need to interrupt one of the tracking routines to inform it that it’s time to begin again. Here’s a puzzle for you: Imagine what happens if a high priority task is waiting for a semaphore from a lower priority task. I’ll leave you to think about that one.

Summing it up

An RTOS is a truly great way to organize code, particularly in situations where timing is of the essence. There are many places to learn more and many RTOSes to use. As with anything in electronics, the best way to learn is to start doing. So get going!

Here is a package of files that I’ve successfully used with STM32 microcontrollers:

FreeRTOS

STM32 ARM Processor

A wise grizzled old engineer once told me that the most important rule of embedded engineering is, “Always use quality tools.” Without quality tools that you can 100% trust, you’ll never be certain of the source of a problem. You’ll constantly be asking yourself, “Is it me or is it the tools?” I’ve validated this engineer’s axiom multiple times, staring for glacial epochs staring at code which should work but doesn’t. I once spent a solid month tweaking and tweaking simple code only to find in the end that a manufacturer’s compiler was incapable of executing logical shifts correctly. I’ve vowed in the past never to suffer again and I reinforced my opinion during this microcontroller selection process. That’s a later part of this story. First, let’s look at how I started this selection process.

The Contenders: Atmel vs. ST

In choosing a microcontroller for the synth cube project, I basically looked at the two companies I know the best, Atmel and ST Microelectronics. I struggled with the decision at first, but now that I’m down the road, I’m not looking back. They’re both fine manufacturers and, for different projects or different people, I might recommend one over the other at different times. For this project and probably for here on out for me, only one micro could reign supreme.

Atmel AVR: The Good and The Bad

I’ve been intimate with Atmel for many years through the AVR line of micros. I used the 8-bit ATMEGA micros for my first synthesizers and I played with the 32-bit AVR32 micros for the Illmatic sequencer. You can read about my selection of the ATMEGA for Rockit here. I’ve built a solid relationship with AVR micros and they’re a great choice for many reasons.

Atmel studio = Open Source Happiness

Atmel is an appealing solution for the open source enthusiast. The GCC compiler integrates seamlessly with Atmel Studio with one click compilation and programming. Atmel Studio, since version 5, now 6, is hands down the best microcontroller development environment I’ve ever used. It’s available for the right price, free, and is based on Microsoft Visual Studio, which is rightfully awesome tool. My favorite feature is never having to remeber variable or function names. You just start typing and it offers suggestions. It sounds simple, but it speeds up the process so much that you’ll miss those little suggestions dearly when you have to live without them. Atmel also provides, like most manufacturers, a very nice standard library and sample projects that greatly accelerate the startup process. With Atmel Studio, you can go from nothing to running in hours without having to dwell on the intricacies of compilers, linker scripts, startup code or any other embedded matters that are generally toxic to quick development.

Price

AVR micros provide an excellent low cost entry point for the hobbyist and have proven popular particularly because of their use in Arduino boards. However, the case for AVR becomes decidedly less rosy as you move from hobbyist to certified maker. Where AVR isn’t competitive, at least in sub-100,000 unit volume, is cost. AVR micros are expensive relative to competitive chips from ST and Atmel offers no decent price break for volume in my production range. For instance, an AVR32 chip, the AT32UC3A1128 is $6.34 on Digikey with no break on price above 100 pieces. An STM32F103CB, a comparable micro, is $4.99 at 100 pieces and the price falls to $3.51 at 2,000 pieces with likely breaks for volumes above that. For a small manufacturer of a niche product, this presents a serious problem. Using Atmel micros will add several dollars to the price of my product or reduce my profit by that amount should the market not bear my higher price. For a small manufacturer, profit really means what buys food and shelter. This is pretty much a dealbreaker. No matter what other advantages there are, cost is king.

STM32

As I mentioned, ST is the price leader. Not just for 32-bit micros, but down the line to the 8-bit STM8 as well. I’ve used STM8 micros for years. They’re in the millions of battery chargers and power supplies that I’ve designed. Pricing on STM8 micros borders on ridiculous with pricing for totally useful chips in the low tens of pennies range. No other manufacturer comes anywhere close. Believe me, I’ve looked.

Development

For the STM8, ST does provide a development environment, ST Visual Develop, but it’s nowhere near the quality of Atmel Studio. And they don’t make a compiler, leaving you at the mercy of third party vendors. They’ll get you hooked with a free compiler for small code sizes, but start charging you for an unlimited version. For the STM32, they don’t offer any IDE at all and leave you to find your own way. This is by far the greatest problem with using an STM32 microcontroller. For a rookie, this challenge may very well be unsurmountable. The initial learning curve of embedded development is a steep one. Without some serious cash, you’ll be at the mercy of the internet to figure out how to get started. If you’re well-funded, you can buy a Keil IDE and compiler for many thousands of dollars. It will work beautifully, just like Atmel Studio, probably even better, but few of us have thousands of dollars to relish on our hobbies. So, what’s a broke electronics nerd to do?

Eclipse

Fortunately, some pioneering and enterprising individuals have developed a way for the poor embedded masses to access powerful chips on the cheap. Eclipse is an open source development environment that can be used for a huge variety of projects, from Java x86 GUIs to lowly microcontrollers. Being open source, developers can make plug-ins and drivers to make Eclipse speak the right language to compile, program, and debug STM32, and any other ARM-based microcontroller as well. The open source nature has a side effect though.  Not being developed by a single cash-loving entity, it’s a piecemeal approach. You’ll have to get the compiler from over here, find a linker script there, figure out the startup code, dabble with a library, and on and on. What was a small investment of a few hours to get Atmel Studio running can stretch to days or weeks with an open source approach to STM32. You’ll learn a lot in the process if you get to the end, but you may just give up before you get there. There are a number of tutorials on the web, but I found them to be lacking and sometimes conflicting. So, after a week of struggling with the fully open source approach, I started looking for alternatives.

Low Cost IDE

Some enterprising companies have noticed the gulf between basic open source Eclipse and Keil, and offer some intriguing alternatives, which work well and won’t end your marriage when the credit card bill arrives.

Mikroelectronika is a popular and cost-reasonable option. At $249 for the compiler, IDE, and some libraries, it can be money well spent. The libaries provide easy-to-use functions for handling most basic tasks. The problem for me is that these libraries are proprietary and not internally debuggable. And, MikroC is their internally developed compiler, which makes it unique and less likely to be interactive with open source libraries designed to work with GCC.

For these reasons, I chose to go with Code Bench from Mentor Graphics. Code Bench also comes with optimized run-time libraries which reduce code size, particulary for some of the more space hungry functions, like malloc(). I also wanted to learn more about using an RTOS, preferably an open source free one, and those are much more likely to be designed to work with GCC. Code Bench costs a little bit more, $399, but it just better met my needs, so I didn’t mind the extra cost.

STM32 IT IS

So far, developing with Code Bench and STM32 has been a lot of fun, especially since I ported over FreeRTOS. I’ll be back with a post about FreeRTOS and getting it running with STM32. If you’ve got the patience and the will, learning to develop with STM32 can be a worthwhile endeavor, particularly if you’re interested in developing a product that you intend to sell. The cost alone makes the effort worthwhile and just think how big your brains will be after all that learning! I’m doing neck exercises just to support all this new information.

I’ve been learning quite a bit about working with ARM processors and open source tools for developing with them. Stay tuned for some technical posts about what I’ve found.

• 8×8/16 step sequencer
• Accelerometer interface (tilt and shake)
• General MIDI synth engine
• Really solid polyphony with drum parts and synth lines together
• Delay effect
• USB-MIDI and DIN MIDI
• USB Bootloader
• Computer programming interface

That’s a bit of it. It’s ideally going to be the first in a series of interconnectable cubes. We’ve got plans for a whole bunch and they’ll all work together. It’s going to be great for noodling, writing, and really fun for performing. I’m working with some clever guys and I’m really hopeful that it’s gonna be fun to use and a really innovative design.

Isn’t it awesome! I’m trying to have production cases ready for next weekend’s Experimental Garage Sale. I hope to see you there!

All set up at maker faire. Come on down and make some racket with Rockit and Sprockit!

makerfaireposter