• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 99 subscribers
  • Views 491 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Additional SPI on OMAP-L138

Brad Griffis
Guru*** 125430 points
Other Parts Discussed in Thread: OMAP-L138

Is there an easy way to get a 3rd SPI port on OMAP-L138?  I hoped to use McBSP in CLKSTP mode though I see notes saying that CLKSTP mode is not supported on these devices.  :(  Another thought that crossed my mind was PRU, but I wasn't sure what kind of performance I could expect of if anyone had ever tried it.

  • 0
    TI__Mastermind 29141 points

    You can bit bang a SPI using the PRU and it's I/O pins.  Toggling an I/O pin takes one PRU cycle, however the bottleneck will be in getting the data to/from L3 or wherever.  PRU reads from L3 can take ~15 cycles (pad added) and writes about ~5 (pad added).  At 1Mbit rate, you have about 150 PRU cycles in between clock cycles, so I think this is achievable.  Note that with the exception of memory read/write instructions all PRU instructions execute in a single cycle.  Internal memory read/write instructions take two cycles.

  • 0
    Intellectual 280 points

    The Linux spi_gpio driver will let you create more SPI ports from available GPIO pins. My quick tests indicated that 700KHz was the top speed with that bitbanging driver. The spi_gpio driver runs "as fast as possible" so the actual SCLK frequency would vary with system load; it is also impossible to specify a particular SCLK frequency.

    Shameless plug: If you require a specific SCLK speed then you might be interested in my RFC patch [1].

    [1] http://article.gmane.org/gmane.linux.kernel/1065748

  • 0 in reply to Ben Gardiner
    TI__Guru*** 125430 points

    Thank you both for your answers.

    Gus, do you know if the PRU solution would have a mechanism to time the signal properly?  In other words, let's say I assume that 20 cycles is the worst possible latency I'll ever see when reading from memory.  Is there a way that in the case where it only takes 11 cycles that I can poll for 9 cycles while if it takes 18 cycles I poll for 2 cycles, etc?

  • 0 in reply to Brad Griffis
    TI__Mastermind 29141 points

    For bit banging your best bet is to use a timer.  The timer interrupts are routed to a PRU register which can be polled in one clock cycle, so you wouldn't incur the penalty of a register access outside the PRU subsystem.  You'd have to clear the interrupt by writing to a PRU interrupt controller register and that wouldn't be a single-cycle access.  However it would only take one write and I believe writes would be "fire and forget", so that single write should only take a couple of PRU cycles.