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. On Wed, 15 Apr 2015 at 15:31 Mark Melvin <[email protected]> wrote: > 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. > > On Wed, 15 Apr 2015 at 13:53 Ytai Ben-Tsvi <[email protected]> wrote: > >> 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? >> >> On Tue, Apr 14, 2015 at 8:26 PM, <[email protected]> wrote: >> >>> 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. >>> >>> -- >>> 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 [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/ioio-users. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at http://groups.google.com/group/ioio-users. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/ioio-users. For more options, visit https://groups.google.com/d/optout.
