Thoughts on the RP2040?

[tomgat]

I was looking at the Raspberry PI Direct website and noticed they are selling their RP2040 (aka Raspberry Pico chip) for $400 for a reel of 500 (ie. $0.80 each) a piece.  Also, since this processor needs flash, they are also selling 16Mbit QSPI-capable serial NOR Flash for $1000 for a reel of 4000 (ie. $0.25).  The chip has an oscillator onboard (no very accurate, but still) as well as an RTC.   Please someone correct me if I wrong, but this seems like a very good price for a ARM M0 dual core processor with great documentation and an easy to place QFN package.   Any idea why we are not seeing more people design with this processor? 

Any thoughts are appreciated, as I am looking for a low cost processor to design with that is not back ordered until 2023 (and beyond).

 

[uer166]

 
Any idea why we are not seeing more people design with this processor?   

From the place/requirements where I work, and why STM32 is still the best fit, RP2040, while interesting, is a no-go for a lot of reasons:

• No security of any kind since code is stored externally without encryption.
• Lack of good peripherals, especially in mixed signal/analog domain
• Lack of industrial communication interfaces such as CAN
• Lack of basic communication peripherals as well (only 2 HW UARTS, although I'm sure PIO can fill in some gaps)
• Temp range insufficient for some work
• Only one chip in family without any options to increase memory/GPIO/different package. Horses for courses and only having one option is a huge risk for any big project.

It may be a good fit for some consumer hardware, however.

[tomgat]

 
Any idea why we are not seeing more people design with this processor?   

• Temp range insufficient for some work

It may be a good fit for some consumer hardware, however.

You make great points that the chip is pretty limiting, but its also a fraction of the cost to STM32.  Also, I am struggling to get allot of the STM32 chips right now.

I was looking at the temp range specs as I do exclusively industrial designing.  Thats appears to be the typical industrial range.

Operating temperature -40°C to +85°C

https://www.raspberrypi.com/products/rp2040/specifications/[/list]

[Monkeh]

You make great points that the chip is pretty limiting, but its also a fraction of the cost to STM32.

It is, but you also need to factor in the cost of external flash and other external peripherals due to its limited feature set. Don't forget board space is also a cost.

[SiliconWizard]

One of the reasons I'm seeing more commercial projects these days with the RP2040 is precisely due to its availability, so you're not alone.

Apart from what uer166 said, minus points are also that it has unimpressive power consumption for a Cortex-M0+ compared to the competition. In particular, it has no decent "deep sleep" mode, so power consumption is going to be a problem for many battery-operated applications. I think the lowest that has been measured in deep sleep was about 300 µA - and even that was achieved with great care. The competition routinely achieves 100x less. If power consumption is not an issue for your application though, it's fine.

Another point is that it's the first MCU from the RPi - trust can be an issue. In the same vein, nobody really knows the intentions of RPi for the future. How long is this product going to last, and will there be successors? Nobody knows. One related point is more general with the RPi: this is a foundation and its goal is not to consistently supply businesses with parts. It is, at best, ambiguous about that point.

Now if the listed minus points are not a problem for your application and your own business, go for it. It's a great chip for what it is and again, it happens (at least for now) to be easily available, which is rare enough at the moment to be noted.

[ataradov]

Lack of code security and general annoyance by external flash and all the variables it adds is one of the things that is stopping me from using it more.

Also inefficient use of pins. There are too many pins reserved for special functions / power supplies. This often happens on new devices because vendors don't know how much they can get away with when it comes to power supply bypassing. But in this case QSPI pins would always be reserved.

And yes, peripherals are lacking. Ability to implement some of them using PIO is great, but not really that useful for real projects.

That being said, if I had a project that was not constrained by those things, I would not hesitate to use it in production. The IC is as stable as any other MCU.

[WillTurner]

Some positive points in favor of the RP2040 :-
  good documentation
  low cost and accessible development board (Raspberry Pi Pico)
  "open source" (an anticipated future positive for someone inheriting your design)
  multiple program development environments (Assembly, C/C++ SDK, FreeRTOS, Picomite and VGA BASIC variants, micropython, Fuzix)
  dual-core support
  anticipated future development path
  lots of RAM and program storage for cost
  PIO's capable of running multiple simple tasks
  (last time I looked) available as an extended JLCPCB component

(edits: Added to/refined list)

[exe]

I believe PIO makes up for the "lack of" interfaces.

My complain is that it needs an external flash, which, for example, limits operational voltages to what flash supports. I also never worked with flash before, this adds some anxiety, and it's yet another IC that needs to be sourced.


PS I just learned it doesn't need xtal for usb to work, that's good!

[ataradov]

PS I just learned it doesn't need xtal for usb to work, that's good!

Where is this described? Even its own bootloader is very explicit on needing the external clock.

And I don't think it has USB clock recovery necessary for reliable operation without a crystal. Its internal RC is definitely not good enough.

[mino-fm]

Lack of code security and general annoyance by external flash and all the variables it adds is one of the things that is stopping me from using it more.

Yes and

That being said, if I had a project that was not constrained by those things, I would not hesitate to use it in production. The IC is as stable as any other MCU.

yes.

In the past I used Renesas RX and STM32 controllers for driving 320x240 QVGA 5,7" TFT-displays. Now these TFTs are not available anymore so my customer needs 1:1 replacement to use 640x480 VGA panels.

RP2040 pico board offers all the stuff which is necessary: 150 KB RAM (6-bit colour, 2 pages), enough flash-ROM for (small) code and startup-screen picture, stable systemclock (12 MHz quarz), UART, DMA-controller and PIO-channel to double each pixel in horizontal to expand 320 to 640 pixels. DMA-controller is triggered twice starting at the same framebuffer address to double vertical lines. Two ADC-channels read out (resitive) touchscreen.

It's a very cheap solution where all part are available. I don't mind that someone could copy the code of <= 100 boards.

[tomgat]

One of the reasons I'm seeing more commercial projects these days with the RP2040 is precisely due to its availability, so you're not alone.

It goes without saying that the current availability is the RP2040s best attribute.   I have more than a couple POs just sitting around until 2023/24 due to component backorders, and the processor is always the most frustrating because rarely are there an easy alternative.  Even worse, I have to choose to either buy the rest of the components and eat the cost of money expense, or risk something else being backordered by the time another part becomes available.

The bulk of my current work at the moment is just reworks so that I can actually make/ship boards to customers.  It's truly a frustrating existence because its not only not new work, but is also mind numbingly boring trying not to trigger the EMC UL paperwork nazis.

[exe]

PS I just learned it doesn't need xtal for usb to work, that's good!

Where is this described? Even its own bootloader is very explicit on needing the external clock.

Ah, I must be mistaken. Earlier today I think I found that somebody reported that this is working. However, I struggle to find that link, and here is one of rpi engineers says that it's unlikely to work: https://forums.raspberrypi.com/viewtopic.php?t=315464#p1887941 .

Well, that's a bummer. I still hope they'll pack both rp2040 die and some flash in one package, just like GigaDevice does that in their stm32 clones. Simply because it's more convenient and less board area.

[ataradov]

and here is one of rpi engineers says that it's unlikely to work:

It might work on a specific device at a specific temperature. But there is no way it would universal or reliable.

Other MCUs that can work without a crystal use USB SOF (Start Of Frame) packets to synchronize their clocks. In that case the accuracy is actually better than a local crystal.

Well, that's a bummer. I still hope they'll pack both rp2040 die and some flash in one package, just like GigaDevice does that in their stm32 clones. Simply because it's more convenient and less board area.

It would be an absolute minimal requirement. But it would be nice to also not be just QSPI device in the same package, but an actual flash controller than can boot on its own.

[b_force]

I never believe in "what's best", but I always find the suitable tool for the project.

So looking from that perspective, I don't see what's inherently wrong with a RP2040.
But again, that also depends on the use case.

On paper a ESP32 is probably a little more powerful, but there is an argument to be made to choose for the RP2040 instead to stay with a European manufacturer for example (if that's important for you).

To answer your question why we don't see more people designing with the RP2040?
I don't know, I don't share that idea, I see plenty of people around me trying the RP2040.

But keep in mind that it's a relatively new device on the market.
So it always takes at least a year to really catch on.
Plus I think people are extra careful atm because of the whole chip shortage issue.
So I would rather stick to something I know that works, or even simplifying, instead of getting a board with a whole new environment.
Not knowing if that will last for at least a couple of years.

[chickenHeadKnob]

Surprised no one has mentioned  this in this thread yet:
   It doesn't appear to have a timer/capture function for its timer. In fact the timer resource is very weak. This would be a show stopper for me.
   Credit to Atadorov for pointing it out in an earlier thread on the pico.
   Also there is some bug in the ADC, missing codes or some such. There is a work-around I think.
See mark omo DNL excursions:https://pico-adc.markomo.me/INL-DNL/#why-does-the-dnl-spike

[mino-fm]

Surprised no one has mentioned  this in this thread yet:
   It doesn't appear to have a timer/capture function for its timer. In fact the timer resource is very weak. This would be a show stopper for me.

I solved this problem using a PIO channel. Timer resolution can be 1/4 SystemCoreClock and max. input capture frequency 1/8 of it. Please look at 'f_mess_RP2040.c' starting at line 427 in 'pico_fmeter_GB.zip' to be found here: https://www.eevblog.com/forum/projects/pico-frequency-counter-using-rp2040/msg4177495/#msg4177495
Actually I use this simple programm for four input channels: Fin, Fin/4, Fin/32 and Fref. One PIO and four DMA-channels are used to give reciprocal frequency measurements simultaneously.

Thanks to Alex (Ataradov) to show me the way not to use PIOASM but brain-assembler ;-)

[hubi]

Surprised no one has mentioned  this in this thread yet:
   It doesn't appear to have a timer/capture function for its timer. In fact the timer resource is very weak. This would be a show stopper for me.
   Credit to Atadorov for pointing it out in an earlier thread on the pico.
   Also there is some bug in the ADC, missing codes or some such. There is a work-around I think.
See mark omo DNL excursions:https://pico-adc.markomo.me/INL-DNL/#why-does-the-dnl-spike

I would like to know more about the work-around for the ADC issue. I don't see how a work-around is possible, other than discarding the lower bits and oversampling to make up for it.

Depending on what you need the timer/capture for, it might be possible to implement it with PIO.

[bidrohini]

I think Raspberry Pi pico is more user-friendly.

[tomgat]

I never believe in "what's best", but I always find the suitable tool for the project.

To answer your question why we don't see more people designing with the RP2040?
I don't know, I don't share that idea, I see plenty of people around me trying the RP2040.

But keep in mind that it's a relatively new device on the market.
So it always takes at least a year to really catch on.
Plus I think people are extra careful atm because of the whole chip shortage issue.
So I would rather stick to something I know that works, or even simplifying, instead of getting a board with a whole new environment.
Not knowing if that will last for at least a couple of years.

That is a great point!  Thank you for saying it.  I did not fully appreciate how new it was on the market.   

[MarkR42]

I think the RP2040 needs an external crystal to run the firmware-update mode over USB from the boot rom.

I may be wrong about this, but the boot rom source is available.

It's possible that the USB can work after boot without an external crystal, but it still needs it to do the firmware load mode. You can still load the firmware without USB boot-rom mode, but you'd need to use the SWD interface pins (or alternatively put your own firmware loading system on your board)

[ataradov]

No, USB can't work on this device without a crystal. If it could, ROM code would be the first to use this feature.

[VEGETA]

for 1$ price on digikey and lots of support, I think it is good. most importantly for me is that it can be programmed by arduino ide using arduino code style... not many people may agree but for people who hate and suck at software, this is a good feature.

by mentioning code security, you mean when you flash your stm32 mcu no one can copy the code? what do you do if you want to make your product get firmware updates?

i always wanted to ask about stm32 and how easy it is for developing projects for people who suck at coding like myself? I mean what is the smallest comparable part to rp2040 and at what price? assuming project which don't need much peripherals besides i2c or spi.

[ataradov]

by mentioning code security, you mean when you flash your stm32 mcu no one can copy the code?

Yes.

what do you do if you want to make your product get firmware updates?

You make a secure bootloader and distribute an encrypted firmware.

i always wanted to ask about stm32 and how easy it is for developing projects for people who suck at coding like myself?

It depends. It is far easier to learn to program and then have all the options available. Never trying and just sticking to Arduino because you "suck" is not a good approach. Everyone sucks when they start.

There is no ST device comparable in performance/price. And especially now when availability is spotty and demand is high. If you are just starting I'd be looking at STM32G0 or G4 series. But again, there is no real way to get those devices now.

[VEGETA]

You make a secure bootloader and distribute an encrypted firmware.

can you explain further? i mean if i have a usb connection in my product where the user connects it to pc then use a software i give him, how it is done?

i never seen a tutorial for writing a bootloader or how to encrypt firmware though, just know that arduino stuff has one.

It depends. It is far easier to learn to program and then have all the options available. Never trying and just sticking to Arduino because you "suck" is not a good approach. Everyone sucks when they start.

i used to program pic mcus in c, but my coding skills are so limited and i am really not a gifted coder. for me doing pcbs, designing hardware, power supplies and their routing, etc... is orders of magnitude easier than doing a simple code program in c. maybe i am the "hardware guy".

since people talked about stm32, is it the most used option for products? i know in china it is very popular but what about say PIC or others.

[MikeK]

If you are just starting I'd be looking at STM32G0 or G4 series. But again, there is no real way to get those devices now.

What about the cheap STM32F103 boards?

https://www.aliexpress.us/item/3256802926378826.html