[sdiy] STM32G4 SAI problems

rburnett at richieburnett.co.uk rburnett at richieburnett.co.uk
Sun Jul 16 21:04:38 CEST 2023

> as for it generating more code when the other chip was selected...
> You are using a current verison of CubeIDE, right? (you were referring
> to CubeMX earlier, which used to be a separate tool, now integrated 
> into
> CubeIDE).
> (just making sure all is up to date, although I guess the old tool 
> would
> not find recources on ST server for newer ICs like that)

Yes, I just installed STM32CubeIDE, which I believe includes CubeMX (or 
at least it's functionality) to do the graphical configuration of 
peripherals, clocks, etc.  I'm new to this platform so sorry if I've 
been using some wrong terminology.  My brain is still a bit frazzled by 
all the terms like HAL, LL, MX, etc. and the relative complexity of 
these modern 32-bitters.

> Have you selected the chip itself, btw, or the Nucleo(?) board that you
> have, when starting the project? The latter would make some things
> easier to setup, because it already knows stuff that's on the board.

I selected the Nucleo-G474RE board directly in the hope that it would 
configure some of the things right for that board.  (It made me log in 
with an internet connection and downloaded and unzipped the package for 
that board.)  It seems to have done a decent job with the LED and the 
UART piped through the Nucleo boards USB virtual COM port which both 
worked first time.  I haven't tried just building for the chip instead 
of the Nucleo board, but could give it a try.

> With questions about issues using these tools, it might be worthwhile 
> to
> ask on the ST community forums.

Very true.  Just thought I'd check here first in case anyone either had 
a working example, or had encountered the same problem.  Unfortunately 
digital audio still seems a bit niche on these forums but I'll do some 

> To get unfamiliar stuff set up ~ quickly, HAL is ok. Once you want to
> get performance out of what you paid for in a chip, HAL may be in the
> way. It does not always implement all use cases for a peripheral, and
> several indirections for interrupt handlers may also not be what you
> want.

This is exactly what I was hoping to do.  Get something lashed up and 
working quickly, then look at the performance and improve/replace code 
as and where necessary.

Thanks again for the advice from all.


More information about the Synth-diy mailing list