MCU choice is really a matter of taste. I think that even if you go SPI to a separate MCU you might have to do some IOIO firmware work in order to meet the high bandwidth requirements that you have. At this point, you're probably better off just doing the whole thing on the IOIO rather than adding additional complexity. Doing something 128K times a second on a 16MHz micro, while still having some spare for other tasks is a challenge, but might be doable. It is certainly worth a try IMO, since it is still relatively simple compared to other options. Another not-too-hard possibility is to look at some of the ADK-type boards. Some of these have faster micros than the IOIO's (for example Microchip's PIC32 based board or the Pinguino). The main drawbacks compared to the IOIO:
- Only works on Android 4.x (requires OpenAccessory support). - Provides a rather low-level interface, where you'll need to do a lot of what the IOIO does yourself, in terms of getting data from side to side using some communication protocol. Might not be terribly hard in your case as you have very specific requirements. On Wed, Feb 19, 2014 at 10:10 PM, Colin Webber <[email protected] > wrote: > Thanks for your response Ytai. > > Yes, there are a lot of 16ch muxes but at these levels it remains cost > effective for the application. I had considered that the long wires might > be an issue but did not consider the noise created by passing through > multiple mux levels. However for this particular application I only need > to detect large and sustained changes in value so small spikes will be > ignored. > > I think your latency question ties in with my original query about needing > something similar to the Motor Control API but it seems that MC only allows > synchronization of output signals. My concern was that I would address a > set of mux channels using digital outputs then read the 16 input values, > but that the inputs would not yet have transitioned from the previous > values. Getting the values mixed up would be disastrous so I need to be > certain that this will work at 2Hz. I could read in the inputs as late as > possible, i.e. directly before changing the outputs to address the next > set. There is no need for real-time detection - a delay of a several > seconds (with transmission to the Internet etc.) is fine, but accurate > addressing is critical. > > Your custom firmware suggestion is something I hadn't considered... shift, > sample, send would avoid the above problem. Also the SPI and faster micro > are great ideas. Do you have any suggestions of micros that would meet > these requirements, preferably one that you have personally hooked up to > IOIO using SPI? > > Much appreciated. > > > On Tuesday, February 18, 2014 6:44:16 PM UTC+2, Ytai wrote: > >> That sounds interesting and challenging for various reasons: >> >> - If you use, say 16x muxes, you'd need >4000 of them. Lots of $$ and >> a complicated assembly. >> - At this fan-out, the depth is going to be at least 4 (i.e. 4 muxes >> to go through before getting to the ADC) - meaning that it may be a >> challenge to avoid excessive noise on the signals. Probably the wires are >> going to be long as well, which is yet more susceptible to noise. >> - At 2Hz we're talking about 128Ksps, which is a non-trivial data >> rate to handle with the IOIO and over USB, but might be doable with some >> effort. Do you have any strict latency requirements? >> - Having said that, I would either go with custom firmware on the >> IOIO, which does just that (shift, sample, send over USB) or with a >> separate (possibly faster) micro. If you want the data to go to Android >> eventually, you can probably use a SPI link between a IOIO and that micro. >> >> >> >> On Tue, Feb 18, 2014 at 6:20 AM, Colin Webber >> <[email protected]>wrote: >> >>> I would like to read 65536 analog signals and be able to identify the >>> source. Note that the analog signals do not change rapidly, i.e. this is >>> not audio, however reading each signal twice per second would be desirable. >>> >>> My plan was to use a stages of analog multiplexers driven by >>> daisy-chained shift registers, which are in turn driven by three digital >>> outputs on the IOIO-OTG. The digital outputs will essentially act as a >>> counter, indexing which 16 analog signals should be routed to the IOIO >>> inputs. >>> >>> Would it be possible and/or advisable to use the new Motor Control API >>> in order to ensure that the signals are correctly indexed, or is this an >>> unnecessary complication? >>> >>> -- >>> 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/groups/opt_out. >>> >> >> -- > 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/groups/opt_out. > -- 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/groups/opt_out.
