 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : RP2350 PSRAM: how to wire, how to use?
Page 1 of 2   |
|||||
| Author | Message | ||||
| matherp Guru  Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
The RP2350 supports PSRAM on the same bus as the flash memory and some commercial offerings are adding 8MB of PSRAM to boards with the 80-pin RRP2350B (e.g. Pimoroni PGA2350). The Pico2 does not have onboard PSRAM or any way to wire it externally as the required QuadSPI pins are not broken out. The PSRAM is comparatively slow, like flash access, with which it contends but it could be useful for things like game levels, or large arrays etc. Like the flash it is accessed through a cache which will be fast if the request hits memory in the cache. To access PSRAM an additional pin is used for the chip select. This can be one of GPIO0, GPIO8, GPIO19 or GPIO47. The PGA2350 uses 47. My current thoughts are to only enable PSRAM if the chip is a RP2350B (80-pin) and to only support GPIO47 as the chip select. When chips become widely available I will design all-in-one boards as per the RP2040 and would intend to follow this. In the meantime Mick is already designing assuming this board as his processor module. RP2350B modules without PSRAM will, of course, be supported. I'd like confirmation that only supporting PSRAM on the RP2350B and only accessing it using chip select on pin 47 meets with general agreement. Next comes the question of how to make the additional RAM available to the MMBasic user. My current thoughts are to keep this simple and just provide routines to copy to/from physical PSRAM addresses into MMBasic arrays and also provide routines to load/store PSRAM from disk. As MMBasic can't guarantee whether PSRAM is available or not it doesn't seem sensible to very tightly integrate it into the firmware and we certainly don't want multiple versions to support with/without PSRAM How does this sound? |
||||
Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6780 |
Ok to me. Pin 47 is also ADC7, but it's unlikely that all 8 ADCs will be used. Would it be possible to have an option to disable the PSRAM? I think it's pointless to support PSRAM on the smaller packages. The CS pin choice isn't great. There's only GP0 that could be used really as GP8 spoils compatibility and the remaining options don't exist. Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 857 |
"How does this sound"? Great for me. I would like somewhere to write large arrays without having to worry about flash wear (machine learning)  |
||||
vegipete Guru Joined: 29/01/2013 Location: CanadaPosts: 1109 |
If a sprite/blit and a "sound" (whatever that might mean) could be stored in an array, then this method of copying to and from PSRAM would be quite useable. Maybe fonts, also. Visit Vegipete's *Mite Library for cool programs. |
||||
Quazee137 Guru Joined: 07/08/2016 Location: United StatesPosts: 567 |
Any way to treat it as a RAM disk drive? years ago I had to record audio and save it as a file. This was on an AT286 and HD access in pascal wasn't fast enough. So used inline asm and I think was 1meg ram card as disk drive. Had to disconnect the studio card from the power bus while recording do to way to much noise on the supply lines. just a though Quazee137 |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6780 |
PSRAM is volatile, you lose what's in it om power off. It is, basically, a slower RAM disk, it's just that it isn't handled as such in firmware (not yet anyway!). (It's weird stuff - dynamic RAM with built-in refresh so it looks like static RAM from the outside.) Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| Quazee137 Guru Joined: 07/08/2016 Location: United StatesPosts: 567 |
Yes it goes away when powered down but a useful way to store runtime data The AT286 1Meg ram went away when at power down. Made it easier to read and write treating it as a drive. Could just copy from it to real HD or 3.5" floppies. Even had a tape drive to copy to. using ram drive one could setup graphic pages then read them into main ram as needed for doing games or menu driven programs. Many useful ways to use. Quazee137 |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4223 |
I remember that in DOS based systems you could create a RAM drive, and recall Ithaca a filesystem on it and was called Z: I never used it much since RAM was precious and you rather used it as main memory. But I know some applications used it to stream MPEG video, something a harddisk was too slow for at that time) Volhout PicomiteVGA PETSCII ROBOTS |
||||
| Mixtel90 Guru Joined: 05/10/2019 Location: United KingdomPosts: 6780 |
PSRAM isn't all that fast. It's somewhere between RAM and flash, apparently, so it wouldn't be as fast as a true RAM disk unless the fetch was for something already in its cache. [RAMBLE] I used to use a RAM disk on the old Nascom-1. As the Z80 was restricted to a 64K memory space add-on boards were designed to handle bank switching. They could get hairy! By twiddling bits in two of the Z80 ports (which take up no memory space) you could switch in one page for read and a different one for write at the same address, If the Write page was the screen you could "rapidly" (we are talking original 2MHz Z80 here, so not really!) blit images onto it using LDIR from and to the same address. If anyone has seen Tandy's Dancing Demon they'll know the sort of thing. Hardware hacking when you had to know about address & data buses, M1 cycles, IORQ etc. was fun. :) [/RAMBLE] . Edited 2024-08-25 19:21 by Mixtel90 Mick Zilog Inside! nascom.info for Nascom & Gemini Preliminary MMBasic docs & my PCB designs |
||||
| PhenixRising Guru Joined: 07/11/2023 Location: United KingdomPosts: 857 |
I used himem.sys (I think) to create a RAM drive in the upper 384K. This is where I stored 640 X 350 .PCX painted images for my DOS GUI. The early hard drives I didn't trust on machinery and so I only booted from the drive, put whatever files I might need in the RAM drive and then "parked" the drive. |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4223 |
In PETSCI robots peter implmented fast copying sprites from flash to video ram. This is something where PSRAM might even be better. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| EDNEDN Senior Member  Joined: 18/02/2023 Location: United StatesPosts: 118 |
If I was doing the work to support the PSRAM, I would be tempted to do it using the Dim statement. Probably something like: Dim X(5000,100,2) In_PSRAM From a logistical perspective, the easy and most natural way to use large blocks of memory is via arrays. So to my way of thinking, it would be very natural for someone writing an MMBasic program to flag that a particularly large array should be located in PSRAM. Other than marking an item as In_PSRAM all of the program logic (and syntax) would be the same. I would add a PSRAM type or flag to the s_vartbl.type field. typedef struct s_vartbl { // structure of the variable table unsigned char name[MAXVARLEN]; // variable's name unsigned char type; ... } and as a variable is evaluated, it would be clear to the MMBasic interpreter code where in memory the item is located and how to access it. Incidentally, DEC's Basic+ on RSTS/E OS's on the PDP-11's had something very similar to what I'm describing. Using the Dim statement the programmer could position the array into a disk file instead of core memory. All of the remaining logic in the program that accessed the array was identical. Where the storage actually existed for the array was controlled by the Dim statement. All of the other program logic was identical and did not care where the storage actually manifested itself. Section 11-1 of http://elvira.stacken.kth.se/rstsdoc/rsts-doc-v70/v7.0-v3-a-dec-11-orbpb-b-d_basic_plus_language_manual.pdf describes the Basic+ syntax for doing this. Edited 2024-08-26 02:00 by EDNEDN |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
The one problem with this approach is the size of the used block table. This uses 2 bits for every 256 bytes So for 8Mbytes this is 8x1024x1024/256/4 bytes. If the same firmware is to support the RP2350 with or without PSRAM then this space needs to be permanently allocated which is a waste if PSRAM is not present. |
||||
| circuit Senior Member Joined: 10/01/2016 Location: United KingdomPosts: 245 |
If I do not want to use PSRAM but instead to use pin 47 as a standard GPIO, do I need to cut the PSRAM to PIN47 link on the reverse side of the Pimoroni PGA23450B board? - I am rather thinking that I do, but just checking. Edit; just after posting the question, I thought to put it to Edge Copilot; this is the response I received; Yes, if you want to use pin 47 as a standard GPIO instead of PSRAM, you’ll need to cut the link between PSRAM and pin 47 on the reverse side of the Pimoroni PGA23450B board. This will allow you to repurpose pin 47 for your desired GPIO functionality. Edited 2024-08-26 20:11 by circuit |
||||
| Volhout Guru Joined: 05/03/2018 Location: NetherlandsPosts: 4223 |
Just desolder the PSRAM chip. Do NOT try to cut wires. That is irevocable. Volhout PicomiteVGA PETSCII ROBOTS |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 118 |
Are you referring to the 8KB cache tables used to support the PSRAM? If so, I'm kind of thinking along a different path. Wouldn't it make sense to have no PSRAM support active unless the user executes an 'Option PSRAM {size?} {GPIO_Pin}' command? The memory for the block table wouldn't be allocated until it is known to be needed? But the other thing is the RP2350 allows both cached and non-cached setup of the PSRAM. Would it make sense to allow the user to configure whether they wanted the cache turned on (and the extra expense of the cache line table to support it)? If so, the above command might be 'Option PSRAM {size?} {GPIO_Pin} {Cache_On / Cache_Off} ' It is incredibly difficult to find good documentation on the PSRAM capability and usage on the RP2350 right now. Can you provide a link for the information you are using? Edited 2024-08-27 00:21 by EDNEDN |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 9110 |
Things like the block table have to be permanently allocated. MmBasic doesn't use Malloc. To use the PSRAM you just need to set the CS pin to the appropriate alternate function and set the memory writable in zip ctrl |
||||
thwill Guru Joined: 16/09/2019 Location: United KingdomPosts: 4036 |
If you wanted to be tricksy then it may be possible to arrange the block table and the MMBasic heap to be contiguous (block table followed by heap) then you can on startup adjust the base pointer from which the running program can be allocated heap space depending on whether you need the bigger block table ... or not ... it's not really important to me  .Best wishes, Tom Edited 2024-08-27 01:53 by thwill Game*Mite, CMM2 Welcome Tape, Creaky old text adventures |
||||
| EDNEDN Senior Member Joined: 18/02/2023 Location: United StatesPosts: 118 |
Yes... Or if it made sense to support the PSRAM via the Dim statement, an extra 8 KB could be allocated for the block table at the same time memory is assigned for usage by the array being declared (in the Dim statement code). The difference being the block table needs to be in SRAM and the array being declared will consume space in the PSRAM. The good news is only the first PSRAM based array would need a buffer setup for it. Subsequent Dim statements or arrays declared in Dim statements would all be using the same buffer memory. And if the user never declared an array In_PSRAM the memory for the block buffer never gets consumed. |
||||
| circuit Senior Member Joined: 10/01/2016 Location: United KingdomPosts: 245 |
I was referring to the "pin 47" option link installed on the board; it is a design feature and allows reversal by simply soldering in a zero ohm link across the two pads if the link has been severed. |
||||
| Page 1 of 2 |
|||||
 Print this page |
