Hi Ytai, Thanks for the clarification. I'll use a single IOIOLooper then from my app and pull that out of my TWI class. I implemented my Send/Receive method to call twi_.writeRead using Java's java.util.concurrent.FutureTask and it works pretty slick. I'm pretty happy with this little unit so far. Nice work! :)
Regards, Mark On Mon, Dec 15, 2014 at 11:33 PM, Ytai Ben-Tsvi <[email protected]> wrote: > > This is not the intended usage of IOIOLooper. You're supposed to have only > one IOIOLooperProvider per app and the framework will use it to create your > IOIOLooper implementations, one per possible IOIO connection. > From the setup() method of your looper you can create as many threads as > you want, passing them the IOIO instance, in case you want to do stuff in > parallel. The IOIO APIs are all thread-safe. Make sure those threads are > either killed explicitly or exit upon a ConnectionLostException. > > A common pattern around I2C devices is to have a class per device driver, > which is initialized with a TwiMaster and an I2C address. For example: > > class MyI2CDevice { > public MyI2CDevice(TwiMaster twi, byte address) { > ... > } > > public DoStuff() throws ConnectionLostException, InterruptedException { > twi_.writeRead(address_, ...); > } > } > > Then, instantiate this guy from your Looper's setup() method and poll it > ("DoStuff()") from either loop() or a separate thread. > > On Mon, Dec 15, 2014 at 2:46 PM, Mark Melvin <[email protected]> > wrote: > >> Hi There, >> >> I am developing a PC app that will utilize a couple different aspects of >> the IOIO. In particular, I am starting with the TWI (I2C) and GPIOs. I >> have implemented a nice TWI class that is also a IOIOLooperProvider, and it >> works well. Now that I am starting to implement my GPIO stuff, I find >> myself polluting my TWI class with GPIO code. Looking more into the API, I >> thought of two approaches: >> >> 1) Have a single, more multi-purpose IOIOLooper that creates the TWI >> interface and hands it off to the TWI class, and also manages the GPIO >> stuff. >> >> 2) Create two separate IOIOLoopers that each do their own thing, and >> somehow get two of them up and running over one USB connection to the board. >> >> I know I can implement #1, but this makes a pretty specific IOIOLooper >> that does everything, while #2 seems like a more flexible and generic >> approach, but I don't know if this is possible or even the intent of the >> API. What is the intended way to do this? A brief look at the code seems >> to indicate it might be possible, but I can't tell yet if multiple >> IOIOLoopers can share the same connection or if they are intended to be >> used one per connection. >> >> Thanks in advance for any advice, >> 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.
