[HN Gopher] I got almost all of my wishes granted with RP2350
___________________________________________________________________
I got almost all of my wishes granted with RP2350
Author : elipsitz
Score : 393 points
Date : 2024-08-08 13:03 UTC (9 hours ago)
(HTM) web link (dmitry.gr)
(TXT) w3m dump (dmitry.gr)
| elipsitz wrote:
| Can't find an official announcement or datasheet yet, but
| according to this post:
|
| * 2x Cortex-M33F * improved DMA * more and improved PIO *
| external PSRAM support * variants with internal flash (2MB) and
| 80 pins (!) * 512KiB ram (double) * some RISC-V cores? Low power
| maybe?
|
| Looks like a significant jump over the RP2040!
| zrail wrote:
| This is pretty exciting. Can't wait for the datasheet!
| dave78 wrote:
| Pico 2, using the 2350, seems to be announced:
|
| https://www.raspberrypi.com/products/raspberry-pi-pico-2/
| jsheard wrote:
| Only $1 more than the original Pico, that's an absolute
| steal. Although the Pico2 doesn't have PSRAM onboard so
| there's room for higher end RP235x boards above it.
| HeyLaughingBoy wrote:
| Make one in an Arduino Uno form factor and double the price
| and they'd make a killing :-)
|
| I try to dissuade n00bs from starting their arduino journey
| with the ancient AVR-based devices, but a lot of the
| peripherals expect to plug into an Uno.
| moffkalast wrote:
| Well there's the UNO-R4 Renasas I suppose, but this would
| be much cooler indeed. There's also the 2040 Connect in the
| Nano form factor with the extra IMU.
| ta988 wrote:
| Look at the adafruit metro then. They just announced the
| rp2350 version
| repelsteeltje wrote:
| ... And RP2354A/B even has 2MB _built in_ flash!
| KaiserPro wrote:
| I'm hoping that its got much better power management. That
| would be really cool for me.
| jsheard wrote:
| Speak of the devil: https://news.ycombinator.com/item?id=41156743
|
| Very nice that the "3" turned out to mean the modern M33 core
| rather than the much older M3 core. It has a real FPU!
| dmitrygr wrote:
| Yes, well-guessed
| RA2lover wrote:
| Is there any info on the analog capabilities compared to the
| RP2040?
| TomWhitwell wrote:
| Looks like 4 x ADC channels again, no on-board DAC
| RA2lover wrote:
| the 80-pin version has 8.
| limpbizkitfan wrote:
| Is there an exhaustive list of stm32h7 errata? Has anyone
| compiled a defect list?
| dmitrygr wrote:
| STM has an inexhaustible list of them, but does not list at
| least a few QSPI ones that I am aware of. :/
| limpbizkitfan wrote:
| >:( hoping to play with a pico 2 soon so I can convince my
| team to move off stm32h7
| zrail wrote:
| Looks like the SDK got updated a couple hours ago:
|
| https://github.com/raspberrypi/pico-sdk/commit/efe2103f9b284...
| blackkat wrote:
| Some specs here: https://www.digikey.ca/en/product-
| highlight/r/raspberry-pi/r...
|
| Based on the RP2350, designed by Raspberry Pi in the United
| Kingdom
|
| Dual Arm M33s at 150 MHz with FPU
|
| 520 KiB of SRAM
|
| Robust security features (signed boot, OTP, SHA-256, TRNG, glitch
| detectors and Arm TrustZone for Cortex(r)-M)
|
| Optional, dual RISC-V Hazard3 CPUs at 150 MHz
|
| Low-power operation
|
| PIO v2 with 3 x programmable I/O co-processors (12 x programmable
| I/O state machines) for custom peripheral support
|
| Support for PSRAM, faster off-chip XIP QSPI Flash interface
|
| 4 MB on-board QSPI Flash storage
|
| 5 V tolerant GPIOs
|
| Open source C/C++ SDK, MicroPython support
|
| Software-compatible with Pico 1/RP2040
|
| Drag-and-drop programming using mass storage over USB
|
| Castellated module allows soldering directly to carrier boards
|
| Footprint- and pin-compatible with Pico 1 (21 mm x 51 mm form
| factor)
|
| 26 multifunction GPIO pins, including three analog inputs
|
| Operating temperature: -20degC to +85degC
|
| Supported input voltage: 1.8 VDC to 5.5 VDC
| synergy20 wrote:
| Wow, can't wait. Love the 5V GPIO and security features.
| Daneel_ wrote:
| 5V GPIO is a huge deal for me - this immediately opens up a
| huge range of integrations without having to worry about line
| level conversion.
|
| I can't wait to use this!
| azinman2 wrote:
| Does tolerant mean ok to do? Or it just won't fry your chip
| but you should actually run at 3.3?
| tredre3 wrote:
| It usually means it's clamped so it might result in a
| small amount of wasted energy/heat but no damage.
|
| So yes it means it's okay but if you can you should go
| for 3.3.
| murderfs wrote:
| 5V tolerant means that it'll accept 5V input (and
| correctly interpret it as high), but output will still be
| 3.3V.
| HeyLaughingBoy wrote:
| Be careful with assumptions though. Being 5V tolerant
| doesn't mean that your 3V output can sufficiently drive an
| input that expects 0-5V levels correctly.
|
| I ran into this problem using an ESP32 to drive a Broadcom
| 5V LED dot-matrix display. On paper everything looked fine;
| in reality it was unreliable until I inserted an LS245
| between the ESP and the display.
| lloydatkinson wrote:
| > LS245
|
| Do you think that would be a good IC to drive these with
| a RP2040? https://www.analog.com/en/products/max7219.html
| HeyLaughingBoy wrote:
| A better question might be why anyone is using a MAX7219
| on a new design in 2024. There are so many other choices
| for displays than a 20 year-old IC from a company that's
| gone through two changes of ownership since.
|
| Anyway, a 74LS245 isn't a level shifter, it's an octal
| buffer. It just happened to be the right choice for my
| needs. In your application, I'd suggest an actual level
| shifter. You can find level shift breakout boards at
| Sparkfun and Adafruit.
| irdc wrote:
| > Being 5V tolerant doesn't mean that your 3V output can
| sufficiently drive an input that expects 0-5V levels
| correctly.
|
| It's fine for TTL (like your 74LS245 is), which registers
| voltages as low as 2V as a logical 1. Being able to
| directly interface with TTL eases up so many
| retrocomputing applications.
| my123 wrote:
| Hazard3 RTL: https://github.com/Wren6991/Hazard3
| IshKebab wrote:
| I wonder how well it's been verified.
| moffkalast wrote:
| > Low-power operation
|
| Low power suspend? In a Pi Foundation product? Impossible.
| thomasdeleeuw wrote:
| Not sure why this is downvoted but the sleep and dormant pico
| examples have quite some issues, they are still in "extras"
| and not in "core", so while documentation of features is my
| personal favorite aspect of the pico, there is room for
| improvement here still.
| coder543 wrote:
| I'm having trouble seeing where the datasheet actually says the
| GPIO pins are 5V tolerant.
|
| EDIT: okay, section 14.8.2.1 mentions two types of digital
| pins: "Standard Digital" and "Fault Tolerant Digital", and the
| FT Digital pins might be 5V tolerant, it looks like.
| sowbug wrote:
| Page 13: "GPIOs are 5 V-tolerant (powered), and 3.3
| V-failsafe (unpowered)"
| coder543 wrote:
| Yep, I edited a few minutes ago to mention a reference I
| found in the datasheet. It's cool, but the reality seems a
| little more nuanced than that quote would indicate, since
| that only appears to work for GPIO-only pins, not just pins
| being used as GPIO. (So, if a pin supports analog input,
| for example, it will not be 5V tolerant.)
| jayyhu wrote:
| Edit: See comment below; The RP2350 _can_ be powered by a 5V
| supply.
| giantg2 wrote:
| I'd rather have it run on the lower voltage - generally
| easier to step down than buck up. Either way, the modules are
| pretty cheap, small, and easy to find.
| skykooler wrote:
| How much tolerance does that have - can it run directly off a
| 3.7v lithium ion battery?
| jayyhu wrote:
| Yep, they explicitly call out that the onboard voltage
| regulator can work with a single lithium ion cell.
| dvdkon wrote:
| The regulator can take that, but as far as I can see it's
| only for DVDD, the core voltage of 1.1 V. You also need
| at least IOVDD, which should be between 1.8 V and 3.3 V.
| So you'll need to supply some lower voltage externally
| anyway.
|
| I suppose the main draw of the regulator is that the DVDD
| rail will consume the most power. 1.1 V is also much more
| exotic than 3.3 V.
| Findecanor wrote:
| To clarify: You can connect a 5V power source by connecting
| it to the VSYS pin which leads into the on-board voltage
| regulator.
|
| But the uC itself runs on 3.3V and is not totally 5V-capable.
| You'd need _level converters_ to interface with 5V.
| jayyhu wrote:
| You're right, after re-reading the Power section on the
| datasheet it seems connecting 5V to the VREG_VIN should
| suffice to power the digital domains, but if you want to
| use the ADC, you still need a external 3.3V source.
| dvdkon wrote:
| Maybe not even that:
|
| > A separate, nominally 3.3 V, low noise supply
| (VREG_AVDD) is required for the regulator's analogue
| control circuits.
|
| It seems it would be painful trying to run this without
| 3.3 V.
| maccam912 wrote:
| Can anyone speak about plans for a Pico 2 W (or Pico W 2)? I've
| been playing around recently with mine and even just syncing with
| the current time over wifi opens up a lot of possibilities.
| coder543 wrote:
| Jeff Geerling said the Pico 2 W is coming later this year:
| https://youtu.be/oXF_lVwA8A4?t=445
| MarcScott wrote:
| It's in this post - https://www.raspberrypi.com/news/raspberry-
| pi-pico-2-our-new...
| katzinsky wrote:
| I suppose this isn't the first time a company that started out as
| a hobbiest board manufacturer produced really amazing micro
| controllers but man is it insane how far they've knocked the ball
| out of the park.
| synergy20 wrote:
| You can pick either ARM cores or RISC-V cores on the same die?
| Never saw design like this before. Will this impact price and
| power consumption?
|
| "The Hazard3 cores are optional: Users can at boot time select a
| pair of included Arm Cortex-M33 cores to run, or the pair of
| Hazard3 cores. Both options run at 150 MHz. The more bold could
| try running one RV and one Arm core together rather than two RV
| or two Arm.
|
| Hazard3 is an open source design, and all the materials for it
| are here. It's a lightweight three-stage in-order RV32IMACZb*
| machine, which means it supports the base 32-bit RISC-V ISA with
| support for multiplication and division in hardware, atomic
| instructions, bit manipulation, and more."
| bri3d wrote:
| This "switchable cores" thing has been appearing in some
| products for a few years now, for example Sipeed SG2002
| (LicheeRV). The area occupied by the actual instruction core is
| usually pretty small compared to peripherals and internal
| memories.
| zer00eyz wrote:
| The MilkV Duo also has this feature I believe...
| https://milkv.io/duo
| Teknoman117 wrote:
| It's the same SoC as the LicheeRV (SG2002)
| geerlingguy wrote:
| Apparently (this is news to me), you can also choose to run 1+1
| Arm/RISC-V, you don't have to switch both cores either/or.
|
| Eben Upton: "They're selectable at boot time: Each port into
| the bus fabric can be connected either to an M33 or a Hazard3
| via a mux. You can even, if you're feeling obtuse, run with one
| of each."
|
| Source:
| https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
| ravetcofx wrote:
| But not 2+2? That seems too bad to have each architecture run
| code based on their strengths for quad core workloads.
| simcop2387 wrote:
| Yea, i was hoping for 2+2 myself but I suspect it's because
| the setup doesn't have the ability to mediate peripherals
| between the cores in a way that'd let that work. I.e.
| trying to turn on both Risc-v and arm #1 cores means that
| there'd be bus conflicts. It'd be cool if you could disable
| the io on the risc-v cores and do all hardware io through
| arm (or vice versa) so you can use the unconnected ones for
| just pure compute tasks (say run ws2812b led strips with
| the arm cores but run python/javascript/lua on the risc-v
| cores to generate frames to display without interrupting
| the hardware io).
| nine_k wrote:
| Why not both: power distribution and cooling? Having to
| route twice as many wide buses, and put in twice as much of
| L0 caches?
| ebenupton wrote:
| We did look at this, but the AHB A-phase cost of putting a
| true arbiter (rather than a static mux) on each fabric port
| was excessive. Also, there's a surprising amount of impact
| elsewhere in the system design (esp debug).
| jaeckel wrote:
| Would've been cool for safety applications if the second core
| could be run in lockstep mode.
| 4gotunameagain wrote:
| afaik that is a whole different rodeo on the silicon level
| jononor wrote:
| This seems like a great way to test the waters before a
| potential full-on transition to RISC-V. It allows to validate
| both technically and market reception, for a much lower cost
| than taping out a additional chip.
| MBCook wrote:
| Fun for benchmarking too.
|
| You're limited to those two exact kinds of cores, but you
| know every other thing on the entire computer is 100%
| identical.
|
| It's not SBC 1 vs SBC 2, but they have different RAM chips
| and this one has a better cooler but that one better WiFi.
| GordonS wrote:
| My thoughts exactly - a risc-free (hurhur) way to get RISC-V
| in the hands of many, many devs.
| kelnos wrote:
| I do wonder if the unavailability of some of the security
| features and -- possibly a big deal for some applications --
| the accelerated floating point on the RISC-V cores would skew
| that experiment, though.
| numpad0 wrote:
| https://www.raspberrypi.com/products/rp2350/
|
| 4 variants? "A" and "B" variants in QFN60 and QFN80, "2350" and
| "2354" variants with and without 2MB Flash. CPU can be switched
| between dual RISC-V @ 150MHz or dual Cortex-M33 @ 300MHz by
| software or in one-time programming memory(=permanently).
|
| Datasheet, core switching details, most of docs are 404 as of
| now; I guess they didn't have embargo date actually written in
| `crontab`.
|
| e: and datasheet is up!
| doe_eyes wrote:
| I think it's a good way to introduce these chips, and it's a
| great project, but the author's (frankly weird) beef with STM32H7
| is detracting from the point they're trying to make:
|
| > So, in conclusion, go replan all your STM32H7 projects with
| RP2350, save money, headaches, and time.
|
| STM32H7 chips can run much faster and have a wider selection of
| peripherals than RP2350. RP2350 excels in some other dimensions,
| including the number of (heterogenous) cores. Either way, this is
| nowhere near apples-to-apples.
|
| Further, they're not the only Cortex-M7 vendor, so if the
| conclusion is that STM32H7 sucks (it mostly doesn't), it doesn't
| follow that you should be instead using Cortex-M33 on RPi. You
| could be going with Microchip (hobbyist-friendly), NXP (preferred
| by many commercial buyers), or a number of lesser-known
| manufacturers.
| dmitrygr wrote:
| 1. Nobody has a wider selection of peripherals than a chip with
| 3 PIOs.
|
| 2. And my beef is personal - I spent months ( _MONTHS_ of my
| life) debugging the damn H7, only to find a set of huge bugs in
| the main reason I had been trying to use it (QSPI ram support),
| showed it to the manufacturer, and had them do nothing. Later
| they came back and, without admitting i was right about the
| bugs, said that "another customer is seeing same issues, what
| was the workaround you said found?" I told them that i'll share
| the workaround when they admit the problem. Silence since.
|
| I fully reserve the right to be pissy at shitty companies in
| public _on my website_!
| doe_eyes wrote:
| I'm not arguing you can't be angry with them, I'm just saying
| that to me, it detracts from the point about the new
| platform. Regarding #1, I'm sure you know that peripherals in
| the MCU world mean more than just digital I/O. Further, even
| in the digital domain, the reason PIO isn't more popular is
| that most people don't want to DIY complex communication
| protocols.
| uticus wrote:
| [edit: I retract this, I see you've had secretly in your
| possession to play with for over a year. You lucky dog. ]
|
| > I have been anti-recommending STM's chips to everyone for a
| few years now due to STM's behaviour with regards to the
| clearly-demonstrated-to-them hardware issues.
|
| You certainly reserve the right. However it is unclear to me
| why the recommendation to complaints over a months-long
| period is a product that has just been released.
|
| Trying to ask in a very unbiased way since as a hobbyist I'm
| looking into ST, Microchip, and RP2040. For my part I've had
| two out of four RP2040 come to me dead on arrival, as part of
| two separate boards from different vendors - one being Pi
| Pico from Digilent. Not a ton of experience with Microchip
| but I hear they have their own problems. Nobody's perfect,
| the question is how do the options compare.
| limpbizkitfan wrote:
| I don't think the issue is QA related, ST released a chip
| that says it can perform X when the reality is it can not
| perform X.
| naikrovek wrote:
| they're complaining _now_ because they still feel the pain
| _now_. while writing the article, they 're thinking of how
| things would have been different on previous projects if
| they had had this chip, and that is digging up pain and
| they felt it should be expressed.
|
| I don't know what's so unclear. Have you never had a strong
| opinion about someone else's stuff? Man, I have.
| 15155 wrote:
| > 1. Nobody has a wider selection of peripherals than a chip
| with 3 PIOs.
|
| NXP FlexIO says "Hello!"
| Archit3ch wrote:
| > STM32H7 chips can run much faster
|
| STM32H7 tops out at 600MHz. This has 2x 300MHz at 2-3 cycles/op
| FP64. So maybe your applications can fit into this?
| spacedcowboy wrote:
| I'm seeing several statements of 2x300MHz, but the page [1]
| says 2x150MHz M33's..
|
| I know the RP2040's overclock _a lot_ but these are
| significantly more complex chips, it seems less likely they
| 'll overclock to 2x the base frequency.
|
| [1] https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-
| new...
| mrandish wrote:
| TFA states extensive 300Mhz OC with no special effort (and
| he's been evaluating pre-release versions for a year).
|
| _" It overclocks insanely well. I've been running the
| device at 300MHz in all of my projects with no issues at
| all."_
|
| Also
|
| _" Disclaimer: I was not paid or compensated for this
| article in any way. I was not asked to write it. I did not
| seek or obtain any approval from anyone to say anything I
| said. My early access to the RP2350 was not conditional on
| me saying something positive (or anything at all) about it
| publicly."_
| spacedcowboy wrote:
| Thanks, I missed that.
| 15155 wrote:
| The STM32H7 and other M7 chips have caches - performance is
| night and day between 2x300MHz smaller, cacheless cores and
| chips with L1 caches (and things like TCM, etc.)
|
| The SRAM in that H7 is running at commensurately-high speeds,
| as well.
|
| Comparing an overclocked 2xM33 to a non-overclocked M7 is
| also probably a little inaccurate - that M7 will easily make
| more than the rated speed (not nearly as much as the RP2040
| M0+, though.)
| mordae wrote:
| It's 6 cycles for dadd/dsub, 16 for dmul, 51 for ddiv.
| adrian_b wrote:
| As other posters have mentioned, this has 2 Cortex-M33 cores
| @ 150 MHz, not @ 300 MHz.
|
| Cortex-M7 is in a different size class than Cortex-M33, it
| has a speed about 50% greater at the same clock frequency and
| it is also available at higher clock frequencies.
|
| Cortex-M33 is the replacement for the older Cortex-M4 (while
| Cortex-M23 is the replacement for Cortex-M0+ and Cortex-M85
| is the modern replacement for Cortex-M7).
|
| While for a long time the Cortex-M MCUs had been available in
| 3 main sizes, Cortex-M0+, Cortex-M4 and Cortex-M7, for their
| modern replacements there is an additional size, Cortex-M55,
| which is intermediate between Cortex-M33 and Cortex-M85.
| limpbizkitfan wrote:
| ST is a zillion dollar company that should be hiring the talent
| capable of delivering product that match the features in their
| sales pamphlets. Integration is tricky but a company with STs
| deep pockets should be able to root cause or at least help
| troubleshoot an issue, not ask for a fix like some nepotism
| hire.
| HeyLaughingBoy wrote:
| They should also be hiring people that can write clearly in
| their datasheets, but here we are, so...
| kaycebasques wrote:
| Official news post: https://news.ycombinator.com/item?id=41192341
|
| Official product page:
| https://news.ycombinator.com/item?id=41192269
| kjagiello wrote:
| Datasheet:
| https://datasheets.raspberrypi.com/rp2350/rp2350-datasheet.p...
| dang wrote:
| Thanks! Macroexpanded:
|
| _Raspberry Pi Pico 2, our new $5 microcontroller board, on
| sale now_ - https://news.ycombinator.com/item?id=41192341 - Aug
| 2024 (71 comments)
| jonathrg wrote:
| Can someone explain the benefit of having essentially 4 cores (2
| ARM + 2 RISC-V) on the chip but only having 2 able to run
| simultaneously? Does this take significantly less die space than
| having all 4 available at all times?
| coder543 wrote:
| Coordinating access to the memory bus and peripherals is
| probably not easy to do when the cores weren't ever designed to
| work together. Doing so could require a power/performance
| penalty at all times, even though most users are unlikely to
| want to deal with two completely different architectures across
| four cores on one microcontroller.
|
| Having both architectures available is a cool touch. I believe
| I criticized the original RP2040 for not being bold enough to
| go RISC-V, but now they're offering users the choice. I'll be
| very curious to see how the two cores compare... I suspect the
| ARM cores will probably be noticeably better in this case.
| swetland wrote:
| They actually let you choose one Cortex-M33 and one RISC-V
| RV32 as an option (probably not going to be a very common use
| case) and support atomic instructions from both cores.
| coder543 wrote:
| All of the public mentions of this feature that I've seen
| indicated it is an either/or scenario, except the datasheet
| confirms what you're saying:
|
| > The ARCHSEL register has one bit for each processor
| socket, so it is possible to request mixed combinations of
| Arm and RISC-V processors: either Arm core 0 and RISC-V
| core 1, or RISC-V core 0 and Arm core 1. Practical
| applications for this are limited, since this requires two
| separate program images.
|
| That is fascinating... so, likely what dmitrygr said about
| the size of the crossbar sounds right to me:
| https://news.ycombinator.com/item?id=41192580
| moffkalast wrote:
| Did Dr. Frankenstein design this SoC? Igor, fetch me the
| cores!
| ebenupton wrote:
| It's aliiiiiive!
| geerlingguy wrote:
| It was also confirmed by Eben Upton in an interview in
| The Register[1], and I believe Adafruit's livestream also
| mentioned it.
|
| [1]
| https://www.theregister.com/2024/08/08/pi_pico_2_risc_v/
| dmitrygr wrote:
| cores are high bandwidth bus masters. Making a crossbar that
| supports 5 high bandwidth masters (4x core + dma) is likely
| harder, larger, and higher power than one that supports 3.
| ebenupton wrote:
| It's actually 10 masters (I+D for 4 cores + DMA read + DMA
| write) versus 6 masters. Or you could pre-arbitrate each pair
| of I and each pair of D ports. But even there the timing
| impact is unpalatable.
| blihp wrote:
| Beyond the technical reasons for the limit, it provides for a
| relatively painless way to begin to build out/for RISC-V[1]
| without an uncomfortable transition. For those who just want a
| better next iteration of the controller, they have it. For
| those who build tools, want to A/B test the architectures, or
| just do whatever with RISC-V, they have that too. All without
| necessarily setting the expectation that both will continue to
| coexist long term.
|
| [1] While it's possible they are envisioning dual architecture
| indefinitely, it's hard to imagine why this would be desirable
| long term esp. when one architecture can be royalty free and
| the other not, power efficiency, paying for dark silicon etc.
| networked wrote:
| I see a business decision here. Arm cores have licensing fees
| attached to them. Arm is becoming more restrictive with
| licensing and wants to capture more value [1]:
|
| > The Financial Times has a report on Arm's "radical shake-up"
| of its business model. The new plan is to raise prices across
| the board and charge "several times more" than it currently
| does for chip licenses. According to the report, Arm wants to
| stop charging chip vendors to make Arm chips, and instead wants
| to charge device makers--especially smartphone manufacturers--a
| fee based on the overall price of the final product.
|
| Even if the particular cores in the RP2350 aren't affected, the
| general trend is unfavorable to Arm licensees. Raspberry Pi has
| come up with a clever design that allows it to start
| commoditizing its complement [2]: make the cores a commodity
| that is open-source or available from any suitable RISC-V chip
| designer instead of something you must go to Arm for. Raspberry
| Pi can get its users accustomed to using the RISC-V cores--for
| example, by eventually offering better specs and more features
| on RISC-V than Arm. In the meantime, software that supports the
| Raspberry Pi Pico will be ported to RISC-V with no disruption.
| If Arm acts up and RISC-V support is good enough or when it
| becomes clear users prefer RISC-V, Raspberry Pi can drop the
| Arm cores.
|
| [1] https://arstechnica.com/gadgets/2023/03/risc-y-business-
| arm-...
|
| [2] https://gwern.net/complement
| tredre3 wrote:
| Each arm/riscv set likely share cache and register space (which
| takes most of the die space by far), resulting in being unable
| to use them both simultaneously.
| formerly_proven wrote:
| Considering that these are off-the-shelf Cortex-M designs I
| doubt that Raspi was able or would be allowed to do that. I'd
| expect most of the die to be the 512K SRAM, some of the
| analog and power stuff and a lot of it just bond pads.
| ebenupton wrote:
| That's correct. The Arm and RISC-V cores are entirely
| separate, sharing no logic.
| mmmlinux wrote:
| And still no USB C on the official devboard.
| jsheard wrote:
| There's plenty of alternatives right out of the gate, at least:
|
| https://www.raspberrypi.com/for-industry/powered-by/product-...
|
| Pimoroni has a maxed-out pin-compatible version with 16MB
| flash, 8MB PSRAM, and USB-C:
|
| https://shop.pimoroni.com/products/pimoroni-pico-plus-2
| moffkalast wrote:
| Unless the USB-C connector costs $7-10, these are beyond
| ridiculously overpriced compared to the official dev board.
| At least throw in an IMU or something if you plan to sell low
| volumes at high prices jeez.
| jsheard wrote:
| The cheapest one I've seen so far is the XIAO RP2350, which
| is $5, same as the official Pico board. I'm sure there will
| be more cheap options once more Chinese manufacturers get
| their hands on the chips, no-name USB-C RP2040 boards are
| ridiculously cheap.
| naikrovek wrote:
| > And still no USB C on the official devboard.
|
| Do you live in a universe where micro-USB cables are not
| available, or something? There's gonna be something or other
| that needs micro-USB for the next decade, so just buy a few and
| move on. They're not expensive.
|
| [later edit: I bet it has to do with backwards compatibility.
| They don't want people to need to rework case designs to use
| something that is meant as a drop-in replacement for the Pi
| Pico 1.]
| ewoodrich wrote:
| Personally I have about three dozen USB-A to USB-C cables
| lying around and the thought of actually spending money to
| acquire extra Micro USB cables in 2024 is very unappealing.
|
| I (deliberately) haven't bought a consumer electronic device
| that still uses Micro USB in years so don't accumulate those
| cables for free anymore like with USB-C.
|
| Of course ubiquitous USB-C dev boards/breakout boards without
| 5.1kO resistors for C-C power is its own frustration ... But
| I can tolerate that having so many extra USB-A chargers and
| cables. Trigger boards are great because they necessarily
| support PD without playing the AliExpress C-C lottery.
| wolrah wrote:
| > Do you live in a universe where micro-USB cables are not
| available, or something? There's gonna be something or other
| that needs micro-USB for the next decade, so just buy a few
| and move on. They're not expensive.
|
| I live in a universe where type C has been the standard
| interface for devices for years, offering significant
| advantages with no downsides other than a slightly higher
| cost connector, and it's reasonable to be frustrated at
| vendors releasing new devices using the old connector.
|
| It's certainly not as bad as some vendors of networking
| equipment who still to this day release new designs with
| Mini-B connectors that are actually officially deprecated,
| but it's not good nor worthy of defending in any way.
|
| > I bet it has to do with backwards compatibility. They don't
| want people to need to rework case designs to use something
| that is meant as a drop-in replacement for the Pi Pico 1.
|
| Your logic is likely accurate here, but that just moves the
| stupid choice back a generation. It was equally dumb and
| annoying to have Micro-B instead of C on a newly designed and
| released device in 2021 as it is in 2024.
|
| The type C connector was standardized in 2014 and became
| standard on phones and widely utilized on laptops starting in
| 2016.
|
| IMO the only good reason to have a mini-B or micro-B
| connector on a device is for physical compatibility with a
| legacy design that existed prior to 2016. Compatibility with
| a previous bad decision is not a good reason, fix your
| mistakes.
|
| Type A on hosts will still be a thing for a long time, and
| full-size type B still makes sense for large devices that are
| not often plugged/unplugged where the size is actually a
| benefit, but the mini-B connector is deprecated and the
| micro-B connector should be.
| bigstrat2003 wrote:
| Micro-B is fine. This is such an overblown non-issue I am
| shocked that people are making a big deal of it.
| kvemkon wrote:
| > 1 x USB 1.1 controller and PHY, with host and device support
|
| Sure, after integrating USB 2.0 HS or 1Gb-Ethernet the
| pico2-board will cost more than $5. So, integrated high-speed
| interfacing with PC was not a nice-to-have option (for special
| chip flavor)?
| solidninja wrote:
| I think the target here is low-power peripherals rather than
| speedy peripherals, and the price is very nice for that :)
| tecleandor wrote:
| Not off topic but a bit tangentially...
|
| How difficult would be emulating an old SRAM chip with an RP2040
| or an RP2350? It's an early 80s (or older) 2048 word, 200ns
| access time CMOS SRAM that is used to save presets on an old
| Casio synth. It's not a continuous memory read, it just reads
| when loading the preset to memory.
|
| I feel like PIO would be perfect for that.
| dmitrygr wrote:
| I did that, not just SRAM but also ROM, to fool a MC68EZ328
| successfully. It works well. PIO + DMA does it well.
| Specifically i replaced rom & ram in an old Palm Pilot with an
| RP2040:
|
| https://photos.app.goo.gl/KabVe5CrfckqnFEt7
|
| https://photos.app.goo.gl/LGAkp6HoYAJc3Uft7
|
| Edit: I did not yet update the rePalm article but much about
| that is in the Palm discord. https://discord.gg/qs8wQ4Bf
|
| see #repalm-project channel
| tecleandor wrote:
| Ooooh, that looks cool and the PCB seems simple (at least
| from this side). Congrats!
|
| Do you have anything published?
| HeyLaughingBoy wrote:
| If it's not an academic question and you have an actual need
| for the SRAM, what's the p/n? I have some old parts stock and
| may have what you need.
| tecleandor wrote:
| Oh! Thanks!
|
| I wanted to do a clone or two of said cartridges, that use,
| IIRC (I'm not in my workshop right now) a couple Hitachi
| HM6116FP each.
|
| I've also seen some clones from back in the day using a
| CXK5864PN-15L, that's 8 kilowords, and getting 4 switchable
| "memory banks" out of it...
| HeyLaughingBoy wrote:
| Thought I had more than this, but it's been literally
| decades...
|
| I found (1) HM6116, (4) HM65256's (1) HM6264 and wonder of
| wonders, a Dallas battery-backed DS1220, although after 20+
| years the battery is certainly dead. All in DIP packages of
| course.
|
| And a couple of 2114's with a 1980 date code! that I think
| are DRAM's.
|
| If any of this is useful to you, PM me an address and I'll
| pop them in the mail.
| swetland wrote:
| Lots of nice improvements here. The RISC-V RV32I option is nice
| -- so many RV32 MCUs have absurdly tiny amounts of SRAM and very
| limited peripherals. The Cortex M33s are a biiig upgrade from the
| M0+s in the RP2040. Real atomic operations. An FPU. I'm exited.
| fouronnes3 wrote:
| Curious about the low-power and sleep mode improvements!
| geerlingguy wrote:
| Me too; I had a little trouble with MicroPython lightsleep and
| deepsleep in the pre-release version I was testing.
|
| I will re-test and try to get better sleep state in my code
| either today or tomorrow!
| bschwindHN wrote:
| Alright, what's the max image resolution/framerate someone is
| going to pump out with the HSTX peripheral?
| SethTro wrote:
| This has 2 of the 3 features (float support, faster clock) + more
| POI that was keeping me on ESP32. For projects that need wifi,
| and can tolerate the random interrupts, I'll stick with ESP32.
| jononor wrote:
| Aha, the 3 is for M33, not Cortex M3 (as some speculated based on
| the name). That makes a lot more sense! Integrated FPU is a big
| improvement over the RP2040, and M33 is a modern but proven core.
| gchadwick wrote:
| This looks awesome a really great step up from the RP2040. I'm a
| big fan of the original and I'm excited to see all the
| improvements and upgrades.
|
| I imagine with the new secure boot functionality they've got a
| huge new range of customers to tempt to.
|
| Also exciting to see them dip their toe into the open silicon
| waters with the hazard 3 RISCV core
| https://github.com/Wren6991/Hazard3.
|
| Of course it they'd used Ibex https://github.com/lowrisc/ibex the
| RISC-V core we develop and maintain at lowRISC that would have
| been even better but you can't have everything ;)
| rowanG077 wrote:
| Would the pio now support sane Ethernet using rmii for example?
| nimish wrote:
| Gross, the dev board uses micro-USB. It's 2024! Otherwise amazing
| work. Exactly what's needed to compete with the existing giants.
| sowbug wrote:
| Perhaps the unfortunate choice of micro USB is to discourage
| real consumer products from being built with the dev board.
| user_7832 wrote:
| I wonder if it is more about simply shaving a few cents off.
| Full USB-C protocol implementation may be much more
| difficult.
| hypercube33 wrote:
| USB-C doesn't require anything special USB wise as it's
| decoupled from the versioned standard. It just has more
| pins and works with all modern cables. Ideally the cables
| won't wear out like Mini and Micro and get loosey goosey in
| the ports.
| ewoodrich wrote:
| Yep, a USB-C connector is more or less a drop in
| replacement for MicroUSB if you don't need USB3 or USB-
| PD. With one aggravating exception: it requires adding
| two 5.1kO pulldown resistors to be compatible with C-C
| cables. Thus signaling to a charger that the sink is a
| legacy non-PD device requesting 5V.
|
| Which is apparently an impossible ask for manufacturers
| of dev boards or cheap devices in general. It's
| _slightly_ more understandable for a tried and true dev
| board that's just been connector swapped to USB-C (and
| I'll happily take it over dealing with Micro) but
| inexcusable for a new design.
|
| My hope is Apple going USB-C only on all their charging
| bricks and now even C-C cables for the iPhone will
| eventually force Chinese OEMs to build standard compliant
| designs. Or deal with a 50% Amazon return rate for
| "broken no power won't charge".
| Brusco_RF wrote:
| As someone who just picked micro USB over USBC for a
| development card, there is a significant price and
| footprint size difference between the two.
| Findecanor wrote:
| For a device, USB-C requires two resistors that older USB
| ports don't.
|
| Declaring yourself as a host/device is also a bit
| different: USB-C hardware can switch. Micro USB has a
| "On-the-go" (OTG) indicator pin to indicate host/device.
|
| The USB PHY in RP2040 and the RP2350 is actually capable
| of being a USB host but the Micro USB port's OTG pin is
| not connected to anything.
| rvense wrote:
| Hm, I've used mine as a USB host with an adapter? Not
| sure of the details, I suppose OTG is the online/runtime
| switching and I was just running as fixed host?
| Findecanor wrote:
| For the _microcontroller_ however, the use in commercial
| products is encouraged.
|
| There are one-time programmable registers for Vendor,
| Product, Device and Language IDs that the bootloader would
| use instead of the default. It would be interesting to see if
| those are fused on the Pico 2.
| Teknoman117 wrote:
| I would assume it's in order to maintain mechanical
| compatibility with the previous Pico.
| janice1999 wrote:
| It saves cost and none of the features of USB-C (speed, power
| delivery etc) are supported. Makes sense.
| hoherd wrote:
| FWIW the Pimoroni Tiny 2040 and Tiny 2350 use usb-c, but as
| mentioned by other commenters, the cost for these usb-c boards
| is higher.
|
| I love having usb-c on all my modern products, but with so many
| micro-usb cords sitting around, I don't mind that the official
| Pico and Pico 2 are micro-usb. At least there are options for
| whichever port you prefer for the project you're using it in.
| nine_k wrote:
| USB-C is way more complicated, even if you're not trying to
| push 4K video or 100W power through it. The interface chip
| ought to be more complex, and thus likely more expensive.
|
| You can still find a number of cheap gadgets with micro-USB on
| Aliexpress. Likely there's some demand, so yes, you can build a
| consumer product directly on the dev board, depending on your
| customer base.
| nimish wrote:
| Chinese boards are both cheaper and have usb type c
| implemented correctly and in spec, so that's no real excuse
| for raspberry pi
| 15155 wrote:
| How are they "way more complicated?" You have to add two
| resistors and short another pair of DP/DM lines?
| nine_k wrote:
| Yes, indeed, I've checked, and apparently you don't need
| anything beyond this if you don't want super speed or power
| delivery (past 5V 3A).
|
| I did not realize how many pins in a USB-C socket are
| duplicated to make this possible. (For advanced features,
| you apparently still need to consider the orientation of
| the inserted cable.)
| Ductapemaster wrote:
| You can use a USB C connector with standard USB, no interface
| chip required. It's simply a connector form-factor change.
| ChrisArchitect wrote:
| Related:
|
| _Raspberry Pi Pico 2, our new $5 microcontroller board, on sale
| now_
|
| https://news.ycombinator.com/item?id=41192341
| weinzierl wrote:
| This is fantastic news. Is there information on power
| consumption? This is something that precludes a good deal of use
| cases for the RP2040 unfortunately and any improvements here
| would be good, but maybe the RP's are just not made for ultra low
| power?
| ebenupton wrote:
| Significant improvements to flat-out power (switcher vs LDO)
| and to idle power (low quiescent current LDO for retention).
| Still not a coin-cell device, but heading in the right
| direction.
| TaylorAlexander wrote:
| This is very exciting! For the last several years I have been
| developing a brushless motor driver based on the RP2040 [1]. The
| driver module can handle up to 53 volts at 30A continuous, 50A
| peak. I broke the driver out to a separate module recently which
| is helpful for our farm robot and is also important for driver
| testing as we improve the design. However this rev seems pretty
| solid, so I might build a single board low cost integrated single
| motor driver with the RP2350 soon! With the RP2040 the loop rate
| was 8khz which is totally fine for big farm robot drive motors,
| but some high performance drivers with floating point do 50khz
| loop rate.
|
| My board runs SimpleFOC, and people on the forum have been
| talking about building a flagship design, but they need support
| for sensorless control as well as floating point, so if I use the
| new larger pinout variant of the RP2350 with 8 ADC pins, we can
| measure three current signals and three bridge voltages to make a
| nice sensorless driver! It will be a few months before I can have
| a design ready, but follow the git repo or my twitter profile [2]
| if you would like to stay up to date!
|
| [1] https://github.com/tlalexander/rp2040-motor-controller
|
| [2] https://twitter.com/TLAlexander
| sgu999 wrote:
| > for our farm robot
|
| That peaked my interest, here's the video for those who want to
| save a few clicks: https://www.youtube.com/watch?v=fFhTPHlPAAk
|
| I absolutely love that they use bike parts for the feet and
| wheels.
| HeyLaughingBoy wrote:
| I have given some thought to a two-wheeled electric tractor
| for dealing with mud -- horse paddocks turn into basically a
| 1-foot deep slurry after heavy rain and it can be easier to
| deal with something small that sinks through the mud, down to
| solid ground than something using large floatation tires.
| Additional problem with large tires is that they tend to
| throw mud around, making everyone nearby even more dirty.
|
| I haven't actually built anything (been paying attention to
| Taylor's work, though), but I came to the same conclusion
| that bike wheels & tires would probably be a good choice. It
| also doesn't hurt that we have many discarded kids' bikes all
| over the place.
| qdot76367 wrote:
| Ah, it's good to see you continuing your work with types of
| robots that start with f.
| brcmthrowaway wrote:
| Why would I pick this over esp32 if I need to get shit done
| ryukoposting wrote:
| I can't imagine someone using an RP2040 in a real product, but
| the RP2350 fixes enough of my complaints that I'd be really
| excited to give it a shot.
|
| There's a lot going for the 2040, don't get me wrong. TBMAN is a
| really cool concept. It overclocks like crazy. PIO is truly
| innovative, and it's super valuable for boatloads of companies
| looking to replace their 8051s/whatever with a daughterboard-
| adapted ARM core.
|
| But, for every cool thing about the RP2040, there was a bad
| thing. DSP-level clock speeds but no FPU, and no hardware integer
| division. A USB DFU function embedded in boot ROM is flatly
| undesirable in an MCU with no memory protection. PIO support is
| extremely limited in third-party SDKs like Zephyr, which puts a
| low ceiling on its usefulness in large-scale projects.
|
| The RP2350 fixes nearly all of my complaints, and that's really
| exciting.
|
| PIO is a really cool concept, but relying on it to implement
| garden-variety peripherals like CAN or SDMMC immediately puts
| RP2350 at a disadvantage. The flexibility is very cool, but if I
| need to get a product up and running, the last thing I want to do
| is fiddle around with a special-purpose assembly language. My
| hope is that they'll eventually provide a library of ready-made
| "soft peripherals" for common things like SD/MMC, MII, Bluetooth
| HCI, etc. That would make integration into Zephyr (and friends)
| easier, and it would massively expand the potential use cases for
| the chip.
| petra wrote:
| For high volume products, given the low cost of this chip, it
| would make sense to bother with the PIO or it's open-source
| libraries.
| TaylorAlexander wrote:
| > My hope is that they'll eventually provide a library of
| ready-made "soft peripherals"
|
| Perhaps they could be more ready-made, but there are loads of
| official PIO examples that are easy to get started with.
|
| https://github.com/raspberrypi/pico-examples/tree/master/pio
| my123 wrote:
| > no hardware integer division
|
| It did have it, but as an out-of-ISA extension
| wrs wrote:
| I haven't dug into the RP2xxx but I presumed there would be a
| library of PIO implementations of the standard protocols from
| RP themselves. There really isn't?
|
| Edit: I see, there are "examples". I'd rather have those be
| first-class supported things.
| robomartin wrote:
| For my work, the lack of flash memory integration on the 2040
| is a deal breaker. You cannot secure your code. Not sure that
| has changed with the new device.
| ebenupton wrote:
| It has: you can encrypt your code, store a decryption key in
| OTP, and decrypt into RAM. Or if your code is small and
| unchanging enough, store it directly in OTP.
| XMPPwocky wrote:
| What stops an attacker from uploading their own firmware
| that dumps out everything in OTP?
| ebenupton wrote:
| Signed boot. Unless someone at DEF CON wins our $10k
| bounty of course.
| jackwilsdon wrote:
| I'm most excited for the partition and address translation
| support - partitions can be mapped to the same address for A/B
| boot slots (and it supports "try before you buy" to boot into a
| slot temporarily). No more compiling two copies for the A and B
| slots (at different addresses)!
| vardump wrote:
| RP2040 had Doom ported to it.
| https://kilograham.github.io/rp2040-doom/
|
| RP2350 looks very much like it could potentially run _Quake_.
| Heck, some of the changes almost feel like they 're designed for
| this purpose.
|
| FPU, two cores at 150 MHz, overclockable beyond 300 MHz and it
| supports up to 16 MB of PSRAM with hardware R/W paging support.
| chipxsd wrote:
| While outputting DVI! I wouldn't be surprised.
| rvense wrote:
| Mouser have 64 megabyte PSRAMs.
|
| I really want a Mac System 7 grade operating system for this
| chip...
| dmitrygr wrote:
| No they do not. 64megabit
| v1ne wrote:
| Hmm, it's really nice that they fixed so many complaints. But
| honestly, reading the errata sheet, I had to chuckle that Dmitry
| didn't tear this chip to pieces.
|
| I mean, there's erratums about obscure edge cases, about
| miniscule bugs. Sure, mistakes happen. And then there's this:
| Internal pull-downs don't work reliably.
|
| Workaround: Disconnect digital input and only connect while
| you're reading the value. Well, great! Now it takes 3
| instructions to read data from a port, significantly reducing the
| rate at which you can read data!
|
| I guess it's just rare to have pull-downs, so that's naturally
| mitigating the issue a bit.
| urbandw311er wrote:
| I absolutely love this guy's enthusiasm.
| kaycebasques wrote:
| Big day for my team (Pigweed)! Some of our work got mentioned in
| the main RP2350/Pico2 announcement [1] but for many months we've
| been working on a new end-to-end SDK [2] built on top of Bazel
| [3] with support for both RP2040 and RP2350, including
| upstreaming Bazel support to the Pico SDK. Our new "Tour of
| Pigweed" [4] shows a bunch of Pigweed features working together
| in a single codebase, e.g. hermetic builds, on-device unit tests,
| RPC-centric comms, factory-at-your-desk testing, etc. We're over
| in our Discord [5] if you've got any questions
|
| [1] https://www.raspberrypi.com/news/raspberry-pi-pico-2-our-
| new...
|
| [2] https://opensource.googleblog.com/2024/08/introducing-
| pigwee...
|
| [3] https://blog.bazel.build/2024/08/08/bazel-for-embedded.html
|
| [4] https://pigweed.dev/docs/showcases/sense/
|
| [5] https://discord.gg/M9NSeTA
| dheera wrote:
| I hate Bazel. A build system for C/C++ should not require a
| Java JVM. Please keep Java out of microcontroller ecosystem
| please -__--
| jaeckel wrote:
| And only discord on top, but maybe I'm simply not hip enough
| kaycebasques wrote:
| We realize Bazel is not the right build system for every
| embedded project. The "Bazel for Embedded" post that came out
| today (we co-authored it) talks more about why we find Bazel
| so compelling: https://blog.bazel.build/2024/08/08/bazel-for-
| embedded.html
| actionfromafar wrote:
| Bazel is great for _some_ Enterprise. Try it somewhere
| Azure rules and behold the confused looks everywhere.
| clumsysmurf wrote:
| Maybe there is a way to create a native executable with
| GraalVM...
| boznz wrote:
| > I got almost all of my wishes granted with RP2350
|
| I got all mine, these guys really listened to the (minor)
| criticisms of the RP2040 on their forums and knocked them out of
| the ball park. Cant wait to get my hands on real hardware. Well
| done guys
| ebenupton wrote:
| Thank you. It's been a major effort from the team, and I'm very
| proud of what they've accomplished.
| begriffs wrote:
| I see CMSIS definitions for the RP2040 at
| https://github.com/raspberrypi/CMSIS-RP2xxx-DFP but none for
| RP2350. Maybe they'll eventually appear in that repo, given its
| name is RP2xxx? I thought vendors are legally obligated to
| provide CMSIS definitions when they license an ARM core.
| tibbon wrote:
| Thanks for making the DEF CON badge! 10000x cooler than last year
___________________________________________________________________
(page generated 2024-08-08 23:00 UTC)