Exmem_mini.spin2 testing
Rayman
Posts: 15,799
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*12to the mailbox base address)Thought did that here:
'Configure exmem interface cogid x mul x,#12 add exmail,xOh 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…
Upgraded to 4 line buffer and looks good now.
Only issue might be junk on the very bottom line (actually one line after the real bottom line).
Think this is something with the streamer.
Might have to fill buffer with zeros or something at the end...
Think this example is in good shape now.
Need to test with a real VGA monitor, think this extra line seeing here is artifact of VGA-HDMI converter...
Also want to add settings for the Parallax P2-EC32 module.
Ok, on real VGA monitor looks good. But, there is one extra line of noise on the bottom...
Looking into this now...
Using a better test image shows the problem...
Seems the forth line was missing and an extra line was read from PSRAM.
Not sure how this is possible... Actually, guess it's always going to read a few extra lines because of where the read from exmem line is in the loop....
But, a fix is the read the forth line again with this:
Very strange... Don't like it, but it works, maybe that's good enough?
Must be something to do with the way streamer commands are buffered, so not in sync with regular code...
Example above shows a stable image with psram4 driver (24MB module) at P2 clock of 100 MHz (after adjusting the delay).
Guess was wrong about bandwidth, seems there is plenty...
Wow, now psram16 mode is all messed up (P2 platform). Palette is coming in wrong too, that's very strange....
Very bizarre that psram16 works with the Simple1d version but not this Simple1f...
Does work if switch it to psram4 mode. And, all four channels work too...
You're doing it wrong.
You don't need to read 2 (or even 4) lines at once, you need to swap the buffers between read/write, only then will it not be precarious and janky.
So on line -1 (last back porch line) you request line 0 into buffer A
On line 0 you scan out buffer A and request line 1 into buffer B
On line 1 you scan out buffer B and request line 2 into buffer A
etc etc
On line 479 (last vis. line) you can be clever and not request anything, or do it anyways to simplify the code
@Wuerfel_21
Ok, switched to that way and it seems to work without anything mysterious...
But, MEMORY_TYPE = 8 is not working with P2 Platform.
4 works on all 4 banks and 16 works as well.
But, getting junk from 8.
Can it be that the MEMORY_TYPE = 8 only works for the 96 MB type module?
Have to try that...
It should work, but the 8-bit one is the weird one.
Ah, okay, I think I see what you're talking about (ignore the screen being offset, the capture card is just having a normal one again)
I think I remember this bug being a thing and having some fix for it, but I forgor 💀 if I had to do a workaround or if there's a fixed version of the driver.
Well I can't find a fixed one, so I'm just going to ping @rogloh on this, surely he has a fixed psram8drv up his sleeve
(But IIRC now the way to work around this is to never do requests that don't align to a long and then cross a row boundary? something like that - just long-align your buffer)
@Wuerfel_21 Ok, long aligned buffers makes it work, thanks.
But now on real VGA monitor and see top line is missing and there's a junk bottom line...
Thinking this 2 line buffering is just not going to work because of the way streamer commands are buffered...
This is literally what everyone else is doing, so it obviously works. (and is really the one (1) correct way of doing this!)
You just need to think about the command buffering.
The streamer can essentially buffer 2 commands; one that is currently executing and one that is queued up. Attempt to add a third and it stalls the CPU.
So whenever you issue a command, you know that after the CPU is done with that instruction, the previous command may currently be executing and the one before that is now guaranteed to be done.
Just remembered @cgracey antialias demo from psram... Think seeing some tricks there...
Think have it now. Trick is to forget getting the very first frame correct and make it so second frame on is correct...
Video loop starts at line #2 and last loop loads line #1
Yeah, something like that.
Though in practice (i.e. showing anything but a still frame) you really want to use last line of blanking to start reading the first buffer line. (that way you have plenty of time to either update the buffer or swap the pointer during VBlank)
Ok, added in first line preload, even though not technically needed for showing still image. Guess could be useful if doing 60 fps updates...
Think it's in good shape now.
Thought the long aligned buffer fixed the use of MEMORY_TYPE = 8 on platfrom2, but now seems still broke...
What's the actual problem with 8 bit mode? Maybe I had a fix for it, once I know there's an actual bug I typically want to fix it so it might be done already.
UPDATE: Hmm, I don't even see a psram8drv in my released drivers so it could have been a @Wuerfel_21 special that was thrown over the wall for testing. There were a few special private builds I sent back during console developments with special chip selecting and clock speed options, perhaps this was one of them. Which boards were using 8 bit? Was the 96MB board one of them? I thought that worked at some point.
@rogloh Pretty sure your driver works with 96MB board. Still need to test that with exmem, but not too concerned. I have a memory of 8-bit mode working with both upper and lower portion of Platform2 memory, so sure that can work too.
Guess the question is about what is here with exmem_mini...
Maybe 8-bit mode only works with 96MB board and that would be fine.