Romram: Using QSPI RAM with RP2040's SSI in read-write mode | Hacker News Reader

Romram: Using QSPI RAM with RP2040's SSI in read-write mode

dmitry.gr

64 pointsfanf221 comments

I recently worked on a product (Realtek 200MHz MCU + integraiton wifi/ble) that had a similar setup - QSPI connected PSRAM and QSPI connected Flash (with read/write).

The PSRAM had a reasonable size page cache in the chip that made this memory quite responsive from a CPU perspective - a few rare cache flushes were needed, but things like DMA and bus masters (onboard radios etc..) were completely coherent and it made development much easier to manage.

My takeaway was that PSRAM was surprisingly capable (with the right can of hardware controller in place). Kudos to Realtek for getting the hardware to work without a thousand impossible to debug CPU lock ups...

SSI is a very useful (and underdocumented!) RPi feature - it’s how socket-compatible Raspberry Pi 68k emulators work with the ~60ish latches that interface with the 68k bus.

Fascinating!

https://github.com/captain-amygdala/pistorm

Oh, this is Pi 3A emulating a 68030, not a RP2040, I'll keep looking.

> General Performance with the current use of Musashi as the 68k CPU emulator is somewhere around a 100-125MHz 68030.

https://github.com/kstenerud/Musashi

Emulating a 128k mac with an RP2040 (using Musashi) https://github.com/evansm7/umac

Oh, you're right – on the larger-footprint Pis (the first project) they use _SMI_, which is a 16-bit parallel interface.

I think the successor to the RP2040 needs to features to absolutely clobber the market:

1. A true, ulta-super-duper-low-power mode, and 2. Proper external memory support.

We'll probably find out soon-ish, they dropped the name in their last investors report and said it's coming in the second half of the year. It's going to be the RP235x, which going by the naming scheme they established would be two Cortex-M3 cores with around 512k of SRAM and "X" onboard flash, whatever that means, as opposed to "0" flash (none) on the RP2040. Maybe multiple SKUs with different amounts of onboard flash this time?

Onboard flash would be welcome. External flash makes things unnecessarily hard for beginners. You either need to investigate their complicated boot scheme and work with built-in SPI even before you can blink the led, or use their overcomplicated SDK with overcomplicated build tools. Both alternatives are terrible. I can write blink led application using few lines of assembly with STM32 and that's how it should be.

Beginners use Arduino or MicroPython. For a microcontroller SDK, picolib is also quite simple. No need to deal with the boot or SPI manually. But of course built in flash will be a welcomed addition :)

I was beginner one year ago and I didn't use Arduino or MicroPython. I don't even know Python and I don't want to know it. I really liked RP2040 datasheet, it's miles ahead of everything I've read so far, but this issue with inability to write simplest program without loads of bloated libraries and tools led me to STM32. Now I have some experience dealing with STM32, nRF52 chips, I learned to use UART, SPI, USB, BLE and I probably would be able to write blink program for RP2040, but I'm not a beginner anymore, I think.

I understand what you're talking about, but I think it's wrong to shoehorn beginners into one size. I, for one, prefer to start simple. Simple start for MCU is assembly code or very basic C code, linker script and programmer. Those are necessary and can't be dismissed. Programming MCU with Python is like writing website with C. Could be done, but feels wrong.

I agree, the whole draw to modern mcu for me is that it resembles 80s personal computers in ram constraints. The bloated libraries run counter to that.

Thanks for the tip this is wonderful!

Wondering why they did not go for M4F. Probably this means they will keep the non-standard FPU which is also on the RP2040?

They don't have an FPU in the RP2040, what they have is a collection of optimized software FP routines baked into the chips ROM. You can see the code here:

https://github.com/raspberrypi/pico-bootrom/blob/master/boot...

Cortex-M3 would be an odd choice in this day and age - the core is 20 years old at this point.

The "3" meaning M3 is an extrapolation from the first "0" in RP2040 meaning M0+, but if the core is that old then yeah maybe it's something else. M33 perhaps?

I'd be perfectly happy with a low-power Cortex-M3 if it keeps the same price point as the RP2040. We all don't need screaming fast cores and the associated price adder.

It might be an old design, but it's not outdated.

There hasn't been any major innovation in CPU design for this power/performance/feature/area target, so the Cortex-M3 is still a valid choice if you don't need/want the extra instructions.

In fact, the basic design is much older, the Cortex-M3 is essentially just a stripped down ARM7TDMI 3-stage pipeline from 1994, with the new Thumb2 instructions from the ARM1156T2 and all the original 32bit instructions ripped out. Arguably, it's not that different from the original ARM1 pipeline either.

The Cortex-M4 is the exact same pipeline, just with a hardware divider, DSP instructions and optional FPU. If you don't need/want those, or area is more important, the Cortex-M3 is the way to go. There is the reason why ARM still have it listed as a current design.

The Cortex-M33 is probably the only thing which could be considered as innovation. The pipeline can now dual-issue some pairs of 16bit instructions, giving it a 20% IPC boost in coremark. But it's now 15% larger and uses 5% more power, so it's not a true replacement for the Cortex-M3 (though, it does seem to outperform the Cortex-M4, with the same area and lower power consumption, and it also supports the optional FPU)

Though, for this exact use case, I don't they are too tight on area. And I agree that it would be nice to have an FPU and DSP instructions. So if we are lucky, that 3 actually means the Cortex-M33 and the optional FPU.

I agree, but am amazed that you didn't include on-board flash, too. I definitely miss that in the feature set (but have barely used the RP2040 so perhaps I'm just shouting at the clouds).

The first comes with a lot of trade-offs, but I would love to see two QSPI controllers or at least two chip select lines that can be controlled by an extra address bit. I also want the DMA engine to be able to address the SIO block to access the GPIOs and interpolators without having to "tunnel" through a different peripheral like PIO or PWM timers.

> Our HardFault handler can now ... quickly interpret the faulting instruction, emulate the write, flush the cache line, and resume.

This sounds similar to the approach taken by yocto-8

https://github.com/yocto-8/yocto-8/blob/main/doc/extmem.md

except they use a memory region that does not exist, forcing them to emulate reads, so their memory is shit slow AND not executable, while this project's memory reads and executes at full speed, only shit-slow for writes.

Reply on news.ycombinator.com