P2 running the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087

ke4pjwke4pjw Posts: 438
edited 2019-02-26 - 05:23:17 in Propeller 2
This is the Alpha 2 release of test code for the Parallax "96 x 64 Color OLED Display Module" Product ID: 28087

Bitclock is at about 12Mhz.
P2 is clocked at 320Mhz.

ToDo:
Allow the init object to properly pass off constants for OLED pins
Determine why the smart pin only pushes data at 24KHz
Move 5x7 font into file (How did I not learn of "file" on the P1! It's Nice!)
Properly attribute code snippets that made this thing work.
Add MIT License
Provide better documentation of hardware hook-up and Software how-to.



Comments

  • I have updated the above to include a demo video and a ToDo list.

    I would appreciate some help in someone pointing me to where to read in the P2 manual about smartpin transfer speeds. I was under the impression that the smartpins were bound to the clock speed. This one is operating at 24KHz.
    1432 x 218 - 39K
  • jmgjmg Posts: 14,424
    ke4pjw wrote: »
    I would appreciate some help in someone pointing me to where to read in the P2 manual about smartpin transfer speeds..

    Which mode ?
    Async ones say this
    "WXPIN is used to configure the baud rate and word length.
    X[31:16] establishes the number of clocks in a bit period, and in case X[31:26] is zero, X[15:10] establishes the number of fractional clocks in a bit period. The X bit period value can be simply computed as: (clocks * $1_0000) & $FFFFFC00. For example, 7.5 clocks would be $00078000, and 33.33 clocks would be $00215400.

    X[4:0] sets the number of bits, minus 1. For example, a value of 7 will set the word size to 8 bits.
    "

    Sync mode says this
    "Words of 1 to 32 bits are shifted out on the pin, LSB first, with each new bit being output two internal clock cycles after registering a positive edge on the B input. For negative-edge clocking, the B input may be inverted by setting B[3] in WRPIN’s D value.
    "
    ie you need to create (or input) a clock on the B-Pin mapping, and that sets the baud rate



  • This is sync mode. My reading of this would indicate that at 160MHz, outputting a byte would be sending data at about 20Mhz. (Two clock cycles per bit at 160Mhz = 80Mhz. Only sending 8 bits (1/4th of 32 bits) lands me at 20Mhz. And I am not sure about that last bit. Either way, it should be way, way higher than 24KHz.

  • Nice!

    For the synchronous serial, you need to generate the clock, ideally using a smart pin.
  • The clock is being generated by the smartpin. Do I need to configure the bitperiod the same way I would for async?
  • The only thing that would have made this better is if the slow image load at the beginning were followed up by a blast of high speed animation that was tracked to the music :smiley:
  • jmgjmg Posts: 14,424
    ke4pjw wrote: »
    The clock is being generated by the smartpin. Do I need to configure the bitperiod the same way I would for async?

    Yes, only the clock timing is done in the clock-pin setup, not in the sync-shifter pin setup.
    You can ask for any clock up to SysCLK/2 onto a pin.
    Which mode does your clock smart pin use ?
  • jmg wrote: »
    Which mode does your clock smart pin use ?

    I will need to unpack that from the code. I pulled from examples that other forum members have given me. Quite frankly, the only thing I changed was to shift on a negative clock. The documentation isn't clear how bit period is configured for sync serial. Based on what you posted above, I think I know what I need to do!
  • Aww, looks a little out of control there. System clock setting is probably not working to requested speed with that 640 MHz setting in the the source code. The measured 24 kHz bit rate would indicate the system clock is likely around 200 MHz.

    I calculate the above from 24000 x 4096 x 2. The 2 is because two clock transitions per bit. 4096 because that's the transition period set on line 468 of test_AsmDrv.spin2.

    As for the system clock setting. You've made an error in comments of _XDIV, a value of 2 gives 10 MHz, not 5. This has caused incorrect calculation for the other components. Also, I'd recommend leaving _XDIVP = 1 unless going below 20 MHz. I know the docs say 100 MHz but that's a hugely conservative number.
  • ke4pjwke4pjw Posts: 438
    edited 2019-02-26 - 05:34:59
    I got a moment to work on it again this evening. Thanks for pointing out the problems in the code. I have updated the code to run the P2 at 320Mhz. Bitclock is now running at about 12Mhz. As we say down south, "It runs like a scalded dog!".

    I removed some of the unnecessary waits I added in the TX code. I had to add waits to the clear screen. My code would start sending data before the RAM on the display could finish it's task after a clearDisplay sequence was sent.

    I will try to clean this code up soon.

    Thanks for everyone's help.

    PS: I updated the video so you can see the end result. We might be able to implement a screen buffer on this bad boy! It's fast!
  • I am having too much fun with this. We have enough RAM and data throughput with the P2, we can animate.

  • Nice!
    If you overclock it will it take off? :lol:
  • Perhaps add in-place pixel rotation? (The method of multiple skew operations, search for "Three shears" here datagenetics.com/blog/august32013/index.html
  • Nice Mark! Yes this is just straight frame flipping as a proof of concept. I am going to attempt to find another short animation that has more motion just to see what it looks like. Maybe add an FPS counter. What made this so cool to me was I just changed a couple of lines a code to do it. The saving grace of this hack is that the frames are loaded into RAM sequentially. I hoped that fastspin would do that, and it did!
  • ke4pjwke4pjw Posts: 438
    edited 2019-02-28 - 06:18:10
    Last one. I did this one just for @cgracey



    Fastspin started segfaulting if the program was over 300K, so I was limited to 24 frames.

    Please don't look at the code. Zero cleanup. This was my first time using raw pixel data vs 16bit 565 bmp, so the offset is set to 0.
  • You know, I haven't been here since the start...can anyone fill me in on Chip's attachment to Fozzie?
  • ke4pjwke4pjw Posts: 438
    edited 2019-03-02 - 16:18:58
    I created two new videos that show off the smoothness of the display. I have determined the best way to create videos is to take video clips or animated GIFs and convert them with ffmpeg. Below is an example of converting a GIF.
    ffmpeg -vcodec gif -i "filename.gif" -vf scale=96x64:flags=lanczos -vcodec rawvideo -f rawvideo -pix_fmt rgb565 "filename.raw"
    




  • Looks great!
  • Terry,

    Do you notice tearing when playing your video?
    I think I see some in your video, but hard to tell...

    It's too bad none of these displays bring out the "FR" signal that would let you sync to the device...

    It appears that up to ~60 fps is possible over SPI, if I'm reading the datasheet right...
  • It appears to be quite fluid. No visible tearing that I can see. If I have time this weekend, I will create a tearing test video for it to play.

    I will have to go back and look at my captures from the logic analyzer and see if there are gains that can be had tweaking the smartpins. I seem to recall I was clocking out at 25Mhz, but there were large gaps between the bytes. The buffer was a single frame as I recall. I do not recall that gaps between the frames. I was just thrilled to get it going :smile: In Spin no less.

    @cheezus updated his SD driver, which I use to pull the video from, so there may be some gains to be had there as well.

    When the P2ES2 is available, I am going to jump back into this.
Sign In or Register to comment.