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.
I've make the same question inside official Rasperry Pi Reddit and it got deleted
at this point it looks like their either are not really proud of this RP2040 MCU
I was reading the datasheets of Raspberry Pi Pico RP2040 and to my big surprise there's no such things like 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 
?
in software like it has been done for decades (and still is) in the numerous MCUs that doesn't have any special filter hardware
FMAC is a special feature of few newer STM32s
odd question really, how do you suppose the millions of MCUs that doesn't have an FPU do floating point?
odd question really, how do you suppose the millions of MCUs that doesn't have an FPU do floating point?
Why 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.
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?
I was just asking if the top notch of MCU from Rasperry can or can't do such thing
This 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 a
confrontational manner?)
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.
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.
That'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...
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.
Why do you define it as cool toy? compared to what? Z80. When is something not a toy?
Why do you define it as cool toy? compared to what? Z80. When is something not a toy?
I'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.
Why do you define it as cool toy? compared to what? Z80. When is something not a toy?
I'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.
I 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
Why do you define it as cool toy? compared to what? Z80. When is something not a toy?
I'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.
I 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
Well, 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.
if you need more advanced peripherals such as Ethernet as langwadt mentioned, then it's out of the question.
Someone wrote code to drive an Ethernet Phy chip via RMII using the PIO... Impressive, and probably dangerous...
the biggest issue is the lack of timers that some mentioned. As far as I've seen, there is only ONE timer.
One "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.
...
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.
1. 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.
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.
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. .
And 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.
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. .
And it has interesting features I don't recall seeing elsewhere.
Calling 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.
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.
I 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.)
FreeRTOS has been ported to the Pi Pico - there are many references on the web but here's a short video
[Off topic question]
What is the difference between writing your own firmware or use FreeRT?
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,
I was reading the datasheets of Raspberry Pi Pico RP2040 and to my big surprise there's no such things like FMAC for digital filtration like on the very cheap and accessible STM32.
My 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.
RTOS on Cortex-M0+ is a stupid idea no matter what.
Waste of precious resources, and for nothing.
I was reading the datasheets of Raspberry Pi Pico RP2040 and to my big surprise there's no such things like FMAC for digital filtration like on the very cheap and accessible STM32.
My 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 toy, despite having tons of memory available.
that 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?