211–220 of 356 posts
Alright, what's the max image resolution/framerate someone is going to pump out with the HSTX peripheral?
[1] https://github.com/raspberrypi/pico-examples/blob/master/dvi...
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!
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…
RP2040 shows up in a lot of qmk keyboards, for real product use
as niche as it gets
Earlier quoted context omitted.
> 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…
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.1kΩ resistors fo…
I guess you’re not gonna be buying a Pi Pico 2, then. So why are you complaining about something you aren’t going to use?
Earlier quoted context omitted.
I really hope people don't do this. Or at least not try to sell it as ARM vs RISC-V tests. Because what you are really testing is the Cortex-M33 vs the Hazard 3, and they aren't equivalent. They might both be 3 stage in-order RISC pipelines, but Cortex-M33 is technically superscalar, as it can dual-issue two 16bit instructions in certain situations. Also, the Cortex-M33 has a faster divider, 11 cycles with early term…
It'd help to know how much area each core takes within the die. I would expect the ARM cores to be much larger, as well as use much more power.
If you ignore the FPU (I think it can be power gated off) the two cores should be roughly the same size and power consumption.
Dual issue sounds like it would add a bunch of complexity, but ARM describe it as "limited" (and that's about all I can say, I couldn't find any documentation). The impression I get is that it's really simple.
Something along the line of "if two 16 bit instructions are 32bit aligned, and they go down different pipelines, and they aren't dependant on each other" then execute both. It might be limitations that the second instruction can't access registers at all (for example, a branch instruction) or that it must only access registers from seperate register file bank, meaning you don't even have to add extra read/write ports to the register file.
If the feature is limited enough, you could get it down to just a few hundred gates in the instruction decode stage, taking advantage of resources in later stages that would have otherwise been idle.
According to ARM's specs, the Cortex-M33 takes the exact same area as the Cortex-M4 (the rough older equivalent without dual-issue, and arguably equal to the Hazard3), uses 2.5% less power and gets 17% more performance in the CoreMark benchmark.
Earlier quoted context omitted.
Signed boot. Unless someone at DEF CON wins our $10k bounty of course.
Do you have any protection against power/clock glitching attacks?
Earlier quoted context omitted.
While outputting DVI! I wouldn't be surprised.
Mouser have 64 megabyte PSRAMs. I really want a Mac System 7 grade operating system for this chip...
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…
> A USB DFU function embedded in boot ROM is flatly undesirable in an MCU with no memory protection. Are you saying DFU is not useful without an MMU/MPU? Why would that be?
Earlier quoted context omitted.
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.
> 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.