[HN Gopher] Romram: Using QSPI RAM with RP2040's SSI in read-wri...
___________________________________________________________________
Romram: Using QSPI RAM with RP2040's SSI in read-write mode
Author : fanf2
Score : 63 points
Date : 2024-08-04 20:42 UTC (1 days ago)
(HTM) web link (dmitry.gr)
(TXT) w3m dump (dmitry.gr)
| mrlambchop wrote:
| 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...
| mmastrac wrote:
| 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.
| jsheard wrote:
| 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?
| vbezhenar wrote:
| 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.
| jononor wrote:
| 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 :)
| vbezhenar wrote:
| 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.
| galangalalgol wrote:
| 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.
| TaylorAlexander wrote:
| Thanks for the tip this is wonderful!
| jononor wrote:
| Wondering why they did not go for M4F. Probably this means
| they will keep the non-standard FPU which is also on the
| RP2040?
| jsheard wrote:
| 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...
| pantalaimon wrote:
| Cortex-M3 would be an odd choice in this day and age - the
| core is 20 years old at this point.
| jsheard wrote:
| 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?
| joezydeco wrote:
| 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.
| unwind wrote:
| 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).
| crest wrote:
| 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.
| cellularmitosis wrote:
| > 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
| dmitrygr wrote:
| 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.
| nxobject wrote:
| 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.
| sitkack wrote:
| 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
___________________________________________________________________
(page generated 2024-08-05 23:01 UTC)