Author Topic: The Raspberry PI PICO 2, now has extra RISC-V cores (Read 19546 times)

MK14 · « **on:** August 08, 2024, 03:50:30 pm »

https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/

Quote

Raspberry Pi Pico 2 lands with (drum roll) RISC-V cores

Quote

It's exciting news for RISC-V fans: Raspberry Pi is adding support for the open ISA with the launch of the Pico 2 and the company's new RP2350 microcontroller.
Pi Pico 2

The Pi Pico 2 that arrived at a seaside Vulture outpost today – click to enlarge

The Pico 2 board retails for $5 and, according to the Pi team, retains backwards hardware and software compatibility with previous versions. While the on-chip memory has been upped to 520KB – there is also 4 MB of on-board QSPI flash – the two RISC-V Hazard3 CPU cores included in the microcontroller may well interest enthusiasts and implementers alike.

The Hazard3 cores are optional: Users can at boot time select a pair of included Arm Cortex-M33 cores to run, or the pair of Hazard3 cores. Both options run at 150 MHz. The more bold could try running one RV and one Arm core together rather than two RV or two Arm.

Hazard3 is an open source design, and all the materials for it are here. It's a lightweight three-stage in-order RV32IMACZb* machine, which means it supports the base 32-bit RISC-V ISA with support for multiplication and division in hardware, atomic instructions, bit manipulation, and more.

Pi supremo Eben Upton told The Register, "RISC-V is an exciting development for us: Our goal is to give software developers a chance to experiment with a different architecture in a stable, well-supported environment, and to express our enthusiasm for the Hazard3 open-hardware core, which was developed by Luke Wren, one of our ASIC engineers, in his spare time.

"I think RISC-V provides researchers with an interesting environment for architectural experimentation, and SoC designers with a high degree of configurability. One contribution we're making here is to legitimize Hazard3 as a mature, 'clean' core for verbatim use in other designs, or as a basis for further development."

As for leaping into the world of RISC-V, Upton explained how the cores would work: "They're selectable at boot time: Each port into the bus fabric can be connected either to an M33 or a Hazard3 via a mux. You can even, if you're feeling obtuse, run with one of each."

Hazard3 is a modest but capable microcontroller-grade design. It's not for running a modern general-purpose operating system on. Then again, that's not really the point of the Pico 2 and the RP2350.

Upton told us: "FreeRTOS is the preferred OS (as on RP2040). There's an increasing amount of excitement around Zephyr, and some community effort to port that to the RP2 platform, and we may engage formally with that in due course."

As with the original Pico, there are 26 multi-purpose GPIO pins, though the jump from 264KB of SRAM and 2MB of onboard flash opens the device up to more intriguing development options. Aside from the obvious, "Does it run Doom?" question – the answer is yes – the RP2040 on the original Pico has been pressed into service by the emulation community, not forgetting the recent implementation of Apple's original Mac on the device.
Security

The Pico has also turned up in smart home implementations and proven popular with industry, although perhaps not as popular as the team would like.

Some users have described the security features, or lack thereof, of the RP2040 as enough to make it a non-starter in the embedded world; they want to keep their proprietary code on the device away from reverse engineers, and the RP2040 doesn't help with that.
Raspberry Pi Pico 2

Extra detail - click to enlarge

To that end, the Raspberry Pi team has implemented what it calls a "comprehensive security architecture" into the new microcontroller. This is built around Arm TrustZone for Cortex-M and incorporates signed boot, 8KB of antifuse OTP for key storage, SHA-256 acceleration, a hardware TRNG, and fast glitch detectors. There's also secure boot ROM.

According to the Pi team, this will allow "professional users to integrate RP2350, and Raspberry Pi Pico 2, into products with confidence."
Well Arm'd

Upton was keen to emphasize the additional performance on tap. On the Arm side, the Pico has stepped up from two Cortex-M0+ cores to a Cortex-M33 pair, which each have extra bells and whistles including an FPU and DSP.

"The extra performance, and particularly floating point and DSP performance, opens up a bunch of new applications, both for hobbyists and professional users," he said of the Pico 2.

"Some of our music synth customers (we have a surprisingly large number of these) are quite excited about the things they'll be able to do with the platform."

However, he noted, "The security and low-power features are probably as interesting to industrial customers as the additional performance."

The downside to all the improvements is the inevitable price increase – the Pico started at $4, and the Pico 2 is slated to begin at $5. While unlikely to worry enthusiasts too much, the price increase could concern customers buying in bulk.

The Pico 2 also lacks some of its predecessor's connectivity options – a Wi-Fi version is not yet available. However, Upton told us that one would arrive "likely before the end of the year."

Getting hold of one could also be tricky. Upton told us that "this is going to be a pretty shallowly stocked launch," with more volume set to come through in the next few weeks. The price increase was attributed to cost growth in the platform and a slightly more expensive chip – the RP2350 is $0.10 more than the RP2040.

And the number? Sadly nothing to do with the Amiga 2000's 2350 genlock, but instead derived from the basic chip itself. As Upton explained: "2350 = 2x Cortex-M33s, with 2^5*16KB of SRAM and 0KB of Flash.

"The 0 indicates the chip itself has no Flash included. In this generation we'll be offering an RP2354 variant which includes 2MB (=2^4*128KB) of in-package QSPI Flash."

Why RISC-V must get its messaging right on open standard vs open source
FOSS funding vanishes from EU's 2025 Horizon program plans
World's first RISC-V laptop with Ubuntu preloaded touts AI smarts and octa-core chip
CHERI Alliance formed to promote memory security tech ... but where's Arm?

As for how the hardware and software compatibility works, Upton told us, "Pretty much everything should work, though it's a case of recompiling rather than just deploying the same binary."

While the microcontroller business represents a tiny percentage of Raspberry Pi's revenue, its volume is becoming substantial.

The price increase may be a shame for some, though there is that additional processing oomph on offer. The arrival of RISC-V in Hazard3 form makes the Pi Pico 2 intriguing from both a hobbyist and an industry perspective.

It will be very interesting to see what customers make of it. ®

Jope · « **Reply #1 on:** August 08, 2024, 04:24:47 pm »

This guy had access to samples over the last year: Why you should fall in love with the RP2350

ataradov · « **Reply #2 on:** August 08, 2024, 04:46:14 pm »

Yes, using two toolchains at the same time is exactly what I want. I guess they wanted to have a smooth transition to RISC-V, but the device is bizarre.

And one again, only 30 GPIO on a 60-pin device.

coppice · « **Reply #3 on:** August 08, 2024, 05:06:23 pm »

Quote from: ataradov on August 08, 2024, 04:46:14 pm

And one again, only 30 GPIO on a 60-pin device.

That does seem a bit thin. What's extra odd is the 60 pin version has 30 GPIOs, but the 80 pin version only has an additional 18. They use 2 extra VDD pins. This kind of thing may be a trend, though. With a lot of MCUs booting or running from QSPI that chews up a few pins. More complex split rails for a fine geometry die chews up a few pins. The trend towards new MCUs have a GPIO capability on everything but the power pins might be over for anything but a tiny package...... unless there is a customer backlash.

langwadt · « **Reply #4 on:** August 08, 2024, 07:21:57 pm »

Quote from: ataradov on August 08, 2024, 04:46:14 pm

Yes, using two toolchains at the same time is exactly what I want. I guess they wanted to have a smooth transition to RISC-V, but the device is bizarre.

And one again, only 30 GPIO on a 60-pin device.

seem like the intention is that you pick tool chain you prefer and just use that

it does show that cpu cores take up hardly any area, it's all RAM and peripherals

Rudolph Riedel · « **Reply #5 on:** August 08, 2024, 07:32:58 pm »

Briefly checked the datasheet - https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdf - if that thing is supported by PlatformIO some day and I get a free board, maybe I let it run some SPI code.

And RISC-V?
I find that extremely boring from a developer point of view.
The core is something for the compiler to deal with, at least for the most part.

Edit: and again, no f*ing reset button and a micro-usb connector.

iMo · « **Reply #6 on:** August 08, 2024, 07:37:46 pm »

Sparkfun offers one with a linear voltage regulator.. nice..
And with USB-C and 2 buttons - the boot and the reset too..
https://www.sparkfun.com/products/24870

PS: and ie. the Waveshare Electronics will follow soon, my bet (the same setup but cheaper)..

SiliconWizard · « **Reply #7 on:** August 08, 2024, 08:04:34 pm »

Quote from: ataradov on August 08, 2024, 04:46:14 pm

Yes, using two toolchains at the same time is exactly what I want. I guess they wanted to have a smooth transition to RISC-V, but the device is bizarre.

And one again, only 30 GPIO on a 60-pin device.

They have a 48-GPIO version: https://www.raspberrypi.com/products/rp2350/
not sure why so many pins for so few GPIOs though. That's a minus point. Other than this, the "dual boot" thing is baroque indeed (reminds me of the SG2000 on the milkV duo 256M). Yes, that looks like the addition that was probably cheap enough to include while trying to please everyone.

But otherwise, the updates are cool. A second USB controller could have been good.

tszaboo · « **Reply #8 on:** August 08, 2024, 08:41:29 pm »

Quote from: SiliconWizard on August 08, 2024, 08:04:34 pm

Quote from: ataradov on August 08, 2024, 04:46:14 pm
Yes, using two toolchains at the same time is exactly what I want. I guess they wanted to have a smooth transition to RISC-V, but the device is bizarre.

And one again, only 30 GPIO on a 60-pin device.

They have a 48-GPIO version: https://www.raspberrypi.com/products/rp2350/
not sure why so many pins for so few GPIOs though. That's a minus point. Other than this, the "dual boot" thing is baroque indeed (reminds me of the SG2000 on the milkV duo 256M). Yes, that looks like the addition that was probably cheap enough to include while trying to please everyone.

But otherwise, the updates are cool. A second USB controller could have been good.

The RPi team for sure has an overzealous signal integrity guy. It shows on all designs. The Pi Pico has GND pin every 4 pad, the RP2040 has a bunch of power supply bypassing pins, while a comparable STM32G0 has total of two power supply pins. The USB is impedance matched for USB 1.1 speeds, with thin PCB and thick traces. for like a 10mm length.
I've run 300mm long USB traces with whatever thickness and stackup, and it just works.
The end result is that it's a mayor PITA to layout the RP2040 with 0402 or larger components.

A few things they don't talk about. The datasheet is twice as long. It has a core voltage DC-DC. New pinout. This also will want 0201 capacitors. Power consumption in sleep is still pretty bad, ~50uA in lowest power states. That's probably already good enough for rechargeable batteries, and it's an improvement over the quite laughable RP2040 sleep currents.

So what am I missing? The built in Flash still. Makes making a custom board PITA, as you either use the exact same flash or you have to compile micropython yourself (yuck). Built in tunable crystal loading capacitors. Same for the USB line resistors, maybe a second USB, though a I recall you can make that with the PIO somehow.

ataradov · « **Reply #9 on:** August 08, 2024, 09:02:24 pm »

Quote from: tszaboo on August 08, 2024, 08:41:29 pm

The RPi team for sure has an overzealous signal integrity guy.

Or inability to meet the requirements without going overboard, which is more likely, IMO.

SiliconWizard · « **Reply #10 on:** August 08, 2024, 09:37:36 pm »

Yep. Anyway, we're criticizing the new RP2350 but I'm sure we'll find fun/interesting uses for it. As it was the case when the 2040 was announced.

But yes, it's still more of an educational chip than something really competitive (apart from pricing).

For the next iteration, I was hoping for more GPIOs yet, the performance upgrade is not bad, but I would have liked a higher Fmax (and while the RP2040 has a wide overclocking margin, with the M33 cores, I'm not sure it will overclock as well). As I said, possibly a second USB controller. As to the PIO, they added a 3rd unit and added some features, but I would have liked an increased program memory, apparently still the same.

The RISC-V cores don't look too bad in terms of performance - about 3.8 Coremark/MHz, which is better than most RISC-V-based MCUs out there.

floobydust · « **Reply #11 on:** August 08, 2024, 09:51:49 pm »

I keep looking for general purpose timers, you know the kind that can do an input capture based on external input, the kind every other MCU has.
RPI Foundation seems to know little about the requirements for embedded systems and these MCU's focus on the OS, there's a 64-bit usec tick timer.
More cores, great - but I think the design team missed the boat again. Yeah I know the PWM state machine and a bunch of hoops sorta works if you don't need accuracy.
It's not yet out what the TPU can do, if it's the same etc.
https://datasheets.raspberrypi.com/rp2350/rp2350-product-brief.pdf

ataradov · « **Reply #12 on:** August 08, 2024, 10:34:28 pm »

More USBs will come at a price of fewer pins until they can figure out how to multiplex them with GPIO pins. They really need to start figuring out the multiplexing part. Too many pins end up being dedicated single function.

brucehoult · « **Reply #13 on:** August 08, 2024, 11:30:47 pm »

Quote from: ataradov on August 08, 2024, 04:46:14 pm

Yes, using two toolchains at the same time is exactly what I want.

GCC is GCC ... just change the triple. Obviously all the peripherals stay the same, at the same addresses, no matter which CPU you use, so presumably the same headers work on either ISA.

A bit of a shame that the Arm cores now have DP FPU and even I think SIMD, while they've used a RISC-V core with neither and has slightly lower Coremark too, so most people will ignore them.

Huge upgrade from the CM0s on the Arm side, at least.

That guy who's been using prototypes for a year says you can add a lot of external RAM (16 MB I think he used) and it works without issues, even with both stack and PC out in that RAM, so that's cool.

MK14 · « **Reply #14 on:** August 08, 2024, 11:37:24 pm »

Quote from: brucehoult on August 08, 2024, 11:30:47 pm

A bit of a shame that the Arm cores now have DP FPU and even I think SIMD, while they've used a RISC-V core with neither and has slightly lower Coremark too, so most people will ignore them.

It seems that was NOT an option, unfortunately.

Amazingly, the floating point double, is implemented, by only using a few thousand, more transistors.

But in order to do that, it couldn't have a high speed multiplier (without greatly exceeding that small transistor budget). So, it 'cheats' and uses the Arms (M33F), (integer very high speed multiplier) one (via the Arm M33F custom instruction option, I think), to allow, relatively fast double floating point (multiply) calculations.

(Presumably) That was not an option with the RISC-V core. Possibly because of the communications route (using the custom Arm instruction features), between the double floating point hardware, and the Arm M33F hardware, not being available when RISC-V is enabled as an option, hence disabling the Arm M33F core(s).

SiliconWizard · « **Reply #15 on:** August 09, 2024, 01:31:52 am »

Quote from: brucehoult on August 08, 2024, 11:30:47 pm

That guy who's been using prototypes for a year says you can add a lot of external RAM (16 MB I think he used) and it works without issues, even with both stack and PC out in that RAM, so that's cool.

Well, yeah, QSPI PSRAM. I got about 30 MBytes/s sustained on a iMXRT1062 with PSRAM, I'd expect even lower throughput with the RP2350. Cool for some extra RAM, but relatively slow. Goes through cache though, so may be ok if you work on relatively small datasets at a time.

From what I've seen in the DS, they have added a second chip select, so now you can use a Flash chip AND a PSRAM chip. They share the same QSPI controller. Don't expect miracles in terms of bandwidth.

As to the RISC-V cores, it's that: https://github.com/Wren6991/Hazard3
It doesn't contain any FPU. Adding one from an external project should be doable, although with some work and especially verification work. Probably something that the RPi didn't care to do.

SpacedCowboy · « **Reply #16 on:** August 09, 2024, 02:47:11 am »

Quote from: SiliconWizard on August 08, 2024, 09:37:36 pm

For the next iteration, I was hoping for more GPIOs yet, the performance upgrade is not bad, but I would have liked a higher Fmax (and while the RP2040 has a wide overclocking margin, with the M33 cores, I'm not sure it will overclock as well). As I said, possibly a second USB controller. As to the PIO, they added a 3rd unit and added some features, but I would have liked an increased program memory, apparently still the same.

A few points.

There's a guy who's been beta-testing it for about a year now, and he says the overclocking is just as impressive - he's never had any problems running at 300MHz.
Using HyperRAM, you can get 42 write, 32 read on an RP2040. I expect the RP235x to be broadly similar. Slightly faster than that iMXRT1062, at least for writes
There's a fast (TX only, sadly) 8-bit parallel port @ 2400Mbit/sec which has a crossbar that can be fed by the PIO, and can reformat data for TMDS
The PIOs got a major upgrade with the ability for a PIO to signal/interrupt another which makes far more complex stuff viable, and also with the ability to read/write directly into the PIO FIFO, treating it as RAM, so you have a lot more options in terms of data transfer
DMA got an upgrade with infinite re-triggering (no longer need to use another DMA channel to re-trigger), and more offset choices for repeated triggering
ADCs are less noisy now
GPIO is 5v-tolerant, which is nice for me, YMMV
signed boot, OTP storage for encryption key, encrypted bitstream stored in the on-board flash makes it more palatable for commercial use
Half a meg of RAM is a nice upgrade
dual-core M33's which (as above) overclock significantly
An extra 18 GPIOs, +2 if you want to use the USB pins +6 if you can download to RAM via SWD and want to use the QSPI pins
Co-processor interface to GPIO, so a single instruction can write up to 64 (!) GPIOs without any register / bus latency (yeah, I'm looking at you, STM32H7) getting in the way. Fast GPIO is awesome
guaranteed production until 2040

... all in a $1 chip. Quite an upgrade IMHO.

[edit]
If you really want more (up to 3, I guess) USB ports, you can use PIO to implement low/full-speed USB, and as alluded to above, the existing hard-ip USB pins are in fact available as GPIO, though there are slew-rate restrictions because of the internal pulls.

MK14 · « **Reply #17 on:** August 09, 2024, 03:43:07 am »

This (Pimoroni Pico Plus 2) seems an interesting board, which is currently available, and in-stock, for £10 + VAT = £12 + shipping charges. (Rather than the £4 + VAT etc, for the standard PICO 2).

https://shop.pimoroni.com/products/pimoroni-pico-plus-2?variant=42092668289107

They add to the standard PICO 2 board, the following:

USB-C for power, programming, and data transfer, which is more compatible for some peoples setups, than the micro-USB one.
The RP2350B version, which gives the extra I/O pins.
Flash increases to 16MB of QSPI flash supporting XiP (from the standard 4MB).
It has an onboard 8MB of PSRAM.
This one has got a RESET button (Reset and BOOT buttons).
Also some other bits and pieces, like some connectors onboard.

WARNING:
If past experience is anything to go by (i.e. the original PICO). After about 2 or 3 days after launch (after initial stocks and pre-orders dry up), the new PICO's, may takes ages to get.
But maybe this time around, there will be plenty of availability. I just don't know.

shabaz · « **Reply #18 on:** August 09, 2024, 03:59:05 am »

Quote

This (Pimoroni Pico Plus 2) seems an interesting board, which is currently available, and in-stock

Nice, thanks for spotting that! I've decided to order one, while I wait for the normal Pico 2 boards to become available.

I do find the original RP2040/Pico quite useful (and easy-to-use SDK too), even though (just like the new products) not all makes sense, there's typically plenty of raspberrypi.com weirdness in their product design decisions.

There's some OTP register for the cores, so maybe the RISC-V is to sell to certain customers/regions they might not have a license to sell ARM to? (i.e. if they disable it before selling it). Pure speculation though.. I know zero about semiconductor sales.

floobydust · « **Reply #19 on:** August 09, 2024, 04:05:30 am »

RP2350 Datasheet.pdf 1,347 pgs. so it will be a while before it's really understood well. I got a bit lost on why two different CPU cores are in this thing.

"3.6 The RISC-V processors on RP2350 do not have access to the Cortex-M33 coprocessors"
"3.9. Arm/RISC-V Architecture Switching
RP2350 supports both Arm and RISC-V processor architectures. SDK-based programs which do not contain assembly code typically run unmodified on either architecture by providing the appropriate build flag.
There are two processor sockets on RP2350, referred to as core 0 and core 1 throughout this document. Each socket can be occupied either by a Cortex-M33 processor (implementing the Armv8-M Main architecture, plus extensions) or by a Hazard3 processor (implementing the RV32IMAC architecture, plus extensions)."

"3.9.2. Mixed Architecture Combinations
The ARCHSEL register has one bit for each processor socket, so it is possible to request mixed combinations of Arm and RISC-V processors: either Arm core 0 and RISC-V core 1, or RISC-V core 0 and Arm core 1.
Practical applications for this are limited, since this requires two separate program images. The two cores interoperate normally, including shared exclusives via the global monitor: a shared variable can be safely, concurrently accessed by an Arm processor performing ldrex, strex instructions and a RISC-V processor performing amoadd.w instructions, for example."

SiliconWizard · « **Reply #20 on:** August 09, 2024, 05:00:49 am »

Interesting. While it may have little practical value, being able to run an ARM core alongside a RISC-V core has potentially some educational value.

MK14 · « **Reply #21 on:** August 09, 2024, 05:10:32 am »

Quote from: SiliconWizard on August 09, 2024, 05:00:49 am

While it may have little practical value

I'd suspect, their future plans, might be to allow this chip to be versatile enough, to be used as a support chip, for either an all Arm or all RISC-V system.

I.e. This now gives the PI foundation, options to make a new (SBC) with big and powerful Arm cores or big and powerful RISC-V cores, and have this new chip, added to the board, regardless. Resulting in an overall, all Arm or all RISC-V SBC.

They might also want to test the water, with RISC-V systems.

josip · « **Reply #22 on:** August 09, 2024, 05:45:03 am »

Using it as USB device still need external crystal.

woofy · « **Reply #23 on:** August 09, 2024, 08:26:23 am »

I recall being quite excited when the RP2040 was announced, especially as a long production run was promised, and purchased a PICO module to play with. Since then it has gathered dust in a spares box. It's a great chip but has never been the right fit for any of my professional or hobby projects. The RP2350 looks like a useful incremental improvement, but has not addressed my biggest showstopper - connectivity. Time will tell if its something I will ever be able to use.
Looking forward to playing with the ESP32-P4, if it ever arrives.

MK14 · « **Reply #24 on:** August 09, 2024, 08:51:33 am »

EDIT: Sorry, the AliExpress store, kept on refusing to let me find the item for you.
Here it is on a German version (probably affiliate link, from where I found it), and it could disappear (the link) at any time.
https://heise.digidip.net/visit?url=https://de.aliexpress.com/item/1005007259059322.html

There have been English links in the past.
Probably best to get the link directly from the Expressif main product website, when they have stock (again) and are happy to advertise it.

Quote from: woofy on August 09, 2024, 08:26:23 am

Looking forward to playing with the ESP32-P4, if it ever arrives.

I think they have been distributing (selling), a very small number, of initial (maybe not fully working) development units.

N.B. Make sure you only buy it from the real Expressif store at the original prices, not some reseller at perhaps three times the launch price.

As a development kit, from Expressif (Via their AliExpress outlet, stock is patchy, I've seen it in-stock, at least once) for around £45, with a 7 inch display and other stuff, in very limited quantities.

The Expressif AliExpress store front:
https://www.aliexpress.com/store/1100220184

There is a (hopefully shortly to be released, they are waiting for the chips to arrive, the first or early units, are already done, if I understand the situation, correctly) Olimex, €10 .. €15 (estimated price, by Olimex) version of the ESP32-P4 development board, which is a bit like a PICO.

https://www.hackster.io/news/olimex-teases-a-low-cost-dual-core-risc-v-dev-board-built-around-the-espressif-esp32-p4-84333cbefeaf

Olimex Blog about it:
https://olimex.wordpress.com/2024/07/25/esp32-p4-dual-core-risc-v-open-source-hardware-board-is-almost-finished/

iMo · « **Reply #25 on:** August 09, 2024, 09:42:52 am »

Quote from: SiliconWizard on August 09, 2024, 05:00:49 am

Interesting. While it may have little practical value, being able to run an ARM core alongside a RISC-V core has potentially some educational value.

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

Quote

..For RISC-V lovers there are also some RISC-V cores to play with, but I do like my Cortex-M33s, so I’ve been sticking to those. The RAM size is doubled!..

Instead waisting silicon they had to focus on improving or adding some new features (a long list)..
So either ARM or RV..

tszaboo · « **Reply #26 on:** August 09, 2024, 10:41:32 am »

Quote from: iMo on August 09, 2024, 09:42:52 am

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.

Andree Henkel · « **Reply #27 on:** August 09, 2024, 11:48:52 am »

The weak point for my applications that will lead to selct a µC of competition is still lack of internal DAC´s
I don´t at all mind to have to connect external flash.

but as soon as I would have to use external DAC´s, Competitor with integrated DAC will have cost advantages.
And no, I won´t go into the hassle of PWM DAC or improvised DAC using R-Networks and several GPIO outputs

nice that the large chiip now has 8 ADC
but it would be much appreciated if small chip had 2 DAC and large one 4 DAC, 10Bit would ne reasonably enough, but 12 Bit would be a nice to have

rteodor · « **Reply #28 on:** August 09, 2024, 11:58:50 am »

Quote from: iMo on August 09, 2024, 09:42:52 am

Instead waisting silicon they had to focus on improving or adding some new features (a long list)..
So either ARM or RV..

This might be some manager being cautious on licensing (fees): Look ARM, if you don't behave RISC-V is waiting behind that door ready to work for cheap!

In fact this seems to be the industry trend: RISC-V has a level of support that looks unusually high compared to any other previous arch. If I was looking for a political answer I would ask from where is this support coming? And why?

MK14 · « **Reply #29 on:** August 09, 2024, 12:11:52 pm »

It will be very interesting, to compare the execution time, power consumption, code size and perhaps other things. By recompiling the same project, between the Arm M33F cores and the RISC-V cores.

Most systems/MCUs, don't let you do that. I.e. Not using exactly the same MCU, and just rebooting into the other CPU type, and recompiling the GCC code, and any other changes that need to be made, between the project types.

Also, according to the datasheet, at least one of the RISC-V features (related to what is usually used as a 1 microsecond timer/time signal for RISC-V), is available for both the RISC-V and Arm M33F modes.

EDIT:
Added quote from datasheet:

Quote

3.1.8. RISC-V Platform Timer
This 64-bit timer is a standard peripheral described in the RISC-V privileged specification, usable equally by the Arm and
RISC-V processors on RP2350

coppice · « **Reply #30 on:** August 09, 2024, 01:45:02 pm »

Quote from: Andree Henkel on August 09, 2024, 11:48:52 am

The weak point for my applications that will lead to selct a µC of competition is still lack of internal DAC´s
I don´t at all mind to have to connect external flash.

but as soon as I would have to use external DAC´s, Competitor with integrated DAC will have cost advantages.
And no, I won´t go into the hassle of PWM DAC or improvised DAC using R-Networks and several GPIO outputs

nice that the large chiip now has 8 ADC
but it would be much appreciated if small chip had 2 DAC and large one 4 DAC, 10Bit would ne reasonably enough, but 12 Bit would be a nice to have

If you look around the MCU market only a small proportion of available parts have a DAC in them, and they are often not big sellers. If you need a DAC you are looking in at a fairly niche market, and that always means most products are not right for you.

langwadt · « **Reply #31 on:** August 09, 2024, 03:29:53 pm »

Quote from: iMo on August 09, 2024, 09:42:52 am

Instead waisting silicon they had to focus on improving or adding some new features (a long list)..
So either ARM or RV..

compared to the large RAM,peripherals, PIOs, and regulator, the area of the extra cores are probably insignificant

NickAmes · « **Reply #32 on:** August 09, 2024, 03:37:19 pm »

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?

josip · « **Reply #33 on:** August 09, 2024, 07:27:13 pm »

Quote from: Andree Henkel on August 09, 2024, 11:48:52 am

The weak point for my applications that will lead to selct a µC of competition is still lack of internal DAC´s
I don´t at all mind to have to connect external flash.

but as soon as I would have to use external DAC´s, Competitor with integrated DAC will have cost advantages.
And no, I won´t go into the hassle of PWM DAC or improvised DAC using R-Networks and several GPIO outputs

nice that the large chiip now has 8 ADC
but it would be much appreciated if small chip had 2 DAC and large one 4 DAC, 10Bit would ne reasonably enough, but 12 Bit would be a nice to have

With internal DAC and USB device without external crystal, form me it will be almost perfect. I see in datasheet that 64 gpio bits / pins can be written in one cpu cycle. With 64 gpio's and less VDIO decap (I guess that they keep the same pinout because of compatibility with rp2040) pins totally perfect. I don't need more than 2MB of flash so RP2354B is the right one.

Quote from: coppice on August 09, 2024, 01:45:02 pm

If you look around the MCU market only a small proportion of available parts have a DAC in them, and they are often not big sellers. If you need a DAC you are looking in at a fairly niche market, and that always means most products are not right for you.

NXP / Kinetis entry level K32L2B are with DAC. I also found other low cost Cortex-M devices from other vendors (I searched for it) that have DAC.

Nominal Animal · « **Reply #34 on:** August 09, 2024, 07:29:48 pm »

No high-speed USB 2.0 (480 Mbit/s) is very limiting, in my opinion. 12 Mbit/s, or about 1 Mbytes/second of data payload, just doesn't cut it for many of my needs with this kind of computing power.

ataradov · « **Reply #35 on:** August 09, 2024, 07:42:26 pm »

With their apparent signal integrity issues/concerns, I would not expect USB HS any time soon. USB 2.0 PHY takes up a lot of silicon area and really tricky from signal integrity point of view. Even big vendors with a lot of design experience struggle with it.

coppice · « **Reply #36 on:** August 09, 2024, 07:57:09 pm »

Quote from: josip on August 09, 2024, 07:27:13 pm

Quote from: coppice on August 09, 2024, 01:45:02 pm
If you look around the MCU market only a small proportion of available parts have a DAC in them, and they are often not big sellers. If you need a DAC you are looking in at a fairly niche market, and that always means most products are not right for you.

NXP / Kinetis entry level K32L2B are with DAC. I also found other low cost Cortex-M devices from other vendors (I searched for it) that have DAC.

And if you find the application those chips were designed for you'll know why the DAC is there, and why its spec is what it is. If you look around most MCU ranges you'll find one or two parts with a DAC or two, especially of the line includes parts with op amps, and other analogue signal conditioning modules. Its generally just a couple, though, and there will have a spec specific to the applications which drove the module to be included. MCUs are NOT general purpose products.

langwadt · « **Reply #37 on:** August 09, 2024, 08:16:19 pm »

imagine if ICs like the one used on this had some actually documentation, https://wiki.sipeed.com/hardware/en/maixzero/m0s/m0s.html

zapta · « **Reply #38 on:** August 09, 2024, 08:48:31 pm »

Platformio support of the PICO is limited because RPI do not pay for the support.

https://community.platformio.org/t/why-the-minimal-presence-of-rp2040-on-platformio/37600/4

Arte · « **Reply #39 on:** August 09, 2024, 08:48:44 pm »

I don't think anyone's expecting a USB HS PHY but one could hope for a ULPI which is considerably less demanding (60MHz signals).
In fact if it wasn't for the external USB PHY e.g USB3300 being the master of the comms channel and having the rights to interrupt comms and start talking within 2 cycles, PIOs on an overclocked rp2040 could maybe cut it...

PCB.Wiz · « **Reply #40 on:** August 09, 2024, 08:49:56 pm »

Quote from: Andree Henkel on August 09, 2024, 11:48:52 am

The weak point for my applications that will lead to selct a µC of competition is still lack of internal DAC´s
I don´t at all mind to have to connect external flash.

but as soon as I would have to use external DAC´s, Competitor with integrated DAC will have cost advantages.
And no, I won´t go into the hassle of PWM DAC or improvised DAC using R-Networks and several GPIO outputs

nice that the large chiip now has 8 ADC
but it would be much appreciated if small chip had 2 DAC and large one 4 DAC, 10Bit would ne reasonably enough, but 12 Bit would be a nice to have

In a core with that much high speed digital, a DAC would be compromised. They are also not low-die-area items.
Best to just pick a small MCU that has the DAC mix you need, and pair it as an Analog focused peripheral ?

Nominal Animal · « **Reply #41 on:** August 09, 2024, 08:57:19 pm »

Quote from: zapta on August 09, 2024, 08:48:31 pm

Platformio support of the PICO is limited because RPI do not pay for the support.

https://community.platformio.org/t/why-the-minimal-presence-of-rp2040-on-platformio/37600/4

The Raspberry Pi Foundation has never been interested in interacting with open source projects. When they have to, they use temporary employees to do it.

PCB.Wiz · « **Reply #42 on:** August 09, 2024, 11:21:35 pm »

Quote from: NickAmes on August 09, 2024, 03:37:19 pm

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

Yes, PWMB allows gate and count inputs, but no capture input (plus registers are only 16b) ?!

There are reciprocal counter examples out there, on the RP2040, so the PIO can certainly manage capture.
Typically these use 3 state engines :

Define Nominal (minimum) Gate time using pin as flag, and sync to Fin edges.
Count Time during gate
Count cycles during gate

The PIO lacks wait edge, so code is forced to use two lines and run slower, and fatter

MT · « **Reply #43 on:** August 10, 2024, 12:10:40 am »

30 GPIO on a 60-pin device!?.. What!?

ataradov · « **Reply #44 on:** August 10, 2024, 12:51:41 am »

They have a lot of power supplies and all special functions (USB/oscillators) are on dedicated pins. Plus external QSPI flash takes up 6 pins.

SiliconWizard · « **Reply #45 on:** August 10, 2024, 01:01:14 am »

Quote from: MT on August 10, 2024, 12:10:40 am

30 GPIO on a 60-pin device!?.. What!?

Or 48 GPIOs on a 80-pin device.

boz · « **Reply #46 on:** August 10, 2024, 01:08:02 am »

What I am seeing is a well specified cheap and configurable microprocessor and can't wait to get my new dev board. I have used the RP2040 since early 2022 the PIO is amazing and can be programmed to fill in most of the gaps people her are whining about, for the new chip the only downside I can see is they dropped the RTC but everything else has improved.

Rather than listen to the doom mongers here who are heavily invested in their current ecosystems I would tell people to spend $5 and try it, the community is large and very friendly as everyone is a noob so you're not going to get some toss-pot greybeard telling you what a fuckwit you are for not knowing about some weird errata about an I2C clock stretching bug.

Shame I didn't sell my stash of STM32 and PIC chips while the prices were high.

ataradov · « **Reply #47 on:** August 10, 2024, 01:13:58 am »

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.

floobydust · « **Reply #48 on:** August 10, 2024, 01:19:30 am »

Raspberry Pi did their IPO June 11, 2024 stock price kinda flat?
As always, investors want new new new so pressure to release something is high.

Why makers have to endure some political battle over two CPU types within the Pico 2 is beyond me. Is this a Dr. Jekyll and Mr. Hyde creation? Really.

Instead, pick one and give us some peripherals like Espressif generously does with the ESP32 which kicks ass off the Pico 2.

The magical unicorn PIO is nothing like a real TPU on Freescale or Infineon MCU's. People are happy with latency, hoop jumping serving the PIO, it doesn't even decr or is it increment anything? 9 op-codes? Oh they broke the silicon piggy bank with that lol. I'm unhappy that as an embedded MCU it misses basics that even 8-bit clunkers have.

kamocat · « **Reply #49 on:** August 10, 2024, 01:44:10 am »

Quote from: NickAmes on August 09, 2024, 03:37:19 pm

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

SiliconWizard · « **Reply #50 on:** August 10, 2024, 02:22:56 am »

Quote from: ataradov on August 10, 2024, 01:13:58 am

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 · « **Reply #51 on:** August 10, 2024, 03:12:24 am »

Quote from: boz on August 10, 2024, 01:08:02 am

..., 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 · « **Reply #52 on:** August 10, 2024, 03:24:18 am »

Quote from: SiliconWizard on August 10, 2024, 02:22:56 am

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 · « **Reply #53 on:** August 10, 2024, 03:26:54 am »

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 · « **Reply #54 on:** August 10, 2024, 04:10:16 am »

Quote from: floobydust on August 10, 2024, 03:26:54 am

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 · « **Reply #55 on:** August 10, 2024, 09:53:33 am »

Quote from: tszaboo on August 09, 2024, 10:41:32 am

Quote from: iMo on August 09, 2024, 09:42:52 am
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 · « **Reply #56 on:** August 10, 2024, 10:23:37 am »

Quote from: kamocat on August 10, 2024, 01:44:10 am

Quote from: NickAmes on August 09, 2024, 03:37:19 pm
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.

Quote

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 · « **Reply #57 on:** August 10, 2024, 02:46:57 pm »

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 · « **Reply #58 on:** August 10, 2024, 02:58:20 pm »

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 · « **Reply #59 on:** August 10, 2024, 05:56:43 pm »

Quote from: iMo on August 10, 2024, 02:58:20 pm

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 · « **Reply #60 on:** August 10, 2024, 06:18:07 pm »

Quote from: ataradov on August 10, 2024, 02:46:57 pm

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 · « **Reply #61 on:** August 10, 2024, 09:05:10 pm »

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 · « **Reply #62 on:** August 10, 2024, 09:38:50 pm »

Quote from: SiliconWizard on August 10, 2024, 09:05:10 pm

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

Quote from: SiliconWizard on August 10, 2024, 09:05:10 pm

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 · « **Reply #63 on:** August 10, 2024, 09:41:08 pm »

Quote from: SiliconWizard on August 10, 2024, 09:05:10 pm

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.

Quote

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 · « **Reply #64 on:** August 10, 2024, 10:51:15 pm »

Quote from: SpacedCowboy on August 10, 2024, 09:38:50 pm

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.

Quote

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 · « **Reply #65 on:** August 10, 2024, 11:34:19 pm »

Quote from: MK14 on August 10, 2024, 10:51:15 pm

Quote from: SpacedCowboy on August 10, 2024, 09:38:50 pm
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.

Quote
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_ · « **Reply #66 on:** August 11, 2024, 09:09:19 am »

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 · « **Reply #67 on:** August 11, 2024, 10:48:03 am »

Quote from: SpacedCowboy on August 09, 2024, 02:47:11 am

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 · « **Reply #68 on:** August 11, 2024, 11:51:52 am »

Quote from: radiolistener on August 11, 2024, 10:48:03 am

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_ · « **Reply #69 on:** August 11, 2024, 01:53:34 pm »

Quote from: guenthert on August 11, 2024, 01:46:43 pm

Quote from: xbst_ on August 11, 2024, 09:09:19 am
[..]
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 · « **Reply #70 on:** August 11, 2024, 03:11:47 pm »

Quote from: radiolistener on August 11, 2024, 10:48:03 am

Quote from: SpacedCowboy on August 09, 2024, 02:47:11 am
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.

Quote from: radiolistener on August 11, 2024, 10:48:03 am

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 · « **Reply #71 on:** August 11, 2024, 04:21:45 pm »

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 · « **Reply #72 on:** August 11, 2024, 08:02:51 pm »

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 · « **Reply #73 on:** August 11, 2024, 08:34:04 pm »

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 · « **Reply #74 on:** August 11, 2024, 08:41:30 pm »

Quote from: SpacedCowboy on August 11, 2024, 03:11:47 pm

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?

langwadt · « **Reply #75 on:** August 11, 2024, 08:47:22 pm »

Quote from: phil from seattle on August 11, 2024, 08:02:51 pm

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 · « **Reply #76 on:** August 11, 2024, 08:49:00 pm »

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 · « **Reply #77 on:** August 11, 2024, 09:02:00 pm »

Quote from: ataradov on August 11, 2024, 08:49:00 pm

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 · « **Reply #78 on:** August 11, 2024, 09:17:58 pm »

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 · « **Reply #79 on:** August 11, 2024, 10:27:40 pm »

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 · « **Reply #80 on:** August 11, 2024, 11:54:23 pm »

Quote from: SpacedCowboy on August 11, 2024, 03:11:47 pm

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 · « **Reply #81 on:** August 12, 2024, 01:07:06 am »

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 · « **Reply #82 on:** August 12, 2024, 02:10:12 am »

Quote from: SpacedCowboy on August 10, 2024, 05:56:43 pm

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 · « **Reply #83 on:** August 12, 2024, 02:21:47 am »

Quote from: radiolistener on August 11, 2024, 08:41:30 pm

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.

Quote from: radiolistener on August 11, 2024, 08:41:30 pm

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

Quote from: radiolistener on August 11, 2024, 08:41:30 pm

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

Quote from: radiolistener on August 11, 2024, 08:41:30 pm

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.

Quote from: radiolistener on August 11, 2024, 08:41:30 pm

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"

Quote from: radiolistener on August 11, 2024, 08:41:30 pm

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 · « **Reply #84 on:** August 12, 2024, 02:27:30 am »

Quote from: PCB.Wiz on August 12, 2024, 02:10:12 am

Quote from: SpacedCowboy on August 10, 2024, 05:56:43 pm

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 · « **Reply #85 on:** August 12, 2024, 02:35:19 am »

Quote from: ataradov on August 11, 2024, 09:17:58 pm

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 · « **Reply #86 on:** August 12, 2024, 02:44:25 am »

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 · « **Reply #87 on:** August 12, 2024, 02:57:27 am »

Quote from: SpacedCowboy on August 12, 2024, 02:21:47 am

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 · « **Reply #88 on:** August 12, 2024, 03:00:03 am »

Quote from: radiolistener on August 12, 2024, 02:57:27 am

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 · « **Reply #89 on:** August 12, 2024, 03:12:27 am »

Quote from: ataradov on August 12, 2024, 03:00:03 am

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 · « **Reply #90 on:** August 12, 2024, 03:18:20 am »

Quote from: radiolistener on August 12, 2024, 03:12:27 am

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.

Quote from: radiolistener on August 12, 2024, 03:12:27 am

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 · « **Reply #91 on:** August 12, 2024, 03:38:24 am »

Quote from: ataradov on August 12, 2024, 03:18:20 am

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.

Quote from: ataradov on August 12, 2024, 03:18:20 am

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 · « **Reply #92 on:** August 12, 2024, 03:46:30 am »

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 · « **Reply #93 on:** August 12, 2024, 03:56:48 am »

Quote from: radiolistener on August 12, 2024, 02:57:27 am

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 · « **Reply #94 on:** August 12, 2024, 04:01:31 am »

Quote from: SiliconWizard on August 12, 2024, 03:46:30 am

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 · « **Reply #95 on:** August 12, 2024, 04:21:24 am »

Quote from: SpacedCowboy on August 12, 2024, 02:21:47 am

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 · « **Reply #96 on:** August 12, 2024, 05:30:01 am »

Quote from: radiolistener on August 12, 2024, 04:21:24 am

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 · « **Reply #97 on:** August 12, 2024, 05:35:58 am »

Quote from: SpacedCowboy on August 12, 2024, 02:21:47 am

Quote from: radiolistener on August 11, 2024, 08:41:30 pm
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 · « **Reply #98 on:** August 12, 2024, 06:39:57 am »

Quote from: radiolistener on August 11, 2024, 08:41:30 pm

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

Good chip, I like it.

Jeroen3 · « **Reply #99 on:** August 12, 2024, 06:47:26 am »

Quote from: NickAmes on August 09, 2024, 03:37:19 pm

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.

Quote from: SiliconWizard on August 12, 2024, 03:46:30 am

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.

radiolistener · « **Reply #100 on:** August 12, 2024, 06:49:28 am »

Quote from: SpacedCowboy on August 12, 2024, 05:30:01 am

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

I'm interesting in realtime capture, DSP processing and transferring high speed streams. The main focus is to keep processing with no breaks, because it leads to broken realtime stream. If there is 100 ns delay that's not a problem, because CPU is fast enough to process more data on next 100 ns...

Raspi Zero 2w has pretty fast 4 cores, so processing speed is not a problem to run linux in background.

But small memory size is noticeable bottleneck. My tasks don't require so many memory, but when running some linux tasks it is very noticeable.

PCB.Wiz · « **Reply #101 on:** August 12, 2024, 07:37:12 am »

Quote from: Jeroen3 on August 12, 2024, 06:47:26 am

I don't know any chips in this size with usable USB HS, you?

WCH have a HS-USB MCU that comes down to TSSOP20.

tszaboo · « **Reply #102 on:** August 12, 2024, 07:52:59 am »

Quote from: radiolistener on August 12, 2024, 06:49:28 am

Quote from: SpacedCowboy on August 12, 2024, 05:30:01 am
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

I'm interesting in realtime capture, DSP processing and transferring high speed streams. The main focus is to keep processing with no breaks, because it leads to broken realtime stream. If there is 100 ns delay that's not a problem, because CPU is fast enough to process more data on next 100 ns...

Raspi Zero 2w has pretty fast 4 cores, so processing speed is not a problem to run linux in background.
But small memory size is noticeable bottleneck. My tasks don't require so many memory, but when running some linux tasks it is very noticeable.

The Zero is has A cores on it with the intention is to run Linux.
These have M cores on them.

USB HS is not trivial for microcontrollers, because you have to be able to run transistors in your design at 480MHz to be able to send the data.
This microchip run at a max of 150 MHz, despite that you repeatedly call it 300 MHz, it's not that much. You cannot add the MHz together. Nor can you compare overclocked performance with design specifications.
You need to work on different semiconductor nodes to have USB HS. Your transistors that are available are different.
And the target audience is different. People want to run Micropython and have USB mass storage and a serial terminal on this, not stream data.

radiolistener · « **Reply #103 on:** August 12, 2024, 08:09:44 am »

Quote from: tszaboo on August 12, 2024, 07:52:59 am

This microchip run at a max of 150 MHz, despite that you repeatedly call it 300 MHz, it's not that much. You cannot add the MHz together. Nor can you compare overclocked performance with design specifications.
You need to work on different semiconductor nodes to have USB HS. Your transistors that are available are different.
And the target audience is different. People want to run Micropython and have USB mass storage and a serial terminal on this, not stream data.

Mass storage also needs high speed.

Regarding to the frequency, if I understand correctly, they can simply use PLL block to generate higher clock frequency and run USB peripherals at higher speed, then synchronize it with slower core clock, so the core can continue to run at 150 MHz and will be able to configure USB and it's DMA which can transfer data from core or directly from other peripherals like memory, ADC, GPIO, etc. Isn't it?

If it can run entire Cortex-M33 core from 300 MHz clock with no issue, I'm sure transistors on that silicon can run at higher clock.

You're talking like there is some fundamental limitation, but I don't see where is the limit? Even if core will send data to USB module at 120-240 MBps that's not a big issue. 240 MBps also pretty good speed in comparison with 12 MBps.

Regarding to micropython, I don't see the real purpose for that. If you want to run interpreter at real time through console you can use Raspi Zero, but if you're programming some function for MCU, there is no reason to use python. This is just a toy to run something like print("Hello world") from console and say "Cool! It can run python..."

iMo · « **Reply #104 on:** August 12, 2024, 08:38:29 am »

@radiolistener: I got two pi-zero-2W at a local ham radio flea market almost free this spring and spent a couple of weeks with it. It is a barely usable board, imho. Well, good for a headless "business as usual" experiments with linux. I even ran OMV nas on them. Not suitable for smaller or specialized projects where we usually utilize mcus for many reasons. A flop I would say..

It seems to me the Pico and Pico2 have been developed by a group of people with an access to only a limited set of silicon libraries and dev tools, I would say more-less talented graduates who got a limited support from a large manufacturer with "show us what you can do but it should be cheap"..
We cannot compare that effort and results with mcus from full fledged vendors like STM, Freescale, Microchip, etc.

MK14 · « **Reply #105 on:** August 12, 2024, 08:41:26 am »

Look, it's a moderately powerful, from $0.80 a chip, and low cost development platform (from around $4 a board).

Some people in this thread, seem to want it to act like a reasonably powerful single board computer, with fast/powerful USB connection(s), and other powerful stuff.

If that is what you want, then be prepared to fork out tens of dollars and get the PI Zero or bigger, full PI versions.

Overclocking it to 300MHz, insisting they put USB2 or even USB3 on it, is perhaps being a little over the top.

Its PIO system, can be very powerful and useful, in some applications.

I agree, it's a pity, they didn't give it more I/O fabric, such as some timers, input captures, output compares and other typical I/O things.

But missing USB2 or even USB3, is really going outside what I think this device should be reasonably used for.

At its official/guaranteed 150 MHz, you can't process lots of data, that quickly (with some probably simple task, such as data movement between devices, highly optimized exceptions, occasionally), so would be better off, with a proper high speed MCU, appropriately fast USB interfaces (2 or 3), along with the (usually) considerable increase in cost of the device.

brucehoult · « **Reply #106 on:** August 12, 2024, 08:58:15 am »

Quote from: MK14 on August 12, 2024, 08:41:26 am

I agree, it's a pity, they didn't give it more I/O fabric, such as some timers, input captures, output compares and other typical I/O things.

I don't think I've ever read a motorcycle review, whether 250cc or 1250cc, that didn't say "It would be better with 50cc more...".

Same deal here.

Sure, but then it would be a different product, in a different class. Other products already exist in that class ... buy one of them and let this one do the job it was designed to do, at the price it was designed to be.

radiolistener · « **Reply #107 on:** August 12, 2024, 09:00:30 am »

Quote from: MK14 on August 12, 2024, 08:41:26 am

At its official/guaranteed 150 MHz, you can't process lots of data, that quickly, so would be better off, with a proper high speed MCU, appropriately fast USB interfaces (2 or 3), along with the (usually) considerable increase in cost of the device.

I didn't worked with RP series MCU, but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations. After all it can write at least 32-bits per cycle. At 150 MHz it can produce up to 4800 MBps with simple bit-banging... And even can do something more complicated and useful, like applying filter to the realtime stream on the fly.

And since it has 2 core, it can produce up to 9.6 GBps stream with dumb write in a loop. This is 800 times higher than USB HS 480 MBps bandwidth.

With 300 MHz overclock it can produce up to 19.2 GBps, but USB bottleneck is just 0.012 GBps... which is 1600 times slower than MCU can produce...

With no high speed communication interface all that speed is almost useless...
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps?
And no way to transfer processed data out of the chip at speed higher than 12 MBps...

MK14 · « **Reply #108 on:** August 12, 2024, 09:00:53 am »

With the original release of the PICO (RP2040), there was a bug(s) in the original initial revision (IIRC A1), which meant that floating point operations (singles worked but not double, IIRC), via its inbuilt software library (like) feature.

But, a few months later (I can't remember exactly how long it was, it might have been only a few weeks, or it could have been a lot longer), they released (IIRC) the A2 version, which was working just fine.

I'm not happy with what I'm hearing about the built in SMPS, which sounds like it might be problematic and/or very tricky to design that feature of the device.

If that is the case, I'm hoping they fix it, or at least improve the situation.

It is not clear if the current crop of development boards, that are for sale. Will work alright, as regards possible voltage regulator (SMPS) issues, or not.

I'm probably being overly cautious here (maybe way so). But since I don't have any PICO 2's yet. I'd prefer to wait, until they fix any issues, as necessary.

SiliconWizard · « **Reply #109 on:** August 12, 2024, 09:02:28 am »

This SMPS issue sure is disappointing. I don't know if they can easily fix it with a "small" silicon revision. We'll see.

MK14 · « **Reply #110 on:** August 12, 2024, 09:12:55 am »

Quote from: radiolistener on August 12, 2024, 09:00:30 am

I didn't worked with RP series MCU, but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations. After all it can write at least 32-bits per cycle. At 150 MHz it can produce up to 4800 MBps with simple bit-banging... And even can do something more complicated and useful, like applying filter to the realtime stream on the fly.

But with no high speed communication interface all that speed is almost useless...
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps? And no way to transfer processed data out of the chip at speed higher than 12 MBps...

Lots and lots of things.

For starters, the (encouraged to use, by the PI foundation) Micropython is an interpreter, so is not going to set any speed records.

Some things, even in C/C++, can need quite a few lines of code, maybe hundreds, thousands or more, in order to process the algorithms and do all the calculations.

In which case, they probably would not handle or need that much data throughput, going in and out.

I agree there is the odd edge case, where the task is so simple, like moving data between devices, that it could easily overload the slower, old USB interfaces.
But that is just one of tens of thousands (or more), of possible application areas.

Basically, with MCUs, you get what you pay for.

If you want a quad core 900 MHz operations, dual-issue, out-of-order execution, MCU, with 276 pins, full range of possible I/O devices, USB3 built in, etc. 16MB of on-chip SRAM, 32MB of built in flash, all on the same die. Quad 10 MHz 16 bit analogue converters, quad 14 bit DACs, with 8 spare very high speed op-amps, analogue comparators, etc.

Then the MCU, usually costs more than the $0.80, I originally mentioned.
Even tens times as much, $8 (I'm not sure, but definitely a lot more than $0.80 each), probably wouldn't be nearly enough. Unless the quantities involves were massive, perhaps 100,000 or even millions, needed.

tszaboo · « **Reply #111 on:** August 12, 2024, 09:16:32 am »

Quote from: radiolistener on August 12, 2024, 08:09:44 am

Quote from: tszaboo on August 12, 2024, 07:52:59 am
This microchip run at a max of 150 MHz, despite that you repeatedly call it 300 MHz, it's not that much. You cannot add the MHz together. Nor can you compare overclocked performance with design specifications.
You need to work on different semiconductor nodes to have USB HS. Your transistors that are available are different.
And the target audience is different. People want to run Micropython and have USB mass storage and a serial terminal on this, not stream data.

Mass storage also needs high speed.

Regarding to the frequency, if I understand correctly, they can simply use PLL block to generate higher clock frequency and run USB peripherals at higher speed, then synchronize it with slower core clock, so the core can continue to run at 150 MHz and will be able to configure USB and it's DMA which can transfer data from core or directly from other peripherals like memory, ADC, GPIO, etc. Isn't it?

If it can run entire Cortex-M33 core from 300 MHz clock with no issue, I'm sure transistors on that silicon can run at higher clock.

You're talking like there is some fundamental limitation, but I don't see where is the limit? Even if core will send data to USB module at 120-240 MBps that's not a big issue. 240 MBps also pretty good speed in comparison with 12 MBps.

Regarding to micropython, I don't see the real purpose for that. If you want to run interpreter at real time through console you can use Raspi Zero, but if you're programming some function for MCU, there is no reason to use python. This is just a toy to run something like print("Hello world") from console and say "Cool! It can run python..."

It cannot run it at 300MHz. You can overclock it and maybe run it at room temperature at 300MHz and it kinda sorta works sometimes, and you haven't verified all the rest of the datasheet values. There is no immediate step for USB. You ether run it at 12 Mbit, or 480 Mbit, there is no in between. The clocking speed is going to be the same, but half the time it's not going to send data.
The mass storage class is there to write the 4 Mbit flash memory with code. You don't need high speed for it, since most of the time it's used to edit the code. Writing is going to be seriously limited by the flash erase anyway, reading is like 3 seconds.

Despite what you think, Micropython is the main purpose of this chip. I guess 99% of users are either running micropython or the Arduino IDE and core for this chip.

iMo · « **Reply #112 on:** August 12, 2024, 09:20:37 am »

Quote from: radiolistener on August 12, 2024, 09:00:30 am

..
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps? And no way to transfer processed data out of the chip at speed higher than 12 MBps...

That could be useful for I/Q based DSP (today's standard) when you are going to process data from an external simultaneously sampling ADCs and the results are fed into an external something (like DAC or codec or similar in case of an SDRadio).
They still have a problem with that simple ADC, it seems, because of the internal noise, or they do not have better ADC silicon libraries handy, or lack of experience (ie the ADC bug in the previous pico version where they messed up the sizes of the weighting capacitors in their SAR ADC - a not easy to fix bug cheap as you would need to generate many new masks for a lot of $$ ).
The same with USB2.0 - it may need silicon libraries, royalties to pay (perhaps), and much better signal integrity in the overall design as atadarov wrote..

radiolistener · « **Reply #113 on:** August 12, 2024, 09:29:59 am »

Quote from: tszaboo on August 12, 2024, 09:16:32 am

You ether run it at 12 Mbit, or 480 Mbit, there is no in between. The clocking speed is going to be the same, but half the time it's not going to send data.

You can run USB module from 480 MHz or whatever you want frequency. USB module can have its own small buffer to perform operations at max speed with no needs to wait for the main core intervention. Its not a big deal to implement clock domain crossing synchronizer, so the core can continue to work at slower clock.

PCB.Wiz · « **Reply #114 on:** August 12, 2024, 09:30:42 am »

Quote from: radiolistener on August 12, 2024, 09:00:30 am

But with no high speed communication interface all that speed is almost useless...
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps? And no way to transfer processed data out of the chip at speed higher than 12 MBps...

Surely the QSPI can go well above 12mbd ?
The native QSPI port looks very fast, but is shared with boot flash, (and I think is master only?) so you may prefer PIO.

The WCH CH347 is a low cost TSSOP20 HS-USB part that has a QSPI interface they claim 60MHz for, so that's 240 Mbd

The posts like here
https://forums.raspberrypi.com/viewtopic.php?t=321476#p1924376
suggest a clocked QSPI slave using PIO can manage something under 50MHz, (~200MBd) it would need tsu/th checks on the CH347 pairing.
Choices would be 50MHz / 37.5MHz / 30MHz / 25MHz etc if you pick whole clk_peri/N matching, tho that's not mandatory.

The std SPI peripherals say this too

At the maximum SSPCLK (clk_peri) frequency on RP2350 of 150MHz, the maximum peak bit rate in mastermode is 70.5Mb/s.
In slave mode, the same maximum SSPCLK frequency of 150MHz can achieve a peak bit rate of 150 / 12 = 12.5Mb/s.

tszaboo · « **Reply #115 on:** August 12, 2024, 09:42:18 am »

Quote from: radiolistener on August 12, 2024, 09:29:59 am

Quote from: tszaboo on August 12, 2024, 09:16:32 am
You ether run it at 12 Mbit, or 480 Mbit, there is no in between. The clocking speed is going to be the same, but half the time it's not going to send data.

You can run USB module from 480 MHz or whatever you want frequency. USB module can have its own small buffer to perform operations at max speed with no needs to wait for the main core intervention. Its not a big deal to implement clock domain crossing synchronizer, so the core can continue to work at slower clock.

You are not listening, do you?
The transistors in the node don't switch at that speed. You need a different process node to have transistors that are designed to work at that speed. And with that, your entire digital design is different.

radiolistener · « **Reply #116 on:** August 12, 2024, 09:43:25 am »

Quote from: iMo on August 12, 2024, 09:20:37 am

That could be useful for I/Q based DSP (today's standard) when you are going to process data from an external simultaneously sampling ADCs and the results are fed into an external something (like DAC or codec or similar in case of an SDRadio).

Yes! This is wonderful feature, but the problem here is that there is no fast enough communication between core and external world.

What is the reason to do some DSP operation at 1 cycle if core will needs to waste next 800 cycles just to wait for the next data word? $:-\$

Quote from: iMo on August 12, 2024, 09:20:37 am

They still have a problem with that simple ADC, it seems, because of the internal noise, or they do not have better ADC silicon libraries handy, or lack of experience

I'm sure this is because they put switching converter inside MCU. This is definitely a bad idea. ADC needs to place any switching mode converters far away as you can. And if you use switching converter in your circuit at all, it requires serious effort to filter and block the noise to avoid any leakage to ADC circuit. When you put switching converter on the same die with ADC, it will be impossible to get good ADC performance.

Quote from: tszaboo on August 12, 2024, 09:42:18 am

You are not listening, do you?
The transistors in the node don't switch at that speed. You need a different process node to have transistors that are designed to work at that speed. And with that, your entire digital design is different.

Sorry, I'm not familiar with modern chip design. I see it something like design for FPGA, when you design or buying some verilog IP and combine it, like you can do using FPGA, but with converting verilog to the mask layout instead of generate gateware for programmable gates. Is that correct?

On FPGA you can generate several different clock sources and clock two circuits from different clocks. When you needs to communicate between these circuits you can implement clock domain crossing synchronizer. So there is no issue to run more complicated logic at lower clock and some simple logic at higher clock together on the same FPGA. Is that approach possible for a usual chip mask layout design?

For example STM32 use different clock for core and peripherals. I worked with FPGA and don't see something strange here. But if this is impossible for a usual chip with mask layout design then how they doing it on STM32?

iMo · « **Reply #117 on:** August 12, 2024, 10:09:03 am »

Quote from: radiolistener on August 12, 2024, 09:43:25 am

Quote from: iMo on August 12, 2024, 09:20:37 am
That could be useful for I/Q based DSP (today's standard) when you are going to process data from an external simultaneously sampling ADCs and the results are fed into an external something (like DAC or codec or similar in case of an SDRadio).

Yes! This is wonderful feature, but the problem here is that there is no fast enough communication between core and external world.

What is the reason to do some DSP operation at 1 cycle if core will needs to waste next 800 cycles just to wait for the next data word?

Again, you may use that 64bits for processing of something coming from outside's world (as I wrote above you need double precision when doing math with 20-32bit data, therefore 64bit FP is something I would expect in any modern mcu) and where you represent the result as a single number, or a set of numbers, or a graph (like nanovna) or a lower frequency signal (music, speech, simple picture like a waterfall in any SDR radio)
You might not need 64bit FPU inside the mcu for a DSP where you want process all that data at the host (ie a 16core 6GHz Intel) streaming via USB2.0/3.0 or via couple of PCIe lines..

rteodor · « **Reply #118 on:** August 12, 2024, 10:24:11 am »

Quote from: radiolistener on August 12, 2024, 09:00:30 am

Quote from: MK14 on August 12, 2024, 08:41:26 am
At its official/guaranteed 150 MHz, you can't process lots of data, that quickly, so would be better off, with a proper high speed MCU, appropriately fast USB interfaces (2 or 3), along with the (usually) considerable increase in cost of the device.

I didn't worked with RP series MCU, but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations. After all it can write at least 32-bits per cycle. At 150 MHz it can produce up to 4800 MBps with simple bit-banging... And even can do something more complicated and useful, like applying filter to the realtime stream on the fly.

And since it has 2 core, it can produce up to 9.6 GBps stream with dumb write in a loop. This is 800 times higher than USB HS 480 MBps bandwidth.

With 300 MHz overclock it can produce up to 19.2 GBps, but USB bottleneck is just 0.012 GBps... which is 1600 times slower than MCU can produce...

With no high speed communication interface all that speed is almost useless...
What is the reason for two cycle float64 operation or single cycle MAC if there is no way to get the data at higher than 12 Mbps?
And no way to transfer processed data out of the chip at speed higher than 12 MBps...

AHB bandwidth in RP2040 is 2GB/s at 125MHz (4 transfers of 32 bit per clock cycle). Mentioned in RP2040 Datasheet chapter 2.1.
I do not expect RP235x AHB transfer width to be bigger.

On a brief search I found that "RP2350 is manufactured on a modern 40nm process node". I think that's on the edge of what USB HS needs: multi GHz PLL and fast line transistors. IMHO power consumption would be the issue in this case (and with that problematic converter everyone is talking about ...).

radiolistener · « **Reply #119 on:** August 12, 2024, 10:35:22 am »

Quote from: iMo on August 12, 2024, 10:09:03 am

Again, you may use that 64bits for processing of something coming from outside's world

The question is what is the reason to use single cycle accelerators if you cannot get any performance improvement? Just because the speed at which the data coming from outside world to MCU through USB FS is so slow that MCU will waste 800 times more time for waiting one data sample from USB, than to process this one data sample with single cycle accelerator...

You can do the same processing without accelerators and it still will be faster than waiting data from USB FS. Because the main bottleneck here is not processing, but USB speed...

iMo · « **Reply #120 on:** August 12, 2024, 10:44:07 am »

Why do you need an USB?
You might have two external 16bit 10Msamples/sec simultaneously sampling ADCs (an example only) wired to the Pico's GPIO pins (or perhaps via its SPI), process the incoming data via Pico's FPU (double precision) and you may show a result in a form of an animated graph on a 320x200 TFT LCD display wired to the Pico's pins..
PS: all latest ham SDR radios (incl the cheapo ones) do it that way, incl. all nanovna-like boxes.. No need for high speed USB as you transfer only pretty low speed (low bit rates) results, like pictures (ie 320x200 2-3x per sec) or sound (mono 3kHz BW) or data (perhaps 9k6 with data/packet modems)..

tszaboo · « **Reply #121 on:** August 12, 2024, 11:35:52 am »

Quote from: radiolistener on August 12, 2024, 09:43:25 am

Sorry, I'm not familiar with modern chip design. I see it something like design for FPGA, when you design or buying some verilog IP and combine it, like you can do using FPGA, but with converting verilog to the mask layout instead of generate gateware for programmable gates. Is that correct?

On FPGA you can generate several different clock sources and clock two circuits from different clocks. When you needs to communicate between these circuits you can implement clock domain crossing synchronizer. So there is no issue to run more complicated logic at lower clock and some simple logic at higher clock together on the same FPGA. Is that approach possible for a usual chip mask layout design?

For example STM32 use different clock for core and peripherals. I worked with FPGA and don't see something strange here. But if this is impossible for a usual chip with mask layout design then how they doing it on STM32?

Me neither, so I try to make this simple, and more knowledgeable forum members are going to extend on it or correct me.
You select a process node for your design, for example 40nm LP = Low power. That will have a library of components, like output transistors, gates and whatnot, that you can use for your digital design. This constrains you to the type of transistors that you can use, and everything must come from the library. Now, RP foundation doesn't design everything themselves. They are going to buy Cortex M33 from ARM, maybe do the PIO themselves, and use a lot of other standard building blocks.
If you change the process node, your basic transistor will be different in size, shape, leakage, power... Once you need just one transistor to run at 480MHz instead of 150 MHz, that means your entire design changes. Because all the parts need to come from that library. And you need to talk to every IP supplier to get them to supply their IP with that process node. It's not a drop-in replacement. Imagine, that you have a PCB design with SOT563 BC817 transistors, and suddenly you need to use SOT23 transistors. Your entire PCB design changes. Plus, I bet you that USB HS is a large chunk of silicon compared to a CM33, and you need to design everything around that.
In an FPGA everything is designed to run at high speed (oversimplification) and you make it slower.

langwadt · « **Reply #122 on:** August 12, 2024, 11:51:40 am »

Quote from: radiolistener on August 12, 2024, 10:35:22 am

Quote from: iMo on August 12, 2024, 10:09:03 am
Again, you may use that 64bits for processing of something coming from outside's world

The question is what is the reason to use single cycle accelerators if you cannot get any performance improvement? Just because the speed at which the data coming from outside world to MCU through USB FS is so slow that MCU will waste 800 times more time for waiting one data sample from USB, than to process this one data sample with single cycle accelerator...

You can do the same processing without accelerators and it still will be faster than waiting data from USB FS. Because the main bottleneck here is not processing, but USB speed...

that clearly and obviously depend on what processing you are doing ....

dave j · « **Reply #123 on:** August 12, 2024, 12:19:37 pm »

Quote from: PCB.Wiz on August 12, 2024, 02:10:12 am

That's a plus, but you cannot poll a IRQ, you can only stall as you wait.

You can with the RP235x. The configuration of the MOV x, STATUS instruction has been extended to include checking the state of IRQs. (See the documentation for the SMx_EXECCTRL registers, table 993, in the datasheet.)

radiolistener · « **Reply #124 on:** August 12, 2024, 02:12:40 pm »

Quote from: rteodor on August 12, 2024, 10:24:11 am

On a brief search I found that "RP2350 is manufactured on a modern 40nm process node". I think that's on the edge of what USB HS needs: multi GHz PLL and fast line transistors. IMHO power consumption would be the issue in this case (and with that problematic converter everyone is talking about ...).

On a brief search I found that CY7C68013A is manufactured on C8 Technology process, there is no details, but I found that L8C-3R technology (which is Derivative of the C8 Technology) uses CMOS, 0.13 μm process and it's transistors supports USB HS with no issue and it don't have power consumption issue, why?

I thought that more smaller process should allow to run at higher frequency and has less power consumption.
Why 130nm process allows to run at 480 MHz and 40nm don't allow?

westfw · « **Reply #125 on:** August 12, 2024, 02:45:47 pm »

Quote

but I read in their advertisement that it has single cycle 32-bit MAC and two cycle float64 operations.

I don’t think it has two-cycle float operations. It has a “double precision accelerator” coprocessor, and while it’s instructions might take two cycles, I think there is quite a gap between its instructions, and what most of us consider an actual dp operation.

And the point is to be able to do more complex operations on the data streams it CAN handle. For example, there were several people trying to optimize a 32x32->64 integer multiply for mp3 decode on CM0 chips. I’ll bet that they are pretty happy right now!

“I’m just disappointed that it doesn’t have an 8k gpu, cryptocoin mining accelerators, or AI!” :-)

coppice · « **Reply #126 on:** August 12, 2024, 03:01:01 pm »

Quote from: radiolistener on August 12, 2024, 02:12:40 pm

I thought that more smaller process should allow to run at higher frequency and has less power consumption.
Why 130nm process allows to run at 480 MHz and 40nm don't allow?

A 130nm speed optimised process has no problem running at 480MHz, especially for fairly simple comms logic. We had 1GHz x86 processors in 180nm, and well above 1GHz in 130nm. It all about the speed power trade off. If you use a low power variant of a particular node it can really hit your maximum clock rate. MCUs usually use low power processes, because so much of the MCU market, while not exactly ULP, wants modest power consumption, and low standby leakage.

SpacedCowboy · « **Reply #127 on:** August 12, 2024, 03:07:41 pm »

Quote from: radiolistener on August 12, 2024, 09:00:30 am

With no high speed communication interface all that speed is almost useless...

For *your* application. Which is a hint that maybe it's not targeted at the things you want it to do.

And if you want to shoe-horn the chip into your problem, I still don't see any issue with adding on the FT232H in FT1248 mode. It'll give you an actual throughput peak of 240Mbit/sec and it's basically an OctoSPI interface with buffers to help speed up the data transfer, which ought to be really easy to do, even if you *don't* use the PIO.

rteodor · « **Reply #128 on:** August 12, 2024, 04:11:27 pm »

Quote from: radiolistener on August 12, 2024, 02:12:40 pm

Quote from: rteodor on August 12, 2024, 10:24:11 am
On a brief search I found that "RP2350 is manufactured on a modern 40nm process node". I think that's on the edge of what USB HS needs: multi GHz PLL and fast line transistors. IMHO power consumption would be the issue in this case (and with that problematic converter everyone is talking about ...).

On a brief search I found that CY7C68013A is manufactured on C8 Technology process, there is no details, but I found that L8C-3R technology (which is Derivative of the C8 Technology) uses CMOS, 0.13 μm process and it's transistors supports USB HS with no issue and it don't have power consumption issue, why?

I thought that more smaller process should allow to run at higher frequency and has less power consumption.
Why 130nm process allows to run at 480 MHz and 40nm don't allow?

I did not say 40nm does not allow USB HS. Implementations of USB HS exists for more than 20 years. It is just that inclusion of USB in general in MCU's was slow. And for HS even more slow. I was guessing this was due to power consumption but there might be more reasons like licensing from USB-IF and low customer demand.

A few examples:
About 15 years ago I used an ancient NXP ISP1581 transceiver to do about 14MB/s transfer. This one had high power consumption (about 0.5W from what I can remember). I did not find on what node it was, I'm guessing either 180 or 130nm as the datasheet is from 2002.
STM32F4xx is on 90nm but needs external ULPI for USB HS.
Arduino Due has SAM3X8E with USB HS. I'm guessing 90nm also.

Yes, its frustrating to have that fast PIO and be limited by USB FS. Pico is probably alone in this situation where its PIO would benefit from a HS interface in some applications. But its only in some applications.

LE: and speaking of Arduino Due, here is the Dynamic Power Consumption for USB HS Port:

Values would be undoubtedly better for 40nm Pico but still significant.

josip · « **Reply #129 on:** August 12, 2024, 04:29:55 pm »

IMXRT is build on 40nm, and it has HS USB. Entry level MIMXRT1011DAE5A (80 LQFP) with high speed GPIO (M7 domain) at mouser is 3.5€ (quantity 10). There are FlexIO, less powerful than PIO, and "only" one core (M7@500MHz). My second choice after new pico.

SpacedCowboy · « **Reply #130 on:** August 12, 2024, 05:21:09 pm »

Quote from: josip on August 12, 2024, 04:29:55 pm

IMXRT is build on 40nm, and it has HS USB. Entry level MIMXRT1011DAE5A (80 LQFP) with high speed GPIO (M7 domain) at mouser is 3.5€ (quantity 10). There are FlexIO, less powerful than PIO, and "only" one core (M7@500MHz). My second choice after new pico.

I've used the larger i.MXRT chips a couple of times. I think the learning curve for the development environment is a lot steeper than the pico - basically Eclipse + a load of custom wrinkles vs VSCode's simpler "build, run, debug". I also found the UI to be awfully, terribly, glaciers-are-created-and-destroyed *slow* when you have a lot of pins configured on that screen... Maybe it's not so terrible with the smaller parts.

Also, the description of how FlexIO works hurts my brain. I find it much easier to grok the assembly of a PIO than I do to understand the shifters and bit-manipulation of FlexIO. I'm sure it is very powerful, but it doesn't ingratiate itself for *me*. Others mileage may vary...

I didn't know the smaller ones were that cheap though, so maybe I ought to keep an open mind

PCB.Wiz · « **Reply #131 on:** August 12, 2024, 07:54:54 pm »

Quote from: dave j on August 12, 2024, 12:19:37 pm

Quote from: PCB.Wiz on August 12, 2024, 02:10:12 am
That's a plus, but you cannot poll a IRQ, you can only stall as you wait.

You can with the RP235x. The configuration of the MOV x, STATUS instruction has been extended to include checking the state of IRQs. (See the documentation for the SMx_EXECCTRL registers, table 993, in the datasheet.)

Thanks for that detail.
I should have said you cannot poll IRQ as quickly or efficiently as you can poll a pin, using JMP.

It's shame those SMx_ series registers failed to allow for flip of PIN polarity, (none I can see?) as that would avoid the need to use TWO GPIO pins for alternating PIO sampling.

phil from seattle · « **Reply #132 on:** August 12, 2024, 08:51:35 pm »

Quote from: MK14 on August 12, 2024, 09:00:53 am

With the original release of the PICO (RP2040), there was a bug(s) in the original initial revision (IIRC A1), which meant that floating point operations (singles worked but not double, IIRC), via its inbuilt software library (like) feature.

But, a few months later (I can't remember exactly how long it was, it might have been only a few weeks, or it could have been a lot longer), they released (IIRC) the A2 version, which was working just fine.

I'm not happy with what I'm hearing about the built in SMPS, which sounds like it might be problematic and/or very tricky to design that feature of the device.

If that is the case, I'm hoping they fix it, or at least improve the situation.

It is not clear if the current crop of development boards, that are for sale. Will work alright, as regards possible voltage regulator (SMPS) issues, or not.

I'm probably being overly cautious here (maybe way so). But since I don't have any PICO 2's yet. I'd prefer to wait, until they fix any issues, as necessary.

The RP2350B appears to be at an A2 stepping level (from the photos I've seen). I will be getting a couple Pimoroni RP2350B carrier boards on Weds so will know for sure by then. At 9 GBP each with about 10 GBP DHL shipping, it was a no brainer to buy.

exe · « **Reply #133 on:** August 12, 2024, 09:04:58 pm »

I think I like it so far. I'll be waiting for the version with integrated flash.

westfw · « **Reply #134 on:** August 12, 2024, 10:00:30 pm »

Hmm. The Integrated flash will preclude using a larger external flash, right?

tszaboo · « **Reply #135 on:** August 12, 2024, 10:25:09 pm »

Quote from: westfw on August 12, 2024, 10:00:30 pm

Hmm. The Integrated flash will preclude using a larger external flash, right?

Not necessarily, Someone mentioned multiple CS pins for flash and PSRAM.

SpacedCowboy · « **Reply #136 on:** August 12, 2024, 11:14:19 pm »

Quote from: westfw on August 12, 2024, 10:00:30 pm

Hmm. The Integrated flash will preclude using a larger external flash, right?

You can have up to two QSPI devices, in any external / "internal" combination, of any type (RAM, Flash), each can be 16MB in size

I say "internal" because the one that comes with 2MB of flash is just a package-on-package that bonds to the 6 QSPI pins. You can configure one of the GPIOs as the /CS for the second QSPI, if you have it.

MK14 · « **Reply #137 on:** August 12, 2024, 11:25:46 pm »

Quote from: phil from seattle on August 12, 2024, 08:51:35 pm

The RP2350B appears to be at an A2 stepping level (from the photos I've seen). I will be getting a couple Pimoroni RP2350B carrier boards on Weds so will know for sure by then. At 9 GBP each with about 10 GBP DHL shipping, it was a no brainer to buy.

For the possible SMPS issues, I'd be much more worried, with the bare MCU chips, which are not for sale yet. Because getting the PCB design right, ideally first time, would be rather tricky, given the possible hiccups, with the SMPS (inductor) component orientation, and maybe other things, like the layout, and specific capacitors, used.

Then, testing the SMPS, under differing conditions, would also be worrying and more important, than if it was not under suspicion of being difficult to deal with.

But, the complete development boards. Given they may well have got direct advice from the Raspberry PI foundation, be using the correct part number(s), which don't seem to have been publicly released yet, as regards the specific/'special' inductor, with orientation dot.

Also the testing when those development boards were developed, should improve things.

So, there is a good chance, those early development boards, should be fine.

It is going to take time, for the various websites with PICO RP2040 hardware and software information, to get updates with the PICO 2 stuff.
Also, time for updated IDE's (depending on what flavor of IDE you like, such as Arduino Studio).

So, (for me), waiting, probably improves the situation, anyway.

brucehoult · « **Reply #138 on:** August 13, 2024, 12:10:33 am »

Quote from: coppice on August 12, 2024, 03:01:01 pm

Quote from: radiolistener on August 12, 2024, 02:12:40 pm
I thought that more smaller process should allow to run at higher frequency and has less power consumption.
Why 130nm process allows to run at 480 MHz and 40nm don't allow?
A 130nm speed optimised process has no problem running at 480MHz, especially for fairly simple comms logic. We had 1GHz x86 processors in 180nm, and well above 1GHz in 130nm. It all about the speed power trade off. If you use a low power variant of a particular node it can really hit your maximum clock rate. MCUs usually use low power processes, because so much of the MCU market, while not exactly ULP, wants modest power consumption, and low standby leakage.

... and the RP2040 was already widely criticised for not having what people considered to be a sufficiently low power sleep mode.

MT · « **Reply #139 on:** August 13, 2024, 12:21:47 am »

Quote from: tszaboo on August 12, 2024, 09:42:18 am

Quote from: radiolistener on August 12, 2024, 09:29:59 am
Quote from: tszaboo on August 12, 2024, 09:16:32 am
You ether run it at 12 Mbit, or 480 Mbit, there is no in between. The clocking speed is going to be the same, but half the time it's not going to send data.

You can run USB module from 480 MHz or whatever you want frequency. USB module can have its own small buffer to perform operations at max speed with no needs to wait for the main core intervention. Its not a big deal to implement clock domain crossing synchronizer, so the core can continue to work at slower clock.
You are not listening, do you?
The transistors in the node don't switch at that speed. You need a different process node to have transistors that are designed to work at that speed. And with that, your entire digital design is different.

Speaking of process nodes, the STM32F334 (72Mhz main clock) HRTIM are feed from a clock multiplier by cascading delay cells (DLL, Delay Locked Loop), i think it was and some pulse shaping
stuff to get the 4,6Ghz clock feeding the HRTIM, how is this done if the wafer are made on the same process node? 90nm would do up to 3,2Ghz, consuming lots of power of course.

tszaboo · « **Reply #140 on:** August 13, 2024, 10:01:12 am »

Quote from: MT on August 13, 2024, 12:21:47 am

Quote from: tszaboo on August 12, 2024, 09:42:18 am
Quote from: radiolistener on August 12, 2024, 09:29:59 am
Quote from: tszaboo on August 12, 2024, 09:16:32 am
You ether run it at 12 Mbit, or 480 Mbit, there is no in between. The clocking speed is going to be the same, but half the time it's not going to send data.

You can run USB module from 480 MHz or whatever you want frequency. USB module can have its own small buffer to perform operations at max speed with no needs to wait for the main core intervention. Its not a big deal to implement clock domain crossing synchronizer, so the core can continue to work at slower clock.
You are not listening, do you?
The transistors in the node don't switch at that speed. You need a different process node to have transistors that are designed to work at that speed. And with that, your entire digital design is different.
Speaking of process nodes, the STM32F334 (72Mhz main clock) HRTIM are feed from a clock multiplier by cascading delay cells (DLL, Delay Locked Loop), i think it was and some pulse shaping
stuff to get the 4,6Ghz clock feeding the HRTIM, how is this done if the wafer are made on the same process node? 90nm would do up to 3,2Ghz, consuming lots of power of course.

I don't think anything is actually running at that frequency in that block. You can enable a delay on the signal, giving you the appearance of higher frequency timer. Here they talk about "equivalent frequency:
https://www.researchgate.net/figure/HRTIM-time-resolutions-and-frequency-limits-versus_tbl1_362293274

coppice · « **Reply #141 on:** August 13, 2024, 12:13:00 pm »

Quote from: tszaboo on August 13, 2024, 10:01:12 am

Quote from: MT on August 13, 2024, 12:21:47 am
Speaking of process nodes, the STM32F334 (72Mhz main clock) HRTIM are feed from a clock multiplier by cascading delay cells (DLL, Delay Locked Loop), i think it was and some pulse shaping
stuff to get the 4,6Ghz clock feeding the HRTIM, how is this done if the wafer are made on the same process node? 90nm would do up to 3,2Ghz, consuming lots of power of course.
I don't think anything is actually running at that frequency in that block. You can enable a delay on the signal, giving you the appearance of higher frequency timer. Here they talk about "equivalent frequency:
https://www.researchgate.net/figure/HRTIM-time-resolutions-and-frequency-limits-versus_tbl1_362293274

One of the reasons people are moving to those self-calibrating delay lines for fine PWM is to avoid having fast high consumption clocking. The die area for all those delay stages is small these days, so its no big deal to throw gates at the problem. The trick is to be able to calibrate them.

exe · « **Reply #142 on:** August 13, 2024, 07:10:35 pm »

BTW, about smps issues... I'm no expert, is the only problem orientation? Anyway, I hope there will be suitable inductors from multiple sources.

Here is another thing. If you guys look closely on these PCBs with rp2350 here, you'll see they use different inductors and different layouts: https://www.raspberrypi.com/for-industry/powered-by/product-catalogue/?category=RP2350 . I'm not sure what that means.

PS I really hoped that the new mcu would require less external components. I didn't like that rp2040 requires external flash. Now instead of external flash we have external inductor

SpacedCowboy · « **Reply #143 on:** August 13, 2024, 08:46:14 pm »

It does get a little tight with them bunching all the non-GPIO things together. It might have been easier if they were more spread out. I'm laying out using their recommended crystal, capacitor sizes, and the same-size inductor (until the real part comes along) and it gets a bit squashed-in by the SMPS parts, next to the USB, next to the flash (and I want to put some QSPI PSRAM in there on a different build, so I'll need to use it), all in amongst the decoupling caps.

i509VCB · « **Reply #144 on:** August 13, 2024, 08:53:08 pm »

Quote from: phil from seattle on August 11, 2024, 08:02:51 pm

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.

Looking at the KiCad project files provided on the raspberry pi website, it seems like the inductor uses the AOTA-B201610SR47MT 3D model. Although in the schematic a 3.3 uH is used.

uer166 · « **Reply #145 on:** August 14, 2024, 12:50:13 am »

Inductor orientation occasionally matters for EMC: there is a self-shielding effect that exists if the switch node is connected to the inside windings in a multi-later windup. This would imply they had major issues with E-field coupling to internals. It would be pretty crazy if there was a functional issue, though I hope it's more of a ADC ENOB thing or something more benign.

radiolistener · « **Reply #146 on:** August 14, 2024, 04:14:53 am »

Quote from: uer166 on August 14, 2024, 12:50:13 am

This would imply they had major issues with E-field coupling to internals.

Since it is caused with inductor, it looks more like H-filed coupling issue.
Which is even worse, because its hard to shield H-fied coupling in near field region.

I think this is a big mistake to share MCU die with switching converter. By embedding it inside MCU they got a lot of issues and now needs to spend a lot of time to fight with power supply issues instead of fix and improve MCU itself.

They needed to add USB HS instead of switching converter.

shabaz · « **Reply #147 on:** August 14, 2024, 05:20:43 am »

Quote from: radiolistener on August 14, 2024, 04:14:53 am

.. they got a lot of issues..

I may have missed it (I scanned the thread but it's 6 pages). Is your comment speculation, or an opinion based solely on that text in the guide, or based on something else?

The reason I ask, is that the Pimoroni Pico 2 Plus board doesn't seem to have the same inductor, nor the same orientation, and "operates" (in that it successfully powers up - I have not measured anything nor tried to run a heavy processing load to try to exercise that core voltage regulator).

MK14 · « **Reply #148 on:** August 14, 2024, 06:54:08 am »

Quote from: shabaz on August 14, 2024, 05:20:43 am

Quote from: radiolistener on August 14, 2024, 04:14:53 am
.. they got a lot of issues..

I may have missed it (I scanned the thread but it's 6 pages). Is your comment speculation, or an opinion based solely on that text in the guide, or based on something else?

The reason I ask, is that the Pimoroni Pico 2 Plus board doesn't seem to have the same inductor, nor the same orientation, and "operates" (in that it successfully powers up - I have not measured anything nor tried to run a heavy processing load to try to exercise that core voltage regulator).

I get the impression (since the claimed 600 mA, sounds too much, for the on-chip version), it has its own (external) regulator (I'm not sure if it's linear or switching), or if it takes over 100%, or shares its duties with the on-chip version.

The 'Pimoroni Pico Plus 2' still says on its product page:

Quote

Download a printable PDF version
Schematic (coming soon)

So, I don't seem to easily be able to find out more, at the moment, as to exactly what they have done.

But, Pimoroni, seem to have a good reputation (I've bought stuff from them in the past, and been pleased with the results, but it was not stuff they designed, themselves).

In fact, they seem to be one of the main, or even the biggest, supplier and maker of Raspberry PI, (add-on) hardware, across their range.

Many of the other PI suppliers, actually sell Pimoroni branded hardware.

There is a very good chance, your board is fine.

It is just so early in the release cycle, it is hard to get definitive information, yet.

iMo · « **Reply #149 on:** August 14, 2024, 07:27:55 am »

Quote from: radiolistener on August 14, 2024, 04:14:53 am

Quote from: uer166 on August 14, 2024, 12:50:13 am
This would imply they had major issues with E-field coupling to internals.
..
I think this is a big mistake to share MCU die with switching converter..

On pico2 original they use the "RT6150 buck-boost SMPS, which generates a fixed 3.3V output
for the RP2350 device and its IO" (see the schematics in the DS).
It allows the powering the pico2 from 1.8-5.5V..

By cutting off the RT6150 chip with the inductor etc. and replacing it with an LDO linear regulator you solve the problem, imho (like all other boards do, afaik)..

Is there somewhere an another switcher on the chip?

PS: Yep there is one for the 1.1V DVDD..
But you may replace it with a linear LDO one as well, my bet..

ftg · « **Reply #150 on:** August 14, 2024, 07:40:53 am »

Quote from: radiolistener on August 14, 2024, 04:14:53 am

Quote from: uer166 on August 14, 2024, 12:50:13 am
This would imply they had major issues with E-field coupling to internals.

Since it is caused with inductor, it looks more like H-filed coupling issue.
Which is even worse, because its hard to shield H-fied coupling in near field region.

I think this is a big mistake to share MCU die with switching converter. By embedding it inside MCU they got a lot of issues and now needs to spend a lot of time to fight with power supply issues instead of fix and improve MCU itself.

They needed to add USB HS instead of switching converter.

Silicon Laboratories was able to pull off a rather decent DC-DC converter on the same die with an ARM MCU and dualband sub-1GHz and 2.4GHz radios in their EFR32 series.

radiolistener · « **Reply #151 on:** August 14, 2024, 07:46:04 am »

Quote from: shabaz on August 14, 2024, 05:20:43 am

I may have missed it (I scanned the thread but it's 6 pages). Is your comment speculation, or an opinion based solely on that text in the guide, or based on something else?

Regarding switching converter serious.

Regarding USB HS... partly joke, partly tease, but partly serious...
I know most likely they wouldn't have added it anyway, but I'd like to see it, because it's not usable for my tasks without fast communication interface...

Quote from: ftg on August 14, 2024, 07:40:53 am

Silicon Laboratories was able to pull off a rather decent DC-DC converter on the same die with an ARM MCU and dualband sub-1GHz and 2.4GHz radios in their EFR32 series.

Yes, some chips have it together with analog parts sensitive to interference, but it adds more issues than good value. I think it's better to spend money and time which was used for its design to improve ADC, PLL and other MCU things.

iMo · « **Reply #152 on:** August 14, 2024, 07:54:25 am »

Quote from: iMo on August 14, 2024, 07:27:55 am

..Is there somewhere an another switcher on the chip?
PS: Yep there is one for the 1.1V DVDD..
But you may replace it with a linear LDO one as well, my bet..

From DS:

Quote

The regulator can be directly controlled by software, but must first be unlocked by writing a 1 to the UNLOCK field in the
VREG_CTRL register. Once unlocked, the regulator can be controlled via the VREG register.
The regulator’s operating mode defaults to Normal, at initial power up or after a reset event, but can be switched to High
Impedance by writing a 1 to the VREG register’s HIZ field. The regulator’s output voltage can be set by writing to the
register’s VSEL field, see the VREG register description for details on available settings. To prevent accidental overvoltage,
the output voltage is limited to 1.3 V unless the DISABLE_VOLTAGE_LIMIT field in the VREG_CTRL is set. The output
voltage defaults to 1.1 V at initial power-on or after a reset event.

Thus the simplest way (A) could be to wire a linear 1.1V LDO (1.2V would work fine imho) via a small resistor (like 4R7 or smaller, for example, it will work as protection when both regulators work and after switching off the internal switcher it will work as the RC filter/decoupling..) to the DVDD and after the reset simply do switch off the internal switcher by setting it into the HiZ state..
And (B) you may remove the 3u3 coil from your pcb (when the 3u3 coil has been removed you may remove/short the 4R7 as well)..

SiliconWizard · « **Reply #153 on:** August 14, 2024, 08:00:02 am »

Quote from: ftg on August 14, 2024, 07:40:53 am

Quote from: radiolistener on August 14, 2024, 04:14:53 am
Quote from: uer166 on August 14, 2024, 12:50:13 am
This would imply they had major issues with E-field coupling to internals.

Since it is caused with inductor, it looks more like H-filed coupling issue.
Which is even worse, because its hard to shield H-fied coupling in near field region.

I think this is a big mistake to share MCU die with switching converter. By embedding it inside MCU they got a lot of issues and now needs to spend a lot of time to fight with power supply issues instead of fix and improve MCU itself.

They needed to add USB HS instead of switching converter.

Silicon Laboratories was able to pull off a rather decent DC-DC converter on the same die with an ARM MCU and dualband sub-1GHz and 2.4GHz radios in their EFR32 series.

Many do, that's certainly doable. The benefit is more integration, but also giving the ability for instance to shut down the buck converter internally in some low-power modes. IIRC, some STM32 MCUs do also have an integrated buck converter, and some others don't but do support external buck converters (and have a pin that can act as an enable for it).

I think what a few said is probably right, they probably don't have a ton of experience relative to analog microelectronics at the RPi and will occasionally get bitten by this kind of issues more so than other vendors.

josip · « **Reply #154 on:** August 14, 2024, 11:40:20 am »

Is there any video, pdf, web page, whatever, with details about dual-issue common 16-bit instruction pairs on M33?

brucehoult · « **Reply #155 on:** August 14, 2024, 11:48:47 am »

Quote from: josip on August 14, 2024, 11:40:20 am

Is there any video, pdf, web page, whatever, with details about dual-issue common 16-bit instruction pairs on M33?

M33 is dual issue???

Hard to believe given it's only 7% faster on Coremark than the Hazard3 RISC-V core which was developed part-time by one of Raspberry Pi's own engineers.

Dual-issue M7 is 5.29 Coremark/MHz. M33 is quoted at 4.09, and the Hazard3 at 3.81.

I'll be running my primes benchmark on both cores as soon as I can get my hands on a board. Or if someone already has one, I'd welcome a submission.

MK14 · « **Reply #156 on:** August 14, 2024, 11:56:25 am »

Quote from: brucehoult on August 14, 2024, 11:48:47 am

Quote from: josip on August 14, 2024, 11:40:20 am
Is there any video, pdf, web page, whatever, with details about dual-issue common 16-bit instruction pairs on M33?

M33 is dual issue???

Quote

Limited dual-issue of common 16-bit instruction pairs

Source:
Google search results, but it gave this as a source reference:
(Arm website, then it has a download of) Arm-Cortex-M33-Processor-Datasheet-1.pdf

Hence not that much of a speed up, seen on the benchmark.

But, could (in theory), allow better performance, in carefully hand-crafted code (assembly or C where you mess around with the source, until its outputted assembly, meets your desires and expectations).

jnk0le · « **Reply #157 on:** August 14, 2024, 07:26:03 pm »

Quote from: brucehoult on August 14, 2024, 11:48:47 am

Quote from: josip on August 14, 2024, 11:40:20 am
Is there any video, pdf, web page, whatever, with details about dual-issue common 16-bit instruction pairs on M33?

M33 is dual issue???

Hard to believe given it's only 7% faster on Coremark than the Hazard3 RISC-V core which was developed part-time by one of Raspberry Pi's own engineers.

Dual-issue M7 is 5.29 Coremark/MHz. M33 is quoted at 4.09, and the Hazard3 at 3.81.

I think it's the same "limited dual issue" as on CM55 which has the official optimization guide here:
https://developer.arm.com/documentation/102692/0101

M33 -> M55 coremark difference is most likely HW loops or the 0 cycle branch (which is a reuse of LOB buffer from HW loops)

MK14 · « **Reply #158 on:** August 14, 2024, 08:19:37 pm »

I've found/read/heard some rumors (also subject to me understanding it correctly), that seem to be correct, and make this new RP2350/PICO2, even more interesting and amazing.

Apparently, the additional RISC-V cores, don't add a significant amount to the transistor count. Because, its design/layout was simply fed into the 'designer software' tool, which just combined/optimized, the whole lot, together.
Since, bigger blocks like the Multiply 32 x 32 ==> 64 bits, and fast divider and stuff, could be shared between the core types, as the tool was smart enough to realize/handle the fact, that you could only select one CPU type or the other.

Which would mean, that attempts to glitch/hack/force the chip into some kind of 4 core mode, would fundamentally NOT succeed, as they share so much logic.

Also, the boot ROM, was not big enough to store the code for both CPU types. So, it only (or mainly) has Arm code in it. But, a special emulator (**VARMULET) is run on the RISC-V core, during booting, which emulates Arm instructions, so that it can share enough of the code, to fit it all in (128 KiB or kB, IIRC).

** = https://github.com/raspberrypi/armulet

Also, the built in OTP, has flag bits, which allows one to permanently disable, core types, if you want. E.g. Eliminate (disable) the RISC-V cores, permanently.
I'm not sure, exactly why. Perhaps for security/reliability reasons, or maybe to allow them to be sold as different chip variants, for certain markets (possibly changing the Arm license fees, as well).

Additional rumors, are that there were/are fears, over very significant Arm license fee cost increases (for reasons). So, the RISC-V's could either be replacements or bargaining chips, to get the best licensing fees.

EDIT: Added name and link to emulator

Postal2 · « **Reply #159 on:** August 14, 2024, 08:46:41 pm »

Quote from: MK14 on August 14, 2024, 08:19:37 pm

...... Also, the built in OTP, has flag bits, which allows one to permanently disable, ......

I liked it. It's like adding a "turn off forever" button on the TV remote control next to the "turn off" button.

jnk0le · « **Reply #160 on:** August 14, 2024, 10:10:30 pm »

Quote from: jnk0le on August 14, 2024, 07:26:03 pm

M33 -> M55 coremark difference is most likely HW loops or the 0 cycle branch (which is a reuse of LOB buffer from HW loops)

or double wide scalar load/store (reuse of mve datapath)

shabaz · « **Reply #161 on:** August 15, 2024, 04:57:23 am »

Quote from: MK14 on August 14, 2024, 06:54:08 am

The 'Pimoroni Pico Plus 2' still says on its product page:
Quote
Download a printable PDF version
Schematic (coming soon)

Added some better photos in case anyone is interested to decipher the parts used. One is the PSRAM chip of course, but the other zoomed image shows a 6-pin 2mm x 2mm DFN style part labeled YE 1 IA
It seems to be the only IC that may be the DC-DC converter.

I just spent most of the day installing the new 2.0.0 SDK and ARM toolchain etc., on Windows. Not a fun exercise, eventually got it functioning.

SpacedCowboy · « **Reply #162 on:** August 15, 2024, 05:40:19 am »

Interesting comment from the raspberry pi pico forums:

Quote

It has proved trivial to get MMBasic running on the RP2350 so many congrats to the developers for creating such a seamless environment.

Perfornance running MMbasic is >150% in general AND the chip overclocks just as well as the RP2040 (running at 378MHz with no issues)
At this overclocked rate performance is 50% of a STM32H743 which given the price comparison is amazing

See https://www.thebackshed.com for more details

macaba · « **Reply #163 on:** August 15, 2024, 08:06:41 am »

Quote from: shabaz on August 15, 2024, 04:57:23 am

I just spent most of the day installing the new 2.0.0 SDK and ARM toolchain etc., on Windows.

Hopefully will help the next person:
In VS Code, there is a “Raspberry Pi Pico” extension that takes seconds to install. The toolchain downloads after completing the “New Project” process (an option that appears on the new Raspberry Pi area that appears) and takes a minute (depending on internet speed).

The source of the extension is on GitHub so nothing secret/closed.

jnk0le · « **Reply #164 on:** August 15, 2024, 11:02:17 am »

more info on the inductor thing from jdb:

Quote

The design guide gives somewhat undue attention to the inductor and the effects of the fringing magnetic field on the nearby components. A Pico 2 will work fine if you unsolder the inductor, throw it up in the air, then solder it back down in the orientation it landed in.

The main effects are on static regulation, where there's an unexplained offset voltage of the order of 30mV at a chip-dependent VDD current draw, and an unexplained slight efficiency degradation at this inflection point.

Hence the comment that we're still working with the IP vendor to find out why this is the case.

exe · « **Reply #165 on:** August 15, 2024, 11:42:36 am »

Ha-ha, love the humor. Finally we've got details!

I'm surprised that the difference is that big (30mV), and that it is present under static (steady power consumption?) condition. I don't know much about SMPS, so, guys, tell me, is this normal? Actually, it probably is, as I quickly googled and found this article: https://www.analog.com/en/resources/analog-dialogue/articles/does-the-assembly-orientation-of-an-smps-inductor-affect-emissions.html .

I wonder, can I determine the best polarity with just a 100MHz scope just by probing at inductor? On the other hand, direct probing can be tricky due to dense layout of the board...

MK14 · « **Reply #166 on:** August 15, 2024, 01:59:45 pm »

Thanks to EVERYONE, as there are many interesting and informative posts, in this thread.

Quote from: jnk0le on August 15, 2024, 11:02:17 am

more info on the inductor thing from jdb:

Quote
The design guide gives somewhat undue attention to the inductor and the effects of the fringing magnetic field on the nearby components. A Pico 2 will work fine if you unsolder the inductor, throw it up in the air, then solder it back down in the orientation it landed in.

The main effects are on static regulation, where there's an unexplained offset voltage of the order of 30mV at a chip-dependent VDD current draw, and an unexplained slight efficiency degradation at this inflection point.

Hence the comment that we're still working with the IP vendor to find out why this is the case.

That's brilliant, and EXACTLY what I (and probably others), wanted to know.

So, even if this 'issue' manifests itself. It doesn't sound too bad at all. Unless the entire/full range of any datasheet information, is super-critical. E.g. Trying to operate it at the bare minimum, or maximum voltages, or very near the minimum or maximum allowed, current ratings, etc.

As I understand it (so I could be mistaken here), in standard designs with the RP2350/PICO2, the ADC gets its reference voltage from that same supply voltage, so could be affected (back of envelope, wild estimate, ball park figure), by 1%, since 30 mV is about 1% of 3.3 V.

So, this issue, is sounding like it is not particularly important, for many applications, many of which, won't even be using the ADC, or won't be bothered by a theoretical 1% of extra error, under some circumstances, maybe?

Anyway, the ADC guide seems to discuss, changing (into fixed PWM mode?) or even disabling, the SMPS, when taking readings, if you want the best accuracy.

Which to me sounds far fetched, as software can be big and complicated. Perhaps using many libraries, and a number of different people, contributing to writing it,

So, to have to change or even switch off the built in SMPS, seems tricky at best to arrange (if there is more than one software developer), and possibly problematic in its own right.

E.g. What if an interrupt or something, causes a (very relatively speaking, for this in general low current device, overall) high current, output device to suddenly turn on, while the SMPS is being messed around with, by the ADC reading software driver section.

In other words, I don't like the sound of changing or disabling the SMPS settings, while reading the ADC, as it sounds unprofessional, and potentially problematic, and possibly difficult to implement, as well.

I.e. It sounds like a hack or bodge, rather than a good feature. On the other hand, it does give a rather low cost device, the capability, to act like a better, and much more expansive one, even if it is a bit fiddly to implement.

Anyway, the entry level chip, only has 4 ADC inputs, which is a very small number, relative to most modern MCUs, meant for that kind of operation.

EDIT: Typo and small changes

EDIT2: I think I was mistaken, and had inadvertently read stuff about the OLD PICO (RP2040), without realizing. So, I've tried to correct (strike out), this post, to avoid spreading FUD.

Please ignore the following for the RP2350/PICO2, only here to show where my mistake came from, probably:
Probable mistaken information, was possibly from here:
https://www.reddit.com/r/raspberrypipico/comments/ptwkxu/noisy_analog_read/

MK14 · « **Reply #167 on:** August 15, 2024, 02:31:28 pm »

Quote from: SpacedCowboy on August 15, 2024, 05:40:19 am

Interesting comment from the raspberry pi pico forums:

Quote

It has proved trivial to get MMBasic running on the RP2350 so many congrats to the developers for creating such a seamless environment.

Perfornance running MMbasic is >150% in general AND the chip overclocks just as well as the RP2040 (running at 378MHz with no issues)
At this overclocked rate performance is 50% of a STM32H743 which given the price comparison is amazing

See https://www.thebackshed.com for more details

That is rather amazing in its own right. The STM32H743 is quite a power house (and rather expensive), with its slightly greater than (claimed) 1,000 DMIPs of (M7 core) performance, claimed on the ST website.

Although, the overclocking is a bit naughty, and probably wouldn't suit production runs, anything even if vaguely critical/important, or (unsuspecting) customer releases.

But for fun hobby projects, and non-professional experiments, it sounds like fun.

It is not just the cost of M7 cores, that can be the issue, either. Those modern, all singing and dancing, powerhouses, can be difficult, for a lone developer or hobbyist, to get around the vast and complicated, peripheral sets, they usually have.

Also, dependent, on if you want to program it yourself, in assembly(not necessarily applicable for the M7)/C/similar-languages, without much help from libraries and things.

In other words, I think something the size and complexity of the RP2350 (PICO 2 etc), can be handled, by a lone developer or hobbyist, without needing to resort to complicated operating systems (rather small simple OSs can be ok) and/or (big complicated) libraries and/or other stuff, to handle all the complexity.

A bit like older times, when 8 bit microprocessors and 8 bit MCUs, were common-place. Where you could read the databook, over a weekend, and start programming it in anger, first thing, Monday. In assembly code, if necessary.

zapta · « **Reply #168 on:** August 15, 2024, 03:26:29 pm »

Possibly they are the same cores, just switching at boot time a different microcode.

MK14 · « **Reply #169 on:** August 15, 2024, 03:35:01 pm »

Quote from: zapta on August 15, 2024, 03:26:29 pm

Possibly they are the same cores, just switching at boot time a different microcode.

I'm not sure if they are microcoded CPUs or hardwired.

Off-hand, I assumed/thought they would be hardwired, especially for the RISC type of CPU (as non-RISC CPUs, especially ones with massively big and complicated instruction sets, can get too complicated to readily hardwire the design), to give the highest speed and lowest power consumption.

But microcoding, does in theory, make the design process quicker, and (as you suggest), allow the same/similar CPU, to handle multiple instruction set formats.

oPossum · « **Reply #170 on:** August 15, 2024, 04:10:20 pm »

This is the RISC-V core: https://github.com/Wren6991/Hazard3

MK14 · « **Reply #171 on:** August 15, 2024, 04:14:39 pm »

Quote from: oPossum on August 15, 2024, 04:10:20 pm

This is the RISC-V core: https://github.com/Wren6991/Hazard3

It was fed into the synthesis tool (or so I was led to believe), as 2005 Verilog, and optimized the entire chip, with it. Adding very few transistors, to the overall transistor budget.

I don't know how accurate my original source is, so if you want to know for sure, best to wait or find a 100% safe source.

EDIT: My (unspecified) source, is NOT hugely trustworthy (such as other forums), but may be true.

EDIT2: Unfortunately, I didn't keep note of the original source(s), and read a number of things, potentially.

But it might have been, and was similar, to the following, which has additional details, as well:
https://news.ycombinator.com/item?id=41214307

ataradov · « **Reply #172 on:** August 15, 2024, 04:52:26 pm »

I don't think there are any tools that could just do that automatically. There would have to be corresponding Verilog code for sharing parts of the design. Tools would optimize the design, but the logic still should match what is written in the code. Otherwise verification of such "optimized" would be a real nightmare.

MK14 · « **Reply #173 on:** August 15, 2024, 05:05:42 pm »

Quote from: ataradov on August 15, 2024, 04:52:26 pm

I don't think there are any tools that could just do that automatically. There would have to be corresponding Verilog code for sharing parts of the design. Tools would optimize the design, but the logic still should match what is written in the code. Otherwise verification of such "optimized" would be a real nightmare.

I can well believe it (what you just said).

It can be hard enough, just to get a simple (small) FPGA to do what you want.

I have noticed, the cycle counts (at a quick glance), of the 32 x 32 ==> 64 bit multiply, and (somewhat) fast integer divider, instructions, seem to be the same, between the Arm M33 and RISC-V cores. Which makes me wonder, if they share the same units.

It is probably a bit too soon, for the proper information to come out. But, in time, I expect there to be (somewhat) official videos or accounts.

Between, e.g. Jeff Girling and Eben Upton, with an hour long chat, perhaps at the Cambridge (UK) Raspberry PI Headquarters (again, IIRC), where such details, may be revealed.

shabaz · « **Reply #174 on:** August 15, 2024, 06:36:23 pm »

Quote from: macaba on August 15, 2024, 08:06:41 am

Quote from: shabaz on August 15, 2024, 04:57:23 am
I just spent most of the day installing the new 2.0.0 SDK and ARM toolchain etc., on Windows.

Hopefully will help the next person:
In VS Code, there is a “Raspberry Pi Pico” extension that takes seconds to install....

Very useful info! I use JetBrains CLion which had a few complications in the setup unfortunately. Pico with CLion info here in case anyone else is using that. But would strongly suggest people try it from command line (Windows or Linux), or VS Code, as you suggest, and once successful, then try CLion if interested. I tend to install on both Windows and Linux, but decided with the new SDK to bite the bullet and try on Windows first since that usually is more problematic.

PCB.Wiz · « **Reply #175 on:** August 15, 2024, 07:40:50 pm »

Quote from: MK14 on August 15, 2024, 01:59:45 pm

As I understand it (so I could be mistaken here), in standard designs with the RP2350/PICO2, the ADC gets its reference voltage from that same supply voltage, so could be affected (back of envelope, wild estimate, ball park figure), by 1%, since 30 mV is about 1% of 3.3 V.

My reading has the inductor used on the 1v1 core Vdd, not the analog supply.

30mV is close to 1% of 1v1, so it would raise a flag in the lab.
They are vague on exactly where that 1% bump occurs, we have just 'at a chip-dependent VDD current draw, and an unexplained slight efficiency degradation at this inflection point'

How many vendors offer 3.3uH inductors, shielded, in that package size ?

iMo · « **Reply #176 on:** August 15, 2024, 08:14:13 pm »

In order to characterize the ADC you have to get rid of both switchers there (the 3.3V and the 1.1V).
Do replace them simply with linear regulators.
Would be great if somebody comes with a new pcb without any switchers, of course..
The ripples produced by the LC based switchers are pretty hard to filter, as they are rather high energetic pulses.
The setup as it is today is good for less demanding educational purposes, for applications with sensitive analog circuitry or with timing sensitive apps it is simply a nogo.

MK14 · « **Reply #177 on:** August 15, 2024, 08:26:28 pm »

Quote from: PCB.Wiz on August 15, 2024, 07:40:50 pm

Quote from: MK14 on August 15, 2024, 01:59:45 pm
As I understand it (so I could be mistaken here), in standard designs with the RP2350/PICO2, the ADC gets its reference voltage from that same supply voltage, so could be affected (back of envelope, wild estimate, ball park figure), by 1%, since 30 mV is about 1% of 3.3 V.
My reading has the inductor used on the 1v1 core Vdd, not the analog supply.

30mV is close to 1% of 1v1, so it would raise a flag in the lab.
They are vague on exactly where that 1% bump occurs, we have just 'at a chip-dependent VDD current draw, and an unexplained slight efficiency degradation at this inflection point'

How many vendors offer 3.3uH inductors, shielded, in that package size ?

I agree with you.

It seems I was mistaken.

Instead of my googling, finding relevant RP2350/PICO2 websites, (missed/unnoticed by me) it had found a much older website, (such as one) about the previous PICO, on an Adafruit board, whose SMPS, needed or could be put into PWM mode, under certain conditions.

NOT RELEVANT HERE.

N.B. Please IGNORE the following link. It is only for people curious as to how I messed up, and was not necessarily the webpage, I used when making previous posts.
https://adafruit-playground.com/u/blakebr/pages/wifi-power-management-for-the-raspberry-pi-pico-w

My mistake!

EDIT:
I've tried to correct the post. here (which seems to have a better link of the wrong information, as well):
https://www.eevblog.com/forum/microcontrollers/possible-click-bait-title-the-raspberry-pi-pico-2-now-has-extra-risc-v-cores/msg5605771/#msg5605771

MK14 · « **Reply #178 on:** August 16, 2024, 07:00:29 pm »

For anyone who is interested, the PICO 2 (original), is now in stock.

Raspberry Pi Pico 2
by Raspberry Pi

For £4 + (for the UK) VAT = £4.80 + Shipping

at Pimoroni (I'm not connected with them, but I do sometimes check their website, fairly often).

Here:
https://shop.pimoroni.com/products/raspberry-pi-pico-2?variant=42096955424851

iMo · « **Reply #179 on:** August 27, 2024, 02:58:06 pm »

westfw · « **Reply #180 on:** August 27, 2024, 08:13:24 pm »

Quote

[compilers matter]

Yeah, RISC-V seems like a bit of a tool-chain nightmare, with all the different "extensions" that are defined (or vendor-defined.)
I assume that a full-featured gcc will have all of them "usable", assuming that you specify all the right options in the command line, which may take some figuring out. (Shades of Motorola 68K, especially after adding CPU32 and CPU32+ and Coldfire, with slightly different instruction sets.)

Then there is the "which floating point library did you get?" question. The C (bloated and slow) libgcc float code (as on vanilla CM0)? An optimized compiler library provided with gcc (as with CM3 (and I assume CM33))? A modified something designed to use the improved floating point in the rp2040 ROM, or the "DP accelerator coprocessor" in the rp2350?
(For instance, the Philhower core for Arduino carefully duplicates the SDK-style (horribly obscure) build that uses the ROM floating point in rp2040. The Arduino core doesn't. They can perform quite differently!) ( https://github.com/arduino/ArduinoCore-mbed/issues/614 )

brucehoult · « **Reply #181 on:** August 27, 2024, 11:30:34 pm »

Quote from: westfw on August 27, 2024, 08:13:24 pm

Quote
[compilers matter]

Yeah, RISC-V seems like a bit of a tool-chain nightmare, with all the different "extensions" that are defined (or vendor-defined.)

I don't see why it's a "nightmare".

Generic code runs correctly everywhere.

If you know what chip you're using (as embedded people always do) then you look up the CPU's exact ISA and add that to your CFLAGS and be happy.

It's no harder than figuring out whether you have a Cortex-M0 or M3 or M4f or M33 or A53 in your Arm board. The RISC-V ISA strings can get a bit longer, but it's just a matter of copying it verbatim from your board/SoC documentation to your build commands.

I would assume Gary could have done that with his Windows VSCode setup rather than going to Linux. (Not that going to Linux is a bad idea)

Quote

I assume that a full-featured gcc will have all of them "usable", assuming that you specify all the right options in the command line, which may take some figuring out. (Shades of Motorola 68K, especially after adding CPU32 and CPU32+ and Coldfire, with slightly different instruction sets.)

Of course. A standard RISC-V gcc install from a package manager such as Debian's "apt" can compile your own code with any set of extensions you want, including custom vendor extensions such as those from THead that have been upstreamed. There are also a number of versions of the libraries compiled with various common combinations of extensions, though of course it is impossible to cover all possibilities, so you might end up with library code using slightly more generic code than your CPU is capable of.

It appears that what made the difference in Gary's case is soft FP routines using the "B" extension, off the top of my head I imagine mostly clz for normalising results. This is a baseline extension going forward for pretty much every CPU core released after late 2021, except the very lowest end ones.

oPossum · « **Reply #182 on:** August 28, 2024, 02:48:41 am »

A look at the silicon inside...

https://electronupdate.blogspot.com/2024/08/pi-pico-2-extreme-teardown.html

langwadt · « **Reply #183 on:** August 28, 2024, 07:44:57 am »

https://www.hackster.io/news/a-surprise-hardware-bug-in-raspberry-pi-s-rp2350-leads-to-unexpected-pull-down-behavior-76b51ec22ede

SiliconWizard · « **Reply #184 on:** August 28, 2024, 07:50:36 am »

Ouch.

iMo · « **Reply #185 on:** August 28, 2024, 09:07:22 am »

That happens when you start to play with off the shelf silicon libraries.. (.. they did the similar with the ADC bug in 2040, imho..)

coppice · « **Reply #186 on:** August 28, 2024, 10:56:34 am »

Quote from: langwadt on August 28, 2024, 07:44:57 am

https://www.hackster.io/news/a-surprise-hardware-bug-in-raspberry-pi-s-rp2350-leads-to-unexpected-pull-down-behavior-76b51ec22ede

An MCU with a bug list, most of which will probably be worked around rather than fixed? I'm shocked, shocked I tell you.

RAPo · « **Reply #187 on:** August 28, 2024, 12:15:21 pm »

But be sure to pick the right combo:

Quote from: ataradov on August 08, 2024, 04:46:14 pm

Yes, using two toolchains at the same time is exactly what I want. I guess they wanted to have a smooth transition to RISC-V, but the device is bizarre.

And one again, only 30 GPIO on a 60-pin device.

macaba · « **Reply #188 on:** August 28, 2024, 12:15:49 pm »

Following that compiler video, I investigated a little by running the same benchmark. You do not need to install the toolchain manually, it is available with a small edit of the CMakeLists.txt when using the VS Code extension.

Code: [Select]

whetstone_rp2350.c [13_2_Rel1] Debug (73,216 bytes) - 50.0 MWIPS (10000 loops)
whetstone_rp2350.c [13_2_Rel1] Release (68,608 bytes) - 333.3 MWIPS (10000 loops)
whetstone_rp2350.c [RISCV_COREV_MAY_24] Debug (131,584 bytes) - 1.9 MWIPS (1000 loops)
whetstone_rp2350.c [RISCV_COREV_MAY_24] Release (129,024 bytes) - 5.9 MWIPS (1000 loops)
whetstone_rp2350.c [RISCV_13_3] Debug (110,592 bytes) - 8.3 MWIPS (1000 loops)
whetstone_rp2350.c [RISCV_13_3] Release (105,472 bytes) - 25.0 MWIPS (1000 loops)

In CMakeLists.txt, use one of these to switch between a recent ARM toolchain and the two RISC-V toolchains, when using the VS Code extension. You'll need to close VS Code, delete the build folder, make the change, and reopen VS Code.

Code: [Select]

set(toolchainVersion RISCV_COREV_MAY_24)
set(toolchainVersion RISCV_13_3)
set(toolchainVersion 13_2_Rel1)

Edit: just in case, here is how you switch from Debug to Release build using the terminal within VS Code:

Code: [Select]

cmake build -DCMAKE_BUILD_TYPE=Release

RAPo · « **Reply #189 on:** August 28, 2024, 12:17:19 pm »

My pico2 will arrive next week, will try out your suggestions.

radiolistener · « **Reply #190 on:** August 28, 2024, 02:49:22 pm »

Quote from: MK14 on August 14, 2024, 08:19:37 pm

Also, the built in OTP, has flag bits, which allows one to permanently disable, core types, if you want. E.g. Eliminate (disable) the RISC-V cores, permanently.
I'm not sure, exactly why. Perhaps for security/reliability reasons, or maybe to allow them to be sold as different chip variants, for certain markets (possibly changing the Arm license fees, as well).

When I read about OTP bits to disable functionality, It looks like the way on how malware/virus can kill your CPU just by writing some bit at specific register... I can understand when functionality is disabled with soldering resistor jumpers as it's done on Intel CPU, but when you can do it with software, it makes such MCU very non reliable...

MK14 · « **Reply #191 on:** August 28, 2024, 03:38:13 pm »

Quote from: radiolistener on August 28, 2024, 02:49:22 pm

When I read about OTP bits to disable functionality, It looks like the way on how malware/virus can kill your CPU just by writing some bit at specific register... I can understand when functionality is disabled with soldering resistor jumpers as it's done on Intel CPU, but when you can do it with software, it makes such MCU very non reliable...

If it was running a proper (full) operating system and directly connected to the internet in a significant way, like a full sized Raspberry Pi running Linux, could be. Then I'd agree with you.

But, it is for running embedded (MCU) applications, typically compiled or interpreted from (often your own) source code. So, should be relatively immune from such attacks.

But, on the internet, there could be downloadable image files for the Pico2/RP2350, with harmful (I don't know if special button/signals are needed, in order to change the OTP, or if anything, at anytime, can mess with the OTP) stuff, designed to 'destroy' your device.

I don't think it is a serious problem.

Perhaps they could have given it some kind of method, for resetting it back into factory default settings mode.

Some other MCUs (IIRC), are also susceptible, because their boot loader code, can be erased/disabled, forcing more dramatic methods of reprogramming it, such as having to use a JTAG device, rather than the usual USB programming (boot) method. I think (IIRC) some are basically bricked if the boot code is erased/disabled, either permanently or unless you have access to (a possibly VERY expensive, but sometimes there are much cheaper clones available), proprietary factory supplied programmer device.

radiolistener · « **Reply #192 on:** August 28, 2024, 04:31:06 pm »

Quote from: MK14 on August 28, 2024, 03:38:13 pm

But, it is for running embedded (MCU) applications, typically compiled or interpreted from (often your own) source code. So, should be relatively immune from such attacks.

even MCU disconnected from the world can write it due to some mistake in the code or failure.

MK14 · « **Reply #193 on:** August 28, 2024, 04:37:23 pm »

Quote from: radiolistener on August 28, 2024, 04:31:06 pm

Quote from: MK14 on August 28, 2024, 03:38:13 pm
But, it is for running embedded (MCU) applications, typically compiled or interpreted from (often your own) source code. So, should be relatively immune from such attacks.

even MCU disconnected from the world can write it due to some mistake in the code or failure.

You're right, but on the other hand. Don't forget that this MCU, and many/most other MCUs, can (due to faulty code or failure), over-write their flash based firmware/software, which for something out in the field (e.g. a product released to customers), would essentially destroy the device.

But in practice, with decently written/tested software, and well designed hardware, there shouldn't really be such a problem, in general.

ataradov · « **Reply #194 on:** August 28, 2024, 04:39:27 pm »

There are a lot of other MCUs with OTP bits and memories. The programming procedure is pretty complicated, it is hard to invoke it by error. The only somewhat realistic scenario is when your code already had the function, but it was not called yet and it gets called by accident due to incorrect jump. But this is really far fetched.

Ability to persistently lock up the device and prevent any further access even after an erase is a new feature that is being introduced in most new devices, since customers demand that..

MK14 · « **Reply #195 on:** August 28, 2024, 04:46:18 pm »

Quote from: ataradov on August 28, 2024, 04:39:27 pm

Ability to persistently lock up the device and prevent any further access even after an erase is a new feature that is being introduced in most new devices, since customers demand that..

Presumably, one need/reason, would be that if the device (as in over-all product, such as an energy providers smart-meter), detects that you are trying to hack/interfere/defeat/mess with it, it can 'self-destruct', by disabling the MCU(s).

tszaboo · « **Reply #196 on:** August 28, 2024, 04:48:58 pm »

Quote from: radiolistener on August 28, 2024, 02:49:22 pm

Quote from: MK14 on August 14, 2024, 08:19:37 pm
Also, the built in OTP, has flag bits, which allows one to permanently disable, core types, if you want. E.g. Eliminate (disable) the RISC-V cores, permanently.
I'm not sure, exactly why. Perhaps for security/reliability reasons, or maybe to allow them to be sold as different chip variants, for certain markets (possibly changing the Arm license fees, as well).

When I read about OTP bits to disable functionality, It looks like the way on how malware/virus can kill your CPU just by writing some bit at specific register... I can understand when functionality is disabled with soldering resistor jumpers as it's done on Intel CPU, but when you can do it with software, it makes such MCU very non reliable...

Do you let others run code on your microcontroller?

coppice · « **Reply #197 on:** August 28, 2024, 04:59:18 pm »

Quote from: radiolistener on August 28, 2024, 02:49:22 pm

Quote from: MK14 on August 14, 2024, 08:19:37 pm
Also, the built in OTP, has flag bits, which allows one to permanently disable, core types, if you want. E.g. Eliminate (disable) the RISC-V cores, permanently.
I'm not sure, exactly why. Perhaps for security/reliability reasons, or maybe to allow them to be sold as different chip variants, for certain markets (possibly changing the Arm license fees, as well).

When I read about OTP bits to disable functionality, It looks like the way on how malware/virus can kill your CPU just by writing some bit at specific register... I can understand when functionality is disabled with soldering resistor jumpers as it's done on Intel CPU, but when you can do it with software, it makes such MCU very non reliable...

OTP bits to enable or disable various kinds of functionality are widespread in modern MCUs. If someone has managed to hijack your device to the point where they can load and run code that will affect one of these selections you have bigger problems than them tampering with the bits.

ataradov · « **Reply #198 on:** August 28, 2024, 05:00:37 pm »

Quote from: MK14 on August 28, 2024, 04:46:18 pm

[Presumably, one need/reason, would be that if the device (as in over-all product, such as an energy providers smart-meter), detects that you are trying to hack/interfere/defeat/mess with it, it can 'self-destruct', by disabling the MCU(s).

Not really, I have not seen anyone want to actually destroy the MCU. In most cases there like this there is a tamper detect mechanism and erase of the keys or other data in SRAM. The unit is still alive, but does not work without new provisioning.

The lock is not destructive, it is just really permanent. Once set, you can't erase it. And sometimes you also have persistent boot section, so not even code running on the MCU can ever erase it.

The reason for persistent lock is to make firmware modification impossible without swapping the MCU. This increases the barrier for hacks. If you have some gadget with an older MCU, an independent firmware may be developed and a simple PiPico will let people without any experience change the firmware and unlock the device. But if unlocking requires CPU swap, there is no way ordinary people will be able to do that.

MK14 · « **Reply #199 on:** August 28, 2024, 05:19:44 pm »

Quote from: ataradov on August 28, 2024, 05:00:37 pm

Quote from: MK14 on August 28, 2024, 04:46:18 pm
[Presumably, one need/reason, would be that if the device (as in over-all product, such as an energy providers smart-meter), detects that you are trying to hack/interfere/defeat/mess with it, it can 'self-destruct', by disabling the MCU(s).

Not really, I have not seen anyone want to actually destroy the MCU. In most cases there like this there is a tamper detect mechanism and erase of the keys or other data in SRAM. The unit is still alive, but does not work without new provisioning.

The lock is not destructive, it is just really permanent. Once set, you can't erase it. And sometimes you also have persistent boot section, so not even code running on the MCU can ever erase it.

The reason for persistent lock is to make firmware modification impossible without swapping the MCU. This increases the barrier for hacks. If you have some gadget with an older MCU, an independent firmware may be developed and a simple PiPico will let people without any experience change the firmware and unlock the device. But if unlocking requires CPU swap, there is no way ordinary people will be able to do that.

Thanks, that makes a lot of sense.

E.g. Unfortunately, a lot of CCTV security cameras these days, use the business model that the cameras are amazingly cheap and feature packed. But they then rely on pressuring or forcing the users, to buy subscriptions either for more features or even just to carry on using it, depending on the make and model.

So, if independent firmware was created, a user could hack it, get all the features and not pay any subscriptions.

But, as you just said, if the user had to physically swap the actual MCU, involving fiddly unscrewing to open the device and difficult surface mount soldering, ideally needing specialist equipment, most people, don't have access to, or the know how/experience to use. Is likely to stop >=99% of users, replacing the firmware, that way.