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. On Wed, 15 Apr 2015 at 23:33 Mark Melvin <[email protected]> wrote: > 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.
