Raspberry Pi Pico RP2040 vs STM32 - How to digital filtration? (FMAC)

[SiliconWizard]

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.

Yes, 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.

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,

Well, 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.

[newbrain]

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.

[commie]

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?

That 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?

[newbrain]

What other compilers, do you have in mind for the Pico?

What 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...

[commie]

I see Mikroelektronika offer is more of a complete environment.

Yep, already tried it, any other?

[SiliconWizard]

* I'm overclocking it to 153.6 MHz, to keep a nice ratio between the sample rate and the PIO clock

Apparently, 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...

[newbrain]

Apparently, 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...

I'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).