Using Multiple IOIO OTG Boards Question and Some Friendly Suggestions

86 views
Skip to first unread message

Michael Grundvig

unread,
Mar 10, 2015, 12:01:20 AM3/10/15
to ioio-...@googlegroups.com
First off, thanks very much for creating a Java-powered IO board. For all my projects that need a lot of IO, I've ended up using the Phidgets 0/16/16 board and while it works well, it's a whopping 100 bucks a board for just 32 digital IO pins. Sparkfun's site showed the IOIO OTG and I ordered it immediately and had it wired up and working in just a few minutes after it arrived. I think it will be perfect for my next few planned projects. Combine it with a Raspberry PI and you have a powerful Java-based system that is cheap enough to leave embedded in the project which is especially nice!

Now, onto my question. My next project will need three IOIO boards and I'm trying to figure out the best way to address/sequence them. I see I get an "Object extra" on createIOIOLooper but after checking, it's just a string that says "COMx". As COM ports are assigned when things are plugged in and removed they are pretty fluid. This makes for a bit of a problem because when I move the display around I have to reconnect everything in a specific sequence as I can't ensure which IOIO board is which and their physical orientation is critical to the app working. In this specific project, I can get away with bringing one of the IO pins I'm not using low and check for it in code but that's a pretty sloppy solution. Is there a better way to physically identify a board rather than just the COM port? Ideally the API would expose some unique ID or allow us to assign an ID to a board. That would totally solve this problem.

Next, I have a couple of suggestions that might lower the barrier of entry for us desktop users based on my initial experience. 
  • Compiled jars - I was really surprised that I had to compile the source for a project. It's been a long time that an open source API I used didn't have already compiled jars. This isn't a big hurdle but it does make it a bit of a hassle for new devs. It also makes it very unclear what versions of the API code I have unless I set up a local repo for this and such. Just not something I'm going to bother to do for a small project. 
  • Non-IDE specific tutorials - unfortunately the tutorials are based around Eclipse. While that's obviously a popular IDE, it's really limiting as many of us don't use Eclipse or are looking for actual details of the API, not details on how to configure Eclipse. I would have been very happy with a simple list of current jars to use and a quick HelloWorld snippet I could cut and paste. The specific jars to use were the most unclear as they are very nicely broken down into PC vs. Android and such but it's not trivial to find which are needed in what context without some digging. 
  • What about using a build tool like Gradle? Obviously Google is going this direction and it's a pretty superb tool all around (we use it on a massive project at work with a huge number of dynamically version-ed modules and its been rock solid). Sadly Eclipse has pretty mediocre support for it (I'm not an Eclipse fan in general though, so I admit bias) but it still works nicely and is completely environment agnostic. Even using it purely command line is very easy with a Gradle wrapper setup. 
  • In the same vein, why not get the jars into the Central Maven repo? That would make IOIO even easier to get started with as you just have a few dependencies and let 'er rip. Overall, it just makes everything simpler.

Anyways, this project is great and I'm really excited to see a Java-language project take off. Is this group open to patches and enhancements to the Java api being submitted? I saw a few things I thought I could contribute if that's on interest. Thanks again for all the amazing work!

-Mike

Ytai Ben-Tsvi

unread,
Mar 10, 2015, 1:07:09 AM3/10/15
to ioio-...@googlegroups.com
Thanks, Mike!
Re differentiating boards, on the USB level there are OS-specific differences:
  • On Windows the port assignment is pretty non-deterministic.
  • On OSX, the device (file) name depends on which USB port it is connected to.
  • On Linux, you can access by connection or serial number.
So it doesn't seem like there's an easy way to secure a consistent name on all OS. Also, currently there is no serial number programmed, but this is solvable with some effort.

An easy alternative for you is to either jumper some of the unused pins to act as an ID (for example, decide that pins 45-46 on each board act as ID, where on one both will be shorted to GND, on one only 45 and on one only 46). You can even be clever and distinguish between "GND", "3V3" and "un-connected" if you open each pin twice, once with a pull-up and once with a pull-down. A similar alternative is to connect an external EEPROM over I2C to each of your boards. Many EEPROMs have built in unique serial numbers, and if not, you can use the EEPROM itself to write an ID.

As far as how the software should be delivered: initially, the main use case has been Android. The official way to distribute libraries was in source + Eclipse project form. Sux, I know, but JARs aren't sufficient for all the metadata. Now that Android has moved to AS / Gradle I'm very open to moving. Maven is something that has been discussed as well and I'm very interested in doing that. Essentially, the fewer number of steps for setting up "Hello World" and the less boilerplate code, the better. Only problem is that I'm not personally familiar with state-of-the-art ways of doing these things. I've previously called out for people on the mailing list to help out, but nobody stepped up (well, some did, who admitted to not being too sure about how this "should" be done). If you think you know how to do this right, please let me know. I'd like to discuss some details with you before you spend any efforts, just to make sure we're on the same page and that you're aware of all the relevant work-flows.

Ytai

--
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.

Raymundo Cornejo

unread,
Aug 3, 2015, 12:28:57 PM8/3/15
to ioio-users
Any update on the Maven? I have an app on Android Studio where I want to integrate the IOIO board.

Thanks

Ytai Ben-Tsvi

unread,
Aug 3, 2015, 12:31:46 PM8/3/15
to ioio-...@googlegroups.com
If you're anxious to get started and can't wait for an official release, check out the gradle branch on github. If you run "gradle build" it will produce the jars/aars for you and the example applications demonstrate how you should author your apps as far as integrating with the IOIO libraries.
There will probably be some minor changes before this code makes it into master, but it should bring you fairly close to what you're after.
Reply all
Reply to author
Forward
0 new messages