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

Scott Gravenhorst music.maker at gte.net
Thu Jul 5 17:14:55 CEST 2018 

I've also been playing with the H7 CPU.  HAL has both good and bad points.  At the very
least, I applaud ST for not delivering this code as precompiled binary libraries.  We have
the source code.  

Indeed, HAL is a bit fat, however, being C source code, one can trim that fat and what one
ends up with is pretty well the same code you would have hand written anyway.  The fat is
due to the fact that HAL needs to accomodate a number of CPU types with different
collections of hardware peripherals.  

As you say, the 3000+ manual is not what I'd call good fireplace reading.  Something I
learned recently is how the use of certain peripheral devices disables either partially or
fully other peripherals due to what I assume is some internal hardware sharing.  This was
not clear to me from reading the Reference Manual, but it was obvious when I used
STM32CubeMX.  

You also make a good point about these devices being complex (and it's going to keep
growing).  As my most recent project developed, it had gone through several peripheral
device selection and pin changes.  I'm also from the figure-it-out-yourself school of
thought which I had done regularly with PIC devices.  Had I decided to avoid HAL and
CubeMX, these changes would have taken hours instead of seconds as they did with CubeMX and
HAL.  CubeMX accounts for the hardware sharing and shows visually what happens.  CubeMX
doesn't allow illegal combinations of hardware to be enabled.  Once the developer is
satisfied with the pins and devices, CubeMX can generate the init software as C source
within a structured project (which can be Makefile).

Obviously, CubeMX is a piece of software and like all software, there are bugs, some bigger
than others.  One bug discussed in the ST fora was related to the max bit rate SPI devices
could work at and CubeMX didn't allow setting it to it's max rate.  However, this bug is
already registered and is easily mitigated by simply editing the init source code to set
the bit rate as needed.  So while this tool has worked for me, I know better than to simply
trust it, I read the code it generates and do tests to ensure it works as required.

At the end of my project, I will look at the HAL code to trim any fat that affects the
performance of my application.  Init code will have fat in options for devices or CPUs I'm
not using, but since it executes only once, the extra code doesn't concern me (and the fact
that the Flash is enormously huge for my application) and I won't edit it.  However, there
are performance affecting parts that I will recode.  One thing in particular is interrupt
service routines that pass control to the user through a callback.  But again, the ISR part
of the driver is C source code, so it's easy enough to edit.  I always change the HAL file
name to include a leading underscore to remind me that it's edited.  My efforts make
changes that don't change the call structure so that either the original HAL files or my
edited version can be used.  The difference will be only that the edited versions are a tad
faster and maybe a bit smaller.

As much as my first looks at HAL caused me gas, I have to say that it's not a horrible way
to get this done.  It allows engineers to quickly create application code without having to
bang out all of the peripheral device drivers by hand.  We should remember that ST doesn't
make it's CPUs just for DIY DSP stuff, they need their devices to be easily integrated into
 all user designs and I believe that HAL is part of that thinking.  All in all, I want to
spend as much of my time as I can working on the application code, not on writing drivers
which turns out to be essentially reinventing several wheels again and again.


Martin Klang <mars at pingdynasty.com> wrote:
>I meant: beat you to posting the link!
>
>The H7 is fun. It's a shame the HAL is so terrible. I know, it's better 
>to roll your own, but it's a complex device and just reading the 
>reference manual is a job in itself!
>
> From my experiments the F7 only gives a moderate performance boost, 
>while consuming almost twice as much power. Not ideal.
>
>
>Martin
>
>
>On 05/07/18 15:03, Eric Brombaugh wrote:
>> Well, perhaps you'll beat me to publishing an open source project, but 
>> I've been using STM32F7 + SAI + I2S codec for a few years in 
>> proprietary products. The Synthtech E352 and E370 are both based on 
>> the F7 + I2S DAC and there were a few R&D projects with true codecs 
>> and SDRAM memory that I did prior to those that never saw the light of 
>> day.
>>
>> Working on an H7 design right now. ;)
>>
>> Eric
>>
>>
>> On 07/05/2018 06:52 AM, Martin Klang wrote:
>>>
>>> Looks like I'll beat Eric to it! Check out his most excellent project 
>>> page here:
>>>
>>> http://ebrombaugh.studionebula.com/synth/stm32f4_codec/index.html
>>>
>>>
>>> It's for the F4 again, but the differences aren't that huge. It uses 
>>> the I2S peripheral though, not the SAI (since the STM32F407 didn't 
>>> have it).
>>>
>>>
>>> For a SAI example for the same codec you could have a look at my new 
>>> OWL / OpenWare firmware, which also uses the ST HAL (for better or 
>>> worse):
>>>
>>> https://github.com/pingdynasty/OpenWare/
>>>
>>> The code is in heavy development though and I don't recommend it for 
>>> readability, correctness, or intelligibility.
>>>
>>>
>>> Martin
>>>
>>>
>>> On 04/07/18 01:02, ulfur hansson wrote:
>>>> me and my buddy just recently managed to get a custom STM32F7 board 
>>>> to blink an LED (!) it’s my first digital design project, and a 
>>>> little blinking light has never made me this happy before.
>>>>
>>>> we have a WM8731 DAC on board, but alas setting up the code properly 
>>>> for use with the STM seems a little tricky.
>>>>
>>>> does anyone have a boilerplate setup/lesrning resource for this 
>>>> particular DAC? the best resource we’ve found so far seems to be a 
>>>> mutable instrument design that has the same chip but for an M4 - we 
>>>> would love to find more detailed info on how to properly implement 
>>>> it into out code on the F7 - no need to reinvent the wheel here i 
>>>> reckon ;)
>>>>
>>>> any help/direction towards further resources would be immensely 
>>>> helpful and well appreciated!!
>>>>
>>>> all the best,
>>>> -úlfur
>>>>
>>>> Sent from outer space
>>>>
>>>> On Jun 29, 2018, at 8:00 AM, Steve <sleepy_dog at gmx.de 
>>>> <mailto:sleepy_dog at gmx.de>> wrote:
>>>>
>>>>> "A debugging IDE not (based on) Eclipse"
>>>>>
>>>>> I've heard some people are using Code::Blocks, I'm not sure there 
>>>>> are any readily made support packages for embedded work, though.
>>>>> But it's native C++, not Java based, so the little naps that 
>>>>> Eclipse may have every now and then because of that, aren't there 
>>>>> in C::B.
>>>>>
>>>>> It's not just step-through debugging at a few key's press and some 
>>>>> mouse hovering over variables that's nice about debugging with an IDE.
>>>>> Also memory watches that highlight when regions of interest 
>>>>> changed, changing display/numerical format or how a data pointer is 
>>>>> interpreted wich a few clicks.
>>>>> And RTOS aware debugging if you have multiple threads - which can 
>>>>> easily be called for on a beast like stm32F7, depending on the 
>>>>> natuer of the project.
>>>>> I mean, probably you could run Quake on that "micro controller" 
>>>>> with one of the boards that has 8MB RAM or so, if somebody bothered 
>>>>> to make an optimized port of the inner rendering loop (which is 
>>>>> famous for being incomprehensively optimized for the Pentium60) :D
>>>>> And if you have plugins for a tree view of peripheral registers and 
>>>>> named register bits and stuff, it can save a lot of time (and 
>>>>> reduce human error factor)
>>>>> Usable overviews of where program & RAM memory bytes are going is 
>>>>> also nice vs. hacking some script that shows some ASCII barf of 
>>>>> that...
>>>>> Did I mention performance profiling with usable result browsers 
>>>>> linked with source code...
>>>>> (I think TrueStudio comes with that ready-to-use)
>>>>>
>>>>> All that stuff is about as much fun to do as a daily routine solely 
>>>>> on the command line as writing SUBLEQ assembly programs as a daily 
>>>>> routine...
>>>>>
>>>>> You can tame Eclipse and shape it a lot (perhaps? ;)) to your 
>>>>> liking, though.
>>>>> I know it's messy, but once it's set up and running...
>>>>> I wouldn't want to miss *language aware* project-wide code editing 
>>>>> features (e.g. rename, extract function, etc), anyone doing that 
>>>>> with mere text search & replace tools needs buttocks paddling.
>>>>>
>>>>> - Steve
>>>>> *Gesendet:* Freitag, 29. Juni 2018 um 02:05 Uhr
>>>>> *Von:* "Chris McDowell" <declareupdate at gmail.com 
>>>>> <mailto:declareupdate at gmail.com>>
>>>>> *An:* music.maker at gte.net <mailto:music.maker at gte.net>
>>>>> *Cc:* synth-diy at synth-diy.org <mailto:synth-diy at synth-diy.org>
>>>>> *Betreff:* Re: [sdiy] STM32 (or other) audio DSP learning 
>>>>> recommendations
>>>>> I actually use openstm32 for work (and synths, duh) and it's 
>>>>> generally a breeze. They have an all-in-one installer for OSX. 
>>>>> pretty great
>>>>>
>>>>>
>>>>> Chris
>>>>>
>>>>> > On Jun 28, 2018, at 6:55 PM, Scott Gravenhorst 
>>>>> <music.maker at gte.net <mailto:music.maker at gte.net>> wrote:
>>>>> >
>>>>> >
>>>>> > John Speth <john.speth at andrews-cooper.com 
>>>>> <mailto:john.speth at andrews-cooper.com>> wrote:
>>>>> >>> Eclipse ... is ... the ... nightmare.
>>>>> >>
>>>>> >> Is there a free debugger UI that is NOT Eclipse.
>>>>> >
>>>>> > That is a good question.
>>>>> >
>>>>> > I'll admit that I just use the LEDs and VCP.
>>>>> >
>>>>> > -- ScottG
>>>>> > 
>>>>> ________________________________________________________________________ 
>>>>>
>>>>> > -- Scott Gravenhorst
>>>>> > -- http://scott.joviansynth.com/
>>>>> > -- When the going gets tough, the tough use the command line.
>>>>> > -- Matt 21:22
>>>>> >
>>>>> > _______________________________________________
>>>>> > Synth-diy mailing list
>>>>> > Synth-diy at synth-diy.org <mailto:Synth-diy at synth-diy.org>
>>>>> > http://synth-diy.org/mailman/listinfo/synth-diy
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Synth-diy mailing list
>>>>> Synth-diy at synth-diy.org <mailto:Synth-diy at synth-diy.org>
>>>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>>>> _______________________________________________
>>>>> Synth-diy mailing list
>>>>> Synth-diy at synth-diy.org <mailto:Synth-diy at synth-diy.org>
>>>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>>>
>>>>
>>>> _______________________________________________
>>>> Synth-diy mailing list
>>>> Synth-diy at synth-diy.org
>>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>>
>>>
>>>
>>> _______________________________________________
>>> Synth-diy mailing list
>>> Synth-diy at synth-diy.org
>>> http://synth-diy.org/mailman/listinfo/synth-diy
>>>
>>
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
>> http://synth-diy.org/mailman/listinfo/synth-diy
>
>_______________________________________________
>Synth-diy mailing list
>Synth-diy at synth-diy.org
>http://synth-diy.org/mailman/listinfo/synth-diy

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

More information about the Synth-diy mailing list