P2 full motion video larger than RAM on a SSD1331

ke4pjw

Thanks to @Rayman and @cheezus and others for getting fsrw running on the P2.

I will share the code and file needed for this to work ASAP. It really needs to be cleaned up.

Enjoy!



Update: Even faster and code is attached below


Code for this Project

cheezus

Very nice work, thanks for the shoutout! I'm looking forward to getting the SSD based 3.2" and 7" displays working.

There's a LOT of places where the sd driver is going to be improved but there's a couple quick places that should help a lot. In SDSPI readblock and writeblock, changing

   cmd(17, doSDHC(n))
' and
   cmd(24, doSDHC(n))

'to

   cmd(17, n)
' and
   cmd(24, n)

should give you a good bump to framerate, as long as you don't use a standard SD. There are some other changes that should be made but I left this in for compatibility. Once converted to ASM the overhead for supporting SD is an extra instruction but here it's significant.

cgracey

Awesome, Terry!!!

That looks great. I'm glad you got it working and it turned out not to be very complex.

I imagine you haven't employed the streamer to make this happen, but when you do, you'll be able to get another speed boost - unless the SD card is the limit, which it sounds may the case.

What is the resolution of that tiny OLED screen?

cheezus

I'd be willing to bet for FMV the current SD driver is the limiting factor. As he said, he's only using 2 cogs. Once the SD driver gets it's own cog and block transfers are native pasm, this thing's going to really rip! The other big boost should come from using smart pins instead of bit-bashing. The SPI read requires a waitx that needs tuning, based on clock, that should go away with the smartpins. You might be able to push past 320mhz (that was where I topped out at) by increasing the waitx in the read function in sdspi.

pri read : r  | c, o        '   Read eight bits from the card.

        c := clk
        o := do
    asm
        mov     r,          #0
        rep     #.end_read, #8
        drvl    c
        waitx   #14    '' !! 13 safe for up to 160 mhz, 14 for 320mhz
        testp   o               wc  
        drvh    c   
        rcl     r,          #1
.end_read
    endasm

Really nice work, makes me want to get back to writing RC3! If you'd like I can make the previously mentioned mods to sdspi for you to see if you can approach 30fps (or 29 or whatever source is). I'm really excited to see your source, might give me a boost with spawning cogs and /or smartpins. I have some notes and code to test over the next few days.

ke4pjw

cgracey wrote: »

I imagine you haven't employed the streamer to make this happen, but when you do, you'll be able to get another speed boost - unless the SD card is the limit, which it sounds may the case.

What is the resolution of that tiny OLED screen?

Thanks Chip!

The SD card is not meeting it's full potential, there are several efficiencies that could be gained by just implementing block mode and implementing a frame buffer. @cheezus has pointed me in the right direction on that. Right now it's just reading two bytes from the SD and handing them off to the OLED cog to write them to the display and repeats until the file ends. That's done in 4 lines of spin.

The streamer is a bit intimidating, as things always are when you don't understand them I will see what can be done there.

The screen is the one Parallax sells, the "96 x 64 Color OLED Display Module" Product ID: 28087. Super cheap and works GREAT!

More to come!

--Terry

ke4pjw

cheezus wrote: »

Very nice work, thanks for the shoutout! I'm looking forward to getting the SSD based 3.2" and 7" displays working.

There's a LOT of places where the sd driver is going to be improved but there's a couple quick places that should help a lot. In SDSPI readblock and writeblock, changing

   cmd(17, doSDHC(n))
' and
   cmd(24, doSDHC(n))

'to

   cmd(17, n)
' and
   cmd(24, n)

should give you a good bump to framerate, as long as you don't use a standard SD. There are some other changes that should be made but I left this in for compatibility. Once converted to ASM the overhead for supporting SD is an extra instruction but here it's significant.

I will give this a try! Right now I suspect that the code is running in hubexec mode, so there may be some efficiencies to be gained there.

Is it using smart pins for the SPI implementation?


I see that it isn't. You might have a look at the 5 wire implementation I used for the display. It uses smartpins.

Tubular

Looks great Terry, well done.

ke4pjw

Going to bump this. Code has been attached and I posted a video that shows the performance improvements. (Without my verbose commentary on how much fun this was to program)

Peter Jakacki

BTW, I have been meaning to get around to doing 320x240 25fps double-buffered video on VGA with TAQOZ since I already have pretty much have had everything in place. I am just converting some videos to bmp frames which I can read in easily at 2MB/s and have the VGA driver alternate between the buffers. I might modify the VGA driver to double up pixels and lines to achieve this resolution with 640x480. I'm downloading some of the Parallax P2 live-stream videos as samples. Let's see how it goes.

ke4pjw

Awesome @"Peter Jakacki" ! I can't wait to see it! I found ffmpeg to be quite helpful in building raw frames. I have a howto of ffmpeg to convert to the RGB 565 needed for this OLED display in the zip.

JimFouch2

This is amazing. And that fact that you're driving the screen with a serial interface to boot.

I'm working on a project to drive a small OLED display and currently am also doing this using SPI. I'm going to parallel not only to speed up the screen, but to also free up my processor to do other tasks. The less time it's sending serial data, the more time it has to do other tasks.

ke4pjw

I have validated this works with Rev. B silicon. I had to pull the clock back some. May be time to optimize with LUT, streamer, and the newest driver from @cheezus