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 On Mon, Mar 9, 2015 at 8:08 PM, Michael Grundvig <[email protected] > wrote: > 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 > > -- > 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.
