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

[langwadt]

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.

it seems to me that if choice and orientation of the inductor in a buck converter is that critical there must be something seriously wrong

[ataradov]

CY7C68013A is a highly specialized device with USB HS being one of the main features. The device is garbage without USB HS.

I'm not sure I would call RP2350 "high-end". It is mid-range at best. And there are not many "modern" devices with USB HS in general.

[radiolistener]

I'm not sure I would call RP2350 "high-end". It is mid-range at best. And there are not many "modern" devices with USB HS in general.

STM32H7 and STM32F4 series with the similar RAM amount and core frequency has USB HS...

The new STM32U5 series which is positioned as extreme low-power MCU also come with USB HS.

[ataradov]

Sure, but this is a drop in a bucket compared to the number of devices available. And I don't expect HS to be a universal feature going forward, it will still be only added to select devices.

And I would not consider devices without HS PHY to really have USB HS. ULPI wastes a lot of pins, board space and increases BOM.

[radiolistener]

I understand your point that this is a compromise. But the low speed USB interface is a real bottleneck of modern MCU and it force to use more expensive models just to have USB HS despite the fact the the cheaper model has enough memory and performance to do the same task. I expect at least USB HS from a new modern MCU and it's sad that they continue to put so ancient USB FS with just 12 Mbps at max.

[radiolistener]

Google: RP2350 datasheet
Section 12.4 “peripherals: ADC and temperature sensor”

12-bit with 9.2 ENOB 500 kHz...

Unfortunately even worse than I expected

[radiolistener]

Raspberry Pi has good board Raspi Zero 2W. It has nice performance and power consumption. The only con is too small memory and lack of USB3 interface.

So if they release some kind of a new Raspi Zero 3W with 1-2 GB RAM and USB3 it will be very nice product for embedders and a good replacement for MCU 

[PCB.Wiz]

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.

That's a plus, but you cannot poll a IRQ, you can only stall as you wait.
That forces you to use GPIO, but there seem to be no virtual GPIO, so you must consume a pin to signal between state engines.
Worse, there is no JMP NOT PIN, only JMP PIN, so if you want interlaced operation, you are forced to duplicate whole code blocks, and use pin pairs where one pin is simply a mirror copy of the other. 

Another peeve, is you cannot poll and increment in a single clock, yet that is a very common PIO usage task.
The PWM gets an edge option on pins as inputs, but alas, not PIO ...
 

[SpacedCowboy]

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.

The CY7C68013A is a USB2-to-serial-bridge controller, with an 8051 bolted on. Its purpose is to handle USB2, the 8051 is more of an add-on. It's great if what you *really* want is USB2 HS, but not so wonderful otherwise.
 

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

This is a cheap-as-chips MCU. Projected costs for a reel are around a dollar, and if the RP2040 is anything to go by, the price will be similar at much lower quantities. I'm expecting the top-of-the-line one (80-pin, with flash) to be ~$1.50 in quantity-1. We'll see when the distributes get a hold of them...

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.

Anything that runs at 50MHz is going to have to have a separate PLL for the HS USB end, and won't be processing much data at that speed anyway. Just handling the protocol stack is going to take a chunk out of that 50MHz...

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

Their flagship is "something that costs more than an RP2040 - they only have the two devices (with some sub-options on the RP235x). So to be their flagship, it has to out-perform a $0.70 (quantity-1) MCU. Which it does, quite handily. "Flagship" is a relative adjective.

Also, it doesn't officially run at 300MHz. It runs at 150MHz, but "overclocks well" - according to the beta-tester on the pre-production silicon who's been using it for the last year.

So if they release some kind of a new Raspi Zero 3W with 1-2 GB RAM and USB3 it will be very nice product for embedders and a good replacement for MCU 

The Raspberry Pi is not (IMHO) an MCU, it's an applications processor. It doesn't give you the tight control over timings and, well, everything that is the main benefit of the MCU - it runs Linux for crying out loud. "Oh, you want me to handle that IRQ ? Tough, I'm spinning on some kernel lock right now" 

STM32H7 and STM32F4 series with the similar RAM amount and core frequency has USB HS...

STM32H{4|7} with HSUSB are not in the price-range of the RP235x. AFAIK they start at $5 at distributors for the HSUSB variants.

This weekend I started to throw together a project for the RP2354 (so it's going to wait until they're ready before I build it) in which I previously used an STM32H7B0IBK + an Efinix FPGA because of the timings requirements. The 'B0 is $11.74 and the T8Q144C3 is $6.50. Instead I'm going to use 3 of the RP2354B's, and I won't need the SII9022a (another $5.85) that I was going to use to convert the RGB output of the STM into HDMI. I'll just link the HDMI up to the HSTX port on the RP2354. That's about $20,a huge difference in price from 3x $1.50 (estimated). And I get dual-core CPUs. And I get the PIO to do the heavy lifting. And the parts are more accessible. And the circuit is far simpler.

I also can't see *any* STM32H part bit-banging a DVI interface...

I realise that everyone's requirements are different, but I couldn't give a [insert thing you don't care about here] about the USB - for me its only purpose is to download firmware and act as a serial port when the firmware is running. I'm more interested in how I can use the stand-out feature of the part. If what it doesn't have was critical, I'd just move on and choose something more appropriate, the part isn't $deity's give to mankind, it's just a cool microcontroller.

If I wanted to get high-bandwidth to (say) a PI, I'd use the PIO to implement the SMI bus and get ~50 MBytes/sec transfer up and running. I don't need that right now...

[SpacedCowboy]

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.

That's a plus, but you cannot poll a IRQ, you can only stall as you wait.
That forces you to use GPIO, but there seem to be no virtual GPIO, so you must consume a pin to signal between state engines.
Worse, there is no JMP NOT PIN, only JMP PIN, so if you want interlaced operation, you are forced to duplicate whole code blocks, and use pin pairs where one pin is simply a mirror copy of the other. 

Another peeve, is you cannot poll and increment in a single clock, yet that is a very common PIO usage task.
The PWM gets an edge option on pins as inputs, but alas, not PIO ...

Yep. It's not perfect. I think even if they did all the above, there'd be something else that would occur, though. My bottom line: for what it costs, and for what it can do, it's pretty impressive.

There's a guy who's got a DECstation 3100 emulator running Ultrix on an RP2040 - when I was at college, I asked for a DECstation as my machine, whereas everyone else was on the VAXen. That changed pretty quickly, because the '3100 was far and away better. And now it's running on a $1 microcontroller (actually faster, and with better graphics than I had, and more memory...)

The PIOs play a large part in how that sort of stuff is pulled off. I couldn't see many other MCUs doing it without extra hardware (over and above a RAM chip and a Flash chip)

[SiliconWizard]

Sure, but this is a drop in a bucket compared to the number of devices available. And I don't expect HS to be a universal feature going forward, it will still be only added to select devices.

And I would not consider devices without HS PHY to really have USB HS. ULPI wastes a lot of pins, board space and increases BOM.

A matter of market entirely. Now the chinese, who tend to have different markets, or at least address them differently, have more low- (ot say, mid-) range MCUs with USB HS, such as WCH.
Is there really no sizable market in the West, I don't know.
Countless designs have resorted to using FTDI chips (or equivalent) and a mid-range MCU to get USB HS. So the market must be there.

I think one related factor is drivers. At least on Windows. Unless you can use one of the standard classes that do not require custom drivers, FTDI was an attractive choice just for that reason.
And apart from maybe the mass storage class (which may not be what you want for your device), you're very unlikely to get satisfying throughput (HID in HS will never get you anywhere close to the 30-50MB/s that are possible with USB HS bulk or mass storage - or maybe video capture.)

All that meaning that development costs could be much higher than expected, and unless you sell millions of devices, the cost of the MCU is likely to be sort of irrelevant. Just a thought.

Think of it from a commercial product POV. Of course, for hobbyists, this driver thing, at least as long as you have one (even dodgy) solution, that'll be fine.

That's much less of a problem on Linux with libusb. (And on macOS for similar reasons.) On Windows, that's still a bitch, although WinUSB can get you there (with some limitations) - but that wasn't always available.

[ataradov]

You no longer need drivers for proprietary devices starting with Win8. You can just add MSOS descriptor and have it install a standard winusb.sys driver. Then you can just work with your device using Win32 APIs. It has been over 12 years since the release of Win8, so it is time to retire this excuse.

WCH is certainly ahead with USB HS device in a 20-pin package and only single pair of power supply pins. They also have USB3.0 MCU. The later one is a really good replacement for the Cypress part.

[radiolistener]

Anything that runs at 50MHz is going to have to have a separate PLL for the HS USB end, and won't be processing much data at that speed anyway. Just handling the protocol stack is going to take a chunk out of that 50MHz...

It don't need to process it, its just needs to control DMA to fill memory from one device (for example ADC) and then read and send it to USB. So, high performance MCU is not mandatory condition to use USB HS.

Just remember CY7C68013A, it is single threaded and runs at 48 MHz with just 16k RAM, but still able to load USB with up to 480 Mbps realtime continuous synchronous stream.

RP2050 can run at up to 300 MHz clock and has two cores (!), the performance is more than 10 times higher than CY7C68013A and I even don't talk that RP2050 core can do more operations than 8051 at the same clock frequency.

But slow and old CY7C68013A with just 16k RAM has USB HS and can utilize it at max speed. But fast and new RP2050 with 512k RAM and two cores don't have USB HS and has slow 12 Mbps USB which is too slow even for 72 MHz STM32F103.

[ataradov]

but still able to load USB with up to 480 Mbps realtime continuous synchronous stream.

It can't do anything even remotely close to that. The only way to use fill bandwidth is to use the external parallel interface where CPU is not involved at all, there is hardware that pushes the data stream directly into the USB buffers.

On its own it can barely fill even FS speed. As I said, it is a specialty controller designed to transmit data to and from the parallel interface, not a general purpose MCU. The core is there to do setup and basic maintenance tasks that can be slow.

I experimented a lot with Atmel SAM V71, which is a Cortex-M7 with USB HS running at 300 MHz. The only reasonable way to saturate USB HS is to use DMA to fill the buffers. In my case I used direct capture from the PIO. From the firmware, it works with the dummy data, but if you need to do any processing at all, it becomes too slow.

[radiolistener]

It can't do anything even remotely close to that. The only way to use fill bandwidth is to use the external parallel interface where CPU is not involved at all, there is hardware that pushes the data stream directly into the USB buffers.

On its own it can barely fill even FS speed.

yes 8051 is unable to generate 480 Mbps stream to utilize max speed of USB HS, but it can communicate with host to establish connection and configure 480 Mbps stream for external bus. This is what is expected from MCU.

The same RP2050 can establish communication with the host and configure DMA to transfer stream from some peripherals, like ADC or GPIO to USB at up to 480 Mbps. Why not?

And even if you want to generate all stream data on RP2050 core, you can generate pretty high stream speed on two cores running at 300 MHz. Much higher than USB FS limit 12 Mbps which is just 1.5 MB/sec 

[ataradov]

This is what is expected from MCU.

I  wish it was an actual design consideration. Even for the ST MCUs you mentioned before, there are not a lot of useful things that can be handled with low CPU intervention.

like ADC or GPIO to USB at up to 480 Mbps. Why not?

Because it does not have peripherals that can generate this much traffic. 500 ksps ADC will work well enough with USB FS.

If you actually what to make a useful MCU with USB HS, you will need to design the whole peripheral set accordingly.  WCH CH569 is a good example of such MCU (and with USB3.0 support too).


Sure, most modern MCUs can saturate USB FS. But almost none of them can saturate USB HS. It is a shame there is no some middle ground.

[radiolistener]

500 ksps ADC

Thats true, too slow ADC with low dynamic range is another issue
Even STM32F103 ADC can run at 2.5 MHz or 5 MHz in interleaved mode.

Sure, most modern MCUs can saturate USB FS. But almost none of them can saturate USB HS.

Something tells me that 2 x Cortex-M33 cores of RP2050 running at 300 MHz can saturate USB HS with no problem 
And it will be nice to utilize single cycle 32-bit MAC or two cycle float-64 operations for that. 

Even if you run it at stock frequency, I don't see the reason why it can't utilize at least half of USB HS bandwidth which would be pretty useful.

And ability to stream some synchronous data from GPIO to USB with DMA will be very useful feature.

[SiliconWizard]

That's for sure.

One point is that USB FS IPs must be dead cheap these days, while USB HS (especially with integrated PHY) must be significantly more expensive. Also they'll have some constraints on IO pads, but if you dedicate USB D+/D- pins rather than multiplex them with other functions, that's not a huge problem.

While it would eat up a significant number of GPIOs, it may be possible to interface with an external PHY via ULPI using the PIO. Although with only 32 instructions per state machine, not sure it's enough to cover all ULPI cases. Would also require overclocking, to get at least 3-4x ULPI clock, so 180 to 240 MHz, which should be possible if that overclocks as well as the RP2040. Quite a challenge though at first sight.

[SpacedCowboy]

But slow and old CY7C68013A with just 16k RAM has USB HS and can utilize it at max speed. But fast and new RP2050 with 512k RAM and two cores don't have USB HS and has slow 12 Mbps USB which is too slow even for 72 MHz STM32F103.

Slow, old and expensive - I just looked on DigiKey and Q1 prices start at ~$18 (!)

Having read through several of your posts, it seems you really want HS USB2, if not USB3. You might have to consider that this cheap MCU might not be the perfect fit for your needs. I can think of a few options for how you could use the RP235x, but I'm not convinced you should do it, if HS USB is that critical to you. You could:

• Use an FT232HQ (or equivalent) - this is probably the easiest way. The 1248 interface it provides is basically a 1,2,4 or 8-bit wide SPI-like interface. Ought to be trivial to get that working with PIO. The combination would still be cheaper than one of those CY7C68013A
• Wait for someone to write a HS USB PIO state machine - DVI is already done, and USB (FS) is already done via PIO, so it may possible. Maybe even give it a go yourself...
• If that turns out to be impossible, maybe an ULPI interface is possible instead
• Use a different MCU

[radiolistener]

so 180 to 240 MHz, which should be possible if that overclocks as well as the RP2040

someone who was beta-tester of RP2050 wrote that it can be easily overclocked to 300 MHz with no issues.

[radiolistener]

The Raspberry Pi is not (IMHO) an MCU, it's an applications processor. It doesn't give you the tight control over timings and, well, everything that is the main benefit of the MCU - it runs Linux for crying out loud. "Oh, you want me to handle that IRQ ? Tough, I'm spinning on some kernel lock right now" 

Yes, I know. But it's high performance allows to spend some resources to run Linux and do some useful work. As result it is very pleasant for development and allows to use HDMI display and many existing software. And its power consumption almost comparable with high speed MCU. So it looks as very nice alternative for MCU.

But too small memory is real bottleneck of Raspi Zero 2w.
512 MB is even not enough to compile btop without installing zram.
The compiler just eats all memory and all swap and freezes due to out of memory even if you run it on single core...   

[SpacedCowboy]

Yes, I know. But it's high performance allows to spend some resources to run Linux and do some useful work. As result it is very pleasant for development and allows to use HDMI display and many existing software. And its power consumption almost comparable with high speed MCU. So it looks as very nice alternative for MCU.

But too small memory is real bottleneck of Raspi Zero 2w.
512 MB is even not enough to compile btop without installing zram.
The compiler just eats all memory and all swap and freezes due to out of memory even if you run it on single core...   

I think you and I are doing very different things, which might explain why we seem to have a different opinion on this MCU. I want response times in tens of nanoseconds, which immediately rules out anything running Linux unless there’s another core running on bare metal. My largest (by far) buffer is the framebuffer at 64k. Most of my other memory blocks are on the order of a kilobyte of RAM…

[brucehoult]

So if they release some kind of a new Raspi Zero 3W with 1-2 GB RAM and USB3 it will be very nice product for embedders and a good replacement for MCU 

The Raspberry Pi is not (IMHO) an MCU, it's an applications processor. It doesn't give you the tight control over timings and, well, everything that is the main benefit of the MCU - it runs Linux for crying out loud. "Oh, you want me to handle that IRQ ? Tough, I'm spinning on some kernel lock right now" 

That's where the Milk-V Duo is interesting. There is one full applications processor with FPU and 128 bit vector unit and MMU running Linux (capable of 1 GHz though the default Buildroot image runs it at 850 MHz), plus a second 700 MHz 64 bit MCU core for running bare metal code (Arduino library is supported) or RTOS. With 64 MB RAM and USB 2.0 (on a USB-C connector) and 100 Mbps ethernet (PHY, but no connector/magnetics). Originally $8, now $3. The CV1800B chips are also available, though are no cheaper than the board (at least in qty 5). For a few dollars more there are 256 MB and 512 MB versions with WIFI/BT and also an Arm A53 that can run instead of the bigger C906 RISC-V CPU. And an 8051 in there as well :-)

The Raspberry Pi Zero 2 is an amazing value if what you want is CPU processing power but, yeah, 512 MB isn't a lot for such a CPU. The Pi 3 with 1 GB also suffers from that -- it could productively use 4 GB or 8 GB.

[Postal2]

... Even old and ancient as mammoth bones CY7C68013A ....

Good chip, I like it.

[Jeroen3]

I'm impressed by the new features, but it's a shame that there's still no input capture functionality. (Maybe the new PIO features enable that? Haven't looked into those yet.)

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?

Sometimes it really matters which way your inductor is put on, for EMC reasons. Maybe they have a really fast switching transistor inside?
Strange though they do not specify part numbers for the capacitors, these are more important from my experience. 

That's for sure.

One point is that USB FS IPs must be dead cheap these days, while USB HS (especially with integrated PHY) must be significantly more expensive. Also they'll have some constraints on IO pads, but if you dedicate USB D+/D- pins rather than multiplex them with other functions, that's not a huge problem.

While it would eat up a significant number of GPIOs, it may be possible to interface with an external PHY via ULPI using the PIO. Although with only 32 instructions per state machine, not sure it's enough to cover all ULPI cases. Would also require overclocking, to get at least 3-4x ULPI clock, so 180 to 240 MHz, which should be possible if that overclocks as well as the RP2040. Quite a challenge though at first sight.

The line driver of USB HS takes a lot of surface area. I don't think they can afford that on this silicon.
See this image on the RP2040 how much space USB FS takes.
I don't know any chips in this size with usable USB HS, you? I also don't see any use case for it. There is no display/camera interface, no audio peripherals, no hardware SDIO. 

Typical, they don't have a !RESET pin, they have a RUN pin    never noticed that on the rp2040.