[sdiy] STM32 (or other) audio DSP learning recommendations

[Scott Gravenhorst]

"Jay Schwichtenberg" <jschwich53 at comcast.net> wrote:
>What are you guys using for H7 hardware?

There is a very inexpensive Nucleo-144 board I'm working with.

>Also what are people using for compilers here, gcc, CubeMX or commercial
>compilers?

I use gcc under Fedora 27.

>I'd like to find a board that has the processor, a whole lot of SDRAM
>(512Mbytes or more) and USB with the rest of the pins broken out that is
>affordable. I could do a board but I figure that I'd have to do at least 4
>layers and that starts to get expensive for just a few boards and some of
>the parts are BGAs.

Check out the Nucleo-144 with STM32H743, it shows up in CubeMX as a supported board and
there's a link there to I believe ST's site that sells it tho it can be found elsewhere
as well.  

>I do have the Disco and Nucleo F7 boards that I haven't had time to play
>with yet since summer is more of an outdoor time for me. Then there is the
>Pi Zero, Teensy 3.6s, and a few more, so little time and so many processors.
>
>I did find this for the F7 series. It does have 8 Mbytes which would be a
>good start.
>
>https://www.waveshare.com/product/mcu-tools/stm32/core/core746i.htm
>
>To Eric's point about caching. With the inclusion of pipe lining, caching,
>cores and treads into processor making them asynchronous real hardware
>debugging has gone away. Now we more or less just have JTAG and various
>other debug interfaces which sort a work (some better than others). Another
>aspect of that is pretty much all the processor people I've talked to in
>quite a while now say stay away from assembly language code and stick with
>compiled code. Issue is it's just too hard to do assembly code that takes
>into account the pipelining and caching to get optimal performance.
>
>Use to work on processor emulators and software tools, that went away. I've
>seen boards with 1800+ channels of logic analyzer hooked up, worked on bus
>based interfaces that replaced that which have been replaced with propriety
>debugging interfaces. Who knows what is next.
>
>Thanks
>Jay S.

I agree, using assembly language isn't necessarily the best route.  At least with gcc,
the optimization available is IMO quite good.  I was wondering about whether or not gcc
would use DSP instructions and was able to find them in the compiled code once I set
optimization to either -O2 or -O3.  IIR and FIR filters and other DSP constructs contain
MAC instructions among other DSP instructions and the code is demonstrably faster.  It is
also easy to include small assembly sequences within C functions or inline code, however,
using optimizations, I've not yet had a reason to do so.

-- ScottG
________________________________________________________________________
-- Scott Gravenhorst
-- http://scott.joviansynth.com/
-- When the going gets tough, the tough use the command line.
-- Matt 21:22