Raspberry Pi Pico RP2040 vs STM32 - How to digital filtration? (FMAC)  - Page 1
Forum section: electronics / general

author: WaveletSea
author_rank: Newbie
timestamp: September 24, 2021, 07:42:45 pm
content: I was reading the datasheets ofRaspberry Pi Pico RP2040and to my big surprise there's no such thing as FMAC for digital filtration like on the very cheap and accessible STM32.Arrived at this point a question has rised in my mind regarding this kind of trouble -RP2040 is not filled with it's own FMAC module when compared to STM32,so at this point how we are supposed to do our digital filtration stuff on the RP2040 microcontroller?For more infos take a look here :https://www.st.com/resource/en/application_note/dm00605584-digital-filter-implementation-with-the-fmac-using-stm32cubeg4-mcu-package-stmicroelectronics.pdf& Also here :

author: floobydust
author_rank: Super Contributor
timestamp: September 24, 2021, 09:12:15 pm
content: Look at how many timers the RP2040 has, it's more of a toy. I would say it's not for any real-time embedded applications.

author: WaveletSea
author_rank: Newbie
timestamp: September 24, 2021, 09:42:28 pm
content: I've make the same question inside official Rasperry Pi Reddit and it got deletedat this point it looks like their either are not really proud of this RP2040 MCU

author: langwadt
author_rank: Super Contributor
timestamp: September 24, 2021, 10:18:57 pm
content: Quote from: WaveletSea on September 24, 2021, 07:42:45 pmin software like it has been done for decades (and still is) in the numerous MCUs that doesn't have any special filter hardwareFMAC is a special feature of few newer STM32sodd question really, how do you suppose the millions of MCUs that doesn't have an FPU do floating point?

author: WaveletSea
author_rank: Newbie
timestamp: September 24, 2021, 10:52:13 pm
content: Quote from: langwadt on September 24, 2021, 10:18:57 pmWhy my question should be odd ?I was just asking if the top notch of MCU from Rasperry can or can't do such thing ... nothing of odd here,just a simple curiosity from a man who wish to get in to it.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 24, 2021, 11:13:14 pm
content: Uh. DSP can be done on CPUs with no FPU and no accelerator whatsoever. This is routinely done.You can do DSP even on an 8-bit CPU. Compared to many MCUs we used even 15 years ago, the RP2040, being a dual core M0+ (if I'm not mistaken) that can be clocked at up to 133 MHz, a lot can be done!If you don't know how to do that, you can even use the CMSIS libraries.Indeed, the FMAC thing is a recent feature found on the STM32G4 - a lot of other STM32s don't have this. Oh, and the FMAC is not FP either as far as I've seen - it's merely a fixed-point coprocessor of some kind.It's all in whether a given CPU can fit given requirements. It's not at all in whether a given CPU embeds a particular coprocessor.And with that said, it's hard to compare a G4, which is Cortex-M4 based with a FPU and various peripherals (and yes, a FMAC), with a RP2040, which is just Cortex-M0+-based, even if it's dual core. Two different worlds. Still, I bet a lot can be done on a RP2040 if used properly, I'm sure you'd be surprised. Of course don't expect the same performance. But why not compare it to a Cortex-M7 MCU with FPU, DSP instructions, and 1MBytes of core-coupled RAM while you're at it?

author: westfw
author_rank: Super Contributor
timestamp: September 24, 2021, 11:32:10 pm
content: QuoteThis is the first I've heard of an MCU with a special FMAC processing. It seems pretty uncommon (although the CM4 core has some "DSP instructions")The STM32G4 is a Cortex-M4 with floating point (in addition to the FMAC and "Cordic Co-processor"); the sort of chip you'd use for low-end DSP applications.The RP2040 is NOT a "top notch" MCU; it's RPi's FIRST entry in the MCU market, a low-end ($1) chip based on a Cortex-M0 core, with a couple of interesting features added (Lots of RAM, Divide accelerator, PIO, dual cores, QSPI XIP, faster FP functions in ROM.) The sort of chip you'd aim at a non-DSP application.Different Application Space.You might as well complain "how come the STM32G4 series is 3 times the price of an RP2040 but doesn't even have a bit-banging accelerator like the PIO?"(Why do such questions seem to always be worded in such aconfrontationalmanner?)

author: ataradov
author_rank: Super Contributor
timestamp: September 25, 2021, 03:45:06 am
content: But the "first" here is the key. RP2040 is just a test device to see if it is even viable for them to make ICs. It is clearly under-featured even for being entry level CM0-based device.I would expect the next one to be much more capable and close to something that may be considered for real production devices.For now, it is just a cool toy. Treat it as such.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 25, 2021, 05:33:19 pm
content: Quote from: ataradov on September 25, 2021, 03:45:06 amThat's right. (Even though I have no clue about the "next one" or if there will even be one, we'll see.)Now, certainly a lot can still be done with this toy. As I said, even if modest compared to powerful MCUs, it still has a lot more power under the hood than most MCUs we used a decade ot two ago, and we could still manage to do many things with those.You can certainly run digital filters in real-time on a RP2040. Don't expect obviously to match a STM32G4 or even just a Cortex-M4 MCU, but still. And the second core could even be used exclusively as some kind of coprocessor. It's a dual core Cortex-M0+. The M0+ is no beast, but certainly already better than the original M0. I don't have a lot of time or interest in the RP2040 right now, but to make a point, I'd even be tempted to implement a cool audio effects processor with it. Heck, IIRC, someone here did this with an AVR. With the RP2040, I'm pretty sure we can run some already cool effects. One core could be dedicated to all the signal processing, while the other would be used for I2S I/O and the UI...

author: MT
author_rank: Super Contributor
timestamp: September 25, 2021, 07:50:02 pm
content: Quote from: ataradov on September 25, 2021, 03:45:06 amWhy do you define it as cool toy? compared to what? Z80. When is something not a toy?

author: ataradov
author_rank: Super Contributor
timestamp: September 26, 2021, 04:02:26 am
content: Quote from: MT on September 25, 2021, 07:50:02 pmI'm comparing it to other modern MCUs in the similar performance range.And when you compare, you can clearly see a lack of peripherals. Timers are the most obvious ones. It is ok for a highly specialized MCU to be somewhat limited in peripherals, but not for a general purpose MCU.Code security is also important in most real-world production cases. While not much is stopping cloning of high-value products even with code security of typical MCUs, simply giving away your firmware is not great.And more importantly is commitment of the vendor. What if I want to have CAN or Ethernet in a future? Why would I commit my product to an MCU with no clear growth plan. I'm fine if there is nothing right now, the vendor can grow as my needs grow, but I need to see that growth is even planned. Otherwise I'll just go with the established vendor.And documentation has to be improved too. At first RPi datasheet looked fresh and new, but as you try to work with it, the advantages of the traditional datasheet that simply describes the hardware become more obvious.And one more thing - different package and pin count options. Limited packaging is normally a sign of a highly specialized IC with set use cases. General purpose MCUs need options to cover wide range of applications. But in a hobby world, you just deal with it, and it is fine.

author: langwadt
author_rank: Super Contributor
timestamp: September 26, 2021, 06:02:52 pm
content: Quote from: ataradov on September 26, 2021, 04:02:26 amI haven't used it or had more than a cursory look at it, but it seems like lack of peripherals can made up for with the PIOs which seems quite versatile, especially if used together with one of the cores

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 26, 2021, 06:15:17 pm
content: Quote from: langwadt on September 26, 2021, 06:02:52 pmWell, yes, but if you need more advanced peripherals such as Ethernet as langwadt mentioned, then it's out of the question. To be fair though, many other MCUs don't have Ethernet. But PIOs are pretty cool indeed.I think that the biggest issue is the lack of timers that some mentioned. As far as I've seen, there is only ONE timer. That's pretty limited. But as I said, I'm pretty sure you can still do a lot of cool things with it. Point is, only ONE package, only ONE timer, limited number of IOs, ... it's hard to think of this chip as more than a prototype.

author: rstofer
author_rank: Super Contributor
timestamp: September 26, 2021, 08:48:08 pm
content: It might also exist to provide interest in MicroPython. There are other platforms but this one has a book:https://www.amazon.com/Get-Started-MicroPython-Raspberry-Pico/dp/1912047861Apparently, there is some MicroPython work being done on the Teensy's. At 600 MHz, the Teensy 4.1 using an ARM M7 is pretty quick.https://www.pjrc.com/store/teensy41.html

author: westfw
author_rank: Super Contributor
timestamp: September 27, 2021, 12:16:25 am
content: QuoteSomeone wrote code to drive an Ethernet Phy chip via RMII using the PIO... Impressive, and probably dangerous...QuoteOne "Timer" (64bit!), eight PWM "slices" that can do some timing functions (or generate up to 16 PWM outputs at 8 different frequencies.) One RTC. One SysTick. Nothing with "capture" capability, though. And the PIO.I've never really understood why some MCUs have SO MANY timers (and of different types.) Sure, there's "motor control", but...Maybe I'm just spoiled by coming along late enough that most timing functions can be done in SW.

author: AndrewBCN
author_rank: Frequent Contributor
timestamp: September 27, 2021, 06:06:09 am
content: Quote from: westfw on September 27, 2021, 12:16:25 am1. Some MCUs have many timers of different types because that provides more flexibility in handling a large variety of tasks, so these MCUs can be used in a wider range of applications.2. Because of its lack of peripherals the RP2040 is more of a "toy" MCU because it doesn't compare to the huge MCU lineup from established vendors, that cover almost any application at any price point.3. No, most timing functions cannot be done in SW, it's actually exactly the other way around in most cases: most non-trivial applications require a number of timers in hardware, and the more powerful these timers are the better. Of course if you are just blinking a LED a single basic timer works fine, and since this is the case for most beginners, the RP2040 should do fine for its intended market.4. The RP2040 is intended and will be successful for a specific, narrow niche market, in which it will settle down after the initial hype wears off.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 27, 2021, 05:22:00 pm
content: Additionally note that the only general-purpose 'timer' in the RP2040 has a fixed internal clock source of 1 MHz. So if you need any other time resolution (another clock source, or period not a multiple of 1 µs), you're screwed. The datasheet mentions other options for timing purposes, including the PWM units and even the PIOs, but all have limitations of their own.Again the whole point we raised here was that the chip IS limited in a number of ways, which shows it's more of a prototype than anything else. That doesn't mean that it's completely unusable; as I said earlier, I'm pretty sure a lot can be done, even a lot more than many would think. But one can't deny the limitations.I agree with AndrewBCN that the hype will probably wear off. If it hasn't already... Still interesting to see if the RPi will come up with new variants.

author: rstofer
author_rank: Super Contributor
timestamp: September 27, 2021, 10:59:37 pm
content: Quote from: SiliconWizard on September 27, 2021, 05:22:00 pmAnd it has interesting features I don't recall seeing elsewhere. How about 32 spin-locks for synchronizing threads and protecting shared resources. Or the Interpolators which are useful for audio but also for generating array indices. There there are the FIFOs between the cores. I have no idea what to do with them but maybe I'll run into a use case one of these days.There are some very interesting features to the Pi Pico. A brief review of the 649 page Datasheet might be in order. Note all the C code provided for each topic. It's all part of the SDK but here they talk about it inline with the datasheet.https://datasheets.raspberrypi.org/rp2040/rp2040-datasheet.pdfThis is a very serious chip and it has some unusual but compelling features.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 28, 2021, 12:58:14 am
content: Quote from: rstofer on September 27, 2021, 10:59:37 pmCalling it a "prototype" doesn't mean that it's not interesting. I agree it has a number of interesting features. It means that as it is now, it has a number of limitations (if just one package only), and is an odd mix of features. Apart from what I said, another point, for instance, is that I personally wouldn't consider a Cortex-M0 or M0+-based MCU unless it was for cost reasons (OK I admit this MCU is cheap, but there certainly are cheaper ones out there) or power consumption reasons; and for the latter, the power consumption, as far as I've seen, is not that impressive.Quote from: rstofer on September 27, 2021, 10:59:37 pmI would have to think about it for the interpolators. But the FIFOs between the cores? I certainly do know what I would do with them. It's just a very low-overhead mailbox, with fast access and completely isolated from main memory. Very handy for passing messages between the cores - and we talked about message passing in some length lately. Great for implementing simple, yet efficient and secure concurrent programming.This isn't quite the only MCU having this - a number of multicore MCUs do have some kind of mailbox for intercommunicating - but, at least with the few others I've seen, the mailboxes are often more complex with a bit more overhead. You can't get much simpler than just FIFOs! (But OTOH, this scheme doesn't scale up that easily, when dealing with more than 2 cores.)

author: rstofer
author_rank: Super Contributor
timestamp: September 28, 2021, 01:41:40 am
content: FreeRTOS has been ported to the Pi Pico - there are many references on the web but here's a short video

author: WaveletSea
author_rank: Newbie
timestamp: September 28, 2021, 03:21:32 am
content: [Off topic question]What is the difference between writing your own firmware or use FreeRT?

author: ataradov
author_rank: Super Contributor
timestamp: September 28, 2021, 04:15:10 am
content: FreeRTOS just gives you a task switcher, so you have multitasking. It also gives you basic synchronization primitives needed for multitasking. That's mostly it. Unlike some other OSes, they don't provide drivers or standardized driver APIs, so for everything else you are on your own. In that sense there is not a whole lot of difference between using the OS and writing bare-metal code. You just structure your code accordingly.That's why this "port" is not really a surprise, FreeRTOS already runs on Cortex-M0+, so the port is just a matter of adding low level build stuff for this device.Which one is better is a matter of preference. I personally think RTOS on Cortex-M0+ is a stupid idea no matter what. We can start discussion on CM4/CM7. And even there, there are things to talk about,

author: commie
author_rank: Frequent Contributor
timestamp: October 05, 2021, 09:40:58 pm
content: Quote from: WaveletSea on September 24, 2021, 07:42:45 pmMy friend, the raspberry pi pico, under micro_python environment, is only capable of 32bit floats with 6 digits of precision, my Bascom AVR compiler is only 8-bit and can do both 32bit and 64bit floats data types.To send a bitbang bitstream routine takes a whole page of code in upython, With my AVR compiler, it takes just one line of code to bitbang..As somebody already pointed out, the PI PICO is a toy, despite having tons of memory available.

author: DiTBho
author_rank: Super Contributor
timestamp: October 05, 2021, 09:54:04 pm
content: Quote from: ataradov on September 28, 2021, 04:15:10 amWaste of precious resources, and for nothing.

author: langwadt
author_rank: Super Contributor
timestamp: October 05, 2021, 10:08:52 pm
content: Quote from: commie on October 05, 2021, 09:40:58 pmthat has nothing to do with the PICO and everything to do with micropython. It'll run ten times faster than your AVR if you run compiled code, so which one is the toy?

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 05, 2021, 11:06:41 pm
content: Quote from: ataradov on September 28, 2021, 04:15:10 amYes, the port is not a lot of work. That's because FreeRTOS is not too badly structured, and that indeed support for Cortex-M0 targets was already there.The RP2040 has two cores, so if the port properly handles scheduling tasks across the two cores, that's a plus. Not that many people, in particular those that the RP2040 targets, would know how to properly use two cores and synchronize between them.Quote from: ataradov on September 28, 2021, 04:15:10 amWell, an RTOS on a modest MCU is *often* overkill, but claiming it's stupid in general is a bit much. FreeRTOS supports the ATMEGA IIRC - *that* I would find stupid. But a dual-core M0+ running at over 100MHz is pretty capable. Now using FreeRTOS for a particular project may or may not be stupid, but the target itself is not ridiculous. Unless the considered target was VERY limited (like those small 8-bitters), I for one do not think the main question would be the target here, but rather the project itself.

author: newbrain
author_rank: Super Contributor
timestamp: October 06, 2021, 10:55:48 am
content: The very limited timer provided by RP2040 was the first thing I noticed, at the same time this is mitigated by PIO and PWM as said above.In addition to those, there are 4 timers dedicated to DMA transfers (with a fractional 16/16 bit divider - still quite limited, as the input clock is fixed to the system clock AFAICS).I also frankly don't like the data sheet - it's too terse in many areas (specification, clocks etc.) and too verbose (but confused) in others.That said, on the practical side, in a couple of afternoons last week I put together a simple I/Q modulator on a Pico board to test my always ongoing SDR project.Core 0 uses tinyusb library to act as an USB sound card - receiving I/Q samples at 48 kS/s (×2 channels) from kiwiradio web or python client on a PC or Raspberry.The received audio is put in buffers and passed through the HW FIFO to core1 (passing only their address, as the RAM is shared).Core 1 upsamples the 48 kS/s I and Q to 3.072 MS/s (64×) using the hardware interpolator and then uses them to IQ modulate a precomputed 96 kHz carrier.The most significant 8 bits are then sent out to the PIO FIFO, and an extra simple R2R DAC + tuned LC converts them to analog.The pacing of output samples is controlled by the PIO clock - if the incoming and outgoing sample rate drift wrt one another, there might be input buffers thrown away or unmodulated carrier stretches but that has never happened so far.The spectrum (FFT on a DS1054) looks good enough for my purposes, 2nd and 3rd harmonics are >40 dB below the signal, par for the course with 8 bits.No need for RTOS, no need for timers or even DMA, extremely simple to use the second core.HW FIFOs between the cores and between the cores and PIO simplify synchronization and cut on code.Speed is more than enough* even with code running from XIP flash, thanks also to the HW interpolator.The cmake based build system is easy to setup, albeit a bit clunky to tailor.Debugging might be simpler, due to their boneheaded idea of using separate DPs for the cores, but works decently with a J-Link mini EDU and the custom version of OpenOCD.The SDK is nothing to write home about, but workable and at least the parts I checked did not seem to be extra bloated.I'm sure I could have done the same on many of the other development boards I have (ST F0-F7, PSoC5, some NXP etc.) but I found that the RP2040 HW and SDK fit like a glove to this task: total written code is about 250 lines + some tinyusb boilerplate (shamelessly copied).The low price is good too, about 1/3 to 1/2 of Nucleo boards (but they are better, at least for including an onboard debugger).All in all: a toy, yes, without a clear roadmap or even a vision and one I'd not consider now for a product, but from an hobbyist perspective a fun and cheap toy, with some surprisingly helpful HW for specific tasks.* I'm overclocking it to 153.6 MHz, to keep a nice ratio between the sample rate and the PIO clock. The 250 lines also include a routine to determine the best integer divisor (no jitter) clock given the maximum overclock frequency, the input and output sample rates and PIO cycles per sample.

author: commie
author_rank: Frequent Contributor
timestamp: October 06, 2021, 01:13:53 pm
content: Quote from: langwadt on October 05, 2021, 10:08:52 pmThat is correct, micropython is the main culprit, I did buy a compiler for arm(Mikroelectronika) which turned out as a bug ridden pile of crap, just a waste of money.What other compilers, do you have in mind for the Pico?

author: newbrain
author_rank: Super Contributor
timestamp: October 06, 2021, 01:41:32 pm
content: Quote from: commie on October 06, 2021, 01:13:53 pmWhat is wrong, for RP2040 or other Cortex-M MCUs, with the usual suspects, gcc and clang?The standard toolchain for Pico/RP2040 is setup with arm-none-eabi-gcc: I had a half hearted attempt (15') to use clang and did not succeed, but I'm sure it can be done.But, maybe, by "compiler" you mean a full IDE+toolchain? I see Mikroelektronika offer is more of a complete environment.In that case, there are a lot of options, according to tastes and distastes, paid and free (beer or freedom) - all based on the above compilers - a topic worth pages of posts, heated discussions and some religious wars...

author: commie
author_rank: Frequent Contributor
timestamp: October 06, 2021, 03:39:53 pm
content: Quote from: newbrain on October 06, 2021, 01:41:32 pmYep, already tried it, any other?

author: SiliconWizard
author_rank: Super Contributor
timestamp: October 06, 2021, 05:27:15 pm
content: Quote from: newbrain on October 06, 2021, 10:55:48 amApparently, this chip is extremely 'overclockable'. I've read reports of overclocks at 400MHz or over. Haven't verified myself if that worked reliably, but there are some Coremark scores at those frequencies...

author: newbrain
author_rank: Super Contributor
timestamp: October 06, 2021, 06:51:34 pm
content: Quote from: SiliconWizard on October 06, 2021, 05:27:15 pmI've got two Pico boards, both stable up to about 260 MHz without raising the core voltage and with code still running from flash.No real deep test though, just the code described above.But hey, I once got some clock setting messed up on an STM32F072, and it ran at 80 MHz (vs. the guaranteed 48) for days before I realized why an I2C display was glitching now and then - the MCU ran OK (I was in Italy, where my only tool is a venerable, but reliable,Hung Chang DMM).