Author Topic: STM32 DMA FIFO bursts and timing tolerances.  (Read 6968 times)

0 Members and 1 Guest are viewing this topic.

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8194
  • Country: fi
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #25 on: January 21, 2023, 07:41:29 pm »
Those I2S FIFOs are very short.  With 32bit stereo frames consuming the entire FIFO for a single stereo sample works out about 10us per FIFO.

So I have no doubt it's going to work for 2 streams, maybe 3, but when it gets to 4 input streams and 2 output streams with 2 different EQs and some routing.  It could get very tight.

Between batch processing of buffers, and processing one sample per ISR, there is no fundamental difference in scalability; they scale the same, namely: linearly. With one sample per ISR, there is ISR entry/exit overhead, plus some SIMD optimization opportunities go out of window. But it's not a massive orders-of-magnitude difference, and the gap does not widen if you increase the number of streams, both solutions scale linearly.

Having any FIFO at all helps. We do these things even with more ancient peripherals which only have a single holding register.

Now, the reason why you see batch processing options of longer buffers being used, is that you need a dedicated DSP/MCU to do per-sample interrupt thing. This is not always an option.

But you have chosen an MCU, so there is nothing wrong doing it MCU way. Quite the opposite, the timing is IMHO easier to analyze, as you have already seen. You have 10us. Measure how long it takes to do the processing. Add some safety margin. Now you know what happens if you double the number of channels. Not exactly, but pretty close.
 
The following users thanked this post: paulca

Offline voltsandjolts

  • Supporter
  • ****
  • Posts: 2309
  • Country: gb
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #26 on: January 21, 2023, 09:15:14 pm »
What I'm trying to get at is circular mode is literally just a feature that STM32 added, it has no relation to DMA at all.

Eh? Continuous circular mode DMA is ideal for peripheral data reception into a large circular buffer, works well in STM32. Background code polls the ring buffer to see if any data has arrived and processes it as needed. Sometimes interrupt reception is a better fit for the application though, "it depends".
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 3148
  • Country: ca
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #27 on: January 22, 2023, 03:12:32 am »
I don't think your coding style will win.

I don't have a coding style. I simply write code which is required by the design.

Nor do I think that there's a war of coding styles where something is winning or losing.

... stop reinventing the wheel!

I've been hearing this since at least early 90-es, so 30 years give or take. Complete non-sense. Wheel is already invented and you cannot re-invent it. But you can make wheels better. Re-using tricycle wheels on everything from trucks to Ferrari is not such a great idea.

 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4081
  • Country: gb
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #28 on: January 22, 2023, 08:31:45 pm »
Anyway, that didn't last long.

The I2S was receiving data yesterday.  Today.  Nought.  It's clocking, it's not timing out, but all it gives me is 0.

I have the full SPI trace on teh scope and it can decode it.  It's the right format.  I've tried both I2S1 and I2S2 and both produce 0s.  It was working yesterday.

I've gone through all manor of combinations, speeds, clock settings, masterclock, no masterclock, I even dropped the CPU speed down to 120Mhz.  Nope.  Audio rate down to 48K and .. nope.

Putting it down tonight. 

Two ways to confirm things:
1. I'm going to connect an F411 back up to the same setup tomorrow.  If it works straight away it's likely I zapped the STM32H7.  I've only had it a few weeks and used it twice.
2.  I'm going to connect another I2S or a basic SPI source to it and see if that works.  I had it receiving from this setup before, but you never know.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5972
  • Country: es
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #29 on: January 22, 2023, 09:37:55 pm »
So you're coding on the fly and now you can't point the culprit of the failure?
Make a local git repo for any serious project, you'll never miss those "WTF did I change?" thoughs at all.
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 
The following users thanked this post: Siwastaja

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8194
  • Country: fi
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #30 on: January 23, 2023, 06:45:51 am »
This, use version control.

And whenever you forget to commit any changes and struggle to find what broke working code, don't admit it online!
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4081
  • Country: gb
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #31 on: January 23, 2023, 09:31:44 am »
I started a new project.  Setup CubeMX with an I2S.... 0s.

I went back to the previous project that was working, 0s.

So, no I haven't coded myself into a corner as I dont have any code in this project yet.  Just one single buffer declaration and an HAL_I2S_Recieve()

Other things may have changed, like I was playing with the formats on the optical side too.  Although I pretty much went through all possible combinations, even though I can see the format on the scope.

If it's zapped it's my own fault.  I don't treat them with that much care.  I wire them up while they are running and they tend to sit around on the desk wired up with the cat standing on them and things.  I might need to show a bit more care.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8194
  • Country: fi
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #32 on: January 23, 2023, 09:40:55 am »
I have seen an STM32 MCU physically fail in a very peculiar way with internal damage but working IO cell: namely, an IO pin worked perfectly in GPIO mode for both input and output, but once SPI peripheral was enabled as alternative function, only zero was read (or was it all ones, I forgot). Code was good and replacing the chip solved the problem.

But such issues are rare. 99% of the time it's in code. Which was also why I struggled with that one so much.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4081
  • Country: gb
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #33 on: January 23, 2023, 10:06:34 am »
I have seen an STM32 MCU physically fail in a very peculiar way with internal damage but working IO cell: namely, an IO pin worked perfectly in GPIO mode for both input and output, but once SPI peripheral was enabled as alternative function, only zero was read (or was it all ones, I forgot). Code was good and replacing the chip solved the problem.

But such issues are rare. 99% of the time it's in code. Which was also why I struggled with that one so much.

Ironically the post you made on here was the third google entry when I searched.

I'm not 100% sure yet, but I'm running out of options.  I'm 90% sure the software is not at fault as I've tried about 3 different projects that were receiving data and are now producing 0s.

I just need to complete the other side of the possibilities tree by using a different I2S source.  It could be an electrical issue a that I'm not seeing.  There is a leaking SMPS feeding 100VAC@1M into the grounds.  I did at the start of the setup yesterday connect the I2S lines to the MCU, while said SMPSU was in circuit, lines first.  GND second.  I actually forgot they were being powered by different power supplies and forgot I needed a GND. 

I know if everything is hooked up the amount of current flowing around from the SMPSU is literally microscopic and not a concern.  Where my concern lies is in when I connecting things up.  The MCU is earthed via the GND on the programming header.  The rest of the system is floating with the SMPSU.  Is it a likely failure mode if I was to, say, connect the MOSI line between these two circuits first.  That MOSI line will momentarily appear to be at a much higher voltage than 3.3V.  It won't carry much current sustained, but what capacitance is there and how much current flows through the data pin while it's equalizing.  Again, I probably wouldn't be concerned if I'd connected the GND first as it's just a bit of copper to earth and will carry the microcamps with no care in the world.  The data pin front ends on the MCU may not though.

And... no the scope ground was no connected at that point either which would have at least been pulling it all down to earth.
« Last Edit: January 23, 2023, 10:08:37 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline DavidAlfa

  • Super Contributor
  • ***
  • Posts: 5972
  • Country: es
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #34 on: January 23, 2023, 04:02:39 pm »
Tell me you're not using a breadboard full of wires!
15 years ago I was burning a lot of GPIOs in my PICs due that.
A wire slips, bang! Here goes 12V to the pin.
I remember labeling my PICs, marking the bad pins in red or directly cutting them  :-DD.
They weren't cheap either, the 16F84 was ~$6 sourced locally, I wasn't working either so I had to improvise, soon after I discovered the free samples!

BTW today was my first work day in 3 years, after a very long hell of recovery!  :)
Hantek DSO2x1x            Drive        FAQ          DON'T BUY HANTEK! (Aka HALF-MADE)
Stm32 Soldering FW      Forum      Github      Donate
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4081
  • Country: gb
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #35 on: January 23, 2023, 06:12:41 pm »
The breadboard amounts to 2 modules, 3.3V power and I2S interconnects.  No 12V or even 5V

The H7 SPI1 works, but not I2S.  Nothing I do makes it do anything but read 0.

I confirmed the stream with an old project and an F411 received the I2S and forwarded it to the H7 over SPI.  That all still works.

SAI1 Block A appears to work.  It's reading something at least.

To be honest, it's maybe fateful.  I really should be using the SAI blocks anyway.  It is they who have the FIFO threshold interrupts available.

I've run out of things to try.  I can strip comments from the code MX generates and post it later if it would help, but I'm off for dinner and some WoW.

Attached is the state the I2S always ends up in.  It says it's working to me.  It's RxFIFO is not empty because it's stopped on a breakpoint, it's raised it's RXP and it's data register is a big fat 0x0.  It always is.   As to why it's also saying it has a Tx packet and a duplex packet I'm not sure.

Note, no DMA my code is literally just:

uint32_t buffer[200];
HAL_I2S_Receive(&hi2s1, (uint16_t*) buffer, 96, HAL_MAX_DELAY);

I get 96 0s at the start of the buffer.
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4081
  • Country: gb
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #36 on: January 23, 2023, 10:06:22 pm »
So, SAIs (code below) works fine.

It's abit micky mouse, but it's Siwastaja's idea basically.  Not even bothering with interrupts. 

And as mentioned, when you change the incoming sample frequency or even change it to 24 bit it just carries on.  The exception being all my filters are tuned for 48k so sound sh1t.

I only have 1 source, but I don't expect a few being a problem.

As you can see I added a completely unnecessary bit of load in the first of 8 filter coefficient calculations.  It won't do 16.  It does 8.  Plenty of overhead.

The trickier part is you can't have all you can eat with 4 SAIs each with 2 blocks.  There are restrictions I still learning what I can't and can't do.

Code: [Select]
while (1) {
HAL_SAI_Receive(&hsai_BlockA1, (uint8_t*) buffer, 8, 10);
                /* Take the smug smile of the core's face */
for(int i = 0; i<8; i++) {
PeakFilter_SetParameters(&bassBoost, 50, 25, 1.6);
}


for (int i = 0; i < 8; i++) {

int32_t sample = buffer[i];  // FIX ME try floats/doubles, the maths might work better.
sample = PeakFilter_Update(&bassBoost, sample);
sample = PeakFilter_Update(&bassBoost1, sample);
sample = PeakFilter_Update(&midCut, sample);
sample = PeakFilter_Update(&highMidCut, sample);
sample = PeakFilter_Update(&highBoost, sample);
                        /* I am not a compressor and Im not even compressing till the compressor comes!*/
while(sample > 0x8FFF ) {
sample = sample/2;
}
buffer[i] = sample;  / precision loss.
}
HAL_SAI_Transmit(&hsai_BlockA2, (uint8_t*) buffer, 8, 10);
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Online NorthGuy

  • Super Contributor
  • ***
  • Posts: 3148
  • Country: ca
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #37 on: January 25, 2023, 04:14:47 am »
Attached is the state the I2S always ends up in.  It says it's working to me.  It's RxFIFO is not empty because it's stopped on a breakpoint, it's raised it's RXP and it's data register is a big fat 0x0.  It always is.

The OVR bit is set, which means it did receive enough of something to overrun the buffer. So, it sees a signal on the clock line. The fact that you receive all  zeroes means that the data line is always low (as seen by the SPI/I2S module). Possibly a wrong pin or a bad contact.

You can try to connect the data pin to VDD instead of the signal and see if your zeroes change to ones. This might give you an idea where the problem is.
 
The following users thanked this post: paulca

Offline STM32

  • Newbie
  • Posts: 9
  • Country: tr
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #38 on: May 24, 2023, 01:00:09 am »
Very interesting, informative topic.

Quoting the OP here:
Quote
if you give people too much information, enough to confuse and distract them, then the thread derails.  If you give the too little information they ask stupid questions and propose stupid solutions.
I totally agree with you! That's why I do not turn to discussion forums most of the time and I often find myself short of a solution, until I figure it out myself. Of course, it would be great to get some help, but most of the time, you will just get into an endless debate, that more likely ends up like a competition, and not "discussion". Well, my experience with another forum went way beyond the "too much info" and "too little info", as stated by the OP. It was way more horrible than that!

Well, in getting back to the topic, I believe my problem is very similar to the OP's. However, I'm not into mixing multiple I2S streams at the moment, it's just a simple audio playback. I just wanted to implement it using the double-buffering approach, without circular mode, halving a single buffer. Even on a low-end device, this approach seems more viable to me in the sense of having plenty of time to do processing, decoding, or whatever on bufferA while bufferB is being sent to the decoder by the DMA. I was struggling for the past couple days to figure it out, but to no avail.

I'm using the BSP driver code, which is based on the DMA in circular mode. First of all, could someone explain to me what is the difference/purpose of 'BSP_AUDIO_OUT_ChangeBuffer()' when compared to the 'BSP_AUDIO_OUT_Play'? As far as I can understand, it's only the macro
Code: [Select]
DMA_MAX(Size / AUDIODATA_SIZE) used on the latter. It took me also another day to find out that one takes nSamples while the other takes nBytes. This absolutely matters when you feed it with stereo samples in an int16_t ring buffer.

Aside from that, I still couldn't figure out what might be wrong with my setup. I was probably one of those confusing circular-mode DMA with double-buffering. I'm going to try it with different DMA configuration and see if that solves the audio playback issue when using double-buffering (two separate buffers, not halving a single one).

By the way, I might be interested to learn more about the feasibility of your multi-channel input/output/mixing/EQ approach on a single STM32. I believe you're working on a device with a large package, QFPA176, or BGA, to get 4 I2S streams available. On most smaller packages, I2S signals are muxed with many peripherals. In my situation, only one I2S is available. Most peripherals are used in the project, SDIO, QSPI, SRAM, LCD, 3 UARTS.


 

Offline peter-h

  • Super Contributor
  • ***
  • Posts: 3736
  • Country: gb
  • Doing electronics since the 1960s...
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #39 on: May 24, 2023, 10:33:08 am »
Quote
I have seen an STM32 MCU physically fail in a very peculiar way with internal damage but working IO cell: namely, an IO pin worked perfectly in GPIO mode for both input and output, but once SPI peripheral was enabled as alternative function, only zero was read (or was it all ones, I forgot). Code was good and replacing the chip solved the problem.

How is that even possible?

Could the CPU contain undocumented FLASH bits which enable some of the peripherals (so STM can sell the same silicon at different price points and with different P/Ns) and these got programmed with a runaway program?

As a general comment in the circular mode, it is very useful for waveform generation, going timer -> DMA -> DAC. Also useful for receiving data but more complicated (than a straight rx isr) to handle an rx overrun.
« Last Edit: May 24, 2023, 10:35:00 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8194
  • Country: fi
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #40 on: May 24, 2023, 11:13:16 am »
Quote
I have seen an STM32 MCU physically fail in a very peculiar way with internal damage but working IO cell: namely, an IO pin worked perfectly in GPIO mode for both input and output, but once SPI peripheral was enabled as alternative function, only zero was read (or was it all ones, I forgot). Code was good and replacing the chip solved the problem.

How is that even possible?

Beats me. ESD damage is one possibility, but it would have to damage some internal structures (input stage transistors at SPI peripheral, or at the MUX leading to the SPI peripheral) without blowing up transistors responsible of the GPIO functionality. It's not that far-fetched - basically the pin is fanned out to many paths leading to different internal parts, and unless the ESD even is strong enough to kill all of them, it could kill just the weakest one (some random path, depending on random process variation).

Quote
Could the CPU contain undocumented FLASH bits which enable some of the peripherals (so STM can sell the same silicon at different price points and with different P/Ns) and these got programmed with a runaway program?
Not impossible, but pretty unlikely, the firmware did have flash programming; runaway flash programming would have likely destroyed something else than just this.

Although it was such freak thing that even most unlikely scenarios are possible.
 

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4081
  • Country: gb
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #41 on: May 24, 2023, 11:32:21 am »
Some MCUs use "fuses" for configuration.  Is there a possibility and over-voltage spike on an IO pin "burnt a fuse" into a different config?
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8194
  • Country: fi
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #42 on: May 24, 2023, 11:38:25 am »
Some MCUs use "fuses" for configuration.  Is there a possibility and over-voltage spike on an IO pin "burnt a fuse" into a different config?

Some kind of undocumented actual fuse or flash-based "fuse" as suggested by peter-h, yes, possibly. As far as I know, there is no user accessible fuses that would cause what I saw.
 

Offline Georgy.Moshkin

  • Regular Contributor
  • *
  • Posts: 148
  • Country: hk
  • R&D Engineer
    • Electronic projects, modules and courses on Arduino and STM32
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #43 on: May 24, 2023, 02:32:28 pm »
I getting fed up with circular array buffers.  To be honest they cause more problems than they solve.
You just need the right information on how to use circular arrays optimal way. Over the past few years I used circular buffers for adc/dma/i2c/i2s/spi/uart/timer/dcmi. And not just for hobby, spi was for ethernet chip, and there was a loopback test. For uart it was dma bridge with protocol conversion, and it must run for days without glitches, for i2s it was audio over radio, and there should be time left for simple haar compression and resampling at receiving end, because either transmitter or receiver mcu had a little higher crystal frequency.

Here is the secret: you copy data to safe buffers on "half complete" and "complete interrupts". Processing in interrupt is an exceptional case. Safe buffer is then processed in the main loop. Safe buffer size is arbitrary. For low frequencies such as i2s you can even use memmove to keep arbitrary buffer of arbitrary size updated in a way of "sliding window". For faster signals you can use two indexes showing from where to where data need to be processed in a safe buffer, which is essentially is a large software circular buffer.

You can think of circular buffer as an external mcu which sends you chunks of data at some frame rate. Size of chunks does not matter, it's the same as copying files by chunks, file size may be arbitrary. If you are sending data over I2S it is the same, you prepare data in main loop and circular DMA will eat it by small chunks, you just need to put the data in right place at the right time. If "half complete", you know that the best time to fill first half with new data is came. When "complete" interrupt fired - the best time to fill second half of DMA buffer is started. Moreover, you can use MEM2MEM dma transfers to free up all this time in main loop for data processing. Or you can use memmove/memcpy, but these are too slow if you are pumping data from dcmi to spi, or just reading adc using dcmi or PSSI.

I did a lot of such data pumping and reliability tests, e.g. output safe buffer indexes through uart and showing percentage of unprocessed data in larger "safe buffer". Everytime the same approach.

Your approach may be interesting, but I am not convinced. Your list of possible problems reminded my own rants of younger age, I just needed the right information on many topics, but there was no ready made solutions, very frustrating. About hear damaging I would argue that rewriting DMA registers to make your approach work have more risk of garbling things.

Below is some code and links that may be useful.

Code: [Select]
   #define ADC_BUFFER_SIZE 1024
   
    // do not forget to place these buffers in DMA-accesible RAM
    uint16_t adcBuffer[ADC_BUFFER_SIZE] ; // for ADC circular buffer
    uint16_t adcBuffer2[ADC_BUFFER_SIZE]; // copied from adcBuffer using mem2mem
   
    volatile uint8_t idx=255;
   
    void m2mCallback(DMA_HandleTypeDef *_hdma)
    {
        // you can track mem2mem complete here, something like
        if (idx==2)  {idx=3;}
    }
   
    // ...
    HAL_DMA_RegisterCallback(&hdma_memtomem_dma2_stream0, HAL_DMA_XFER_CPLT_CB_ID, m2mCallback);
   
    while (1)
    {
        idx=0; // allow mem2mem
        while(idx!=3){asm("nop");
        // process data here
        // if processing fast enough, idx will be set to 0 before
        // HAL_ADC_ConvHalfCpltCallback
        // will be called again
        // idx=0 - need to copy, 1 - first half copy initiated,
        // 2 - second half copy initiated,
        // 3 - second half copy mem2mem completed
    }
   
   
    void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef* hadc)
    {
        if (idx==0) {
            // memmove(  (void *)&adcBuffer2[0],
            // (void *)&adcBuffer[0],
            // sizeof(adcBuffer)/2);
            HAL_DMA_Start_IT(&hdma_memtomem_dma2_stream0,
                    (uint32_t)&adcBuffer[0],
                    (uint32_t)&adcBuffer2[0],
                    sizeof(adcBuffer)/2/4);
            idx=1;
        }
    }
   
    void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc)
    {
        if (idx==1) {
            //memmove(  (void *)&adcBuffer2[ADC_BUFFER_SIZE/2],
            // (void *)&adcBuffer[ADC_BUFFER_SIZE/2],
            // sizeof(adcBuffer)/2);
            HAL_DMA_Start_IT(&hdma_memtomem_dma2_stream0,
                    (uint32_t)&adcBuffer[ADC_BUFFER_SIZE/2],
                    (uint32_t)&adcBuffer2[ADC_BUFFER_SIZE/2],
                    sizeof(adcBuffer)/2/4);
            idx=2;
        }
    }
 

https://community.st.com/s/question/0D53W00001hjcYgSAI/stm32h747-dma-linked-list-or-double-buffering-and-adc-interleaved

https://community.st.com/s/question/0D53W000016nboxSAA/spireceive-to-usbtransmit-via-dma-on-stm32h7

Offline paulcaTopic starter

  • Super Contributor
  • ***
  • Posts: 4081
  • Country: gb
Re: STM32 DMA FIFO bursts and timing tolerances.
« Reply #44 on: May 26, 2023, 08:25:24 am »
In my trade we pick patterns based on the problem being solved.

CircularBuffering or RingBuffering are one type of buffering pattern.

Double buffering is a different pattern.
Triple Buffering is a similar pattern.

n Buffering isn't really a thing.  Because that is the combination of two patterns.  A collection of buffers usually has an ordering mechanic to it, thus it is a Queue.  A Queue is a high level pattern type, like Buffer and could be a FIFO, a LIFO or a dynamic queue.  A fairness queue, a priority queue, a transactional serialising queue, and inoperatability queue....

Alternatively you could use a "pool" pattern around your buffers.  Such that you have have pools of free buffers, busy buffers and ready buffers.  A pool is basically a "bag" collection.  You just want one of the right type, so you reach into the bag and take anyone.  Yes that is an acedemic definition of an unordered collection where access to individual items is unavailable and only a random item may be recovered.  Similar to it's more specialised cousin, the Set which is a bag, which cannot contain duplicates, but you can only ask for a specific item, or take one out at a time.


The HAL Libraries come with a Circular pattern which is so broad grained it looks almost like a double buffer as it only have 2 "sections".  The difference between this fairly rudimentary "circular" buffer and "double buffer"'ing is semantics and details, but depending on where and on what you are writing they can become extremely important.

They also come with the DMA "Double buffer" mode.  And as you can call it sequencially with different buffers that allows for you to implement double, tripple buffering.  If you need more buffers, then you need to think in terms of queues or pools.

You may all be right in that none of the above engineering is required.  As it turned out this whole implementation, thanks to advice on here, went a completely different direction entirely.  With no buffers.  Processing sample by sample in real time in the interrupts!

EDIT:
Also of note.  Technically a circular buffer, if done correctly will allow WAY more than a fixed 2 independant access points.  In fact a very, very basic low level pattern is to have every element in the concurrent array read/write individually.  So your 256 byte array can have a read and write pointer for each element, protected for each other.  You can ever have multi-readers and multi-writers.

The parent topic to the above or where it is usually laid out, is in the Producer, Consumer patterns.  Slow consumer, fast producer.  Many consumers, single producer... and so on and so forth.  With in that you find all the different buffering, pools, queues and other patterns emerging.
« Last Edit: May 26, 2023, 08:38:04 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  STM32F411RE+ESP32+TFT for home IoT (NoT) projects.  Child's advent xmas countdown toy.  Digital audio routing board.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf