plz help me with choosing a MCU

[Hatsune_electronic]

so i am going to make a synth and i dont really wanna use a teensy because its kinda overpriced and expensive, plus i am not gonna use their library anyway so paying that much for it kinda seems like a waste for me coz its lib is basically its superpower
I was stuck bw STM32G474 and STM32H563ZIT6
I need unison, additive synthesis, adsr , 2 oscillators , wavetable , filters , lfo , 8 voice polyphony and 16 bit 44.1khz voice out
I was leaning more towards the h5 because it had the same cordic and fmac from g4 but more cpu processing speed ram and flash to give me more room
Please give some advice since i am pretty new and this will be my biggest project lol
Thanks!
Edit: STM32H750VBT6 popped up on my radar and it seems like a more viable option to me now

[hans]

The unique selling point of the G474 is its high-resolution timers.. useful for generating high frequency PWMs with fine resolution. Along with the analog peripherals to support multi-channel motor drives, digital power supplies, etc.

If all your audio circuits don't need that, then I'd also go for the H5 family chip.

One consideration, perhaps, is that the Teensy uses a Cortex-M7 core which is a bit quicker than the M4 or M33 (clock for clock). Plus it can run at very high speeds. And it has double-precision floating point hardware, opposed to a regular floating point unit on the M4 and M33's.
In some number crunching benchmarks the M7 really pulls quite a bit ahead though.

But if you're talking about CORDIC and FMAC peripherals, I think these are all integer and not float, so its perhaps not that important.
Might also want to consider some H7 chips like the STM32H723, it also has CORDIC/FMAC but 3x the Coremark score as the H5 chips.

[westfw]

i dont really wanna use a teensy because its kinda overpriced and expensive

Really?   At about $35 (about the same as the original price of the original (official) Arduino Nano)?  Doesn't seem overpriced to me!
And I'd predict that that's going to be a small fraction of your overall costs...

i am not gonna use their library anyway

OTOH, their library WOULD be one of the big advantages, and if you're not going to use it, I guess there's less reason to consider it...

[SiliconWizard]

Agree with westfw, for what you want to achieve here, a NXP iMX RT1062 looks pretty good and while the ready made boards are not as cheap as some other MCUs, you get a lot of processing power. Alternatively, you could consider a STM32H7 which would be more on par with it than the STM32H5, and dev boards are still cheaper.

I really don't recommend cheaping out on the MCU for this project, you're almost guaranteed to regret it.
A decent synth needs some processing power and with a M4/M33 you will quickly hit a wall.

[westfw]

A decent synth needs some processing power

Does it?  I seem to recall pretty decent audio coming out of sounds cards back in the day when even "200MHz CPU" was unobtainium.
Do you need double-precision floating point?  ANY floating point?  Seems like a decent interface to an audio DAC (DMA I2S?) would be the most important feature...
(Of course "mutiply by 8 for 8 voices" might be tough...)

[brucehoult]

A decent synth needs some processing power

Does it?  I seem to recall pretty decent audio coming out of sounds cards back in the day when even "200MHz CPU" was unobtainium.
Do you need double-precision floating point?  ANY floating point?  Seems like a decent interface to an audio DAC (DMA I2S?) would be the most important feature...
(Of course "mutiply by 8 for 8 voices" might be tough...)

Back in 1983 I helped a couple of my friends design and build a wire-wrapped M6809 computer. One of Paul's big interests was music synthesis, which was part of the reason we choose the M6809 over the M68000 — the 6809's 11 cycle 8x8->16 multiply was more attractive for synthesis than the 68k's 38+2n (maximum 70) cycle 16x16->32 multiply, especially given we could get a 2 MHz 6809 for around $30-$35 and the same money would only buy a 4 or 6 MHz 68000. 10 and 12.5 MHz ones existed but cost up to 10x more and anything less than 12.5 MHz would on average take longer for a multiply where we only cared about the top 8 bits.

[NorthGuy]

I was stuck bw STM32G474 and STM32H563ZIT6

I don't see any substantial difference between these for your purpose from the technical point of view.

With 44 kHz output and 200 MHz CPU you get roughly 4000 instructions per data point. Looks like plenty to me. Unless you like to bloat ...

Why do you want to use a 144-pin chip?

[westfw]

I will note that building a synth with an overpowered CPU that gives you a lot of flexibility in your implementation of algorithms and etc, vs building a synth with the minimum possible CPU and a lot of cleverness, are two different projects.
Both are "worthy."

[Psi]

If you're doing time critical real-time stuff try to avoid having to link timers to make bigger timers if you can afford it (two linked 16bit linked timers to make the 32bit timer you wanted) etc..

You can do it, but its annoying and sometimes doesn't work quite how you want.

Also, if you are planning on using DMA make sure you fully understand any limitations of the DMA controllers in the MCU before selecting it.
eg, sometimes there are two DMA controllers and some peripherals or memory is only available to one of them. Or they share a bus etc..


But sometimes you just have to hack something together in order to figure out the proper way to build it, then you can start again from scratch and to it properly. So don't be afraid to do that  (The same exists in hardware and software, eg SpaceX Raptor 1,2,3)

Uni loves to teach extreme levels of planning, but sometimes the only way to truly figure stuff out is to just dive into it and build it until you fail and have to start again once you figure out all the problems you didn't know about.  (unknown unknowns)

Basically, sometimes starting is more important than planning. You can only plan once you know enough about what is required.

[brucehoult]

But sometimes you just have to hack something together in order to figure out the proper way to build it, then you can start again from scratch and to it properly. So don't be afraid to do that  (The same exists in hardware and software, eg SpaceX Raptor 1,2,3)

A better example is the original launch stand.

[negativ3]

But sometimes you just have to hack something together in order to figure out the proper way to build it, then you can start again from scratch and to it properly. So don't be afraid to do that  (The same exists in hardware and software, eg SpaceX Raptor 1,2,3)

A better example is the original launch stand.

There needs to be a banana for scale in all the spacex pics.

[brucehoult]

But sometimes you just have to hack something together in order to figure out the proper way to build it, then you can start again from scratch and to it properly. So don't be afraid to do that  (The same exists in hardware and software, eg SpaceX Raptor 1,2,3)

A better example is the original launch stand.

There needs to be a banana for scale in all the spacex pics.

There is, didn't you see it?

Human for scale is more useful. Or B737 for scale.

[Hatsune_electronic]

Hello
Yes I did consider the bare chips of nxp 1062  but adding costs of a custom pcb to accommodate the bga pack and other components plus the chip itself did put the price of it above a teensy and I took another chip into consideration since it popped in my radar which is STM32H750VBT6 since it's cheap where I live and readily available locally at about 8.40 - 10$ a pop and I could hand solder it to a breakout board and it has all the periphs I need

[NorthGuy]

... adding costs of a custom pcb to accommodate the bga pack and other components ...

$2 at JLCPCB plus shipping.

[NorthGuy]

If you're doing time critical real-time stuff ...

I don't think a synthesizer is a critical real-time stuff. You can add considerable delay between generation and playing, as long as you have space for a buffer.  For example, if you have a 1000-point buffer  (roughly 20 ms at 44 kHz), it is perfectly OK if calculation of some points will take much longer than 4000 instructions, as long as you don't exceed 4000 on average.

[tooki]

If you're doing time critical real-time stuff ...

I don't think a synthesizer is a critical real-time stuff. You can add considerable delay between generation and playing, as long as you have space for a buffer.  For example, if you have a 1000-point buffer  (roughly 20 ms at 44 kHz), it is perfectly OK if calculation of some points will take much longer than 4000 instructions, as long as you don't exceed 4000 on average.

Just FYI, for a synth, 5ms is considered the maximum tolerable latency by the sources I saw. I don’t know what your threshold for “considerable” delay is, but 20ms is certainly too much.

[NorthGuy]

If you're doing time critical real-time stuff ...

I don't think a synthesizer is a critical real-time stuff. You can add considerable delay between generation and playing, as long as you have space for a buffer.  For example, if you have a 1000-point buffer  (roughly 20 ms at 44 kHz), it is perfectly OK if calculation of some points will take much longer than 4000 instructions, as long as you don't exceed 4000 on average.

Just FYI, for a synth, 5ms is considered the maximum tolerable latency by the sources I saw. I don’t know what your threshold for “considerable” delay is, but 20ms is certainly too much.

Even with 1 ms you still will have a 44-point buffer which gives you room for averaging.

[tycz]

I don't think a synthesizer is a critical real-time stuff. You can add considerable delay between generation and playing, as long as you have space for a buffer.  For example, if you have a 1000-point buffer  (roughly 20 ms at 44 kHz), it is perfectly OK if calculation of some points will take much longer than 4000 instructions, as long as you don't exceed 4000 on average.

Just FYI, for a synth, 5ms is considered the maximum tolerable latency by the sources I saw. I don’t know what your threshold for “considerable” delay is, but 20ms is certainly too much.

Maximum tolerable by whom? I think you could raise the total latency to 50ms before it becomes a significant problem. Just from my limited playing around with digital audio. I haven't made a musical instrument before.

For reference, you will add 5ms of latency by simply being 1.5 metres further away from the sound source. An upright piano has significantly more lag in its mechanical action. I haven't measured the delay the action introduces compared to an electrical switch, but just by looking at it I'd say it's at least 20ms and it's more when played softly.

[John Celo]

Please ignore these people.

Any competent sound engineer for digital musical instrument will fight tooth and nail against adding latency, any latency whatsoever.
Every single millisecond of latency will be fought for, fiercely.

Saying adding 20-50ms latency is "tolerable" is why world is filled with sloppy garbage software and garbage products where UI is unresponsible and laggy.

Re: OP question, consider buying stm32h743 or stm32h750 devboard from Ali for ~15-20eur. (https://github.com/WeActStudio/MiniSTM32H7xx)

[NorthGuy]

Saying adding 20-50ms latency is "tolerable" is why world is filled with sloppy garbage software and garbage products where UI is unresponsible and laggy.

UI buttons need to be debounced, so you would get a delay whether you like it or not.

Therefore, there must be a different reason why some of the UI is responsive while others are not.

Generally, your data flow and delays are part of your requirements. In your design process, you select a chip which would help you meet the requirements. Blindly buying H7 and hoping that its speed would solve all the problems is totally "unresponsible"

[er12]

I'll go with a smt32h743, and with this board Seed 3 : https://daisy.audio/
The library is nice
https://www.synthux.academy/

And the same discussion :
https://www.elektronauts.com/t/the-bare-metal-mcu-for-great-synthesis-thread/231870/3

[John Celo]

UI buttons need to be debounced, so you would get a delay whether you like it or not.
"unresponsible"

Since when does UI button debouncing add 20-50ms latency?

Moreover, if you know what you're actually doing, debouncing doesn't actually add any latency whatsoever and response would be instantaneous.

The only thing what would happen is that you'd have some time (cooldown) before the button can be triggered again, on good switches this would be no more than 5ms.

Therefore, there must be a different reason why some of the UI is responsive while others are not.

Yeah, it's called incompetence and very low standard for quality. Very prevelant these days.

[NorthGuy]

Since when does UI button debouncing add 20-50ms latency?

Moreover, if you know what you're actually doing, debouncing doesn't actually add any latency whatsoever and response would be instantaneous.

I looked at my debouncing code for a project. I used 10 ms timer interrupt and the firmware would confirm button pressed after it's been in the same state for 3 consecutive reads. This puts debouncing delay at 20-30 ms plus some additional time if there were actual bounces. I cannot notice the delay when I use this button.

Googling "how long a button debouncing should take for a human to feel the delay" yeilds an AI answer telling that 50 ms is the average delay used in debouncing. It also says that people are able to notice the delay only at 100 ms or more. Not sure it is entirely accurate, but sounds plausible.

If you're interested, you can create a project with different debouncing delays and then run a statistical experiment. Program your chip to do debouncing with delay A or delay B randomly. Press the button 20 times, record which delay you perceived and compare it to the actual delay produced by the chip. If you can detect whether this was A or B correctly most of the time then you can perceive the difference between A and B. If you make many mistakes you can not. Repeat it with various A and B delays. Post the results.

[John Celo]

Since when does UI button debouncing add 20-50ms latency?

Moreover, if you know what you're actually doing, debouncing doesn't actually add any latency whatsoever and response would be instantaneous.

I looked at my debouncing code for a project. I used 10 ms timer interrupt and the firmware would confirm button pressed after it's been in the same state for 3 consecutive reads. This puts debouncing delay at 20-30 ms plus some additional time if there were actual bounces. I cannot notice the delay when I use this button.

Googling "how long a button debouncing should take for a human to feel the delay" yeilds an AI answer telling that 50 ms is the average delay used in debouncing. It also says that people are able to notice the delay only at 100 ms or more. Not sure it is entirely accurate, but sounds plausible.

If you're interested, you can create a project with different debouncing delays and then run a statistical experiment. Program your chip to do debouncing with delay A or delay B randomly. Press the button 20 times, record which delay you perceived and compare it to the actual delay produced by the chip. If you can detect whether this was A or B correctly most of the time then you can perceive the difference between A and B. If you make many mistakes you can not. Repeat it with various A and B delays. Post the results.

I wouldn't program button debouncing in a way which adds any delay whatsover. It's stupid.
If a line can flip from 0 to 1, BEFORE the actual button is fully pressed (and not after), your design already has some other - very severe - issues.

The topic is musical instruments.
I can take a Bach piece or some fast synth licks and play it via MIDI instrument with total latency of 3-4ms.
And then increase audio interface buffer size such that total latency is 13-14ms.
I can instantly tell the difference, it's laggy ass.

It also says that people are able to notice the delay only at 100 ms or more.

There are people out there that are... to put bluntly... delayed up there and everywhere.
You could beat them with a steel pipe and they wouldn't notice.
That's not an argument or excuse for sloppy engineering.

[brucehoult]

I wouldn't program button debouncing in a way which adds any delay whatsover. It's stupid.
If a line can flip from 0 to 1, BEFORE the actual button is fully pressed (and not after), your design already has some other - very severe - issues.

I was puzzled too.

Don't report a 2nd (3rd, 4th) button press within the debounce time, but why delay the initial press at all?

Unless you want to see some minimum continuous press time to not be triggered by noise, but that's different to debounce.