Shop OBEX P1 Docs P2 Docs Learn Events
Raspberry Pi Zero to P2 communications over SPI bus — Parallax Forums

Raspberry Pi Zero to P2 communications over SPI bus

RaymanRayman Posts: 13,861
edited 2019-11-23 00:50 in Propeller 2
I'm looking into using Raspberry Pi Zero as a GPU for P2...

Want to use SPI bus to get high speed.
I'm using wiringPi right now, which supports up to 32 MHz.
Here's my initial stab at this in C++ from raspi side and spin2 for P2 side.

It seems like I need two added delays in there that depend on the SPI bus speed.

I was able to get to 5 MHz using this approach.
Not horrible, but would like to do better in the future.

This is with raspi being the SPI master, which is a bit of an issue.
I think what I'll try next is using a raspi GPIO to tell the raspi that a command is ready to be issued and to start a 32-bit transfer.
Still thinking about best way to do this...

Comments

  • roglohrogloh Posts: 5,158
    Have you looked into the SMI approach Rayman instead of SPI? Should be faster though it burns more pins.
  • jmgjmg Posts: 15,145
    Rayman wrote: »
    I'm looking into using Raspberry Pi Zero as a GPU for P2...

    Want to use SPI bus to get high speed..

    There are companies selling LCD modules like ' WS 320x240 3.2 inch Touch Screen TFT LCD for Raspberry Pi 125MHz High-Speed SPI' and those have Pi drivers, so maybe you could look at those drivers
    for ideas ?
    or even consider making P2 'look like' one of those LCDs so it just discards the config info, and accepts the streamed pixels ?

    Of course, those are focused on one-way traffic, whilst a GPU may be more two-way ?

  • evanhevanh Posts: 15,187
    edited 2019-11-23 03:57
    With the Prop2 as the slave, replying from the Prop2 to the PiZero will be limited by the I/O stages in the prop2. The output response to the SPI clock edge has a few sysclocks of lag. The bigger you have the ratio of sysclock rate to SPI clock rate the cleaner this appears.

    But even if that wasn't an issue then the lack of a truely synchronous external I/O clock on the prop2 means you would still strike problems as you approach sysclock/3. If this was the limiting factor then sysclock/4 would be the recommended max SPI clock rate with prop2 as slave.

    Sooo ... apparently there is one serial port on the Pi's that can be configured as a slave. Doing this would provide the best opportunity for a speed up.

  • msrobotsmsrobots Posts: 3,704
    I am hammered with work right now and moving into a new man-cave, so I have no play time right now. But Chip said to me that the external clocked ADC mode he added could be used digital also.

    I think this will be the solution to my ringbuffer problem, but I hadn't had any time to check this out, yet.

    It might help for spi slave code?

    Mike
  • evanhevanh Posts: 15,187
    edited 2019-11-23 05:02
    msrobots wrote: »
    It might help for spi slave code?
    The prop2 can handle receiving SPI better than transmitting because the SPI clock and data have equal path so present themselves as parallel signals in-step all the way to the smartpin. The number of clocked stages between the pins and the smartpin don't matter then.

    So the first problem with the prop2 being a slave is the limitation of the smartpin tx mode, due to the intermediary stages, cannot be compensated for when the prop2 is not controlling the SPI clock.

    Short answer is, something like sysclock/8 is likely about as fast as you can get.

Sign In or Register to comment.