The Bare Metal MCU for Great Synthesis Thread

I’ve seen a few people talking about this around here (most recently @diswest and @moving_particles) and it’s been the target of my obsession for the last month or so, so I thought I start up a thread!

Note: “MCU” and “bare metal” can mean a lot of things, but for the sake of this topic can be read as “stand alone microcontroller that is not raspberry pi”. Nothing against pis, they are great machines. But I think it’s worth distinguishing code that talks to registers from code that talks to linux. Let’s keep the conversation focused on the former.

Edit: if you landed here to talk about the Marvel Cinematic Universe, I’m really sorry about how disappointed you’re going to be.

5 Likes

Marvel comics universe? I ask in all seriousness (ignorant sorry).

2 Likes

I’m guessing machine coding ……

1 Like

So I’ve been focusing mostly on ARM stuff, namely the Daisy Seed (STM32H7) and Teensy 4.1 (Freescale RT1060). Also playing around with a STM32F4 nucleo board when I need to keep things simple.

Having the integrated codec on the Daisy lets me plug it directly onto the Erica Labor’s breadboard and get prototyping right away, which is pretty cool. I’ve also seen a lot of people prototyping with the kits from Synthux Academy. Lots of really interesting stuff happening in this space right now!

A great blog series (and video from ADC22) is Jack Campbell’s Anatomy of a Bare Metal Synth.

Another project that helped me a lot comming to grips with the STM32 was Sergey Lyubka’s Bare Metal Programming Guide.

4 Likes

Heh, yeah. “MCU” is the standard abbreviation for “microcontroller” (microcontroller unit, I suppose). Marvel has really screwed up the search terms for that.

My programming language of choice in most things is still swift. And searching without a -taylor is more or less futile. I miss when the internet was just geeks, and didn’t have all these nerds about :wink:

6 Likes

Great thread idea!

It’d be totally new development wise to me so I’m all ears/eyes on this.

I’m quite a beginner in embedded development in general, and in audio/midi programming in particular. However, currently this is my active hobby, so I’ll be glad to share experience, knowledge and links.

First, let me correct the terminology a little, if you don’t mind.
The most common meaning of “Bare metal” development is when your software works with hardware registers directly without any libraries like STM32 HAL or Arduino or operational systems like Linux or FreeRTOS. Technically, you can program Raspberry PI in bare metal manner.

This is important because when you’ll search for any books, articles and courses you will mostly meet this particular meaning of “bare metal”.


Back to topic.
There are tons of things to discuss.
For the beginning, I’d like to share what I recently found about various DSP chips.

Source: https://www.thegearpage.net/board/index.php?threads/sharc-vs.2405852/page-3#post-35733418

I worked at Analog Devices during the development of all the various DSP technologies and when it became practical to use DSP for pro audio applications (1986 to 2005).

Most early DSP chips were 16 bit fixed point math. It was fine for voice band and communication stuff, but not for audio. TI and ADI were early into the market. Teddy Ruxpin was the first consumer product to use DSP (TMS320-C10).

Motorola came out with the 5600 series processors, and they were 24 bit fixed point. They were the first DSP chips to be broadly adopted for audio applications.

A new generation of 32 bit floating point processors came out with TI (TMS320-C30) and ADI (ADSP-21000). When the ADSP-21000 was integrated with memory, it was branded SHARC. My boss at the time named it as a complete joke, but the name turned out to be great branding.

Harvard Architecture means that one can take 2 numbers, perform a multiply/accumulate, and then put them back in memory in one cycle. This is the sort of thing that separates a general purpose computational processor (like intel) from a DSP chip. It is an operation that makes the processing of real world signals (like audio) fast enough to keep up with the rate at which new samples are coming in.

All DSP chips trade off instruction rates (speed), on board memory, instruction set types, hardware acceleration blocks, bit depth, and chip size (aka cost).

Some random notes on various chips I am familiar with:

SHARC - Kind of expensive. Good for audio, and was broadly adopted in home theater and car HiFi. Can be programmed in a “C-like” code. Widely used in applications beyond audio.

Blackfin - 16 bit DSP that was intended for communications applications. It must be run in double precision (32 bit) for audio applications. ADI had an internal battle over this chip between the SHARC team and the Blackfin team. The only reason it is used in audio applications is the Blackfin team bombed the price to get audio design wins. Double precision cuts your instruction rate in half. ADI should never have let this happen.

SigmaDSP - The audio group that I was responsible for came out with a line of 28 bit fixed point chips that were specifically designed for audio. The creator (super famous guy in the audio world) wrote an AES paper at the time on why 28 bits was the idea number for audio (more bits is not better when looking at the big picture). Because this chip was so small and efficient, we could put audio converters on it. Eventually I got excited about using this chip for guitar effects. I got ADI to do a custom chip with delay memory, and Source Audio was born. We are the only effects company I know of with a proprietary DSP chip.

TigerSHARC - Designed for 5G basestations. Fractal used it, but I think they moved on.

FV-1 - I believe this chip was intended for karaoke machines originally. The advantage of this device is that it has integrated converters and memory. It is also easy to program. Other than that, there is nothing it does that cannot be done far better with almost any other solution. The integrated converters are less than 90dB. That is similar to computer audio of the AC-97 CODEC era. Anything from TI, Cirrus or AKM is miles ahead. The instruction rate is something like 128 per audio sample. The compares with thousands per sample for any ADI DSP (we are at 3500 on most of our products). Despite what I have said here, some of the products made with this device are very popular. No. Surrounding this device with additional analog circuitry does not improve the SNR/DNR of the signal path nor the number of instructions. I have heard this stated on TGP, but it’s not true. Yes, you can certainly hide some of the noise with filtering or gain-ranging, but at a cost to dynamic range and/or frequency response. There is NO digital I/O on this device. You are stuck with the audio performance as is.

ARM - embedded RISC processors are getting faster and there is lots of money being poured into this space for lots of applications all over. The audio market will be riding on the coattails of high-volume applications. They are getting fast enough to compare with general purpose DSP chips. The SigmaDSP chip we use for the Atlas Compressor and the EQ2 can now almost be executed on a 64 bit ARM chip. However, 64 bit ARM chips are still rare. Once they are more common, we will certainly take advantage. For now, we have assembly code running on very small and efficient high speed audio DSPs. For those who have been using SHARC and a higher level language, the switch-over might need to be sooner. I dont know how others do it exactly, so I am speculating a bit. In ten years most high end digital pedals will use ARM-based processors, I suspect.

Probably more than any of you want to know. I am showing my age given the number of years I have been involved with DSP chips!

Agree with the comment that algorithms are the most important aspect

Personally, I believe STM32 is a safe bet for beginners. There are tons of them in all possible configurations. Almost all Mutable Instruments are built using STM32. I’ve seen nice digital guitar pedals based on STM32F7/H7 chips.

Also, there is nice reading about STMs in MI documentation: Stm32 miscellania - Mutable Instruments Documentation


The most important outcome for me is that your DSP code is much more important than your MCU.
And for DSP I would recommend Will Pirkle books:

Even if you’re not going to develop VST plugins, there are tons of useful information about implementing DSP in C++;

And Cycling’74 Max is a great tool for learning DSP as well. Digitone algorithms were initially designed in Max.
This series of book is great learning material for high level understanding of Max
Electronic Music and Sound Design - Theory and Practice with Max 8

And this book covers “gen~” operator which allows to build DSP algorithms from the very scratch operation at sample level.
Generating Sound and Organizing Time

I own most of these books (apart from the 3rd part of Max series, which is not possible to buy in a country where I’m currently live). I briefly read them and they’re well written and full of useful information.


And on top of that you’ll must learn

  • C++ (I wouldn’t recommend to write in plain C)
  • embedded C++ (almost no dynamic allocations, no exceptions, more specific architectures, and many other embedded specific things),
  • electrical engineering (you will hit the boundaries of development boards like Nucleo very fast, and you’ll want to design and manufacture your own PCB)
11 Likes

I’ve looked into the Synthux kits before, they are very tempting. Visually they have a lot of neat designs, and looks like they have information to help build this stuff. The main thing holding me back is not knowing how difficult and time consuming it is. My own fault, I’d just need to do some more reading / watching. I’m alright with general electronics and I don’t think I’d have too much trouble physically putting the stuff together, my main concern is the code side of things. I’m intrigued enough to want to try, although historically I’ve had a hate-hate relationship with programming :sweat_smile:

Sadly, I don’t think there is a common meaning. While I share your definition, I’ve seen plenty of “bare metal” tutorials where the first thing they do is fire up CubeIDE and never leave HAL. I’ve also seen it used to refer to whether one relies on a bootloader or even to distinguish between asm and higher level languages.

This is why I felt the need to provide a clear litmus test in the initial post. If your code talks to registers, cool. If it talks to Linux, that’s a different thread.

But I think, in general, the less we worry about semantics, the more welcoming the thread will be :smiley:

Can’t say I agree with this. There’s plenty of great embedded code written in C. And Rust is a big up and comer in this space.

Also, while designing your own boards can be fun, with the prevalence of audio focused packages and kits these days, it’s no longer necessary and can add a rather intimidating cliff to the learning curve.

Glad you said this - I am in no way a programmer, but I can follow directions, copy/paste and duckduckgo an error message, so I’ve built a bunch of small stuff like modep and zynthian with pi’s. I’m currently working on/trying to find the time to build a minidexed, which is a raspberry pi dx7 that purports to run on bare metal. I have absolutely nothing else to contribute to the subject lol, just that modep and zynthian (and lots of other pi stuff) are built on linux, but fwiw minidexed isn’t.

1 Like

This is, IMHO, justified. I’ve had a 30 year career in programming, and there are bits about building for MCUs that tripped me up good. Trying to learn programming and bare metal development at once is a big ask.

So I’d normally say “first just learn C on its own.” But the best way to learn is by doing, and there aren’t a huge number of C projects around anymore.

So what I’d suggest is starting with Arduino. This is an MCU platform that has really robust training wheels and a focus on making sure things “just work” so you don’t derail your learning. There’s a vibrant community, infinite kits and projects, and the whole thing runs on C, so you’ll be picking up the fundamentals of programming while working with it.

That alone is not going to get you to the point where you’re writing a reverb pedal. Arduino’s ATMega platform is not powerful enough to run DSP. But:

  • There are bunches of uses of MCUs in synths that have nothing to do with DSP. MIDI, preset management, reading pots, etc. So it’s not like the experience you’ll be gaining will go to waste.
  • There are more powerful chips like the Teensy and Daisy Seed that have some amount of compatibility with Arduino’s training wheels. So when you need something bigger, you can in theory move on to more advanced chips.

I say “in theory” because at some point the training wheels are going to be getting in your way and you’ll want to cast them off and do all that lower-level stuff yourself. But in the meantime it can be a fantastic way to learn in a large community that is doing the exact same thing. Which can do a lot to lessen the programming anxiety.

1 Like

It’s funny that the same reason I think I might have a shot at doing bare metal MCU programming is the reason I’m afraid I’d be frustrated by it. I actually was in the process of getting a software development degree in yesteryears and I dropped out in the middle of year 2 of C++ when I finally accepted that I really did not like writing programs. However, I was a much younger guy, and these days I have other programming experience instead (PLC and Step 7) and I think it’d be easier to learn C if I have an exciting goal in view (making a synthesizer).

Thanks for all the advice, I’ve bookmarked your response and I’ll definitely be referring back to some of your recommendations here :slightly_smiling_face:

1 Like

Heck yeah. Full speed ahead, then. C is not a complicated language, so if you have other experience (especially C++, which is a superset of C) you should find it familiar.

There’s some idiomatic surprises that arise from the way C types map to memory and how that’s used to address registers in MCUs that can be a little unintuitive. But when you run into a blocker just ask here. We’ll get it sorted out.

2 Likes

I am very interested in the Synthux stuff and think I am going to sign up for their course. I haven’t used the Teensy before but the specs look good, I’m OK with C and have a fairly solid knowledge of DSP/signal processing. The 64mb RAM is a big deal.

I also like stuff from M5stack, although they are not specifically music/DSP oriented, just that the ESP32 is a fun general purpose microcontroller and m5stack makes lots of used modules like banks of knobs and encoders which make it very easy to try out ideas. Very nice company to deal with.

1 Like

Just want to add this, as i think I think its an interesting use of the ESP32-mcu

1 Like

Hi all, I thought I’d post here rather than making a new thread.

I’ve been a web developer professionally for a few years now. At the beginning of the year, I was giving thought to embedded software and it’s appeal for something for me to at least try, and potentially pursue career wise in the future.

I kind of popped it to one side as I felt like it might be a bit of a departure from my current role and potentially inhibit me focusing on the next steps of my career. It’s cropped up again for me though a few times and I think it’s something I’d really like to shift towards, or at the very least learn enough about to see if it truley is.

I’m not looking for a roadmap as such as I understand there are multiple ways to approach these things. However, It would be great to get some advice from those more experienced in this field as to some good resources and advice.

Perhaps some advice on balancing with a development job if anyone has experience in that also, though in my experience, if I take to something I tend to make time and have motivation/energy for it regardless.

All advice welcomed and appreciated.

If you’ll permit me my extremely opinionated take as a graybeard:

  • Junior developers are primarily concerned with syntax which they comprehend by rote
  • Senior developers are primarily concerned with systems which they understand in the abstract.

So career progress can be measured by the extent to which you can leave details such as languages and platform behind. The goal is to see all languages as equivalent tools that store and manipulate state through conditionals and all API as equivalent interfaces that provide some sort of C.R.U.D.

Towards this, the intermediate developer’s job is to develop an abstract understanding of languages and API. The best way to do this is to gain as much experience with diverse code and platforms as possible. If you can do this within the confines of your company, excellent! Someone is paying you to get improve! This is ideal.

But if not, there’s really nothing for it but to adopt side projects to engineer these experiences for yourself. Viewed this way, a collection of coding hobbies is not just healthy, but necessary for professional development. And if your company is at all clueful, they will encourage you in this. It might be worth asking for support, at least in the form of a modest budget for books or e-courses.

So; through this lens whither firmware development? I feel it’s a very helpful step on the above path because:

  • its primary language (C) is the quintessential “store and manipulate state” language and
  • its primary API (direct register manipulation) is the quintessential “CRUD API”.

Learning bare metal development hands you an X-ray of the javascript/REST world (I assume?) you inhabit as a web developer. It lets you see the bones that undergird it and gives you perspective on the breadth of the languages/API spectrum you will have to build a mental abstraction around to progress.

4 Likes

thank you for that and totally agree, I might not have made it clear but I parked that line of thinking, hence my post!

it would of course be great learning for me.

I think asking for support at work is a nice idea - I had mentioned it to a previous colleague.

I’m going to read this again when I have a bit more time, thanks.

Sure. Though when you ask for advice on how to balance a development job, I guess I’m saying I reject the premise of the question. Having coding hobbies is your development job. And this is a good coding hobby for the reasons outlined above.