The Raspberry PI PICO 2, now has extra RISC-V cores

[SiliconWizard]

People are not "whining", but discussing objective downsides to the design. Everyone knows what PIO is and how good it is, there is nothing to discuss here.

As it is right now, this MCU is fine for hobby use, but it will not be suitable for a lot of commercial designs. And the new device does not address most of those concerns.

Yep. I think it'll be fun. Probably not much more than this. The success of the RP2040 in some commercial designs was mainly due to the fact it was available during a very nasty shortage period. I know of quite a few companies that switched to it "at the last moment" just to be able to have something to put into production. The 2350 isn't coming in the same context.

I don't think we should focus on commercial uses for this, and see it more for learning/experimenting purposes, which, as far as I can tell, is the RPi's main goal. I know they need to make cash too, but clearly the design wasn't alike anything we are used to seeing in commercial devices. Which has its strong points too.

Apparently they even removed the RTC? Odd.

[PCB.Wiz]

..., for the new chip the only downside I can see is they dropped the RTC but everything else has improved.

I think they dropped the 32kHz Xtal option.

The manual says you can still connect a external CMOS 32kHz - a few vendors have those now, with choices of uA and ppm.

12.10.5.2. Using an External Clock in Place of LPOSC
If LPOSC is not sufficiently accurate, an external 32.768kHz clock can be used. This will be multiplexed onto the internal
low-power clock and will therefore drive all components that are driven by that clock, including the power sequencer
components.

and you can also feed in a 1Hz tick to snap the on-chip OSC to 32768 counts per second. ( I doubt that works on external 32Khz)

The following features use a GPIO as a clock or a tick:
• external 32kHz clock source
• external 1kHz tick
• external 1Hz tick

An example of higher crystal divided 32kHz oscillators - these give higher Icc ( < 90uA) but faster start times (5ms) and better tempco than tuning fork crystals.
https://www.lcsc.com/datasheet/lcsc_datasheet_2406051009_Shenzhen-SCTF-Elec-SX1M32-768KM10F30TNN_C2901615.pdf


or for a bit more money, you can get a DTCXO, for uA region Icc and low digit PPM - ie a lot better than a tuning fork.

https://www.lcsc.com/datasheet/lcsc_datasheet_2109101130_Seiko-Epson-TG-3541CE-32-7680KXA3_C1987384.pdf

[ataradov]

I don't think we should focus on commercial uses for this, and see it more for learning/experimenting purposes

Well, they provide explicit supply commitments with substantially long times. Hobby and educational uses will typically move to the newest available chip with relative ease. The only people that care about 10+ year availability are commercial customers.

And they provided the same long commitments for RP2040. If this MCU is functional at basically the same price, then all hobby projects would just more to it. Yet they committed to making RP2040 (and Pico board itself) for a long time.

[floobydust]

The custom Abracon inductor 3.3uH 1.5A is because the shielding is critical, stray flux caused a lot of problems apparently, and inductance roll-off with current is a problem too. (6.3.8.3)

RP2040 GPSDO using magical unicorn PIO and many hoops with DMA, I'm not sure but it seems dependent on CPU intervention to count pulses... average that latency out. Not real time. https://rjk.codes/post/building-a-frequency-counter

The directors sold a lot of stock. Mike Buffham - Chief Commercial Officer sold over 120,000 shares worth £500,000. I'm sure he believes in the company lol.
"... the company says that 72% of its unit sales target the industrial market, where it is used, for example, in factories." ARM and Sony did buy in.

[PCB.Wiz]

RP2040 GPSDO using magical unicorn PIO and many hoops with DMA, I'm not sure but it seems dependent on CPU intervention to count pulses... average that latency out. Not real time. https://rjk.codes/post/building-a-frequency-counter

That looks to have multiple versions, some with Sw interactiuons.

This code looks to be all in PIO, using 3 state engines, which I think has maxed out the code size.
https://forums.raspberrypi.com/viewtopic.php?t=306250

I think this needs a GPIO pin as GATE semaphore ?  Not sure if that can be avoided ?

[iMo]

I think the dual ARM and RV has not been a good decision..
99% of the mainstream pico users do not care, they want to run their programs architecture regardless (see for example above the testing approach of the mysterious 2350 tester when he did not mess with the RV either).

If they want to continue with RV in the future, they need to port the ecosystem to RV. This means Mciropython, Circuitpython, RTOSes, and any other resources need to work with RV. If you only have developer chips, that's a chicken and egg problem, since as you said, most people are not interested, so no work would be done on the RV ports.. This way they can ship eggs together with the chicken, so hopefully hackers will start using it, and porting.
And since the peripherals are the same, this could hopefully be a very smooth transition.

The main reason I see why they did it is to save money on the masks - the masks are the most expensive item when manufacturing the chips - with the ARM+RV setup they need one set of masks, with two chips (ARM or RV - my favorite version) they would need two sets (2x more $$).

PS: the switcher there on the pico board - perhaps good for simple educational exercises (powering it off a higher voltages), but not good for anything with signal processing, or with some timing critical stuff (see the other thread on multislope adc, for example). But that is not critical as there are boards with a linear regulator as well.

Also their ADC is still something of pretty low performance (sensing a potentiometer perhaps), moreover the sticking with only 32 instructions per state machine seems to me a bad move as well (as I personally have been attracted to the Pico because of its PIOs only)..

PPS: adding the double precision FPU - that is a good move, imho, but it would also require to have the other components on the chip "compatible" when using it for a more demanding applications - ie. in the test equipment (ie. now w/ math using external 20-32bit data), etc. The "analog world" processing has to be of a high quality as well then (ie. simultaneously sampling ADCs for I/Q, PLLs and signals jitter, noise sources, signal integrity, etc.), simply because to make precise calculations with a crappy data makes none sense..

[tszaboo]

The switching regulator seems odd. In Hardware Design with RP2350 (pg. 6), there's a defensive-sounding paragraph about how physics is hard, followed by a strong recommendation to use only their custom-wound inductor. I've used a few microcontrollers that included buck regulators, and none of them needed that. (Although their current output was in the 20-50mA ballpark, not 200mA as in the RP2350.) Has anyone seen that before?

Using a custom inductor? No, I've never seen that. But some buck regulator datasheets show a capacitor in the feedback network to improve stability.
You can see it in the application circuit of my favorite buck converter AP63200 pg. 9

Wow, you are talking about this:
It's indeed quite a bit of magical thinking here, I've never seen an engineering document talk about "happy DC-DC converters" that you don't want to "upset".
The layout requires you to run the inductor current below two 0402 capacitors. The switcher is right next to the AVDD, which is sensitive, so much so that you need RC filtering for it. It's also 7 pins to power the core with a DC-Dc. The same for example on a silicon labs chip is 3 pins. And you can run the radio, core, IO and whatever else from the DC-DC if you wish, and orient it the way you want, if you really wish you can place a ferrite in series with the output and the AVCC.

great deal of work
has gone into the design of this circuit, with many iterations of the PCB required in order to make it as good as we
possibly can. While you could place these components in a variety of different ways and still get the regulator to 'work'
(ie, produce an output voltage at roughly the right level, good enough to get it running code), we’ve found that our
regulater needs to be treated in exactly the right way to keep it happy, and by happy, I mean producing the correct
output voltage under a range of load current conditions.
While performing our experiments on this, we were somewhat disappointed to be reminded that the inconvenient world
of physics cannot always be ignored. We, as engineers, largely try and do exactly this; simplifying components, ignoring
(often) insignificant physical properties, and instead focusing on the property that we’re interested in. For example, a
simple resistor does not just have a resistance, but also inductance, etc. In our case, we (re)discovered that inductors
have a magnetic field associated with them, and importantly, radiates in a direction depending on which way the coil is
wound, and the direction of the flow of the current. We were also reminded that a 'fully' shielded inductor doesn’t mean
what you think it might. The magnetic field is attenuated to a large extent, but some does still escape. We found that the
regulator performance could be massively improved if the inductor is 'the right way round'.
It turns out that the magnetic field emitting from a 'wrong way round' inductor interferes with the regulator output
capacitor (C7), which in turn upsets the control circuitry within RP2350. With the inductor in the proper orientation, and
the precise layout and component selections used here, then this problem goes away. There will undoubtedly be other
layouts, components, etc, which could work with an inductor in any orientation, but they will most likely use a lot more
PCB space in order to do so. We have provided this recommended layout to save people the many engineering hours we
have spent developing and refining this compact and well-behaved solution. More to the point, we’re going so far as
saying that if you choose not to use our example, then you do so at your own risk. Much like we already do with RP2040
and the crystal circuit, where we insist (well, strongly suggest) you use a particular part (we will do so again in the
crystal section of this document).
Hardware design with RP2350
2.1. New on-chip voltage regulator 6
The directionality of these small inductors is pretty much universally ignored, with the orientation of the coil winding
impossible to deduce, and also randomly distributed along a reel of components. Larger inductor case sizes can often
be found to have polarity markings on them, however we could find no suitable ones in the 0806 (2016 metric) case size
we have chosen. To this end, we have worked with Abracon to produce a 3.3μH part with a dot to indicate polarity, and
importantly, come on a reel with them all aligned the same way. The TBD are (or will very shortly) be made available to
the general public from distributers. As mentioned earlier, the VREG_AVDD supply is very sensitive to noise, and
therefore needs to be filtered. We found that as the VREG_AVDD only draws around 200μA, an RC filter of 33Ω and
4.7μF is adequate

This goes on for another 2 pages, talking about the same thing over and over.

[ataradov]

Their datasheets are strange in general. They are less of a formal document and more of a lab manual or something like this. I guess this is the part of the "disruption" they are trying to introduce, but I'm not sure it is a good thing.

[iMo]

I was looking in that manual for what is the "new" number of instructions per PIO (while one PIO consists of 4 state machines).
While I assumed it is still 32 I searched with "32 instructions" and it found a single instance buried in the picture Fig 43..

[SpacedCowboy]

I was looking in that manual for what is the "new" number of instructions per PIO (while one PIO consists of 4 state machines).
While I assumed it is still 32 I searched with "32 instructions" and it found a single instance buried in the picture Fig 43..

I mean, that is the very first thing you see when you go to the "PIO" section... It is also possible to embed instructions into the shifter output, though this is less-often used, and takes a clock for the OUT before the instruction is executed. Most people stay within the 32-instruction pool limit.

The PIO units do have the same number of instructions but they have better linkage between them - being able to (without any going-external penalty) wait on and send IRQs to other PIOs (+1 and -1 with circular arithmetic). That makes it easier to build much larger co-operating programs.

It is also now possible to write (from either system or PIO side but not both simultaneou) directly into any position within the PIO FIFO elements, effectively making status registers (if the PIO has write-access) or control-registers (if the system has write access).

It's also possible to set the base offset for the PIO GPIO pins on the fly. You still only have 32 GPIOs at a time, but you can control where they start from.

There's also less DMA latency (1 clock cycle) compared to the previous RP2040 version.

All told, the PIOs got quite a bit, IMHO.

[SpacedCowboy]

Their datasheets are strange in general. They are less of a formal document and more of a lab manual or something like this. I guess this is the part of the "disruption" they are trying to introduce, but I'm not sure it is a good thing.

I like them - they're more "human" and I don't see any reason for technical datasheets to be as soulless as most of them are. I've sometimes read something in other datasheets and wondered "why the hell did they do it *that* way ?" It's refreshing to see someone explaining the why as well as the what.

I don't think I've ever struggled to find something in a R-pi datasheet, which is something that other vendors could take notice of. Maybe I've just been lucky. Maybe.

At least they're not the living nightmare that was Silicon Image datasheets, who put out intentionally wrong information in the "public" one, and then when you rang up your FAE and complain that you'd spent the last 3 weeks trying to do X as it says in the datasheet and you can *prove* that X is just not possible, look at these traces, they said "oh, you must be using the public datasheets, I'll send you the real ones, just sign this extra NDA"

Yeah, we stopped using Silicon Image parts at that point. I don't think that's changed even since Lattice bought them.

[SiliconWizard]

The reason they didn't increase the 32 instructions depth is instruction encoding - for 'branching' instructions, they would have had to change the encoding and probably increase the width of instructions, which would probably have had other impacts. As they state here and there, one of their goals with the new RP2350 was that it was almost a drop-in replacement with (almost?) no change in firmware required.

What's going to be the price for the chips? Probably higher than the RP2040?

[SpacedCowboy]

The reason they didn't increase the 32 instructions depth is instruction encoding - for 'branching' instructions, they would have had to change the encoding and probably increase the width of instructions, which would probably have had other impacts. As they state here and there, one of their goals with the new RP2350 was that it was almost a drop-in replacement with (almost?) no change in firmware required.

Yep - they also have a lot of investment in the RP2040, leveraging as much of that as they can seems smart to me. The PIO are already a very significant differentiator at this price level and they've tried hard (it seems to me) to make the transition to the new device as easy as possible. I think the ability to more easily split larger programs over multiple PIO blocks, and adding another block pretty much solves the problem anyway. It might not be as elegant as "all PIO programs now have 128 instructions available" but it certainly helps. Maybe the next revision of PIO will make the breaking change - or maybe not

What's going to be the price for the chips? Probably higher than the RP2040?

Pricing is pretty comparable, an RP2040 from DigiKey is currently $0.70. The RP2350 price depends on configuration:

RP2350A QFN60 no flash $0.80
RP2350B QFN80 no flash $0.90
RP2354A QFN60 2Mbyte flash $1.00
RP2354B QFN80 2Mbyte flash $1.10

I suspect I'll be after the RP2354B, but I can't find them on sale anywhere yet. I ordered the RP2350A that MK14 posted about earlier. Supposed to ship in a few days.

[MK14]

What's going to be the price for the chips? Probably higher than the RP2040?

Apparently, in quantity pricing, each $0.80 for the entry level chip, for a reel of 3,400.

Available by the end of the year.

    RP2350A QFN60 no flash $0.80
    RP2350B QFN80 no flash $0.90
    RP2354A QFN60 2Mbyte flash $1.00
    RP2354B QFN80 2Mbyte flash $1.10

https://www.electronicsweekly.com/news/products/micros/rp2350-available-by-year-end-with-flash-inclusive-option-2024-08/

I have to admit.  That does sound rather good, given all the features it has to offer.

Yes, you can get MCU's, with all the bells and whistles, some in this thread, seem to insist on having.  But that can make the MCU cost, massively more, such as $10 each, depending on the specifications required.

$0.80 including high speed (full) double floating point, dual core M33's, can include in-package flash for a bit more, doesn't sound too bad, to me.

[MK14]

I ordered the RP2350A that MK14 posted about earlier. Supposed to ship in a few days.

The exact one, I linked to, seems to be the higher pin count version, RP2350B, not the A version.

Powered by RP2350B (Dual Arm Cortex M33 running at up to 150MHz with 520KB of SRAM)

But they do sell other versions which may have the A version in, as well, if that is what you ordered (differing board option types, in different shapes).

[SpacedCowboy]

I ordered the RP2350A that MK14 posted about earlier. Supposed to ship in a few days.

The exact one, I linked to, seems to be the higher pin count version, RP2350B, not the A version.

Powered by RP2350B (Dual Arm Cortex M33 running at up to 150MHz with 520KB of SRAM)

But they do sell other versions which may have the A version in, as well, if that is what you ordered (differing board option types, in different shapes).

No, you're right - I just looked at the pinout (after ordering) and saw it only went up to GPIO28 and did the "ass" part of assume. Looking closer, there's a GPIO45 for the BOOT button, and it does say 2350B I ordered some of the PGA ones as well, which have all the pins (and are available now, not on 23rd August)

[xbst_]

I'm looking forward to trying this MCU for a new project when it's available more widely. Hopefully I'll have a better experience with this chip than RP2040. I like some of the changes with this MCU, but it still isn't ideal for most of my (admittedly fairly niche) applications. At least it is cheap though.

• The built-in flash option is the biggest thing I like about this chip so far. Most of my PCBs are low-volume products, so keeping the BOM count low saves a lot of money. 128 KB of flash is usually more than enough for most of my PCBs, but the larger 2M flash is nice too. Plus, makes PCB design easier and allows for smaller PCBs.
• 5V tolerance on GPIO pins is great too.
• Better ADCs will definitely be nice.
• I don't have any use cases that'll benefit from the RISC-V cores, but I still think it's a good thing. We need more alternatives on the market, and having both cores might help encourage its adoption.
• The new regulator is a negative from my point of view. The need for more external components makes PCB design more complicated, adds more BOM lines (which add up quickly for low volume low price products) and potentially can cause noise related issues. But, yes, it'll be more efficient, which can matter for low power applications.
• USB still needs termination resistors.
• Still no HW CAN bus support.
• USB speeds don't matter for my applications, but I can see why some people aren't happy about it. Faster speeds would've been nice.

Overall, I don't think this'll ever become a MCU I use often. My preferred MCU for applications like this is STM32G0B1, which I can buy for around a dollar very easily (this'll likely be slightly cheaper at similar volumes). It has a similar number of GPIO, more features, requires less external components and I had much better luck with designing PCBs for it. There are quite a few RP2040-based PCBs on Ali/Amazon that have a high percantage of bad units, so I don't think it's just me.

As I said, I'm still looking forward to trying it, but it's mostly because I want to have the experience of designing for this MCU too, just in case we have another STM-shortage. I want to be ready for it, especially if it is as big of a PITA as the RP2040.

[radiolistener]

• ADCs are less noisy now

I tried to find any info about ADC specification on Raspi Pico 2 and didn't find anything.
Even resolution is not specified. Since they already released it, this is strange...
Does it have DAC?

Very ancient and extremely slow 12Mbps USB interface is also a very big con.
Also I read that they installed micro-USB connector on their Raspi Pico 2 board...
This is ridiculous because find micro-USB cable these days is not a trivial task...

[MK14]

Also I read that they installed micro-USB connector on their Raspi Pico 2 board...
This is ridiculous because find micro-USB cable these days is not a trivial task...

Since they decided to make it compatible with the original model, as much as reasonably possible.  That was perhaps why they continued with the same connector type.

E.g. Accessories for the PICO (1), would use (if applicable) the Micro USB connector, so if you want compatibility with the PICO (1) hardware and software, the connector would need to remain the same type.

Perhaps (but I don't really know, what they will do, then) when they release the WiFi version, much later (apparently it has been confirmed that they will be doing that).  It might be a time when they can move to a more modern connector type (USB-C).

The alternative versions (made by other companies), can include the USB-C connector, so that could be the solution.  They can have other benefits, such as larger standard flash sizes, and other add-ons.

[xbst_]

[..]

• The built-in flash option is the biggest thing I like about this chip so far. Most of my PCBs are low-volume products, so keeping the BOM count low saves a lot of money. 128 KB of flash is usually more than enough for most of my PCBs, but the larger 2M flash is nice too. Plus, makes PCB design easier and allows for smaller PCBs.

[..]

I don't grok that.  For low-volume products, development cost swamps BOM (unless you have very exotic parts or materials).  When I read such, I get bad flash-backs for the time when I had to work around the limitations of a $50 motherboard used in a product with a list price of $50k+ ...

Well for products that cost ~$20-30 it matters. BOM is usually a few dollars for products like that, not much room for fees.

[SpacedCowboy]

• ADCs are less noisy now

I tried to find any info about ADC specification on Raspi Pico 2 and didn't find anything.
Even resolution is not specified. Since they already released it, this is strange...
Does it have DAC?

Google: RP2350 datasheet
Section 12.4 “peripherals: ADC and temperature sensor”
Read first few lines

[edit: forgot this bit] No, it does not have a DAC.

Very ancient and extremely slow 12Mbps USB interface is also a very big con.
Also I read that they installed micro-USB connector on their Raspi Pico 2 board...
This is ridiculous because find micro-USB cable these days is not a trivial task...

I confess to not having the slightest trouble finding a micro-USB cable - I think I have several dozen of them. It would have been nice to see 480 Mbit/sec USB, but most of the MCUs that run at a nominal 125-ish MHz and are in this price-range are also 12MHz devices AFAIK.

[josip]

RP2354B is the right one for me. I need some horse power, but prefer two slower cores (execution in parallel) over one more powerful like IMXRT. For low cost entry level IMXRT external flash is must, and for me integrated 2 MB is more than enough.  Don't see anything similar with reach datasheet under 1.5$.

[phil from seattle]

One of the concerns I have about the design is the 1.1V switcher's inductor.  As others have noted in the "Hardware design with RP250" document they go on and on about the proper orientation of the inductor and how they worked with Abracom to get a special part distributed. They go so far as to say they can't guarantee any design that does not use the specific Abracom part which is listed as TBA. Kind of hard to order without the actual number. 

Is this them just being unconfident?  I see a number of designs for sale that use the RP2350 part so if these are actually being manufactured, why can't they get us the Abracom inductor part number? Or, I'm guessing, the orientation isn't that critical? Hopefully they will get the design doc updated soon.

[MK14]

On this new PICO 2, how come there is so little (apparent, especially when looking at this thread, but even when looking at other, PICO 2 resources), love for the RISC-V cores?

I thought, some people wanted to test and play around with them (RISC-V cores).

I do accept, that within some of the available cozy/sealed environments, such as Micropython, and to a lesser extent C/C++.  Other than possible performance changes (and apparent lack of hardware floating point support, on the RISC-V side).  It doesn't really affect the programmer/user.

But if you take your gloves off, and mess around with assembly code, it could provide some interesting experiments and insights, into different CPU architectures.

It seems to be a relatively new (or at least, uncommon), thing, to have two different architectures, available to choose between at boot time.

If the Arm M33 (via GCC), is a fair bit faster (which I suspect, but don't know for sure yet) than the equivalent GCC/RISC-V mode.  I guess many people will just shrug their shoulders, and stick with the Arm M33, along with its high speed hardware single and double floating point units, and other possible benefits.  Since the Arm M33, seems to be a lot better than the previous Arm M0 version.

[radiolistener]

It would have been nice to see 480 Mbit/sec USB, but most of the MCUs that run at a nominal 125-ish MHz and are in this price-range are also 12MHz devices AFAIK.

Even old and ancient as mammoth bones CY7C68013A running on ancient 8051 core at 48 MHz with 16k RAM has USB 2 HS support with up to 480 MBps and allows to keep realtime continuous synchronous stream at that speed.

Cheap low end STM32 which cost is less than a buck really still have slow USB, but that's the price to pay for being cheap.

As I understand, RP2350 is positioned as a flagship modern high-end MCU, it has 512k RAM, so it's very strange that it come with so outdated and slow USB interface... Very strange choice... 

I think at least 480 MBps USB interface is must have for any modern MCU, even if it runs at 50 MHz. I expect to see at least USB3 from modern MCU.

They name it "flagship microcontroller" and running at up to 300 MHz... And what I see?! USB FS 12 MBps? Really?