SPI and "lag bytes"

[mark....@gmail.com]

Hi All,

I am trying to implement a fairly high bandwidth SPI data connection and I am a bit unclear on the "lag bytes" mentioned in the wiki.  My device typically has 0 lag bytes, but if I assume 0 lag bytes, the data I read back is incorrect.  Is there a fixed number of lag bytes inherent to the IOIO-OTG that I need to account for?  I'm not seeing any padding (none of the data is 0xFF, so I am assuming that there are no lag bytes, as I would expect from my device, but the fact that the data appears to be wrong makes me think otherwise.  But I may have other issues I have yet to figure out. I would like to clear up the bit about lag bytes though. Should I account for any on the ioio side of things? Any advice would be appreciated.

Thanks,

Mark.

[Ytai Ben-Tsvi]

The lag bytes feature is merely an optimization, completely functionally equivalent to you manually discarding a number of leading bytes from the response. The optimization works by simply discarding those bytes on the IOIO side, so that they don't have to be sent to the client (Android/PC) and discarded there.

The IOIO is a SPI master, so it should be immune to any timing-related problems (since it is driving the clock).

Seems like there's something else going on. Ideally, if you have access to a logic analyzer, you can probe the SPI lines and figure out what's wrong. Otherwise, just try to really simplify your program to zero in on the problem. What sort of incorrect data are you getting? Are you running at high frequencies (multiple MHz)? If so, are you confident about your signal integrity?

--
You received this message because you are subscribed to the Google Groups "ioio-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ioio-users+...@googlegroups.com.
To post to this group, send email to ioio-...@googlegroups.com.
Visit this group at http://groups.google.com/group/ioio-users.
For more options, visit https://groups.google.com/d/optout.

[Mark Melvin]

Thanks for the confirmation.  I have a logic analyzer and will dig further into things that way.  Likely the problem is on my end.

Thanks!

Mark.

[Mark Melvin]

Hi Ytai,

OK - I got this to work (read back the correct data anyway - it was a clock polarity, and data alignment issue), but I have a bit of a unique situation I was hoping you may be able to help with.  What I am trying to do is get audio data out of a microcontroller connected to the IOIO (16-bit, 8KHz).  I only have the following interfaces on my micro:

SPI (master mode only)

PCM/I2S (stereo audio channel)

UART (kind of inconvenient for me as it isn't wired on the PCB)

I would love to use SPI, but I can't because my device is master mode only, and the IOIO is master mode only.  PCM is almost the same as SPI, except it is a stereo channel, and I already have code that works for my device.  If you connect it to an SPI port on the IOIO, and use the chip select (SS) as the frame/channel signal, it actually works.  And this is what I am doing.  However, the problem is I need to read 2 bytes (a 16-bit audio sample) while the chip select is low, then read 2 bytes from another "dummy" slave so my chip select (acting as the frame signal) goes high for the other audio channel.  This allows me to talk to my micro and I actually get the right data, but it is far too slow.  The overhead to switch slaves is about 0.8 to 1 ms.  Since I need to read out two audio samples essentially every 0.125 ms, I'm about 16x too slow.  Cranking the SPI clock does not help because the overhead between SPI reads is constant. 

Now, I can put my device in PCM master mode where it accepts the clock from the IOIO but it drives the frame signal (which the IOIO can conveniently ignore if I don't MUX it to anything), and then I can increase the bandwidth by a quite a bit, but I still get significant dropouts in between the 64 byte SPI transactions, and the PCM interface being synchronous, well it is just not going to work.

I may be able to sort out some sort of bursted PCM transfer, but I am wondering:

- Is there any plan to support SPI slave mode on the IOIO?

- If not, can the UART go faster than 115200?  That bitrate is still less than I would need to stream the audio data.

Any other clever ideas would be appreciated.

Thanks in advance,

Mark.

[Mark Melvin]

What a difference a day makes!  I found an issue with my PCM code this morning, and it is actually working reasonably well at the moment with my device as a PCM master!  So I guess, don't worry about my last email.  :)

Thanks,

Mark.

[Ytai Ben-Tsvi]

Great! I was going to advise you to use UART, but if you found a way that works - great. Just to answer the question, UART can operate at any rate that is 4MHz/N, with N being [1..65536].