Exmem_mini.spin2 testing
The @Wuerfel_21 exmem_mini driver for various configurations of PSRAM and HyperRam looks great.
Finally writing some code to test it out...
The this driver first appeared in the teapot demo as discussed here:
https://forums.parallax.com/discussion/177853/where-to-find-a-p2-ec32mb-driver-for-ram/p1
Here's a very simple test of reading and writing 100 bytes to the 24MB PSRAM module on P2 basepin 0.
It should be easy to adapt for other configurations, such as the P2-EC32MB module...
Displays first 10 bytes read back using debug.
(note in and out buffers made 4x bigger than needed to make sure won't overflow...)
Comments
One thing that need to ask about is granularity... Think #bytes can be odd with 24MB PSRAM module, but not 100% sure.
For P2-EC32MB maybe needs to be multiple of 4 or 8 bytes?
Actually, I think it came from an earlier demo, but I basically just wrote it once because Roger's spin API hurt my head and have copied it between projects ever since.
Do note that you can just joink the mailbox address and manually invoke the more complex features.
Since it's a wrapper around Roger's drivers, it can do byte granularity, but if you disrespect the native granularity/alignment of the memory it will have to do extra work. Native granularity for these quad PSRAMs is always 2x the bus width, so 1 byte for 4-bit, 2 bytes for 8-bit and 4 bytes for 16-bit. Also consider row boundaries. Each row has 8192 bits, so for 4-bit (single chip) the row boundaries are every 1024 bytes (2048/4096 for 8bit/16bit instead). Transfers should ideally not cross them (also extra work).
Here trying to use 24MB PSRAM as VGA buffer... Not working yet...
Maybe it's just not fast enough? Seems it is close to working...
Maybe need another cog to coordinate transfers or something...
For the QoS thing to work, you need to actually use the correct mailbox for that cog (i.e. add
cogid*12
to the mailbox base address)Thought did that here:
Oh yeah, just didn't see that while skimming through, is fine.
Guess it's better now, image is stable, just not right...
Better now, found a bad error in buffer address math...
PSRAM4 isn't so happy at 250 MHz, but good at 300 MHz.
PSRAM16 (platfrom2) needs a delay tweak when going from 250 to 300 MHz...
Doesn't like me fixing the line buffer at $60000 in hub, but is OK with $40000.
Must be something using a lot of stack?
Need a better test image because think something strange is going on with the very bottom line...
It was solid blue when image memory was filled with 10, but black now that filled with 0.
Think that might be something to do with streamer though....
Wait, are you using a single line buffer only? You need at least two lines to alternate between, otherwise your timing ends up being very precarious.
Yeah, made a better test image and it is not good…