Max SPI speed?
Rayman
Posts: 13,894
in Propeller 2
Can P2 do 125 MHz SPI with 250 MHz clock?
If so, how would you do it?
The smartpin synchronous serial transmit mode talks about a 2 clock delay between clock edge and data output.
That sounds like clock/4 would be max speed, right?
Also, how do you generate the clock?
If so, how would you do it?
The smartpin synchronous serial transmit mode talks about a 2 clock delay between clock edge and data output.
That sounds like clock/4 would be max speed, right?
Also, how do you generate the clock?
Comments
A lot of devices look to top out at SPI speed of 30 MHz, so that is easy.
Looks like class 10 SD card and do 50 MHz, I think should be OK there...
I think that comes down to if you want SPI-duplex, and you likely need to add in the external devices Clock to out delays in that time budget too.
The data says
11100 = sync serial transmit (A-data, B-clock)
11101 = sync serial receive (A-data, B-clock)
but also says that B-clock is an input signal ?
%11100 = synchronous serial transmit
This mode overrides OUT to control the pin output state.
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
That's starting to sound limiting. If the remote unit samples on _/= and idles HI, that's half a clock period for P2 to generate the CLK, plus a Tsu budget.
Practical might be SysCLK/5 ?
There are 128MHz SPI LCD displays designed to talk to RaspPi, it would be interesting to see how fast those can run on P2.
I think those are write-only, so just need fastest clock and data. They claim 60Hz frame rates.
Some info seems to be here https://github.com/kedei/LCD_driver
- but I do not see the specific SPI setups / data widths for that display ?
eg This linkage could be nice, not sure if P2 can connect these dots ?
HUB memory -> Streamer -> LUT palette -> Smart Pin SPI -> 128MHz LCD link.
Running a clock separate from shifter sounds tricky to get right - phasing becomes critical, and what happens if an interrupt occurs ?
Does sync serial transmit really not 'generate its own clock' ?
The DOCs say this "This mode allows steady data transmission with a continuous clock, as long as the WYPIN’s after each IN-rise occur before the current word transmission is complete."
- but if the data has occasional small pauses due to interrupts, how does the clock know to pause ?
Addit:
I also find this
https://www.ebay.com/itm/2-8-TFT-LCD-Display-Touch-Screen-Monitor-640x480-60fps-For-Raspberry-Pi-Zero-W/264014279144
Claims 60fps for 640x480 in 2.8" - very impressive ! - but skip the important bpp and MHz numbers ...
and they have the CPLD model, 3.5", 480x320
https://www.ebay.com/itm/New-3-5-inch-128M-SPI-60Hz-LCD-Display-Touch-Screen-Module-For-Raspberry-Pi-3-B-/263892520798
and I think this is older, HC595 x 3 design... slower ?
https://www.ebay.com/itm/3-5-TFT-LCD-Touch-Screen-Module-320-480-RGB-Display-Board-For-Raspberry-Pi-3-B-/381182260459
** Addit 2:
Google finds this
http://www.raspberrypiwiki.com/index.php/2.8_inch_Touch_Screen_for_Pi_zero
https://github.com/tianyoujian/MZDPI
Shows a version B PCB, (2018.5.28) with more options, includes PWM backlight, ... but still vague on SPI specs...
Addit 3: hmm... maybe that 640x480 in 2.8" is not SPI ? - PCB seems to have a lot of connections ? - can Pi do some DMA parallel bus ? (640x480x60Hz is min-mean of 18.432MHz )
Google finds this - good numbers and scope grabs, but somewhat confusing results, where DMA is worse than bit-bang, seems DMA+GPIO was never intended ?
https://github.com/hzeller/rpi-gpio-dma-demo
Strange, as the PiZero is a single core I think ? So hitting that claimed 60fps, uses most of the CPU resource ?
To make this more interrupt tolerant, I think you would need to send just 8/16/24 bits at a time, reloading CLK and DAT ?
Or is that reload DAT and CLK, I think loading DAT is buffered, and you want to ensure that is ready for the next clock burst,
Is CLK setting also buffered ?
What about for a Pi-as-Master case, where the P2 looks like that LCD display.
What speed is possible then ?
The streamer can go to SysCLK tho, so that seems a limitation ?
Q: Should a mode be extended, so the smart pins can also generate FSys speed outputs ?
That would allow users to use a lower Sysclk for many of these designs, which is inside a wider temperature range spec, and lowers Icc.
I think the logic needed is not large, in sync modes, it would be 2 x D-FF and an XOR gate, one D-FF is _/= and one is =\_
Or, it allows them to over-clock existing designs - eg that CPLD Pi LCD above, specs 128MHz because that's the Pi limit, but a P2 with SysCLK out ability, could probably wiggle a pin to 200MHz + ?
( It seems to deliver data fine at 250MHz to HDMI displays )
Being able to have higher fps than a Pi, would certainly get peoples attention
Yes, there are many over-laps.
I was looking at using the better Pi LCDs (fastest fps) with P2, as well as P2-as-slave to a Pi system.
It seems Pi can talk at 128M, can P2 listen at that speed, on a practical connection ?
Conversely, CPLD Pi displays spec 128M, but that's because that's where Pi stops, P2 could drive much faster (with the right pin cell details)
Pi also seems able to burst-send at reasonable speeds on GPIO, so here the streamer could act as a FIFO interface.
That might be interesting too...
Mike
That is already asked. In the Pi talking at 128M, the P2 is a slave SPI device. (Clock comes from Pi)