[Stm32] Am I the only one not using HAL?

[DavidAlfa]

I understand pretty well how stm32 works despite using HAL frequently.
I just can avoid the hassle of searching every register bit every time I need a small change and lets me develop very fast.
To date it works fine, for most things I did there was no need of extracting every performance drop, neither I'm getting paid for what I do, so it's my time and my decision, and I don't want to spend so much time with it.
Using HAL doesn't make you an idiot, if tomorrow I need to manually setup a DMA, SPI, UART, etc , I pretty much know the registers, HAL is not so much high-level as you might think like ex. Arduino.

[dietert1]

The STM supplied open source libraries have been useful for me. Using CubeMX and the HAL libraries is very convenient and worth learning. Anyway, sometimes i could not use it.

For example the SPI driver has so many options that a basic transfer can be to slow for a certain slave, like the ADS1256. When that sigma-delta ADC runs at 30 kilosamples per second, the HAL library functions can not send a command within 30 usec and synchronous to the DRDY output as required by the ADC. Anyway it was easy to extract the basic SPI operation from the HAL implementation in order to solve the problem. One nice thing about the STM32 SPI HW component were the four byte FIFOs for transmit and receive, as all transfers of the ADS1256 fit into this size. This simplified everything.

Regards, Dieter

[Siwastaja]

SPI peripherals with FIFOs are indeed the best thing since sliced bread!

Not only it increases performance, it makes writing code simpler, and code more readable. Of course the downside is, if you write code assuming you have those FIFOs, then you need to pretty much rewrite it if you port it to something with no FIFOs.

Example:
Read accelerometer 3 x 16-bit values:
In an ISR: write 7 bytes to SPI data register: command and 6 dummy bytes. This is just 3 memory accesses: word, halfword and byte.
Set a timer, or SPI interrupt, whichever is fine, to give you another interrupt once you have full 7 bytes in RX FIFO.
In the second ISR: Read 7 bytes from the DR (again 3 memory accesses), do whatever you want with the data.

With DMA, you would still use an interrupt to do something with the data, and you would still read it from the memory. In this case, just accessing the SPI through the FIFO is just as efffient.

Without the FIFO, you have to interrupt every damn byte, or use DMA, and the DMA will still chuck quite some memory BW because every byte creates a DMA transfer. With FIFO, the DMA and interrupt based both are viable options, and having more options never hurts.

[SiliconWizard]

I like FIFOs for peripherals. They are pretty common on MCUs. I haven't used a MCU that didn't have SPI or UART FIFOs, of at least 4 words - sometimes deeper -, in a long time. Even the PIC MCUs have FIFOs. Except maybe the very, very old models?

[nctnico]

I like FIFOs for peripherals. They are pretty common on MCUs. I haven't used a MCU that didn't have SPI or UART FIFOs, of at least 4 words - sometimes deeper -, in a long time. Even the PIC MCUs have FIFOs. Except maybe the very, very old models?

You might see FIFOs go away. Recently I used a relatively new microcontroller from NXP. The (newer) UART doesn't have a FIFO; you are supposed to use DMA.

[DavidAlfa]

Most basic mcus don't have fifo, at best dual -buffering/shadow registers allowing to write new data once it started the transfer...

[newbrain]

This horrific piece of bloatware ST calls a HAL is truely written by someone without experience.
I mean, you have numerous structs that pollute your stack just to do some case-switching inside some crazy-bastard-#if-orgy-spagetti-code....

You probably never dug deep in NXP SDK, at least the one for iMX RT.
It's handles structures pointed by handle structures inside some other handle - plus static stuff pointing to the handles...
As a cherry on top, the writers of the code only have a superficial knowledge of the English grammar and orthography (I think they also write their DSs).

ST HAL would then look as lightweight as a feather.

[peter-h]

Clearly the ST ARM32 approach is "no FIFOs; use DMA if you need speed" but it leads to much more complicated code. You can easily spend a whole day or two getting DMA to work. There are various timing quirks. Of course the experts here will disagree and I too have no problems with it now because after I finally managed to make it work I just recycle the code. The code structure is also completely different however; a FIFO is very simple to use (it is transparent) and makes UART, SPI, etc servicing from ISRs easy and efficient.

I have an off-topic question here: do the 32F4 DMA controllers run at the CPU clock speed, or at the PCLK1/2 speed? If the latter, loading the (many) DMA registers is going to be pretty slow.

[Siwastaja]

You can easily spend a whole day or two getting DMA to work.

This sounds weird. The very first time I used DMA on MCU ever, and this was on STM32, I think it took .... maybe quarter of a day to read through the DMA section of the reference manual and just get it working. After all, there is not much to configure: which channel (which peripheral it maps to), memory address from/to, transfer size, number of transfers. Then ONE (1) trick: clear status registers before enabling. And then: enable it. And I'm not some super genius who always gets things done in minutes, but geez, it's still five lines of code.

So I find this just... weird.

If interested, check out nRF52. Their "simplicity of use" paradigm works with DMA, too: basically they just decided to drop non-DMA use of peripherals completely, and make DMA trivially simple to use. So instead of checking flags and reading out separate "data registers", or configuring separate DMA peripheral to map with other peripherals, their peripherals like UART or SPI just have pointer register where you want the data to be written to, or read from! I mean, is it legal to make things this obvious and simple?

[peter-h]

I said

Of course the experts here will disagree

and I was right

And I'm not some super genius

You are in the top 0.1%.

Then ONE (1) trick: clear status registers before enabling. And then: enable it

That could take somebody many days to find out, many days wasted posting on forums where a hundred desperate people posted the same Q over years and never got a reply.

That is where looking at somebody's code can save a lot of time, but a great deal of code online does not work and was never tested. Somebody just posted it to look smart...

The business of coupling peripherals to DMA is full of tricks. Like timer -> DAC with the DAC fed from DMA. You have to enable this and then enable that. I do have it running but it wasn't trivial. Actually I paid someone about £1000 to write the whole piece of code (but couldn't directly use what he wrote because he did it for a particular ST dev board... another story).

[voltsandjolts]

And I'm not some super genius

You are in the top 0.1%.

Yes, he is very good isn't he, a credit to the forum in the way he shares know-how.
(not sarcasm btw)

[Siwastaja]

Then ONE (1) trick: clear status registers before enabling. And then: enable it

That could take somebody many days to find out, many days wasted posting on forums where a hundred desperate people posted the same Q over years and never got a reply.

That should not happen because it is clearly spelled out in the reference manual. In fact, I have never tried what happens if I don't do it.

It's literally the first thing in the step-by-step instructions:

Stream configuration procedure
1. If the stream is enabled, disable it by resetting the EN bit in the DMA_SxCR register,
then read this bit in order to confirm that there is no ongoing stream operation. Writing
this bit to 0 is not immediately effective since it is actually written to 0 once all the
current transfers are finished. When the EN bit is read as 0, this means that the stream
is ready to be configured. It is therefore necessary to wait for the EN bit to be cleared
before starting any stream configuration. All the stream dedicated bits set in the status
register (DMA_LISR and DMA_HISR) from the previous data block DMA transfer must
be cleared before the stream can be re-enabled.

It's a bit verbose and they explain every freaking bitfield within the registers in that step-by-step checklist, making it a full page long, but still, you just need at least half-decent attention span, not to be a genius.

I purposely avoid posting a question on forums and instead just RTFM more carefully. Posting on forums about things that are explained in the manual is a problem for two reasons:
1) you waste time waiting for answer, when you could just proceed by reading the manual,
2) you decrease S/N ratio of the forums

[peter-h]

A lot of truth in that - which is why when I get a solution I post the details because it will help somebody one day.

The product may be commercial but the company is my own and I don't care, because I am not revealing anything earth shattering.

[DavidAlfa]

Yeah so much DMA... The you read the errata and find only 2 dmas can run concurrently, more will lead to data corruption.
Not sure if they fixed it...

[cfbsoftware]

It's literally the first thing in the step-by-step instructions:

Stream configuration procedure
1. If the stream is enabled, disable it by resetting the EN bit in the DMA_SxCR register,
then read this bit in order to confirm that there is no ongoing stream operation. Writing
this bit to 0 is not immediately effective since it is actually written to 0 once all the
current transfers are finished. When the EN bit is read as 0, this means that the stream
is ready to be configured. It is therefore necessary to wait for the EN bit to be cleared
before starting any stream configuration. All the stream dedicated bits set in the status
register (DMA_LISR and DMA_HISR) from the previous data block DMA transfer must
be cleared before the stream can be re-enabled.

It's a bit verbose and they explain every freaking bitfield within the registers in that step-by-step checklist, making it a full page long, but still, you just need at least half-decent attention span, not to be a genius.

In general the level of detail in the STM32 documentation is excellent. Unfortunately, however, verbose prose like this is not helpful when used to describe a sequence of events. I would find it infinitely more comprehensible if shown as a flow diagram or using some sort of pseudo-code. But then I'm a software engineer not a hardware engineer - does that make a difference?

[peter-h]

Yeah so much DMA... The you read the errata and find only 2 dmas can run concurrently, more will lead to data corruption.
Not sure if they fixed it...

Which chip is this on?

That would be a huge issue.

[jeremy0]

Yeah so much DMA... The you read the errata and find only 2 dmas can run concurrently, more will lead to data corruption.
Not sure if they fixed it...

Which chip is this on?

That would be a huge issue.

I'm not sure which device DavidAlfa was referring to, but the silicon errata sheet for the SAMD21 reads like a frickin Stephen King novel.

When at least one channel using linked descriptors is already active, enabling another DMA channel (with or without linked descriptors) can result in a channel Fetch Error (FERR) or an incorrect descriptor fetch. This occurs if the channel number of the channel being enabled is lower than the channel already active.
Workaround: When enabling a DMA channel while other channels using linked descriptors are already active, the channel number of the new channel enabled must be greater than the other channel numbers.

or

TCC peripheral is not compatible with an EVSYS channel in SYNC or RESYNC mode.

And then there are the undocumented shortcomings, such as the DMAC only supporting a subset of the documented functionality (e.g. no WRBADDR=BASEADDR, no BURSTLEN), and mysterious misbehaviour.