STM32U5 for precision DSP - Page 1
Forum section: electronics / general

author: davegravy
author_rank: Regular Contributor
timestamp: December 27, 2021, 04:55:21 pm
content: For my application I need to do a fair bit of digital IIR and FIR filtering on audio signals (~50kHz sample rate) taken from a discrete ADC via SPI. I also need to minimize power draw. I'm fairly new to MCUs and I'm looking through the offerings trying to find a good candidate to investigate further.I'm eyeing the STM32U5 for it's fairly good performance/power consumption ratio and the various DSP acceleration it seems to have. As this is a precision measurement device with significant dynamic range requirements, I think I need to do my DSP using 32 bit floating point samples.From my reading of the U5 documentation it does have an FPU, which is good, however most of the DSP acceleration (FMAC, SIMD, enhanced MAC) seem targeted towards fixed point 8 and 16bit sample data and won't be useful to me. Do I understand this correctly? Are there other MCUs I should consider that may be better suited to my application?

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 27, 2021, 05:29:58 pm
content: Quote from: davegravy on December 27, 2021, 04:55:21 pmIt is excellent in terms of performance/power consumption (AFAIR, it's even lower power than the previous L4 and L5 series, while being significantly more powerful). Now I haven't really looked at the "DSP" features it has.Quote from: davegravy on December 27, 2021, 04:55:21 pmJust a quick reply to a "quick" statement: using single-precision FP is not necessarily the best way of achieving accurate results. But we'd need to know exactly what it is you're going to compute and what you requirements are.Quote from: davegravy on December 27, 2021, 04:55:21 pmI was going to talk about that exactly. And see my reply above. Fixed-point is certainly a valuable option in many cases, actually. Now I'll have a look at what the U5 offers exactly. But even if it has operations on 16-bit fixed-point maximum, you can certainly use that to implement wider fixed-point while still being more efficient than hand-implementing it using integer operations only.

author: davegravy
author_rank: Regular Contributor
timestamp: December 27, 2021, 05:46:39 pm
content: Quote from: SiliconWizard on December 27, 2021, 05:29:58 pmIf it helps, my requirements will be very similar tothis hackaday project. An IIR equalization filter to correct the frequency response of a microphone (yet to be selected & evaluated), an IIR filter to A-weight the signal, potentially also an FIR decimation filter to reduce the sample rate out of the ADC by 2 or 4x, and a running sum of squares to calculate RMS over an interval. The author landed on single-precision floating point though it looks like that was maybe partly related to compiler issues with the ESP32 target.A while back I came across an article about PowerQuad on recent NXP processors and very good floating point benchmarks I think relative to STM32. I'm struggling to re-find the article.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 27, 2021, 06:14:45 pm
content: All of this can certainly be implemented with fixed-point.Actually, doing "embedded" DSP with floating point is something relatively "recent". Many older DSPs (let alone MCUs) did not have floating point units.But that said, looking at the above project, I'm pretty sure a reasonably powerful MCU could do it in real time with FP, even if it has no FPU! Software-emulated FP could very well be alright for this (would depend on the number of coefficients for the filters, but IIR filters rarely have that many). So if it has a FPU, then you should not even bother using accelerators or such. It should be plenty enough as it is.

author: ogden
author_rank: Super Contributor
timestamp: December 27, 2021, 06:16:12 pm
content: Quote from: davegravy on December 27, 2021, 04:55:21 pmIn addition to already asked questions: How many channels and bits for audio signals? "Fair a bit" means close to nothing because you can run one IIR filter or many, also FFT performance differs depending on filter size, number of taps. Please be more specific.

author: mark03
author_rank: Frequent Contributor
timestamp: December 27, 2021, 06:41:11 pm
content: You'll find things much easier to get up and running with floating point. In addition, there is little if any speed advantage from fixed point on an MCU with FPU. If you are not overly power constrained, I would look at the STM32H7, particularly the "value line" parts which were very attractively priced. Of course, the supply situation overrules all other advice here. STM32s are especially hard to come by, so if you need this in the short to medium term, you'll most likely be stuck with whatever you can find.I would not consider STM32U5 unless power minimization (battery life) is paramount. I've had a cursory look at the accelerator hardware and I'm not convinced it is much of a help in your use case. Also, you'll want to use the ready-made DSP functions (FFT, FIR/IIR filtering, ...) in the CMSIS DSP library, and I am next to certain they have not been re-written to take advantage of the fancy hardware.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 27, 2021, 06:55:42 pm
content: 50 kHz is 20 us per ADC reading, that is 3200 CPU instructions at 160 MHz. If you devote half of that to calculations it's 1600 instructions per ADC reading. Whether it's enough or not depends on the number of filters and the number of taps in your filters. Most likely it's not only enough, but a huge overkill for your application.You don't really need floating point for filters and RMS calculations - integer arithmetic is enough. 32-bit is probably too much resolution for audio. 16-bit is reasonable, so you can use DSP. Single precision floating point will give you 23-bit, which is plenty. When you have time to spare, it doesn't really matter whether you use floating point or integers.

author: davegravy
author_rank: Regular Contributor
timestamp: December 27, 2021, 07:14:50 pm
content: Quote from: mark03 on December 27, 2021, 06:41:11 pmLow power consumption is very important which is why I'm looking at the u5. Financial cost for the part is not a significant constraint as it'll be a low volume run and it's replacing an existing system that's quite expensive.Should I take what you're saying regarding CMSIS not being updated to mean I'd likely need to implement my DSP directly in assembly if I want to take advantage of this hardware acceleration?

author: davegravy
author_rank: Regular Contributor
timestamp: December 27, 2021, 07:19:25 pm
content: Quote from: ogden on December 27, 2021, 06:16:12 pmSingle channel of audio coming from a 24 bit ADC (but ENOB probably around 18-20). Not sure about FIR filters yet and number of taps, but 2 or 3 iir filters each implemented as 2-3 stage second order sections. See the reference hackaday project I linked in an earlier post in this thread.

author: mark03
author_rank: Frequent Contributor
timestamp: December 27, 2021, 07:32:01 pm
content: I would still start with single-precision floats and the CMSIS library, then once you have that working, you could investigate if moving to hardware accel and fixed point is worthwhile.

author: davegravy
author_rank: Regular Contributor
timestamp: December 27, 2021, 07:39:42 pm
content: I'm needing a dynamic range of at least 110dB which I thought precludes 16bit. Thanks for the time estimations it sounds like I shouldn't be too constrained.Quote from: NorthGuy on December 27, 2021, 06:55:42 pm

author: Marco
author_rank: Super Contributor
timestamp: December 27, 2021, 07:48:59 pm
content: It has a 16x16 multiplier with a 24 bit accumulator. It's generally the accumulator which will determine the dynamic range.That said, even without the fused multiply add and fast loop support you get if you used the fixed point FMAC it should be more than fast enough using the FPU. FPU code will probably use 3x the cycles, but meh.

author: errorprone
author_rank: Contributor
timestamp: December 27, 2021, 08:19:07 pm
content: The PowerQuad peripheral is part of the LPC55S6x family of parts. I evaluated the part but didn’t end up using it. From what I remember it supports both floating and fixed point operations but it was not memory mapped. To use it you had to copy data to the peripheral and then copy back.

author: commie
author_rank: Frequent Contributor
timestamp: December 27, 2021, 09:02:03 pm
content: Quote from: Marco on December 27, 2021, 07:48:59 pmThe 89lp52 8-bit Harvard has a 16x16 mac 40 bit unit, so much for 32bit power, what a joke.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 28, 2021, 04:13:29 pm
content: The whole point (pun intended) in floating point is ease of code writing so that you don't "need" to think about ranges your variables live in. In order to really leverage that effect, you should use an overkill float format, basicallydoublefor everyday tasks.Once you use single-precisionfloat, you already are in muddy waters regarding accuracy. So you need to startthinking. In which case, fixed point could prove easier.With fixed point, you are just forced to think about the ranges. You decide how much one LSB matters (in whatever units, is it x millivolts or y Pascals) and then you know what is the maximum possible value before saturation clips the result (youneed to write that saturation logic) or worse, the number wraps around, showing complete potatoes instead of expected result.OTOH, that can be easily done on Excel or even a napkin, so it's not rocket science or difficult; just some work.On the other hand,float"automatically" switches to higher range if your number wouldn't fit, but this also means accuracy is automatically reduced. Working with huge and small numbers at the same time may produce surprises when you just expect perfect results. With fixed point, you are pretty much "forced" to do that verification beforehand and surprises are avoided.In case of FIR/IIR filters where you can guarantee that all coeffs are not much beyond 1, you can just choose the fixed point range to cover from -2.0 to (+2.0 minus 1 LSB). This is quite optimal for memory use, compared to float where you would always waste space on the exponent field.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 28, 2021, 06:32:07 pm
content: Quote from: Siwastaja on December 28, 2021, 04:13:29 pmAgreed. Good points. Better yet, unless, as you said, you use overkill-precision FP so you don't have to really bother, FP can actually be much trickier to reason about than fixed-point (if you care about accuracy, that is, and do not just use FP as a cargo cult tool "that should be good enough".) Yeah, the floating point gives you a wide range of values for "free", but the resulting precision you get on a given calculation is not easy to figure out.I for one practically NEVER use single-precision FP. When I really need FP (for whatever reason), I use double-precision FP only.The only cases I've used single-precision FP were occasionally on small targets that have an FPU, for things like PIDs, for which accuracy rarely matters a whole lot. And with the embedded FPU, that would be faster than using fixed-point.Fixed-point is still widely used in DSP.But again, back to the OP, even an STM32U5 is a powerful beast for the task at hand IMO. I'm pretty sure you could do what needs to be done in real-time using software-emulated double precision floating point. It's just a couple filters and a RMS calculation, as far as I've seen.

author: NorthGuy
author_rank: Super Contributor
timestamp: December 28, 2021, 09:35:16 pm
content: I don't agree that you need lots of thinking to do DSP with integers. Typically you get ADC values which are integers of a known length. You then use whatever units you had in ADC and do all the analysis (such as IIR/FIR filtering). There's no loss in precision and you get the results in the same units as ADC. Then you just scale the results as needed. This is all there's to it.I think most people use FP when they want to work with rational numbers. I guess such approach is thought in schools. Also, for some reason most people believe that FP are somehow more precise than integers while the opposite is true.

author: davegravy
author_rank: Regular Contributor
timestamp: December 29, 2021, 02:01:27 am
content: OK so to summarize what I think I've learned:1) Fixed point is likely an option, not just floating point.2) From a processing resouces perspective the DSP I need to do should be easily achievable even without any hardware acceleration. Floating or fixed point.Out of curiosity, if I wanted to go with fixed point and to leverage the hardware acceleration, given that it seems limited to 8 and 16 bit is this even feasible? Marco mentioned the accumulator is 24bit which drives dynamic range but I don't quite understand this. If I have to transform the 24bit values I get from my ADC into 16 bit to pass through these filters then I am throwing away needed dynamic range the DSP isn't going to recover right?I did notice there's one SIMD instruction that operates on signed 32bit integers:https://www.keil.com/pack/doc/CMSIS/Core/html/group__intrinsic__SIMD__gr.html#gaea60757232f740ec6b09980eebb614ff

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 29, 2021, 02:23:46 am
content: Quote from: davegravy on December 29, 2021, 02:01:27 amOf course, if you truncate the samples, the extra bits will be lost forever. That is why I suggested - without saying how exactly, because I admit I don't know much about STM32's FMAC stuff - that you could probably use the acceleration, but would need to take extra steps, like executing multiple operations instead of just one. I'd just have to take a closer look at the FMAC to see what would be possible.But yes, although I'm not quite sure about the whole exact processing chain for your project, it would probably work even without any accelerator on a M33 @160 MHz.Quote from: davegravy on December 29, 2021, 02:01:27 amYes, this is the intrinsic for this instruction:https://www.keil.com/support/man/docs/armasm/armasm_dom1361289901101.htmI don't know how many cycles it takes though. Not quite sure how "SIMD" it is either, as this is a 32-bit CPU and SIMD usually operates on 32-bit words to compute operations in parallel for 2 16-bit or 4 8-bit chunks. Someone knowing the Cortex-M assembly better can maybe answer this. In any case, since the instruction is there, it's probably more efficient than doing it in several instructions.But thinking about it, I seem to remember that the Cortex-M ISA has no instruction for getting the upper 32-bit value of a 32-bit x 32-bit multiply (if someone knows better please correct me!), so to get the same as this SIMD instruction would surely take quite a few regular ARM instructions!

author: emece67
author_rank: Frequent Contributor
timestamp: December 29, 2021, 10:02:58 am
content: .

author: Siwastaja
author_rank: Super Contributor
timestamp: December 29, 2021, 11:13:09 am
content: Quote from: NorthGuy on December 28, 2021, 09:35:16 pmYeah, really, usually it's little work, I agree with you. FIR and IIR just happen to be so simple that figuring out the ranges of fixed point number systems takes 5 minutes on a napkin, if even that. Ease of development wise, there is not much to be gained. But obviously a beginner needs to be careful. Usingdoubleeverywhere makes certain footguns just disappear. Numbers won't just wrap around when you expected to get 1.97 but actually got 2.01. But IMHO, it's better to fall into those traps sooner than later.Fixed point is specifically suitable for typical DSP work exactly because of the simplicity of the operations, and ease of analysis (for example, because coeffs are compile time constants, or at least constrained over known ranges).Now I wouldn't use fixed point for every program in universe, though.Your comment of floating points numbers being less accurate is a good one; this is, given same number of bits, and hand-optimizing the range of the fixed-point number by knowing the use case. By using double, we just lazily use enough bits. But fixed point int64_t with carefully chosen gain term would allow even higher accuracy.And in real life, it often happens that int32 can replace a double, halving memory footprint, and possibly enabling 64-bit wide SIMD instructions.

author: davegravy
author_rank: Regular Contributor
timestamp: December 29, 2021, 05:05:04 pm
content: This thread got me interested in trying to design a fixed point version of the of the filters from the Hackaday project I linked earlier. I'm not clear on the best method to simulate / evaluate the design without implementing it on the actual target. Actually, even if I did implement it directly on the target I'm not sure what are the important tests to run to catch the typical issues with fixed point.I would assume you want to run some impulses through with varying amplitude and confirm the impulse response matches expectation. Is there anything else?In terms of simulating on PC, is there anything good besides MATLAB (which I don't have a license for) and Labview? I have Labview and tried to follow this:https://documentation.help/Digital-Filter-Design/design_fxp_filter_6.htmlBut it seems pretty opaque in terms of how it's converting the floating point filter to fixed point, and the simulation test stimulus seem to be floating point values - it's unclear how these are being converted to integer values before hitting the filter input so I have no idea what range of amplitudes to test.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 29, 2021, 05:16:50 pm
content: Quote from: emece67 on December 29, 2021, 10:02:58 amAh thanks. I don't know the M33 much yet. The M33 is Armv8-M based, while older Cortex-M4 and M7 are Armv7E-M based.Was I right remembering that the latter do not have direct support for getting the most significant 32-bit word of a 32x32->64 multiply? That rings a bell, but I'd have to check. Maybe it was the case for the M0 (which is Armv6-M), and that's where I remembered this from. I still don't know all the minute differences between all variants of the ARM ISA, while I now know the RISC-V ISA much better.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 29, 2021, 05:20:30 pm
content: Quote from: Siwastaja on December 29, 2021, 11:13:09 amNah, I agree with the fact is not nearly as easy to implement correctly. You need to be careful with ranges at all steps of all calculations. It's not rocket science, but it's definitely harder and can lead to a nice range of bugs. You just need to know how to do it. And yeah, using floating point, you almost don't (although, as I said, it can still be ridden with traps if precision matters). FP is for the birds, as someone would say.

author: dietert1
author_rank: Super Contributor
timestamp: December 29, 2021, 06:19:36 pm
content: Arm Cortex MCUs support single cycle 32-bit integer operations and make perfect audio DSPs, even without using floating point nor multiple operand acceleration. In the past we had to use 16 bit or 24 bit or loose performance. 24 bit is the precision you will get using floating point. Better use 32 bit integers and manually keep track of amplitude. As far as i remember there is even a single cycle multiply and add to help for filters. Often filters are short loops, so performance-wise instruction cache may be more relevant than FPU.Regards, Dieter

author: Jeroen3
author_rank: Super Contributor
timestamp: December 29, 2021, 07:14:20 pm
content: Based on my limited experiences with fixed point is that you're not really gaining any speed over floating point if you don't properly matrix your operations.What I found is that you lose a lot of the benefit from the "single cycle integer" instructions by the fluff around fixed point. Such as wrapping, shifting and and saturating.You'd basically have to use the arm math library or write some highly specific code, perhaps with some assembly in between, which is a drawback for testing and modifying.Of course, without FPU floats are impossible to do quickly.Single precision floating point is faster if you have an FPU, the slowest part in there is getting the datatothe FPU. It's trivial to write C with a bit of unrolling and operands in the right order to have it executing quite quickly.Simulating your DSP concepts can be done with python. You can use thenumpy typesand plot your results with matplotlib.There is also scilab, which is free and is like matlab. But lacks all the popular examples so it more difficult to get going with.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 29, 2021, 07:42:02 pm
content: Quote from: Jeroen3 on December 29, 2021, 07:14:20 pmYes, of course. It will usually be actually worse in terms of speed if the CPU you use has an embedded FPU, unless it also has a specific fixed-point accelerator, that happens to deal with the fixed-point format(s) you need to use. A number of ifs.OTOH, if there is no FPU available, fixed-point is definitely better in terms of speed in most cases. I implemented a fixed-point FFT for a RISC-V core with no FPU - a 256-point FFT was at least 20 times faster than the same using emulated floating point, IIRC, while accuracy was on par.If not for speed, the whole point is controlling precision at all steps, something extremely hard to do with floating point. (Which is why, as we said above, you otherwise use floating point with an overkill precision just to make sure it'll be ok, but it's a bit of a wet-finger approach =) ).

author: Siwastaja
author_rank: Super Contributor
timestamp: December 29, 2021, 08:16:45 pm
content: Indeed, if you have to saturate and the instruction set does not have saturating instructions, that's a colossal waste of time, especially if you need to do it at multiple steps. But really the algorithm implementation should be so that saturation is needed only as the final step, once per output sample, if at all possible.Inputs coming from real-world sources are always constrained to begin with and coeffs are constrained, all that is needed is to saturate the output (or even better, guarantee by running worst-case numbers that output never wraps around and doesn't need saturation).This being said, even if your processing is in floating point, the output often needs to be saturated or range checked anyway, so the same work needs to be done.Floating point sometimes have performance benefit over integer due to the fact that many cores (Cortex-M MCUs for example) come with a lot more FPU registers than general purpose integer registers; and they are all free to use, not being wasted in trivial things like loop counters.For example, I hand-wrote decimating FIR filter in assembly, where all the accumulators were in single precision floating point registers (32 registers is massive number of single-cycle storage, without need of load/stores!), eliminating a lot of load and stores. With the loops unrolled, code running from ITCM, and coeffs being loaded from DCTM as a dual-issued (cortex-m7) parellel operation, the performance basically is that of a classical dedicated DSP, even on "just" a general purpose MCU.But sure, at some point you run out of those 16 (DP) / 32 (SP) registers and can't avoid memory loads and stores. In that case, if you can load four 16-bit values in one go with 64-bit wide AXI bus and then utilize integer SIMD instructions to do whatever you need, fixed point performance will greatly exceed the floating point version.So the answer really is,it depends.

author: Jeroen3
author_rank: Super Contributor
timestamp: December 29, 2021, 08:26:14 pm
content: I compared the performances of the cortex m types with various common operands I use.Fixed point is basically the same speed over m3/m4/m7, m0+ is a bit slower. You're looking at max 10 cycles per raw operand, but when you add the fluff oflibfixmathyou're around 100 to 350 cycles per operand.I agree with the precision. Using float you can have strange rounding sometimes or funny stuff when the numbers go big. But also NAN which you have to check for sometimes.otoh, NAN and INF can also be used to your advantage.

author: emece67
author_rank: Frequent Contributor
timestamp: December 29, 2021, 09:00:48 pm
content: .

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 29, 2021, 11:01:35 pm
content: Scilab is the closest "clone" actually.https://www.scilab.org/But yes, there are tons of other options, like Octave, or using C, or your favorite interpreted language - although it might be harder to properly emulate fixed point with some of the latter, for instance.But well, if the OP is looking for a point-and-click tool, such as what he linked to, that's something else...

author: davegravy
author_rank: Regular Contributor
timestamp: December 29, 2021, 11:18:06 pm
content: Quote from: SiliconWizard on December 29, 2021, 11:01:35 pmThanks for the suggestions, I will investigate these. No need for point and click interface, Labview is just what I happen to have.Any recommended learning resources would also be appreciated. I know fundementals of digital filters from my undergrad EE degree years ago but have limited knowledge of practical design issues such as those we've been discussing,as well as testing methodology.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 29, 2021, 11:35:22 pm
content: Quote from: davegravy on December 29, 2021, 11:18:06 pmOK then... Scilab is routinely used in universities over here for DSP courses, and then people keep using it at work. It's gotten pretty good, and frankly more than enough except if you need very specific Matlab tools or packages. Not the case here IMO.You'll find a lot of free resources online. Otherwise, there are also many seminal books.Two of them are the classic "Theory and Application of Digital Signal Processing" (Rabiner) and "Digital Signal Processing" (Oppenheim)

author: NorthGuy
author_rank: Super Contributor
timestamp: December 30, 2021, 03:48:21 pm
content: Quote from: davegravy on December 29, 2021, 02:01:27 amSIMD stands for "Single Instruction Multiple Destinations". Say, instead of one 32-bit operations a SIMD instruction can perform two 16-bit operations at the same time. In theory, you can use SIMD to speed things up, but simply using compiler intrinsics won't help you. You need to ensure that you don't waste instructions on loading/storing etc. The best way to do this is assembler. But the looping is the biggest overhead anyway, so you wouldn't get much even if you tried very hard.With 24-bit data, you would simply use 32-bit data and possibly 64-bit accumulator. The C code wouldn't be much different from the code you would have with doubles:Code:double a,x,y;a += x*y;Code:uint64_t a;uint32_t x,y;a += x*(uint64_t)y;Either way, in your case, there's no need to worry about efficiency.

author: errorprone
author_rank: Contributor
timestamp: December 30, 2021, 06:16:13 pm
content: Easiest way to utilize the built in DSP instructions is to use the CMSIS libraries. Here are some benchmarks of the CMSIS FFT vs KIssFFT with different data types.http://openaudio.blogspot.com/2016/09/benchmarking-fft-speed.html?m=1

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 30, 2021, 06:23:49 pm
content: Quote from: errorprone on December 30, 2021, 06:16:13 pmThe ARM DSP extensions yes, but I doubt CMSIS uses any proprietary accelerator such as STM32's FMAC. If that's what the OP wanted to use.But yes definitely - as several of us said - the OP probably doesn't need any acceleration or even DSP instructions for what he wants to achieve. But having a look at CMSIS libraries is not a bad idea. I've always shied away from them myself, but maybe there was no good reason.

author: Siwastaja
author_rank: Super Contributor
timestamp: December 30, 2021, 06:40:34 pm
content: CMSIS DSP library is of course fine if what you need is a use case where you have input buffer and output buffer so then you can just call one function and save the "hassle" of writing the 5 LoC FIR/IIR implementation. And if you are lucky, the CMSIS implementation might be faster, too.In real world embedded systems though, it's quite typical samples come and go in which case using such library becomes impressively difficult for a beginner (are you supposed to create two buffers and manage between them seamlessly?), whereas implementing FIR/IIR is just a few lines of code so you can do it in "new sample" IRQ handler or whatever you need. So again, it depends.In any case, avoid premature optimization (unless that is what you want to learn). My suggestion: write normal FIR/IIR implementation (a few lines of code) without any special tricks. Try it. Is it too slow? Only then try to optimize it.You can ballpark-approximate the filter performance as 20 CPU clock cycles per coeff per sample. Such napkin calculation is useful before committing your time to even trying it.Exact details like memory bus latency then matters. For example, if the core has separate core-coupled piece of RAM, put coeffs there. Another option is enabling cache because coeffs will definitely end up in the cache after the first loop iteration.

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 30, 2021, 06:51:10 pm
content: One of the main reasons I never used those CMSIS libraries is that I favor portable code as much as possible. If some specific instructions/features for a specific target are needed for performance reasons (and I make sure I really need the extra performance to begin with), I'll just use C intrinsics (or assembly if really anything else fails), and/or isolate the specific code as much as possible, so that porting it to another target would still not be a major pain. Oh, and this approach also tremendously helps testing your code on a different target - typically, on PC, something I do quite often. Try testing code that relies on CMSIS libraries on a PC...

author: Siwastaja
author_rank: Super Contributor
timestamp: December 30, 2021, 07:14:38 pm
content: Yeah, for libraries, you would need to be sure it exists - and behaves 1:1 - for each platform you use, including unit testing etc. Then you usually need to follow some installation steps, sometimes as easy as just including a header-only library, sometimes a tad more difficult (especially if cross compilation is involved).So consider the amount of work writing from scratch vs. installing, learning how to use, and maintaining the library. If a library saves 5 minutes of work, it's very unlikely to be useful. OTOH, if it saves 1000 hours, the choice is obvious.People often completely ignore this aspect when giving out the "use as many libraries as possible because you don't want to reinvent the wheel" lecture.

author: emece67
author_rank: Frequent Contributor
timestamp: January 01, 2022, 11:09:13 pm
content: .