Shop OBEX P1 Docs P2 Docs Learn Events
SPI bus objects / demo's — Parallax Forums

SPI bus objects / demo's

Don MDon M Posts: 1,653
edited 2012-06-10 19:59 in Propeller 1
I want to experiment with the SPI bus. Anyone here have any favorite objects they use or suggest? I will be working with an Android device that "polls" every 2 seconds or so to a PIC processor and utilizes MOSI, MISO, CLK & SELECT. I want to connect it to the Propeller instead of the PIC and respond to those polls.

As you can tell I haven't messed around with SPI before but want to learn more about it. I will use my Logic analyzer to decode the "conversations" going back and forth now with the PIC.

Any help or suggestions appreciated. I looked through the OBEX and found several but am curious as to others thoughts here.

Thanks.
Don

Comments

  • Mike GMike G Posts: 2,702
    edited 2012-06-09 16:46
    Take a look at AN012: Interfacing the Propeller to External SRAM with SPI
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-06-09 16:56
    In my somewhat limited experience, you're often better off modifying a SPI object to fit your particular needs. It seems like there's so much variation in the way devices use SPI.

    After making a custom SPI driver for Nordic nRF24L01+ chips, at the request of Ron Czapala, I made a similar driver using the SPI_ASM object in the Propeller library.

    I also have SPI drivers for SRAM and magnetic encoders.

    Some SPI devices require you to both read as you write to the device. I just posted a piece of code in post #6 here that reads as it writes via SPI.

    Logic analyzers are very useful for debugging SPI protocols. I finally purchased a 16-channel logic analyzer which has finally let me find the bugs in my Noridic code by allowing me to watch two Nordic modules at the same time.

    BTW, the Nordic driver I previously linked to is not very good. I'm close to releasing an all PASM driver that is much faster and if much more useful.
  • Tracy AllenTracy Allen Posts: 6,664
    edited 2012-06-09 17:10
    One good intro to SPI on the Prop is to be found in the BS2_functions object. Look for the shiftin and shiftout methods. They are nicely laid out there for both master and slave.
  • AribaAriba Posts: 2,690
    edited 2012-06-09 18:00
    Don M wrote: »
    ...I will be working with an Android device that "polls" every 2 seconds or so to a PIC processor and utilizes MOSI, MISO, CLK & SELECT. I want to connect it to the Propeller instead of the PIC and respond to those polls....

    This sounds like the Android device is the SPI master. Then you need an SPI slave on the Propeller, which is much harder for the Prop because the master defines the clock rate. Do you know the clock rate of the SPI communication and if the PIC is master or slave?

    Andy
  • Don MDon M Posts: 1,653
    edited 2012-06-09 19:27
    Andy- Good point. I forgot to mention that yes the Android is the Master. I think it is running at around 115K but not positive.
  • Don MDon M Posts: 1,653
    edited 2012-06-10 08:03
    Will the 115K as a slave be a problem?
  • Mike GMike G Posts: 2,702
    edited 2012-06-10 08:37
    Don M, SPI is a mature technology with a lot of openly published information.
    http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus
    AN012: Interfacing the Propeller to External SRAM with SPI
    Will the 115K as a slave be a problem?
    No, the prop can easily handle a 115K clock. The trick is processing the command from the master. Then shifting the response out the prop pins with the correct clock polarity and phase.
  • Don MDon M Posts: 1,653
    edited 2012-06-10 16:01
    So I'm assuming that most if not all of these code demo's are using the Prop as the Master? I'll have time tomorrow to connect the logic analyzer and scope to determine the clock polarity and phasing.

    The reason this has come up is that the PIC as you know uses interrupts. The SPI routine (polled from Master approx every 2 seconds) as I am told uses the highest priority interrupt while the asynch communications from another port on the PIC (9600 baud polled every 20 - 40 mS) is the lower priority. The problem for them has been that the SPI data doesn't always get handled correctly. What I wanted to try and show them was the Propellers capabilities of being able to handle the async communications independently from the SPI communications and everybody's happy since it has the independent cogs.
  • jmgjmg Posts: 15,183
    edited 2012-06-10 18:29
    Don M wrote: »
    So I'm assuming that most if not all of these code demo's are using the Prop as the Master? I'll have time tomorrow to connect the logic analyzer and scope to determine the clock polarity and phasing.

    Also check the turn-around time. Some SPI systems (like memory read as a common example) send a preamble of address bits, and then flip to reading a reply stream.

    Software based systems can need care at that turn-around point.

    Don M wrote: »
    The reason this has come up is that the PIC as you know uses interrupts. The SPI routine (polled from Master approx every 2 seconds) as I am told uses the highest priority interrupt while the asynch communications from another port on the PIC (9600 baud polled every 20 - 40 mS) is the lower priority. The problem for them has been that the SPI data doesn't always get handled correctly.

    Strange, as SPI would be expected to trump Serial here ? Which PIC ? - I don't recall the simpler PICs having a true Priority scheme ?
    Of course, as you say the Prop sidesteps the entire issue..
  • Don MDon M Posts: 1,653
    edited 2012-06-10 19:21
    jmg wrote: »
    which pic ? - i don't recall the simpler pics having a true priority scheme ?
    Of course, as you say the prop sidesteps the entire issue..

    PIC18F25J11 The programmer that was working on this mentioned that he thought it might be some kind of "race" condition in the software that was written for it. However he was unable to identify it.
  • jmgjmg Posts: 15,183
    edited 2012-06-10 19:59
    Don M wrote: »
    PIC18F25J11 The programmer that was working on this mentioned that he thought it might be some kind of "race" condition in the software that was written for it. However he was unable to identify it.

    I had a quick look at a PIC18xx datasheet, and it has this gem

    ["If both low and high priority interrupts are enabled, the stack registers cannot be used reliably to return from low priority interrupts."]

    Ouch indeed. Be interesting to hear how the Prop manages.
Sign In or Register to comment.