The Raspberry PI PICO 2, now has extra RISC-V cores - Page 1
Forum section: electronics / general

author: MK14
author_rank: Super Contributor
timestamp: August 08, 2024, 03:50:30 pm
content: https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/QuoteQuote

author: Jope
author_rank: Regular Contributor
timestamp: August 08, 2024, 04:24:47 pm
content: This guy had access to samples over the last year:Why you should fall in love with the RP2350

author: ataradov
author_rank: Super Contributor
timestamp: August 08, 2024, 04:46:14 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: August 08, 2024, 05:06:23 pm
content: Quote from: ataradov on August 08, 2024, 04:46:14 pmThat 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 08, 2024, 07:21:57 pm
content: Quote from: ataradov on August 08, 2024, 04:46:14 pmseem like the intention is that you pick tool chain you prefer and just use thatit does show that cpu cores take up hardly any area, it's all RAM and peripherals

author: Rudolph Riedel
author_rank: Regular Contributor
timestamp: August 08, 2024, 07:32:58 pm
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: August 08, 2024, 07:37:46 pm
content: 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/24870PS: and ie. the Waveshare Electronics will follow soon, my bet (the same setup but cheaper)..

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 08, 2024, 08:04:34 pm
content: Quote from: ataradov on August 08, 2024, 04:46:14 pmThey 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.

author: tszaboo
author_rank: Super Contributor
timestamp: August 08, 2024, 08:41:29 pm
content: Quote from: SiliconWizard on August 08, 2024, 08:04:34 pmThe 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 08, 2024, 09:02:24 pm
content: Quote from: tszaboo on August 08, 2024, 08:41:29 pmOr inability to meet the requirements without going overboard, which is more likely, IMO.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 08, 2024, 09:37:36 pm
content: 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.

author: floobydust
author_rank: Super Contributor
timestamp: August 08, 2024, 09:51:49 pm
content: 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

author: ataradov
author_rank: Super Contributor
timestamp: August 08, 2024, 10:34:28 pm
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: August 08, 2024, 11:30:47 pm
content: Quote from: ataradov on August 08, 2024, 04:46:14 pmGCC 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.

author: MK14
author_rank: Super Contributor
timestamp: August 08, 2024, 11:37:24 pm
content: Quote from: brucehoult on August 08, 2024, 11:30:47 pmIt 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).

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 09, 2024, 01:31:52 am
content: Quote from: brucehoult on August 08, 2024, 11:30:47 pmWell, 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/Hazard3It 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.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 09, 2024, 02:47:11 am
content: Quote from: SiliconWizard on August 08, 2024, 09:37:36 pmA few points.There's a guywho's been beta-testing itfor 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 readon an RP2040. I expect the RP235x to be broadly similar. Slightly faster than that iMXRT1062, at least for writesThere'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 TMDSThe 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 transferDMA got an upgrade with infinite re-triggering (no longer need to use another DMA channel to re-trigger), and more offset choices for repeated triggeringADCs are less noisy nowGPIO is 5v-tolerant, which is nice for me, YMMVsigned boot, OTP storage for encryption key, encrypted bitstream stored in the on-board flash makes it more palatable for commercial useHalf a meg of RAM is a nice upgradedual-core M33's which (as above) overclock significantlyAn 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 pinsCo-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 awesomeguaranteed production until 2040... all in a $1 chip. Quite an upgrade IMHO.If you really want more (up to 3, I guess) USB ports, you canuse PIOto 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.

author: MK14
author_rank: Super Contributor
timestamp: August 09, 2024, 03:43:07 am
content: 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=42092668289107They 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.

author: shabaz
author_rank: Frequent Contributor
timestamp: August 09, 2024, 03:59:05 am
content: QuoteNice, 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.

author: floobydust
author_rank: Super Contributor
timestamp: August 09, 2024, 04:05:30 am
content: RP2350 Datasheet.pdf1,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 SwitchingRP2350 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 CombinationsThe 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."

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 09, 2024, 05:00:49 am
content: 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.

author: MK14
author_rank: Super Contributor
timestamp: August 09, 2024, 05:10:32 am
content: Quote from: SiliconWizard on August 09, 2024, 05:00:49 amI'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.

author: josip
author_rank: Regular Contributor
timestamp: August 09, 2024, 05:45:03 am
content: Using it as USB device still need external crystal.

author: woofy
author_rank: Frequent Contributor
timestamp: August 09, 2024, 08:26:23 am
content: 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.

author: MK14
author_rank: Super Contributor
timestamp: August 09, 2024, 08:51:33 am
content: 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.htmlThere 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 amI 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/1100220184There 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-84333cbefeafOlimex Blog about it:https://olimex.wordpress.com/2024/07/25/esp32-p4-dual-core-risc-v-open-source-hardware-board-is-almost-finished/

author: iMo
author_rank: Super Contributor
timestamp: August 09, 2024, 09:42:52 am
content: Quote from: SiliconWizard on August 09, 2024, 05:00:49 amI 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).QuoteInstead waisting silicon they had to focus on improving or adding some new features (a long list)..So either ARM or RV..

author: tszaboo
author_rank: Super Contributor
timestamp: August 09, 2024, 10:41:32 am
content: Quote from: iMo on August 09, 2024, 09:42:52 amIf 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.

author: Andree Henkel
author_rank: Regular Contributor
timestamp: August 09, 2024, 11:48:52 am
content: The weak point for my applications that will lead to selct a µC of competition is still lack of internal DAC´sI 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 outputsnice that the large chiip now has 8 ADCbut 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

author: rteodor
author_rank: Frequent Contributor
timestamp: August 09, 2024, 11:58:50 am
content: Quote from: iMo on August 09, 2024, 09:42:52 amThis 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?

author: MK14
author_rank: Super Contributor
timestamp: August 09, 2024, 12:11:52 pm
content: 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

author: coppice
author_rank: Super Contributor
timestamp: August 09, 2024, 01:45:02 pm
content: Quote from: Andree Henkel on August 09, 2024, 11:48:52 amIf 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 09, 2024, 03:29:53 pm
content: Quote from: iMo on August 09, 2024, 09:42:52 amcompared to the large RAM,peripherals, PIOs, and regulator, the area of the extra cores are probably insignificant

author: NickAmes
author_rank: Contributor
timestamp: August 09, 2024, 03:37:19 pm
content: 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. InHardware 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?

author: josip
author_rank: Regular Contributor
timestamp: August 09, 2024, 07:27:13 pm
content: Quote from: Andree Henkel on August 09, 2024, 11:48:52 amWith 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 pmNXP / 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.

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 09, 2024, 07:29:48 pm
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 09, 2024, 07:42:26 pm
content: 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.

author: coppice
author_rank: Super Contributor
timestamp: August 09, 2024, 07:57:09 pm
content: Quote from: josip on August 09, 2024, 07:27:13 pmAnd 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 09, 2024, 08:16:19 pm
content: imagine if ICs like the one used on this had some actually documentation,https://wiki.sipeed.com/hardware/en/maixzero/m0s/m0s.html

author: zapta
author_rank: Super Contributor
timestamp: August 09, 2024, 08:48:31 pm
content: 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

author: Arte
author_rank: Contributor
timestamp: August 09, 2024, 08:48:44 pm
content: 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...

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 09, 2024, 08:49:56 pm
content: Quote from: Andree Henkel on August 09, 2024, 11:48:52 amIn 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 ?

author: Nominal Animal
author_rank: Super Contributor
timestamp: August 09, 2024, 08:57:19 pm
content: Quote from: zapta on August 09, 2024, 08:48:31 pmThe Raspberry Pi Foundation has never been interested in interacting with open source projects. When they have to, they use temporary employees to do it.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 09, 2024, 11:21:35 pm
content: Quote from: NickAmes on August 09, 2024, 03:37:19 pmYes, 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 gateCount cycles during gateThe PIO lacks wait edge, so code is forced to use two lines and run slower, and fatter

author: MT
author_rank: Super Contributor
timestamp: August 10, 2024, 12:10:40 am
content: 30 GPIO on a 60-pin device!?.. What!?

author: ataradov
author_rank: Super Contributor
timestamp: August 10, 2024, 12:51:41 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 10, 2024, 01:01:14 am
content: Quote from: MT on August 10, 2024, 12:10:40 amOr 48 GPIOs on a 80-pin device.

author: boz
author_rank: Regular Contributor
timestamp: August 10, 2024, 01:08:02 am
content: 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 10, 2024, 01:13:58 am
content: 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.

author: floobydust
author_rank: Super Contributor
timestamp: August 10, 2024, 01:19:30 am
content: Raspberry Pi did their IPO June 11, 2024stock 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 theESP32which 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.

author: kamocat
author_rank: Newbie
timestamp: August 10, 2024, 01:44:10 am
content: Quote from: NickAmes on August 09, 2024, 03:37:19 pmUsing 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 converterAP63200 pg. 9

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 10, 2024, 02:22:56 am
content: Quote from: ataradov on August 10, 2024, 01:13:58 amYep. 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 10, 2024, 03:12:24 am
content: Quote from: boz on August 10, 2024, 01:08:02 amI 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 LPOSCIf LPOSC is not sufficiently accurate, an external 32.768kHz clock can be used. This will be multiplexed onto the internallow-power clock and will therefore drive all components that are driven by that clock, including the power sequencercomponents.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 tickAn 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.pdfor for a bit more money, you can get a DTCXO, for uA region Icc and low digit PPM - ie alotbetter than a tuning fork.https://www.lcsc.com/datasheet/lcsc_datasheet_2109101130_Seiko-Epson-TG-3541CE-32-7680KXA3_C1987384.pdf

author: ataradov
author_rank: Super Contributor
timestamp: August 10, 2024, 03:24:18 am
content: Quote from: SiliconWizard on August 10, 2024, 02:22:56 amWell, 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.

author: floobydust
author_rank: Super Contributor
timestamp: August 10, 2024, 03:26:54 am
content: 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-counterThe 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 10, 2024, 04:10:16 am
content: Quote from: floobydust on August 10, 2024, 03:26:54 amThat 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=306250I think this needs a GPIO pin as GATE semaphore ? Not sure if that can be avoided ?

author: iMo
author_rank: Super Contributor
timestamp: August 10, 2024, 09:53:33 am
content: Quote from: tszaboo on August 09, 2024, 10:41:32 amThe 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..

author: tszaboo
author_rank: Super Contributor
timestamp: August 10, 2024, 10:23:37 am
content: Quote from: kamocat on August 10, 2024, 01:44:10 amWow, 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.QuoteThis goes on for another 2 pages, talking about the same thing over and over.

author: ataradov
author_rank: Super Contributor
timestamp: August 10, 2024, 02:46:57 pm
content: 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.

author: iMo
author_rank: Super Contributor
timestamp: August 10, 2024, 02:58:20 pm
content: 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..

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 10, 2024, 05:56:43 pm
content: Quote from: iMo on August 10, 2024, 02:58:20 pmI 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.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 10, 2024, 06:18:07 pm
content: Quote from: ataradov on August 10, 2024, 02:46:57 pmI 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 10, 2024, 09:05:10 pm
content: 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?

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 10, 2024, 09:38:50 pm
content: Quote from: SiliconWizard on August 10, 2024, 09:05:10 pmYep - 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 notQuote from: SiliconWizard on August 10, 2024, 09:05:10 pmPricing is pretty comparable, an RP2040 from DigiKey is currently $0.70. The RP2350 price depends on configuration:RP2350A QFN60 no flash $0.80RP2350B QFN80 no flash $0.90RP2354A QFN60 2Mbyte flash $1.00RP2354B QFN80 2Mbyte flash $1.10I 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.

author: MK14
author_rank: Super Contributor
timestamp: August 10, 2024, 09:41:08 pm
content: Quote from: SiliconWizard on August 10, 2024, 09:05:10 pmApparently, in quantity pricing, each $0.80 for the entry level chip, for a reel of 3,400.Available by the end of the year.Quotehttps://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.

author: MK14
author_rank: Super Contributor
timestamp: August 10, 2024, 10:51:15 pm
content: Quote from: SpacedCowboy on August 10, 2024, 09:38:50 pmThe exact one, I linked to, seems to be the higher pin count version, RP2350B, not the A version.QuoteBut 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).

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 10, 2024, 11:34:19 pm
content: Quote from: MK14 on August 10, 2024, 10:51:15 pmNo, 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 2350BI ordered some of thePGA onesas well, which have all the pins (and are available now, not on 23rd August)

author: xbst_
author_rank: Contributor
timestamp: August 11, 2024, 09:09:19 am
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 11, 2024, 10:48:03 am
content: Quote from: SpacedCowboy on August 09, 2024, 02:47:11 amI 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...

author: MK14
author_rank: Super Contributor
timestamp: August 11, 2024, 11:51:52 am
content: Quote from: radiolistener on August 11, 2024, 10:48:03 amSince 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.

author: xbst_
author_rank: Contributor
timestamp: August 11, 2024, 01:53:34 pm
content: Quote from: guenthert on August 11, 2024, 01:46:43 pmWell for products that cost ~$20-30 it matters. BOM is usually a few dollars for products like that, not much room for fees.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 11, 2024, 03:11:47 pm
content: Quote from: radiolistener on August 11, 2024, 10:48:03 amGoogle: RP2350 datasheetSection 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 amI 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.

author: josip
author_rank: Regular Contributor
timestamp: August 11, 2024, 04:21:45 pm
content: 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$.

author: phil from seattle
author_rank: Super Contributor
timestamp: August 11, 2024, 08:02:51 pm
content: 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.

author: MK14
author_rank: Super Contributor
timestamp: August 11, 2024, 08:34:04 pm
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 11, 2024, 08:41:30 pm
content: Quote from: SpacedCowboy on August 11, 2024, 03:11:47 pmEven 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?

author: langwadt
author_rank: Super Contributor
timestamp: August 11, 2024, 08:47:22 pm
content: Quote from: phil from seattle on August 11, 2024, 08:02:51 pmit seems to me that if choice and orientation of the inductor in a buck converter is that critical there must be something seriously wrong

author: ataradov
author_rank: Super Contributor
timestamp: August 11, 2024, 08:49:00 pm
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 11, 2024, 09:02:00 pm
content: Quote from: ataradov on August 11, 2024, 08:49:00 pmSTM32H7 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 11, 2024, 09:17:58 pm
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 11, 2024, 10:27:40 pm
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 11, 2024, 11:54:23 pm
content: Quote from: SpacedCowboy on August 11, 2024, 03:11:47 pm12-bit with 9.2 ENOB 500 kHz...Unfortunately even worse than I expected

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 01:07:06 am
content: 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

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 12, 2024, 02:10:12 am
content: Quote from: SpacedCowboy on August 10, 2024, 05:56:43 pmThat'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 ...

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 12, 2024, 02:21:47 am
content: Quote from: radiolistener on August 11, 2024, 08:41:30 pmThe 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 pmThis 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 pmAnything 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 pmTheirflagship 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 pmThe 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 runsLinuxfor 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 pmSTM32H{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...

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 12, 2024, 02:27:30 am
content: Quote from: PCB.Wiz on August 12, 2024, 02:10:12 amYep. 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 aDECstation 3100emulator 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)

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 12, 2024, 02:35:19 am
content: Quote from: ataradov on August 11, 2024, 09:17:58 pmA 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2024, 02:44:25 am
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 02:57:27 am
content: Quote from: SpacedCowboy on August 12, 2024, 02:21:47 amIt 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2024, 03:00:03 am
content: Quote from: radiolistener on August 12, 2024, 02:57:27 amIt 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 03:12:27 am
content: Quote from: ataradov on August 12, 2024, 03:00:03 amyes 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

author: ataradov
author_rank: Super Contributor
timestamp: August 12, 2024, 03:18:20 am
content: Quote from: radiolistener on August 12, 2024, 03:12:27 amI 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 amBecause 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 03:38:24 am
content: Quote from: ataradov on August 12, 2024, 03:18:20 amThats true, too slow ADC with low dynamic range is another issueEven STM32F103 ADC can run at 2.5 MHz or 5 MHz in interleaved mode.Quote from: ataradov on August 12, 2024, 03:18:20 amSomething tells me that 2 x Cortex-M33 cores of RP2050 running at 300 MHz can saturate USB HS with no problemAnd 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 12, 2024, 03:46:30 am
content: 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.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 12, 2024, 03:56:48 am
content: Quote from: radiolistener on August 12, 2024, 02:57:27 amSlow, old andexpensive- I just looked on DigiKey and Q1 prices start at ~$18 (!)Having read through several of your posts, it seems youreallywant 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 youcoulduse the RP235x, but I'm not convinced youshoulddo 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 CY7C68013AWait 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 insteadUse a different MCU

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 04:01:31 am
content: Quote from: SiliconWizard on August 12, 2024, 03:46:30 amsomeone who was beta-tester of RP2050 wrote that it can be easily overclocked to 300 MHz with no issues.

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 04:21:24 am
content: Quote from: SpacedCowboy on August 12, 2024, 02:21:47 amYes, 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...

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 12, 2024, 05:30:01 am
content: Quote from: radiolistener on August 12, 2024, 04:21:24 amI 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…

author: brucehoult
author_rank: Super Contributor
timestamp: August 12, 2024, 05:35:58 am
content: Quote from: SpacedCowboy on August 12, 2024, 02:21:47 amThat'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.

author: Postal2
author_rank: Frequent Contributor
timestamp: August 12, 2024, 06:39:57 am
content: Quote from: radiolistener on August 11, 2024, 08:41:30 pmGood chip, I like it.

author: Jeroen3
author_rank: Super Contributor
timestamp: August 12, 2024, 06:47:26 am
content: Quote from: NickAmes on August 09, 2024, 03:37:19 pmSometimes 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 amThe 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 pinnever noticed that on the rp2040.

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 06:49:28 am
content: Quote from: SpacedCowboy on August 12, 2024, 05:30:01 amI'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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 12, 2024, 07:37:12 am
content: Quote from: Jeroen3 on August 12, 2024, 06:47:26 amWCH have a HS-USB MCU that comes down to TSSOP20.

author: tszaboo
author_rank: Super Contributor
timestamp: August 12, 2024, 07:52:59 am
content: Quote from: radiolistener on August 12, 2024, 06:49:28 amThe 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 08:09:44 am
content: Quote from: tszaboo on August 12, 2024, 07:52:59 amMass 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..."

author: iMo
author_rank: Super Contributor
timestamp: August 12, 2024, 08:38:29 am
content: @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.

author: MK14
author_rank: Super Contributor
timestamp: August 12, 2024, 08:41:26 am
content: 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.

author: brucehoult
author_rank: Super Contributor
timestamp: August 12, 2024, 08:58:15 am
content: Quote from: MK14 on August 12, 2024, 08:41:26 amI 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 09:00:30 am
content: Quote from: MK14 on August 12, 2024, 08:41:26 amI 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...

author: MK14
author_rank: Super Contributor
timestamp: August 12, 2024, 09:00:53 am
content: 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.

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 12, 2024, 09:02:28 am
content: This SMPS issue sure is disappointing. I don't know if they can easily fix it with a "small" silicon revision. We'll see.

author: MK14
author_rank: Super Contributor
timestamp: August 12, 2024, 09:12:55 am
content: Quote from: radiolistener on August 12, 2024, 09:00:30 amLots 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.

author: tszaboo
author_rank: Super Contributor
timestamp: August 12, 2024, 09:16:32 am
content: Quote from: radiolistener on August 12, 2024, 08:09:44 amIt 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.

author: iMo
author_rank: Super Contributor
timestamp: August 12, 2024, 09:20:37 am
content: Quote from: radiolistener on August 12, 2024, 09:00:30 amThat 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..

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 09:29:59 am
content: Quote from: tszaboo on August 12, 2024, 09:16:32 amYou 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 12, 2024, 09:30:42 am
content: Quote from: radiolistener on August 12, 2024, 09:00:30 amSurely 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 MbdThe posts like herehttps://forums.raspberrypi.com/viewtopic.php?t=321476#p1924376suggest 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 tooAt 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.

author: tszaboo
author_rank: Super Contributor
timestamp: August 12, 2024, 09:42:18 am
content: Quote from: radiolistener on August 12, 2024, 09:29:59 amYou 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 aredesignedto work at that speed. And with that, your entire digital design is different.

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 09:43:25 am
content: Quote from: iMo on August 12, 2024, 09:20:37 amYes! 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 amI'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 amSorry, 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?

author: iMo
author_rank: Super Contributor
timestamp: August 12, 2024, 10:09:03 am
content: Quote from: radiolistener on August 12, 2024, 09:43:25 amAgain, 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..

author: rteodor
author_rank: Frequent Contributor
timestamp: August 12, 2024, 10:24:11 am
content: Quote from: radiolistener on August 12, 2024, 09:00:30 amAHB 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 ...).

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 10:35:22 am
content: Quote from: iMo on August 12, 2024, 10:09:03 amThe 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...

author: iMo
author_rank: Super Contributor
timestamp: August 12, 2024, 10:44:07 am
content: 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)..

author: tszaboo
author_rank: Super Contributor
timestamp: August 12, 2024, 11:35:52 am
content: Quote from: radiolistener on August 12, 2024, 09:43:25 amMe 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.

author: langwadt
author_rank: Super Contributor
timestamp: August 12, 2024, 11:51:40 am
content: Quote from: radiolistener on August 12, 2024, 10:35:22 amthat clearly and obviously depend on what processing you are doing ....

author: dave j
author_rank: Regular Contributor
timestamp: August 12, 2024, 12:19:37 pm
content: Quote from: PCB.Wiz on August 12, 2024, 02:10:12 amYou 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.)

author: radiolistener
author_rank: Super Contributor
timestamp: August 12, 2024, 02:12:40 pm
content: Quote from: rteodor on August 12, 2024, 10:24:11 amOn a brief search I found that CY7C68013A is manufactured on C8 Technology process, there is no details, butI found that L8C-3R technology (which is Derivative of the C8 Technology) uses CMOS, 0.13 μm processand 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?

author: westfw
author_rank: Super Contributor
timestamp: August 12, 2024, 02:45:47 pm
content: QuoteI 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!” :-)

author: coppice
author_rank: Super Contributor
timestamp: August 12, 2024, 03:01:01 pm
content: Quote from: radiolistener on August 12, 2024, 02:12:40 pmA 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.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 12, 2024, 03:07:41 pm
content: Quote from: radiolistener on August 12, 2024, 09:00:30 amFor *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.

author: rteodor
author_rank: Frequent Contributor
timestamp: August 12, 2024, 04:11:27 pm
content: Quote from: radiolistener on August 12, 2024, 02:12:40 pmI 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 insomeapplications.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.

author: josip
author_rank: Regular Contributor
timestamp: August 12, 2024, 04:29:55 pm
content: 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.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 12, 2024, 05:21:09 pm
content: Quote from: josip on August 12, 2024, 04:29:55 pmI've used the larger i.MXRT chips a couple of times. I think the learning curve for the development environment is alotsteeper 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

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 12, 2024, 07:54:54 pm
content: Quote from: dave j on August 12, 2024, 12:19:37 pmThanks for that detail.I should have said you cannot poll IRQ asquickly or efficientlyas 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.

author: phil from seattle
author_rank: Super Contributor
timestamp: August 12, 2024, 08:51:35 pm
content: Quote from: MK14 on August 12, 2024, 09:00:53 amThe 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.

author: exe
author_rank: Unknown
timestamp: August 12, 2024, 09:04:58 pm
content: I think I like it so far. I'll be waiting for the version with integrated flash.

author: westfw
author_rank: Super Contributor
timestamp: August 12, 2024, 10:00:30 pm
content: Hmm. The Integrated flash will preclude using a larger external flash, right?

author: tszaboo
author_rank: Super Contributor
timestamp: August 12, 2024, 10:25:09 pm
content: Quote from: westfw on August 12, 2024, 10:00:30 pmNot necessarily, Someone mentioned multiple CS pins for flash and PSRAM.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 12, 2024, 11:14:19 pm
content: Quote from: westfw on August 12, 2024, 10:00:30 pmYou can have up to two QSPI devices, in any external / "internal" combination, of any type (RAM, Flash), each can be 16MB in sizeI 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.

author: MK14
author_rank: Super Contributor
timestamp: August 12, 2024, 11:25:46 pm
content: Quote from: phil from seattle on August 12, 2024, 08:51:35 pmFor 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.

author: brucehoult
author_rank: Super Contributor
timestamp: August 13, 2024, 12:10:33 am
content: Quote from: coppice on August 12, 2024, 03:01:01 pm... and the RP2040 was already widely criticised for not having what people considered to be a sufficiently low power sleep mode.

author: MT
author_rank: Super Contributor
timestamp: August 13, 2024, 12:21:47 am
content: Quote from: tszaboo on August 12, 2024, 09:42:18 amSpeaking 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 shapingstuff 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.

author: tszaboo
author_rank: Super Contributor
timestamp: August 13, 2024, 10:01:12 am
content: Quote from: MT on August 13, 2024, 12:21:47 amI 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

author: coppice
author_rank: Super Contributor
timestamp: August 13, 2024, 12:13:00 pm
content: Quote from: tszaboo on August 13, 2024, 10:01:12 amOne 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.

author: exe
author_rank: Unknown
timestamp: August 13, 2024, 07:10:35 pm
content: 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

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 13, 2024, 08:46:14 pm
content: 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.

author: i509VCB
author_rank: Contributor
timestamp: August 13, 2024, 08:53:08 pm
content: Quote from: phil from seattle on August 11, 2024, 08:02:51 pmLooking 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.

author: uer166
author_rank: Super Contributor
timestamp: August 14, 2024, 12:50:13 am
content: 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 14, 2024, 04:14:53 am
content: Quote from: uer166 on August 14, 2024, 12:50:13 amSince 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.

author: shabaz
author_rank: Frequent Contributor
timestamp: August 14, 2024, 05:20:43 am
content: Quote from: radiolistener on August 14, 2024, 04:14:53 amI 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 thePimoroni Pico 2 Plusboard 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).

author: MK14
author_rank: Super Contributor
timestamp: August 14, 2024, 06:54:08 am
content: Quote from: shabaz on August 14, 2024, 05:20:43 amI 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:QuoteSo, 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.

author: iMo
author_rank: Super Contributor
timestamp: August 14, 2024, 07:27:55 am
content: Quote from: radiolistener on August 14, 2024, 04:14:53 amOn pico2 original they use the "RT6150 buck-boost SMPS, which generates a fixed 3.3V outputfor 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..

author: ftg
author_rank: Frequent Contributor
timestamp: August 14, 2024, 07:40:53 am
content: Quote from: radiolistener on August 14, 2024, 04:14:53 amSilicon 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 14, 2024, 07:46:04 am
content: Quote from: shabaz on August 14, 2024, 05:20:43 amRegarding 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 amYes, 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.

author: iMo
author_rank: Super Contributor
timestamp: August 14, 2024, 07:54:25 am
content: Quote from: iMo on August 14, 2024, 07:27:55 amFrom DS:QuoteThus 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)..

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 14, 2024, 08:00:02 am
content: Quote from: ftg on August 14, 2024, 07:40:53 amMany 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.

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

author: brucehoult
author_rank: Super Contributor
timestamp: August 14, 2024, 11:48:47 am
content: Quote from: josip on August 14, 2024, 11:40:20 amM33 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.

author: MK14
author_rank: Super Contributor
timestamp: August 14, 2024, 11:56:25 am
content: Quote from: brucehoult on August 14, 2024, 11:48:47 amQuoteSource: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.pdfHence 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).

author: jnk0le
author_rank: Regular Contributor
timestamp: August 14, 2024, 07:26:03 pm
content: Quote from: brucehoult on August 14, 2024, 11:48:47 amI think it's the same "limited dual issue" as on CM55 which has the official optimization guide here:https://developer.arm.com/documentation/102692/0101M33 -> M55 coremark difference is most likely HW loops or the 0 cycle branch (which is a reuse of LOB buffer from HW loops)

author: MK14
author_rank: Super Contributor
timestamp: August 14, 2024, 08:19:37 pm
content: 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/armuletAlso, 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

author: Postal2
author_rank: Frequent Contributor
timestamp: August 14, 2024, 08:46:41 pm
content: Quote from: MK14 on August 14, 2024, 08:19:37 pmI liked it. It's like adding a "turn off forever" button on the TV remote control next to the "turn off" button.

author: jnk0le
author_rank: Regular Contributor
timestamp: August 14, 2024, 10:10:30 pm
content: Quote from: jnk0le on August 14, 2024, 07:26:03 pmor double wide scalar load/store (reuse of mve datapath)

author: shabaz
author_rank: Frequent Contributor
timestamp: August 15, 2024, 04:57:23 am
content: Quote from: MK14 on August 14, 2024, 06:54:08 amAdded 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 IAIt 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.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 15, 2024, 05:40:19 am
content: Interesting comment from the raspberry pi pico forums:Quote

author: macaba
author_rank: Regular Contributor
timestamp: August 15, 2024, 08:06:41 am
content: Quote from: shabaz on August 15, 2024, 04:57:23 amHopefully 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.

author: jnk0le
author_rank: Regular Contributor
timestamp: August 15, 2024, 11:02:17 am
content: more info on the inductor thing from jdb:Quote

author: exe
author_rank: Unknown
timestamp: August 15, 2024, 11:42:36 am
content: 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...

author: MK14
author_rank: Super Contributor
timestamp: August 15, 2024, 01:59:45 pm
content: Thanks to EVERYONE, as there are many interesting and informative posts, in this thread.Quote from: jnk0le on August 15, 2024, 11:02:17 amThat'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 changesEDIT2: 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/

author: MK14
author_rank: Super Contributor
timestamp: August 15, 2024, 02:31:28 pm
content: Quote from: SpacedCowboy on August 15, 2024, 05:40:19 amThat 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.

author: zapta
author_rank: Super Contributor
timestamp: August 15, 2024, 03:26:29 pm
content: Possibly they are the same cores, just switching at boot time a different microcode.

author: MK14
author_rank: Super Contributor
timestamp: August 15, 2024, 03:35:01 pm
content: Quote from: zapta on August 15, 2024, 03:26:29 pmI'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.

author: oPossum
author_rank: Super Contributor
timestamp: August 15, 2024, 04:10:20 pm
content: This is the RISC-V core:https://github.com/Wren6991/Hazard3

author: MK14
author_rank: Super Contributor
timestamp: August 15, 2024, 04:14:39 pm
content: Quote from: oPossum on August 15, 2024, 04:10:20 pmIt 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

author: ataradov
author_rank: Super Contributor
timestamp: August 15, 2024, 04:52:26 pm
content: 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.

author: MK14
author_rank: Super Contributor
timestamp: August 15, 2024, 05:05:42 pm
content: Quote from: ataradov on August 15, 2024, 04:52:26 pmI 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.

author: shabaz
author_rank: Frequent Contributor
timestamp: August 15, 2024, 06:36:23 pm
content: Quote from: macaba on August 15, 2024, 08:06:41 amVery useful info! I use JetBrains CLion which had a few complications in the setup unfortunately.Pico with CLion info herein 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.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: August 15, 2024, 07:40:50 pm
content: Quote from: MK14 on August 15, 2024, 01:59:45 pmMy 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 ?

author: iMo
author_rank: Super Contributor
timestamp: August 15, 2024, 08:14:13 pm
content: 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 appsit is simply a nogo.

author: MK14
author_rank: Super Contributor
timestamp: August 15, 2024, 08:26:28 pm
content: Quote from: PCB.Wiz on August 15, 2024, 07:40:50 pmI 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-wMy 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

author: MK14
author_rank: Super Contributor
timestamp: August 16, 2024, 07:00:29 pm
content: For anyone who is interested, the PICO 2 (original), is now in stock.Raspberry Pi Pico 2by Raspberry PiFor £4 + (for the UK) VAT = £4.80 + Shippingat 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

author: iMo
author_rank: Super Contributor
timestamp: August 27, 2024, 02:58:06 pm
content: FYI

author: westfw
author_rank: Super Contributor
timestamp: August 27, 2024, 08:13:24 pm
content: QuoteYeah, 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)

author: brucehoult
author_rank: Super Contributor
timestamp: August 27, 2024, 11:30:34 pm
content: Quote from: westfw on August 27, 2024, 08:13:24 pmI 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 yourCFLAGSand 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)QuoteOf 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 mostlyclzfor 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.

author: oPossum
author_rank: Super Contributor
timestamp: August 28, 2024, 02:48:41 am
content: A look at the silicon inside...https://electronupdate.blogspot.com/2024/08/pi-pico-2-extreme-teardown.html

author: langwadt
author_rank: Super Contributor
timestamp: August 28, 2024, 07:44:57 am
content: https://www.hackster.io/news/a-surprise-hardware-bug-in-raspberry-pi-s-rp2350-leads-to-unexpected-pull-down-behavior-76b51ec22ede

author: SiliconWizard
author_rank: Super Contributor
timestamp: August 28, 2024, 07:50:36 am
content: Ouch.

author: iMo
author_rank: Super Contributor
timestamp: August 28, 2024, 09:07:22 am
content: That happens when you start to play with off the shelf silicon libraries.. (.. they did the similar with the ADC bug in 2040, imho..)

author: coppice
author_rank: Super Contributor
timestamp: August 28, 2024, 10:56:34 am
content: Quote from: langwadt on August 28, 2024, 07:44:57 amAn MCU with a bug list, most of which will probably be worked around rather than fixed? I'm shocked, shocked I tell you.

author: RAPo
author_rank: Super Contributor
timestamp: August 28, 2024, 12:15:21 pm
content: But be sure to pick the right combo:Quote from: ataradov on August 08, 2024, 04:46:14 pm

author: macaba
author_rank: Regular Contributor
timestamp: August 28, 2024, 12:15:49 pm
content: 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:whetstone_rp2350.c  Debug (73,216 bytes) - 50.0 MWIPS (10000 loops)whetstone_rp2350.c  Release (68,608 bytes) - 333.3 MWIPS (10000 loops)whetstone_rp2350.c  Debug (131,584 bytes) - 1.9 MWIPS (1000 loops)whetstone_rp2350.c  Release (129,024 bytes) - 5.9 MWIPS (1000 loops)whetstone_rp2350.c  Debug (110,592 bytes) - 8.3 MWIPS (1000 loops)whetstone_rp2350.c  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: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:cmake build -DCMAKE_BUILD_TYPE=Release

author: RAPo
author_rank: Super Contributor
timestamp: August 28, 2024, 12:17:19 pm
content: My pico2 will arrive next week, will try out your suggestions.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 02:49:22 pm
content: Quote from: MK14 on August 14, 2024, 08:19:37 pmWhen 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...

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 03:38:13 pm
content: Quote from: radiolistener on August 28, 2024, 02:49:22 pmIf 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.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 04:31:06 pm
content: Quote from: MK14 on August 28, 2024, 03:38:13 pmeven MCU disconnected from the world can write it due to some mistake in the code or failure.

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 04:37:23 pm
content: Quote from: radiolistener on August 28, 2024, 04:31:06 pmYou'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.

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2024, 04:39:27 pm
content: 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..

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 04:46:18 pm
content: Quote from: ataradov on August 28, 2024, 04:39:27 pmPresumably, 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).

author: tszaboo
author_rank: Super Contributor
timestamp: August 28, 2024, 04:48:58 pm
content: Quote from: radiolistener on August 28, 2024, 02:49:22 pmDo you let others run code on your microcontroller?

author: coppice
author_rank: Super Contributor
timestamp: August 28, 2024, 04:59:18 pm
content: Quote from: radiolistener on August 28, 2024, 02:49:22 pmOTP 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.

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2024, 05:00:37 pm
content: Quote from: MK14 on August 28, 2024, 04:46:18 pmNot 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.

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 05:19:44 pm
content: Quote from: ataradov on August 28, 2024, 05:00:37 pmThanks, 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.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: August 28, 2024, 05:31:05 pm
content: Quote from: iMo on August 28, 2024, 09:07:22 amI think that'a a bit harsh. Raspberry Pi asked the *vendor* to modify the pad logic, they didn't do it themselves - which meaning could be inferred by your comment. If anyone should be able to do it correctly, it's the people who created the IP in the first place.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 06:54:16 pm
content: Quote from: MK14 on August 28, 2024, 04:37:23 pmYes, thats true. But it's easy to recover it with SWD.While OTP writing is unrecoverable action and will need to replace MCU or even entire device.

author: iMo
author_rank: Super Contributor
timestamp: August 28, 2024, 07:07:06 pm
content: Quote from: SpacedCowboy on August 28, 2024, 05:31:05 pmOk, I am correcting my sentence herewith:That happens when the silicon library vendor starts to play with his silicon libraries.. (.. they did the similar with the ADC bug in 2040, imho..)

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 07:08:27 pm
content: Quote from: tszaboo on August 28, 2024, 04:48:58 pmYes, anyone who use for example C compiler uses it's libraries and startup code. If you use some third party modules, they also can be vulnerable and allows to execute some code on your MCU.These days it's hard to write entire code with no using third party libraries and fully isolate MCU code from any possible intervention.And if your MCU has some communication with internet, it can be hacked with some kind of buffer overflow and execute hackers code on your MCU.For example seeBroadpwn attack, which allows for remote code execution on your smartphone or tablet with no need physical access to it, it is possible if it uses Broadcom’s BCM43xx family WiFi chipset and don't have patch...So, just imagine that your expensive device may unexpectedly stops to work and when you try to analyze what is going on all what you can see is that the chip is dead due to OTP bit write and you even don't have chance to survive it.

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 07:11:33 pm
content: Quote from: radiolistener on August 28, 2024, 06:54:16 pmOnce a product is sold to customers, SWD very likely, wouldn't help the end user, and the MCU may use other methods, anyway.As already said (emphasis added by me):Quote from: ataradov on August 28, 2024, 04:39:27 pmSome customers, want it that way, for their applications.

author: tszaboo
author_rank: Super Contributor
timestamp: August 28, 2024, 07:27:24 pm
content: Quote from: radiolistener on August 28, 2024, 07:08:27 pmYou can brick something if you call block erase on the bootloader. It's recoverable in theory, but impossible to do in practice.So anything with a flash is already vulnerable with your strange world view.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 07:28:12 pm
content: Quote from: ataradov on August 28, 2024, 04:39:27 pmOnce your firmware or bootloader has OTP write unlock/write procedure for factory configuration, it can be executed with unexpected state and data... It can be random error, due to some power or EMI condition or can be due to hackers attack...Quote from: tszaboo on August 28, 2024, 07:27:24 pmGood MCU has bootloader code in a factory written OTP memory which don't allow to erase/write with no physical intervention into the chip die... So you can't brick it. Even if you disable SWD, it can be bypassed and all firmware restored.

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2024, 07:37:09 pm
content: You can accidentally erase part of the firmware in the flash.Short story here is that it is not a real issue. It is only an issue if you want to complain about something . Most new devices contain OTP memories and this is not going to stop.EMI may happen, but this is not an MCU issue. It is on the equipment manufacturer to define the level of EMI compliance, design the equipment accordingly, and then test that compliance.By the same token, you can complain that RP2350 can't survive direct mains connection to the pins. What if a user has exposed wiring and it accidentally touches the pins? You would have to replace the MCU or throw away the device.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 08:02:28 pm
content: Quote from: ataradov on August 28, 2024, 07:37:09 pmYes, if we see at Broadpwn exploit, millions users have tablet, smartphone or other gadget with Broadcom’s BCM43xx WiFi chip. But not all of them were hacked with Broadpwn exploit despite the fact that they all were vulnerable for it before patch. And many of these who were hacked, even don't know about it, so they don't complain.The same applies to OTP programmable features available for writing after factory settings. Not all users will lose their devices because of this. Even those who do, won't know exactly what happened. They will just see a dead device and will need to spend more money on a new one. I can understand manufacturers who want more bricked devices because it increases demand for new devices. But this approach is definitely not good for the user and certainly not fair. It can be seen as the manufacturer cheating.

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 08:07:10 pm
content: Quote from: radiolistener on August 28, 2024, 08:02:28 pmNo.That is completely off-topic.This thread is about a new embedded MCU, not something which runs a fairly big OS, such as Android, with Wi-Fi.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 08:16:20 pm
content: Quote from: MK14 on August 28, 2024, 08:07:10 pmBroadpwn exploit is not about big OS. It's about the smallest deeply embedded ARM Cortex-R4 MCU (armv7-R) with about 900k firmware running on WiFi chip. It has even less resources than RP2350. I mention it as an example that hackers can execute any code on your MCU even if its protected.So, OTP-configurable MCU features that can be written after the chip leaves the factory are bad for the user. This is because the user can't write-protect these bits and is forced to accept the risk of losing their device at any time without the possibility of recovery by completely rewriting the firmware and data from backup.

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 08:27:13 pm
content: Quote from: radiolistener on August 28, 2024, 08:16:20 pmLet me check my understanding then.So my project or product (hypothetical), is a sealed electric toothbrush, with an RP2350 for brains, no Wi-Fi/Blutooth or USB sockets. No OS whatsoever, all handcrafted C code.It PWMs the motor for up to 2 minutes, when its single button is pressed, and turns a green LED on, while running. If the battery is low, it changes the LED colour to red.How exactly, does the hacker, thousands of miles away, change the OTP?

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 08:37:19 pm
content: Quote from: MK14 on August 28, 2024, 08:27:13 pmelectric toothbrush don't needs so powerful MCU, it's obviously too expensive and too powerful for this task. The projects where RP2350 can be used is more complicated and may use communication modules.Quote from: MK14 on August 28, 2024, 08:27:13 pmEven with electric toothbrush example you might accidentally write something in OTP when you play with MCU during development and lose it... This is the main risk that I see for myself as for developer.

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 08:49:46 pm
content: Quote from: radiolistener on August 28, 2024, 08:37:19 pmIt uses, a very complicated, 4 phase, ultrasonic cleaning pattern, which gets around all pre-existing and currently active patents. Needing the full power of all 3 PIO units.I'm planning to call it the Hyperphetical-SuperClean-2350, withOTPunit for increased reliability and cleaning power.Quote from: radiolistener on August 28, 2024, 08:37:19 pmBut I might also accidentally destroy the prototype, with static electricity, by accidentally setting the bench power supply to silly high voltages, or be so frustrated with someone on a forum, that I throw the only prototype, hard against a wall, smashing it to pieces.Yes, the prototype electric toothbrush,couldbe run over by a bus, with a big advert on the side of the bus that says "Vote NO to OTP".But life is full of risks, without going wildly overboard, with worrying about things, which are extremely unlikely to happen.

author: tszaboo
author_rank: Super Contributor
timestamp: August 28, 2024, 09:35:29 pm
content: Quote from: MK14 on August 28, 2024, 08:49:46 pmI have a toothbrush with OLED display and Bluetooth.It's not even expensive, cheaper than my dentist visits.

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 09:47:16 pm
content: Quote from: tszaboo on August 28, 2024, 09:35:29 pmIf my post hadn't been a hypothetical (joke), to illustrate why the OTP is acceptable. It probably would have had Bluetooth, wireless charging and other features. But I left them out from my hypothetical example, as the other poster, might have used them as a mechanism to allow hackers, to change its OTP, in order to damage it.There is a tiny bit of danger/risk, by having OTP disabling features in the RP2350. But like with lots of things in life, things are an overall balance of risks and features.Overall, I suspect the OTP is (part of the system, that provides) a very big boost to the security of the device, if needed, in some applications, for some customers.

author: ataradov
author_rank: Super Contributor
timestamp: August 28, 2024, 09:51:40 pm
content: Also, if you are so afraid of OTP and don't use it in your application, just program it yourself to whatever value you like. Then nobody else would be able to change that for you.

author: tszaboo
author_rank: Super Contributor
timestamp: August 28, 2024, 09:52:40 pm
content: Quote from: MK14 on August 28, 2024, 09:47:16 pmI agree. I find it ridiculous how we are discussing that having OTP is a danger. Also OTP in the bootloader is somehow OK, but not somewhere else.And you can just reflash PCI-Express network cards now. But we should give radiolistener a break, it's stressful to live in that country now.

author: radiolistener
author_rank: Super Contributor
timestamp: August 28, 2024, 10:03:38 pm
content: Quote from: tszaboo on August 28, 2024, 09:35:29 pmOMG, be careful, someone may hack your toothbrush from internet...

author: langwadt
author_rank: Super Contributor
timestamp: August 28, 2024, 10:13:41 pm
content: Quote from: MK14 on August 28, 2024, 08:49:46 pmwith OTP so copycats won't be selling toothbrushes running verbatim copies of your firmware next week

author: MK14
author_rank: Super Contributor
timestamp: August 28, 2024, 10:19:05 pm
content: Quote from: langwadt on August 28, 2024, 10:13:41 pmExactly!Apparently, that was one of the big complaints about the previous RP2040, lack of firmware security, especially with an external flash chip.OTP is useful for writing one-time production serial-number/batch-number/security-codes/date etc. In the knowledge that would be hackers, can't easily change it, like they could if it was simply in flash somewhere.EDIT: I'm speculating here. But, if your secure code runs on the Arm M33 cores. Disabling the RISC-V processors, on production units, permanently via the OTP. May make it more secure, as access to the RISC-V mode, could be an avenue for hackers to get round some of the security features (maybe?, speculation, as I said earlier).In the same way, on a secure server. Unnecessary services, IP-ports and things, may be disabled, and other things, to try and make the server more robust against attackers, trying to hack into it. E.g. Disabling external (non-local) SSH access, if it is NOT required.

author: rteodor
author_rank: Frequent Contributor
timestamp: August 29, 2024, 01:02:22 am
content: Tamper resistant systems are always controversial.It is by our human nature how we judge them: on one side are societal safety benefits (e.g. safety in automotive/avionics/medical/industrial, economic righteousness in meters) on the other side is the potential for abuse (in various ways either by manufacturers with bad market manners or by hackers with destructive intent).Different people look at at such systems from one or the other end depending on their cultural background.Without discussing the exact implementation on RP2350 with datasheet in front, the discussion will undoubtedly drift towards the "forever question": who benefits from using tamper resistant systems?And both sides will remain frustrated as such answer is not to be found now but in each particular future use of it.At this point it seems obvious that RP2350 is intended to be sold to the bigger market. Be that from one or the other side of the spectrum as described above. For now Broadcom wants to up the game for this device. Some will find this a hair rising, tooth sharpening bad sign, others will see it as a big and needed improvement. Again, the answer is not here and definitively not available now.

author: brucehoult
author_rank: Super Contributor
timestamp: August 29, 2024, 04:21:59 am
content: Quote from: RAPo on August 28, 2024, 12:17:19 pmMine arrived today (29th), in (very) rural far north New Zealand. Ordered from Pimoroni (UK) on the 17th, shipped on the 20th.The same mail contained a 16 GB RAM Sipeed Lichee Pi 3A (8 core SpacemiT K1, with 256 bit RVV 1.0 vectors).Hard to know which to play with first.

author: bob1033
author_rank: Contributor
timestamp: August 29, 2024, 02:20:17 pm
content: Looks like the GPIO latch-up issue can happen even without pullups/pulldowns enabledhttps://github.com/raspberrypi/pico-feedback/issues/401

author: MK14
author_rank: Super Contributor
timestamp: August 29, 2024, 02:40:57 pm
content: Quote from: bob1033 on August 29, 2024, 02:20:17 pmIf that is true, I'd be very disappointed with the teams, testing and validation performance. As that would be such a fundamental datasheet specification.I.e. This part of their datasheet specification (Page 1323):QuoteReading the supplied link, it seems as low as a 9k Ohms pull-down resistor (with 4k7 seeming to be the initial value, which reliably work as a pull-down, but best to wait until an official 'fix' is announced), is needed to defeat the potential latch-up.This seems pretty fundamental and bad, on the face of it.EDIT: I.e. An MCU with many of its pins having unreliable inputs (when somewhat weakly driven).EDIT2: It is good that there can be workarounds, but in my initial opinion, that does really need to be fixed. But it would probably cost something like (based on the IC processes process node of 40nm and my recent/quick research on the costs, perhaps a few days ago) $850,000 just for the mask(s), and perhaps millions more in practice, for the overall cost.

author: tszaboo
author_rank: Super Contributor
timestamp: August 29, 2024, 02:55:05 pm
content: Quote from: bob1033 on August 29, 2024, 02:20:17 pmThat's an issue that calls for a B revision silicon.The inputs not working properly is not something that you can downplay and solve in software.

author: coppice
author_rank: Super Contributor
timestamp: August 29, 2024, 03:53:13 pm
content: Quote from: bob1033 on August 29, 2024, 02:20:17 pmThat thread isn't very specific about what was done. When they pulled high, what exactly were they pulling to, and was this a dead short connexion? Was this 3.3V connexion guaranteed not to exceed whatever is used inside the MCU as its pin protection reference at all times? Modern multi-rail MCUs can have some pretty complex pin protection, especially if that protection was designed to deal with things like 5V tolerant inputs on a device with a lower, typically 3.3V, peripheral power rail. You can't simply diode clamp to the rail, and check very thoroughly for parasitic SCRs. There are quite a few fine geometry MCUs that have had troublesome latch up conditions on port pins, which typically proved hard to fix, as the pin protection has had to be seriously reworked.

author: bob1033
author_rank: Contributor
timestamp: August 29, 2024, 04:23:14 pm
content: If you look lower in the issue thread you can see that Ian from Dangerous Prototypes has some code to replicate the issue on the Bus Pirate. It seems like any weakly low pin can latch up to 2.1V

author: iMo
author_rank: Super Contributor
timestamp: August 29, 2024, 04:42:14 pm
content: Quote from: tszaboo on August 29, 2024, 02:55:05 pmThat would be interesting now.. They made a revision in 2040 afaik, but in the ROM code only which may cost them only 1 new mask, and the ADC bug has not been fixed as that would mean a complete new set of mask, imho. So the total $$ lost will depend on how many masks they have to generate new.With perhaps a million (??) 2350 chips already produced, the new B revision may increase the costs of this exercise significantly..

author: langwadt
author_rank: Super Contributor
timestamp: August 29, 2024, 05:28:12 pm
content: Quote from: iMo on August 29, 2024, 04:42:14 pmafaiu a mask set for 40nm is close to $1M, gotta sell a lot <$1 chips to make that up

author: iMo
author_rank: Super Contributor
timestamp: August 29, 2024, 05:33:14 pm
content: Interestinglythe mysterious testerspent a year testing it .. and did not spot the issue..

author: coppice
author_rank: Super Contributor
timestamp: August 29, 2024, 05:39:39 pm
content: Quote from: iMo on August 29, 2024, 05:33:14 pmMost people never see most issues in MCUs. They just don't use anything like the full range of functionality the device has. That's why it often puzzles people when they notice an MCU is up to revision M or N, when they thought it was fine when they were doing their development with revision A or B. The vendor didn't keep making those revisions for no reason. A few revisions are to improve manufacturability, but most fix bugs.

author: bob1033
author_rank: Contributor
timestamp: August 29, 2024, 05:50:19 pm
content: Quote from: iMo on August 29, 2024, 05:33:14 pmI work in pre and post silicon verification of microcontrollers. A lot a bugs we discover come from stochastic tests, randomizing GPIO input and register settings and verifying the behavior against a software model. Often bugs go unnoticed until someone runs code in a very specific sequence that triggers the bad behavior. Most customers use the chip for a very specific use case and therefore don't exercise the peripherals enough to catch these edge cases.

author: rteodor
author_rank: Frequent Contributor
timestamp: August 29, 2024, 05:54:21 pm
content: Quote from: langwadt on August 29, 2024, 05:28:12 pmA new mask doesn't cost only upfront money. Some clients specifically look for chips that were sold without a mask change in the last N years. Were N can be 5 ...10...15 or even more years.A new mask for RP2040 may not be worthy especially when it has a successor. RP2350 OTOH is young so it may have a new mask when enough problems pile up.

author: coppice
author_rank: Super Contributor
timestamp: August 29, 2024, 06:02:34 pm
content: Quote from: rteodor on August 29, 2024, 05:54:21 pmThat argument makes no sense. Almost all revisions happen in the first few years. After that, even if a problem shows up, sales have tailed off and nobody wants to put resources into further updates. Also, it clear most customers can live with whatever problems remain.

author: rteodor
author_rank: Frequent Contributor
timestamp: August 29, 2024, 06:16:00 pm
content: Quote from: coppice on August 29, 2024, 06:02:34 pmMy point exactly, only in better wording.

author: wasedadoc
author_rank: Super Contributor
timestamp: August 29, 2024, 06:57:39 pm
content: Quote from: rteodor on August 29, 2024, 01:02:22 amThe RP2350 is NOT a Broadcom device.

author: iMo
author_rank: Super Contributor
timestamp: August 29, 2024, 06:57:56 pm
content: This is my calculation - an estimate only - how many chips I have to produce when I plan to have 2 new revisions (not counting development costs and costs of sw tools and libraries and licenses - as the Rpi Foundation is a registered charity organization in England and Wales):Mask set cost: $1,000,000Wafer cost: $3,000 per 300mm wafer in 40nm TSMCChips per wafer: 15,000 chipsSelling price per chip: $0.60 (+ 40cents distributor's costs and margins = $1.00 street price)Two new revisions means additional two sets of mask costsPackaging cost per chip (QFN-60 epoxy): around $0.05 to $0.10, but let us assume $0.10 per chip as a conservative estimate.Result:We would need to sell 10,000,000 chips to break even.The actual calculation left as a homework for the readers..

author: wasedadoc
author_rank: Super Contributor
timestamp: August 29, 2024, 07:06:28 pm
content: Quote from: iMo on August 29, 2024, 06:57:56 pm^^ Another person who does not understand the relationship between the RPi Foundation charity and the commercial business which designs and sells the products.

author: tszaboo
author_rank: Super Contributor
timestamp: August 29, 2024, 07:09:11 pm
content: Quote from: wasedadoc on August 29, 2024, 07:06:28 pmSo why don't you spell it out instead of saying: "yor dumb"

author: coppice
author_rank: Super Contributor
timestamp: August 29, 2024, 07:12:07 pm
content: Quote from: iMo on August 29, 2024, 06:57:56 pmThis assumes a complete new mask set. A huge number of problem resolutions are achieved with metal fixes. If it turns out to be the something basic in the port protection an all layer fix may be needed, but its amazing how creativity can turn may fixes into metal only ones. You do realise most chips have a sprinkling of spare bits spread around that can be patched in with a metal fix, don't you?

author: MK14
author_rank: Super Contributor
timestamp: August 29, 2024, 07:22:54 pm
content: I think it is best to wait, until Raspberry Pi themselves, investigate (if necessary), agree that there is a problem (worse than the already officially agreed, low-pulldown not working properly issues), and if there is, they will be in the best situation, to see how bad/costly a possible fix might be.E.g. It is very easy to (without realizing) blow up I/O ports on your MCU, and then accuse the manufacturer of having bugs in their chip.It really needs more people to investigate and report back. Ideally, officially via the Raspberry Pi organizations.Maybe just that chip was faulty?EDIT: Added to.EDIT2: There does seem to be confirmation, from another person/entity, but that is still a bit too few and unofficial to start panicking about it.

author: iMo
author_rank: Super Contributor
timestamp: August 29, 2024, 07:36:54 pm
content: The above estimation plans one initial revision A and 2 new complete mask revisions B and C.Does not include development costs (opex/capex) for simplicity, but to add the cost estimation is not that difficult. I did it to somehow estimate the ballpark.How the Rpi foundation/company/charitywill do exactly proceed with current or future 2350 issues is not related to the above estimation, and frankly I do not care..

author: wasedadoc
author_rank: Super Contributor
timestamp: August 29, 2024, 07:37:20 pm
content: Quote from: tszaboo on August 29, 2024, 07:09:11 pmGoogle not working again?https://www.raspberrypi.org/about/https://www.raspberrypi.com/about/

author: brucehoult
author_rank: Super Contributor
timestamp: August 29, 2024, 11:05:31 pm
content: Quote from: tszaboo on August 29, 2024, 07:09:11 pmHere, let me try:No Raspberry Pi device has to make back its development costs. For the commercial business the selling price only has to cover the marginal cost of producing the device. Development costs (including re-spin of silicon to fix bugs) is paid for by the charity from donations.

author: tszaboo
author_rank: Super Contributor
timestamp: August 29, 2024, 11:28:30 pm
content: Quote from: wasedadoc on August 29, 2024, 07:37:20 pmIt does, but when you do that, you don't come off as an rude prick.

author: wasedadoc
author_rank: Super Contributor
timestamp: August 30, 2024, 12:04:43 am
content: Quote from: brucehoult on August 29, 2024, 11:05:31 pmNope the charity does not fund development costs. The charity side is not even single minded on RPi products. The commercial business is one of the donors to the charity.Lots of finance details of RaspberryPi Ltd (commercial) in the pdf for '25 Oct 2023 Amended full accounts made up to 31 December 2022' athttps://find-and-update.company-information.service.gov.uk/company/08207441/filing-history

author: abraxalito
author_rank: Contributor
timestamp: September 07, 2024, 03:26:23 am
content: Quote from: MK14 on August 29, 2024, 07:22:54 pmThere's now an updated datasheet with the 'E9' erratum spelled out in detail. The TL;DR version is - treat GPIO inputs as if they're TTL and you'll be fine. In other words any pull-downs need to be strong ones (lower than 8k2 at current estimates). This rather rules out use of the internal pull-downs.

author: MK14
author_rank: Super Contributor
timestamp: September 07, 2024, 09:12:47 am
content: Quote from: abraxalito on September 07, 2024, 03:26:23 amEDIT2:On reflection, that errata, seems way, way too complicated, to expect, the wide range of differing skill levels, from beginner to expert, to be able to reliably use these RP2350's (Pico 2's etc). In my opinion. Since inputs, are such an important part of some embedded projects.Thanks for that information!I would like to add, to that.First, one of the (apparently a) Raspberry Pi people/engineers/moderators, seems to have said, they are considering if they need to (as a result), release an updated version of the chip, on the official Raspberry Pi Forums. I'm not sure if that decision has been made yet, or not.Second, (partly based on what other(s) on unofficial sources, have said), that may not really work out, in practice. Because if it is (or is also used as, sometimes, by the hardware), an analogue input, it may not have such strong pull-low drive characteristics, depending on the exact circuit configuration/design used.E.g. An LDR (Light Dependent Resistor), whose resistance depends on the light level, and might be fed into an ADC pin, for reading the ambient light level, without an op-amp buffer. Could easily, sometimes be in the problematic (too high), resistance range, and then latch up the pin.N.B. I'm NOT familiar enough with the exact details of it all, to be 100% certain, so maybe the exact scenario, has to be different.EDIT:Looking at the updated datasheet, version information follows:QuoteSource:https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.pdfQuoteQuoteN.B. More information in actual datasheet, I've not copied the multiple graphs, included in the datasheet, about this issue.Quote

author: abraxalito
author_rank: Contributor
timestamp: September 07, 2024, 02:27:34 pm
content: Quote from: MK14 on September 07, 2024, 09:12:47 amAs far as I understand it, when using the ADC on a pin its digital input is supposed to be disabled therefore the bug doesn't affect ADC operation. Right at the end of the part you quoted :As normal, if ADC channels are being used on a pin, clear the relevant GPIO input enable as stated in Section 12.4.3.

author: MK14
author_rank: Super Contributor
timestamp: September 07, 2024, 04:43:17 pm
content: Quote from: abraxalito on September 07, 2024, 02:27:34 pmThanks, I didn't notice that bit.The thing is, having this weird (latched) fault state, with (what appears to me as) this extremely long winded, complicated technical details on how and when to avoid it.Is just asking for trouble and possible weaknesses in peoples designs.The RP2350 manual, seems to be 1,349 pages long, currently.I think it is asking too much, to expect all users, to realize/remember and technically handle this overly-complicated possible fault situation. Also, how do users, extensively check their designs for this possible short-coming.Some (perhaps many) users, just want to use an Arduino library function (or similar methodology), connect some standard (pre-assembled), hardware to it, and then have fun with their project.Not have to read all of a datasheets 1,349 pages, understand complicated technical issues, then consider if each of their hardware inputs, will meet all of E9's, errata specifications.Some sources, seem to state, that the majority of Pico2 units, will be used in educational and (by implication, beginner/hobbyist) environments, such as Schools and Universities. Some of whom, shouldn't really have to deal with such technical difficulties.So in summary, since this product (at least the Pico2 development boards), seem to be aimed, at beginners, early-education, and other non-expert (yet), users. It seems to me, to be unfair for them to have to deal with this problem, themselves.I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.The fact that hardened/experienced, electronics engineers (and similar), should be able to handle this shortcoming of the Pico2's inputs, via the errata (E9), shouldn't stop them from properly creating and releasing a 'fixed' later version of these chips (RP2350), assuming the costs and other practicalities, allow them to do so.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: September 07, 2024, 09:01:26 pm
content: > I.e. I consider these (current version) of Pico2 boards, to be (technically) faulty, and unsuited to their task.I don't think it's as bad as that. Most chips have errata and you use workarounds. Bottom line seems to be that:Inputs with external pullups of 10k will workInputs with external pulldowns of less than 8k2 will workDriven outputs will workIt means you can't connect high-impedance devices to an input port without going through a buffer but otherwise it seems still a reasonable part to use. They recently updated the E9 text to make it clearer what the issue is, and where it will occur. I agree it's a bit wordy, but the above seems to hold.

author: MK14
author_rank: Super Contributor
timestamp: September 07, 2024, 09:24:14 pm
content: Quote from: SpacedCowboy on September 07, 2024, 09:01:26 pmThat is NOT how I see it at all.The parts BASIC specification, that a competent engineer/hobbyist/person would reasonably expect, should follow the NORMs. I.e. General normal/usual inputs should be (as with most modern day, logic/MCU/similar devices), have a high impedance, and not need external pull up/down resistors, or much current, at all, under standard/normal/usual conditions.They also, should NOT exhibit latch-up behavior, under reasonable/normal conditions.To rely on them specifically checking the datasheet and/or errata, on a supposedly working, tested and under-full production part (i.e. NOT a specialist device, or very early prototype part etc), is risky and (opinions can vary) NOT reasonable.E.g. A teacher/lecturer, of reasonable background electronics knowledge and abilities. Should be able to walk into a classroom, full of pupils/students, with Raspberry Pi Pico2's at the ready.Then draw up a circuit on the white-board/projector etc, showing a simple push switch, a 47k ohm resistor, as pull-up or pull-down, and some simple code, used to set up the appropriate pins as inputs, read the input(s), and process that input, perhaps lighting an LED, when the switch is pressed, or toggling its state.To rely/assume the teacher will already know about this issue and/or have read the entire, very long datasheet and/or will have carefully read/checked the errata, is (opinions can vary), a bad (or even terrible) idea.That is just one example, out of millions (and probably a lot more), on how this situation could easily cause undesirable effects.Yes, technically speaking it can be sorted out, with appropriate hardware changes, IF YOU KNOW ABOUT THIS PROBLEM, in advance.But (opinions can vary) I seriously doubt, everyone will know about it, or do the due diligence (check the errata etc).

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 07, 2024, 09:55:56 pm
content: I consider both issues found so far (susceptibility of the internal buck converter and this IO problem) pretty "severe" to consider it for any serious use and can't see how it can be sold as is as a part for any commercial product.For hobbyist use, as long as you follow the workarounds, that should be usable.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 08, 2024, 01:17:40 am
content: Quote from: MK14 on September 07, 2024, 04:43:17 pmThe pin current source effect only really impacts light pulldown designs.i2c use will be fine, which is to me a key reality check.Even open-drain RC monostable type delays are ok, as the assist source current only appears after the pin passes the logic threshold.Their graphs are a little suss, (too few points & poor correlation to pin state ) but it looks very similar to the classic 8051 quasi bidirectional port.Billions of those parts shipped, and continue to be used.Newer 8051 variants have more port controls so users can enable/disable the quasi bidirectional action.Note the PFET nearest the PIN, has input positive feedback so a held low pin has no Icc current, but a rising pin gets an acceleration when the threshold is reached.Any light pulldown needs to briefly overcome that upward assist.80C51 Port Pin designQuote from: MK14 on September 07, 2024, 04:43:17 pmThat's cool. You are entirely free to never use it then.

author: brucehoult
author_rank: Super Contributor
timestamp: September 08, 2024, 01:34:39 am
content: Quote from: SiliconWizard on September 07, 2024, 09:55:56 pmI would have thought the other way around. Professionals embedding it inside something else, which they are designing, should be capable of designing so as to avoid the problems. It's non-ideal, but then so are transistors!It's hobbyists who are far more likely to run into problems. Especially as they probably don't read the manual in full.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 08, 2024, 01:36:14 am
content: This is how Atmel specify the Port pins, Raspberry Pi should include a similar pin diagram and pin spec.NoteAtmel AT89LP51 ITL Logic 1 to 0 Transition Current VIN = 2V, VDD = 5V ± 10% MAX -750 μARaspPi say 8k2 pulldown is ok, so that suggests the RP2350 has a3v3 ITL Logic 1 to 0 Transition Current MAX -150 μA

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 08, 2024, 01:48:55 am
content: Quote from: SpacedCowboy on September 07, 2024, 09:01:26 pmThey are prone to be very wordy !I had trouble following what they were trying to say, until I saw the current plots. It's a light regenerative P-FET.It means inputs with any external pullups will work, they do not need to be 10k.Any pull down needs to exceed the pin supplied current ITL Logic 1 to 0 Transition Current MAX -150 μAie even a somewhat feeble optocoupler will be ok. Transistors, MOSFETS and i2c parts will all be fine.Someone using ESD protection resistors should use less than the 8k2, to give themselves some noise margin.eg a 4k7 resistor will pull low with 0.5V of VOL or ground differential.

author: MK14
author_rank: Super Contributor
timestamp: September 08, 2024, 02:06:32 am
content: Quote from: PCB.Wiz on September 08, 2024, 01:17:40 amI have to admit, I don't yet properly/fully understand (technically), this fault mechanism. So I accept, I could easily be badly over-estimating how much of an issue, it really is.In the past, when there use to be chips (very early CMOS ones, come to mind), that could latch up, if even slightly abused. I remember (hearing), it caused nothing but problems and annoyances. Resulting in later chips, boasting that they were 'Latchup free'.It is NOT so obvious, even if I did more fully understand the fault, when and how, in real life situations. It would cause a problem/issue.

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: September 08, 2024, 02:28:03 am
content: Quote from: PCB.Wiz on September 08, 2024, 01:48:55 amYeah, I didn't mean to specify you needed 10k pull-ups - 10k is my go-to standard for a light pull-up on something active-low. Somehow that translated to "you must use 10k" between my brain and the keyboard....Agreed on the 4K7, in fact that's what I changed my 10k pull-downs to.Also agreed on the wordiness. But I prefer wordy to overly-laconic, which some data sheets are IMHO.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 08, 2024, 02:35:00 am
content: Quote from: MK14 on September 08, 2024, 02:06:32 amTheir very wordy prose does not helpGo straight to the graphs, where it becomes much clearer.Quote from: MK14 on September 08, 2024, 02:06:32 amLatchup is more serious, it is a crowbar parasitic SCR that appears across the supply rails. These days, it takes hundreds of mA to trigger it.I know some alarm companies who insist on power removal watchdogs, as simply firing the reset pin does not recover from all failure modes.Quote from: MK14 on September 08, 2024, 02:06:32 amIt only sources current ( < 150uA), so only has an effect on light pulldown cases, that might struggle to counter that 150uA.i2c, N-MOSFET, NPN transistor and even a PNP emitter follower can drive the pin low ok.eg someone may have designed a keypad matrix with (high) 10k ESD resistors, what would work on a CMOS input but not work here, without a value change, to lower the sum < 8k2.

author: MK14
author_rank: Super Contributor
timestamp: September 08, 2024, 03:05:16 am
content: Quote from: PCB.Wiz on September 08, 2024, 02:35:00 amThanks!That was VERY helpful.Now you mention it, I remember it better now. Yes, the CMOS latch-up, would (attempt to) overheat, to destruction, the chip, if the power supply, and perhaps other factors would let it.Quote from: PCB.Wiz on September 08, 2024, 02:35:00 amThat makes me feel a lot better about it, and helps a lot with my understand of the problem, as well.I've also realized, most (maybe heading towards all), other MCUs, also have one or more typical issues, even if they are working and designed, 100% perfectly in every way.Which is, that (current technology, as well as many technologies in the past), doesn't handle floating inputs, at around half the supply voltage, well/perfectly. As it tends to make both the top and bottom FETs conduct at the same time (shoot-through).At best it can just cause excessive power consumption, of perhaps a few milliamps (extra), instead of microamps or less, at other voltage levels.But at its worst, it may be able to cause unintended functional changes (off-hand, I'm not 100% sure).With the 'big' (full) Raspberry Pi's, there have been various, 'first release version', faults/bugs/issues, in many cases.Such as (IIRC) USB-C power-adapter incompatibilities, with ones (power adapters) from high end phones.One which had a light sensitive chip (as it didn't have any covering), which had some effect(s). I think EEVblog, did a video about it. I can't remember, quickly, what issue(s) it caused.Early edition Pico's, had error(s), or missing, floating point, built in ROM libraries (missing floating point doubles library?).

author: brucehoult
author_rank: Super Contributor
timestamp: September 08, 2024, 04:57:12 am
content: Quote from: MK14 on September 08, 2024, 02:06:32 amWell, for example if you wire a switch/button from the input pin to Vcc, and use either internal pull-down or a weak external pull-down to make a lo input when the switch is open.If you put a 2nd resistor in series with the switch. comparable to the pull-down resistor, and take the input from the junction of the two resistors, then you won't be pulling the input hi hard enough to make it latch up. Anything from maybe 40% to 80% of Vcc should be fine.

author: MK14
author_rank: Super Contributor
timestamp: September 08, 2024, 08:06:56 pm
content: Quote from: brucehoult on September 08, 2024, 04:57:12 amThanks, that has improved my understanding of the situation a lot. I didn't realize, that this issue, varied at various voltage levels, between 0 and 3.3 V. Partly because of lack of time spent in my studying of the issue and partly because the information available, is not that easy to understand.EDIT: Complete rewrite of post, previous one was too long, and had unnecessary details.

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2024, 03:59:15 am
content: Quick Update, on Errata E9:Some seem to be saying, that they are determining, if it can be sorted, by a quick fix (just the metal layers?), or will take major reworking.Which will affect, how long it takes to create and roll out, fixed chips. Estimates (if it is a big fix), seem to go as high as 2 years. Presumably because of the time to redesign, check, new masks etc, then go through all the chip producing and packaging stages. Then eventually reaching the shelves, again.Not to mention, enormous costs as well.There is also, lots of bickering, as to how often, this problem will occur in practice, and how easy, it is to fix. Especially with some designs/needs, being sensitive to the 120 microamps of input current, pulling it towards about 2 volts, in some circumstances. E.g. unbuffered analogue circuitry.Also, concerns about it leading to too high current consumption, due to all the stronger pulldown resistors (where needed), wasting power, if running on small batteries.EDIT: Information based on reading various forum and similar posts. So not 100% confirmed. But, I find it interesting, until we get later official announcements, about what is going to happen.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: September 10, 2024, 10:07:41 am
content: Quote from: MK14 on September 10, 2024, 03:59:15 amIt does not pull toward 2 volts.Think of it as half a pin keeper, that canonlypull up, when above the threshold.Once pulled down, to below the threshold there is no current adder.

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2024, 10:24:44 am
content: Quote from: PCB.Wiz on September 10, 2024, 10:07:41 amWell, the following thread, with details of practical examples, and a number of oscilloscope traces. Doesn't seem to fully agree with what you just seemed to say at a quick glance (or a much longer one, as I try and digest, all this information, and summarize it).I wish I had one (or some) now, so I could play around with the I/O and find out. Because, they are very interesting (at least to me), even just as a somewhat powerful (for the money), MCU, as long as you don't try and do too much with the inputs, as regards errata E9.EDIT: Sorry, here it is:https://community.element14.com/products/raspberry-pi/f/forum/55046/rp2350-gpio-pull-down-latching-bug/223658EDIT2: If anyone hasn't got the time or interest to look at that thread, my quick summary, is:When the input(s), are setup in such a way, that they can exhibit the bug/fault. Sweeping the input, across its range, via a 10k resistor, and watching it with an oscilloscope, seem to show it at certain voltages, to varying extents, sourcing or sinking currents, when it SHOULD NOT be, in a worrying manner, not fully described by the errata E9, at around or before, the time they made their post.

author: newbrain
author_rank: Super Contributor
timestamp: September 10, 2024, 11:20:50 am
content: Quote from: excerpt from MK14's post on September 10, 2024, 10:24:44 amI do not see any current sinking. In the scope traces, the voltage isalwaysabove the sine, indicating that the pin is sourcing current into the generator, never the opposite.

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2024, 11:27:38 am
content: Quote from: newbrain on September 10, 2024, 11:20:50 amIf you look at the picture (from the thread I linked to), in the middle of the picture, the sine wave, seems to be (suddenly, at perhaps 1.5 V) dragged down (i.e. the input would be sinking current).EDIT: Also, on reflection. It is suddenly dropping by around 1 centimeter (crude monitor screen measurement/estimate), which is about a volt, so for a 10k ohm resistor, should represent a current change of around 100 microamps, which sounds about right. I presume, it is caused by the hysteresis mechanism coming into play (switching states) or something like that.

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2024, 11:45:31 am
content: I've changed my mind. Maybe you were right.Perhaps what I'm seeing, is the input suddenly, pulling 100 microamps, LESS source current. Confusing me.

author: newbrain
author_rank: Super Contributor
timestamp: September 10, 2024, 11:47:29 am
content: Quote from: MK14 on September 10, 2024, 11:27:38 amStill, it does not go anywhere under what the sine should have been, as the crude picture I put together shows.So, no sinking.Quote from: MK14 on September 10, 2024, 11:45:31 amGreat! but I made the picture, so here's the post nonetheless

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2024, 11:51:55 am
content: Quote from: newbrain on September 10, 2024, 11:47:29 amThat trace (picture), was EXACTLY! what I wanted.Ideally I'd have set a scope (none of these scope traces were done by me), to capture both the unaffected sine wave and the messed around one, and then show both on the screen (by storing and recalling one trace), to better see what is really going on.

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2024, 12:01:58 pm
content: Quote from: PCB.Wiz on September 10, 2024, 10:07:41 amSorry, you were right, that is what it looks like.Remark(s) by people in the other thread, and the way, some of the oscilloscope trace(s) look, confused me.That misshapen sine wave, seems to have a number of defects/distortions applied to it. Which at a quick and simple (initial) glance, makes it look like various/funny sourcing and sinking of current, at various points, taking place.I now stand corrected, by yourself, Newbrain (and me, as I eventually noticed myself, as well).

author: tszaboo
author_rank: Super Contributor
timestamp: September 10, 2024, 02:03:30 pm
content: Anyway, I suggest changing the topic title from "now has extra RISC-V cores" to "now has extra Errata issues".

author: MK14
author_rank: Super Contributor
timestamp: September 10, 2024, 02:15:30 pm
content: Quote from: tszaboo on September 10, 2024, 02:03:30 pmI've been wondering, what smart and clever, nifty external circuits, could be built. Without utilizing its CPUs or inbuilt feature set. Just by utilizing, the input(s) set to their problematic mode, then putting some passive(s) around it, to exploit its voltage/current characteristics, to make things.Maybe the latching effect, would make a nice monostable timer.Perhaps a comparator, related circuit, with one of its pins, preconnected internally to 1.5 V to 2.2 V.A bit like the old radio circuits, in some electronics magazines, that could reportedly been made from the first generation ('A'), of 4000 series CMOS logic gates (hex inverters, or maybe it was (6) straight, non-inverting buffers?, IIRC).Until the later, 'improved' B series, with an (IIRC) extra internal transistor (per logic device/gate/inverter), and (not sure if the following also affected it, IIRC) improved EMC (static) protection, stopped it from working, viably, as the gain effect capability, almost completely disappeared.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 10, 2024, 09:51:08 pm
content: Quote from: brucehoult on September 08, 2024, 01:34:39 amVery much a matter of perspective. Sure, as a professional you're more likely to understand the errata and implement appropriate workarounds, but (usually) the end result is much more critical than any hobby project.If you kill a $1 MCU as a hobbyist or some parts of your board because you didn't closely follow the errata, that's not a big deal. Forums will just flood with topics about this and countermeasures will be spread relatively quickly. Sure, it may (or not) give this MCU a bad rep in the hobbyist market, but the silicon bugs are there already anyway and the RPi will have to deal with the hobbyist market appropriately if that matters to them.As a professional, even though the workarounds seem straightforward, that still doesn't look good and doesn't inspire confidence. I have actually used the RP2040 in one commercial project with no failure so far. It had no real issues other than a meh ADC. Potential latch-up, though, is bad. I hadn't seen a single modern, commercial MCU (seen that on ASICs for student projects though for sure) with this kind of issue in a long time.The workaround will often imply an increased power consumption, which may or may not be a problem. (But it may.) It also pretty much prevents using internal pull-ups, so requires additional passives. Finally, while the workaround is straightforward and shouldn't leave much surprise, that's still a problem that may be lurking in ways that haven't yet been completely identified.The buck converter thing is even more concerning to me, as it's not (at least as far as I've personally read) clearly explained in details. It looks like an aggravated susceptibility to EMI, which obviously could be caused by other external factors than the orientation of its inductor. That doesn't look good. Of course, you still have the option to use an external rail (if I got it right), but that means having to add an external regulator. That's a pain.I don't know how sales and uses are all going to work out for this chip at this point. I'm a bit curious about that.

author: RAPo
author_rank: Super Contributor
timestamp: September 11, 2024, 03:17:36 pm
content: There is a new video on the (Windows) compiler front:https://youtu.be/e536gcOmMbc

author: MK14
author_rank: Super Contributor
timestamp: September 11, 2024, 05:24:36 pm
content: Quote from: RAPo on September 11, 2024, 03:17:36 pmI watched it a few hours ago. A bit over 10 minutes long. (Gary Explains).It is a good video.It basically shows you one way of (easily/quickly) correctly installing the latest and properly working (on windows) compiler systems, for both the Arm M33 and RISC-V cores, then repeats the (interesting) benchmarks.Which seem to show that this new RP2350 is generally around 1.5 to 2.5 times faster (on both Arm or RISC-V), than the previous (older/original) RP2040. Except for the new hardware floating point (including doubles now), which can give a 6 to 7 times speed up compared to the old version (RP2040), but no speed up for the RISC-V cores, which don't have access to the floating point hardware, or their own version.Apart from floating point (which is a lot, maybe x6 or x7 times slower, on the RISC-V, until it eventually gets its own floating point hardware, perhaps?, in the distant future), the RISC-V cores, are almost as fast as the Arm M33 ones, which I think is a very impressive achievement.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 11, 2024, 08:22:22 pm
content: Quote from: MK14 on September 11, 2024, 05:24:36 pmTheir RV core appears to be a RPi project if I got it right?https://github.com/Wren6991/Hazard3, rather than having used one of the existing open-source cores available.They claim a Coremark of 3.81/MHz, which is one of the (if not the) best performance among existing small RV32 cores. That's not bad!They wrote it in pure Verilog. I think the existing open-source RV FPUs are all more or less part of cores written in Chisel or SpinalHDL (don't remember which), so piggy-backing one of these in a pure Verilog project (while possible if you just reuse the Verilog output) may not make a lot of sense. And writing a decent FPU from scratch is not an easy task.Keep in mind you can actually run one RV core and one ARM core in parallel on this chip, so you can have the ARM core do all the heavy FP.

author: MK14
author_rank: Super Contributor
timestamp: September 11, 2024, 08:40:34 pm
content: Quote from: SiliconWizard on September 11, 2024, 08:22:22 pmRaspberry Pi made (or bought the rights to, I'm not sure), the double floating point unit, so they could have either duplicated it (but which may have exceeded their gate allowances), or digitally shared it between the cores (possibly, I don't know what technical difficulties, that would have created).But for many uses of the RISC-V cores (given most people will probably use the Arm M33's, anyway), either floating point is not important, or emulating one in software, is good and fast enough.I think the Raspberry Pi team, employed/hired/contracted (I'm not sure of the exact details), someone, (possibly a researcher, or similar), who had already created RISC-V cores (by copying and/or changing the readily available open ones). So it was not too difficult, for him to give them one, for their project.There do seem to be blogs and other information sources, with much more details, including the github pages, with those particular RISC-V cores, in it. I've only really somewhat quickly glanced at such things, rather than extensively read them.

author: westfw
author_rank: Super Contributor
timestamp: September 11, 2024, 11:13:34 pm
content: QuoteNote that it's a "double accelerator co-processor", not the full ARM double floating point hardware (which I guess is also a coprocessor. But significantly different.)

author: brucehoult
author_rank: Super Contributor
timestamp: September 12, 2024, 02:16:11 am
content: Quote from: MK14 on September 11, 2024, 05:24:36 pmYes, I agree that a single Raspberry Pi engineer, putting 20% of his time to making the RISC-V core, and ending up with something very very close to Arm's flagship M33 microcontroller core, is quite impressive.Note also that Coremark is just one benchmark, and it's close enough that there are quite likely to be other benchmarks or algorithms on which the RISC-V cores are faster than the Arm cores.I have a Pi Pico 2 sitting right in front of me, but I haven't yet used it. I should probably check a few other benchmarks, not least of course my own Primes one :-) (which I wrote in 2016 before I knew RISC-V existed, to compare Pi 3 and Odroid XU4&C2 and x86, but which tends to do quite well on RISC-V)

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 12, 2024, 02:28:54 am
content: Yep, pretty nice work for the RV32 core. I haven't looked deeply into the HDL, but wasn't under the impression that it was an evolution of something existing. It seems 100% original. Though again, haven't inspected it in much detail.@MK14: Regarding the FPU, I'm not sure what they implemented for the RP235X but a FPU is tightly-coupled to the core, so sharing it across two cores with completely different ISAs is probably hard enough/costly in terms of performance loss, that they haven't bothered. A FPU is not like a peripheral shared on some peripheral bus. Even if they had chosen to separate and "duplicate it", a FPU tailored for the ARM FPU instructions requires some non-trivial work to adapt it to RISC-V, and yes, we don't know about the licensing, they may have bought it and not even have the rights to do this.

author: radiolistener
author_rank: Super Contributor
timestamp: September 12, 2024, 05:23:56 am
content: It will be interesting to compare RP2350 board with thisSTM32H562RGT6board and see results as a table comparison - bench performance, float/double performance, ADC/DAC performance, power consumption, etc...

author: brucehoult
author_rank: Super Contributor
timestamp: September 12, 2024, 06:39:34 am
content: Quote from: SiliconWizard on September 12, 2024, 02:28:54 amI haven't looked at the HDL but I've read the manual for the core, trying to figure out where the performance comes from.- short 3-stage pipeline with just 1 cycle penalty on branches of course helps minimise stalls.- there is a tiny 1-entry BTB used only for taken backwards branches. i.e. inner loops. FE310, for example, has much more extensive branch prediction but doesn't perform as well on Coremark- single-cycle multiplier is in fact quite a huge benefit in Coremark. To an unrealistic extent compared to most code I'd say, and all the other cores which have 3 or 4 cycle multipliers aren't wrong. Almost all code out there just wants barrel shift, or maybe shift-and-add, not full on multiply. And single-cycle multiply can limit the clock speed ... but this chip only has to do 155 MHz and on a fairly small 40nm process. In contrast FE310 with 4 cycle multiply was doing 320 MHz on 180nm, and FU540 1.5 GHz on 28nm.- it does register access in the instruction fetch stage, as the RISC-V encoding makes easy but Arm doesn't. The two register contents are already available at the start of the X (2nd) pipeline stage, as I believe is the EQ/LT/LTU comparison between them.- there is an option to have a 2nd ALU that does only EQ/LT/LTU for branches with I think the result available a cycle earlier. It's interesting that RISC-V has *only* register-to-register comparisons (with, as mentioned above, register access started very early), not register-to-constant comparisons (except for the Zero register), so you don't have to wait for decoding of the instruction format and the various immediate formats. SLTI/SLTIU use the immediate from the instruction, but are only in the main ALU, a cycle later. EQ/LT/LTU with a boolean output is also a simpler computation than full subtraction. I assume the RP2350 has that option.

author: SiliconWizard
author_rank: Super Contributor
timestamp: September 12, 2024, 09:45:29 am
content: Interesting. Yep, the single-cycle multiplier certainly makes a significant difference with Coremark. With my own core (which ended up as a 6-stage with good branch prediction and a comfy BTB), I was getting about 3 Coremark/MHz and that fell down to about 2.5 when I made the multiplier 3-cycle (to increase Fmax).Register access at the instruction fectch stage looks interesting.

author: exe
author_rank: Unknown
timestamp: September 12, 2024, 10:40:49 am
content: Quote from: SiliconWizard on September 12, 2024, 09:45:29 amDid you just make own CPU? How did you do that?

author: brucehoult
author_rank: Super Contributor
timestamp: September 12, 2024, 11:08:10 am
content: Quote from: exe on September 12, 2024, 10:40:49 amIn recent years hundreds of people (maybe thousands) have designed their own CPU cores for use in the increasingly cheap and capable FPGAs that have become available.Some have invented their own instruction set at the same time, but most are now using the RISC-V instruction set as it is (in RV32I form) very simple to implement, legal to share the results, and there is a large and growing body of software to run on them, so you can take ready-made open source assemblers, compilers, libraries, RTOSes etc rather than having to do all that yourself too. Even full Linux is possible on your own CPU.Getting real ASIC chips made is of course another thing altogether. There is Tiny Tapeout, but what you can do there isn't big enough for a full CPU.

author: coppice
author_rank: Super Contributor
timestamp: September 12, 2024, 11:55:38 am
content: Quote from: exe on September 12, 2024, 10:40:49 amMaking a working CPU is pretty easy for a moderately competent engineer. FPGAs can make the assembly and test process pretty fast these days. Making is great CPU - fast, dense, dense code, power efficient, etc. - is what is hard.

author: brucehoult
author_rank: Super Contributor
timestamp: September 12, 2024, 01:02:08 pm
content: Quote from: coppice on September 12, 2024, 11:55:38 amDMIPS/LUT is an interesting metric. (On a given FPGA family)VexRISCV is pretty good on this measure at 190 DMIPS from 816 LUTS on an Arty (i.e. Artix-7) with "small and productive" settings (RV32I, datapath bypass) That's 0.82 DMIPS/MHz at 232 MHz but it's best just to take the overall DMIPS as µarch and MHz are not independent variables.

author: i509VCB
author_rank: Contributor
timestamp: December 16, 2024, 03:36:22 am
content: Can't recall when it was updated, but the hardware design guide seems to name the previously unknown inductor as the AOTA-B201610S3R3-101-T

author: SiliconWizard
author_rank: Super Contributor
timestamp: December 16, 2024, 05:36:18 am
content: Does anyone know if the RPi is/is going to fix the IO bug in upcoming silicon revisions?

author: PCB.Wiz
author_rank: Super Contributor
timestamp: December 16, 2024, 07:46:20 am
content: Quote from: SiliconWizard on December 16, 2024, 05:36:18 amYou mean the pin-keeper action on IO ?They are unlikely to fix just that, as it is not a show stopper for 99% of uses, and the 1% can have a workaround.They may fix it, if they have other bugs to sweep.How is the overall errata looking ?

author: jnk0le
author_rank: Regular Contributor
timestamp: July 26, 2025, 06:44:18 pm
content: Quote from: jnk0le on August 14, 2024, 07:26:03 pmtaking that back.It can't dual issue arith+arith or L/S + arith like m55Only branches.https://github.com/jnk0le/random/blob/master/pipeline%20cycle%20test/doc/cortex_m33.md

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: July 27, 2025, 02:27:25 pm
content: Quote from: PCB.Wiz on December 16, 2024, 07:46:20 amThey apparently may make improvements after the hackathon results, so they might fix it then. Seejamesh’s reply

author: jnk0le
author_rank: Regular Contributor
timestamp: July 27, 2025, 03:05:23 pm
content: Quote from: SiliconWizard on September 11, 2024, 08:22:22 pmGCC 15 bumps it to 4.15 (4.25 with zbc)https://types.pl/@wren6991/114647537150065441

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2025, 04:43:59 pm
content: Quote from: jnk0le on July 27, 2025, 03:05:23 pmOh, yeah, but then it's pretty much down to compiled optimizations and it would be at least fair to compare with a Cortex-M4 and -M33 with the same compiler and options.I think Coremark recommends compiling at -O1 to have something that can be compared across multiple different cores, but in any case, one should always mention the compiler and optimizations used, otherwise comparing is a bit misleading.Bottom line anyway is that their RV core is definitely in the Cortex-M4 or even near -M33 territory, which is pretty good.

author: jnk0le
author_rank: Regular Contributor
timestamp: July 27, 2025, 07:06:34 pm
content: Quote from: SiliconWizard on July 27, 2025, 04:43:59 pm1 cycle branch and fully pipelined loads/stores is at m33 level, just lacking the FPU and DSP insns.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2025, 07:41:00 pm
content: Yes, no FPU unfortunately, but I'm sure they added those RV cores to get their feet wet. Surely with a FPU and vector extension, it would be a killer.And... everyone is free to use this core in their own design. It's under the Apache 2.0 license, pretty liberal one.

author: brucehoult
author_rank: Super Contributor
timestamp: July 28, 2025, 03:11:37 am
content: Quote from: SiliconWizard on July 27, 2025, 04:43:59 pmAnd it's the work of one engineer, apparently as his "20%" project, not even full time.

author: ejeffrey
author_rank: Super Contributor
timestamp: July 28, 2025, 03:23:29 am
content: Quote from: brucehoult on September 12, 2024, 01:02:08 pmAnyone know how many LUTs the hazard3 core uses in something like the 7 series or ultrascale? I'm curious how this compares to cores designed with fpgas as the primary target.

author: brucehoult
author_rank: Super Contributor
timestamp: July 28, 2025, 03:35:42 am
content: Quote from: ejeffrey on July 28, 2025, 03:23:29 amIt's got quite a lot of options, so it's hard to give one figure and you should probably pick the config with exactly the things you need and synthesise it yourself.I'm a little surprised to see it's not yet supported in litex.Can also ask @wren6991 on twitter.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 28, 2025, 03:32:16 pm
content: Yes, it seems to have remained "below the radar" at this point. But I wouldn't be surprised if some chinese companies, which are much more active in the RV adoption, hadn't already been working on using it in one of their new chips.

author: jnk0le
author_rank: Regular Contributor
timestamp: July 29, 2025, 06:50:35 pm
content: A4 revision is out:https://www.raspberrypi.com/news/rp2350-a4-rp2354-and-a-new-hacking-challenge/

author: SpacedCowboy
author_rank: Frequent Contributor
timestamp: July 29, 2025, 07:45:22 pm
content: So the GPIO is fixed, which is awesome.The 5v tolerance is called out...QuoteI'm not seeing that's any different to before (you still have to have VDDio powered to (say) 3.3v), but maybe they're just saying it's now "qualified" rather than "we think this works".Of course, this is announced just after I bought 100 of the darn things

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 29, 2025, 08:57:40 pm
content: Great. Now of course you'll have to be careful about getting A4 and not A2, for which there must still be significant stock.

author: ataradov
author_rank: Super Contributor
timestamp: July 29, 2025, 09:05:15 pm
content: They said that they actually removed A2 from the channel. It does not exclude from secondary distributors having them, but all main distributors will have A4.And strangely enough, they said that there are going to be 30k Pi Pico using A3, which will not be sold as a standalone device.

author: macaba
author_rank: Regular Contributor
timestamp: July 30, 2025, 10:21:56 am
content: Appendix C of the datasheet reveals some detail here.Of the 19 changes made between A2 and A4, 16 of them are in the A3 stepping, including the input leakage current, so A3 is a large improvement.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 30, 2025, 12:35:00 pm
content: Quote from: macaba on July 30, 2025, 10:21:56 amYes, the new datasheet just got released yesterday.There's actually NO hardware change from A3 to A4, only bootrom changes.

author: MK14
author_rank: Super Contributor
timestamp: July 30, 2025, 01:07:31 pm
content: Unfortunately, as far as I can tell (and I've got it researched for, via a research agent). No (UK) seller, is currently declaring guaranteed A4 stepping, RP2350 and similar, development boards. Such as the Pico2 and Pico2 W.But as time goes on (probably weeks and months), as the existing stocks of A2 stepping chips, sells off. Suppliers will start stocking A4 stepping devices and boards.It is interesting about the A3 stepping, but I'd prefer to get the actual A4 stepping, and ignore A2/A3, even though for many applications, they will (in theory) be fine.I've been 'burnt' in the past, with duff/faulty early stepping MCUs/CPUs etc. So try, very hard to avoid getting 'faulty' steppings. Such as (too) early arm MCUs or X86 chips, with faults in the earliest stepping.E.g. I bought the original RP2040's (PICO's), which was missing the fast (at the time), in-built floating point double library feature. As it was missing from the original ROM set, or similar. Not the end of the world, but somewhat annoying though. As it means I can't exploit (use) that feature.

author: PCB.Wiz
author_rank: Super Contributor
timestamp: July 30, 2025, 10:44:38 pm
content: The logical thing to do here, is to have thefull part number RP2350A0A4as a stock code (SiLabs do this)A search does find some in stock, but not manyhttps://octopart.com/search?q=RP2350A0A4&currency=USD&specs=0

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 31, 2025, 12:15:41 am
content: Yes, it's barely out. Just a little patience...

author: newbrain
author_rank: Super Contributor
timestamp: July 31, 2025, 08:49:40 am
content: Quote from: SpacedCowboy, abridged by me on July 29, 2025, 07:45:22 pmI agree, I welcome the additional guarantee, but the datasheet always supported 5 V operation, in my reading (with IOVDD present).Checking with thevery first version (2024-08-08 15:36:51)found on Wayback Machine, the FT pin description (14.8.2.1) used to say:QuoteThe text inboldwas removed the very same day - without a revision change! - and has been reintroduced in the latest released version (2025-07-29).Nothing in the Absolute Maximum Rating and IO electrical characteristics chapters has ever changed in all the other revisions, AFAICS.If the FT pins were not qualified for 5 V operation (again, with the IOVDD caveat), why did VIHalways showed a 5.5 V maximum in the normal operating conditions section?Though I like this chip a lot, I'm not a fan of this or the RP2040 DS, it ranges from confusing to just a copy of the IP description and skimps on many electrical characteristics (e.g.: slew rate?).

author: tszaboo
author_rank: Super Contributor
timestamp: July 31, 2025, 03:06:52 pm
content: Ah the RP2354 is out with the built in flash, nice.I wasn't really interested in using these chips before. If you couldn't get the right flash memory, to be able to run your python code, you would've needed to fork the micropython, change flash settings and recompile it. I would rather stick a fork deep into my hand. So this solves that, nice.