Comments

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.

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.

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.

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!

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!

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.

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 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.