IOIO-OTG on a 4.3 android galaxy nexus

[Emmanuel Michon]

Hello, 

I received from sparkfun a ioio board, I could upgrade it this way using ioiodude on a Linux PC :

IOIO Application detected.

Hardware version: SPRK0020

Bootloader version: IOIO0400

Application version: IOIO0500

(I upgraded the app to 0500, I think the rest is out of the box).

Now I'd like to run the app, or some sample ADK-enabled app under Android ; for this purpose I use the red OTG cable, plug the power to 12V, switch on "A", disable ADB debugging on phone, and the phone USB stack recognizes a new hardware. (Not sure it's a host or device at this point, my understanding is that is meant to work with the phone being the device.)

Unfortunately, neither IOIOManager, IOIOHardware, ADK 2012, ADK DemoKit seem to be able to interact with it.

Where can I find an .ioioapp binary (already built please...) to make a basic functional test and blink a led ?

(Btw can the ADK_Beta : firmware/SPRK001?.hex files be fed into ioiodude write!? what is this ?)

Is there hope I can talk to the device with plain C using the NDK ? I'm not fond of java (not at all). I plan to process inputs to outputs using neon assembly so I don't want to lose time running the dalvik nonsense, latency verified with a digital scope.

Thanks...

[Ytai Ben-Tsvi]

Everything "ADK" is completely unrelated.

The software bundle on the downloads page include a few pre-build Android apps (e.g. HelloIOIO.apk).

ioioapp is a different thing, it is firmware for the IOIO, not Android apps.

If you want to use NDK you're looking at quite a lot of development on your end. IOIOLib is pretty elaborate. You'd be going into uncharted territory.

What exactly are you developing that's latency sensitive? Perhaps there's a better way to do it, either by writing only a small portion of your app in C++ or running some of the realtime stuff on the IOIO.

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

[Emmanuel Michon]

Well the page https://github.com/ytai/ioio/wiki/IOIO-Over-OpenAccessory-Beta says ADK is a more recent way to proceed...

Ok I could force the install of HelloIOIO.apk and now I can blink a led. If I can do some remarks, it would be more obvious if the first application found on the market (IOIO Hardware Tester) could work. And also if HelloIOIO had some error message when the device is not plugged in ;-)

Regarding latency, I'm gonna just measure it and see. The USB stack introduces some uncompressible delay too, and indeed running some code on the PIC24 might be possible (I don't know if that one even has a Linux C compiler).

Thanks

[Ytai Ben-Tsvi]

Thanks for the feedback. See inline.

On Wed, Apr 23, 2014 at 9:52 AM, Emmanuel Michon <emmanue...@gmail.com> wrote:

Well the page https://github.com/ytai/ioio/wiki/IOIO-Over-OpenAccessory-Beta says ADK is a more recent way to proceed...

This page is obsolete (as it said at the top).

I updated the newer page that this page links to to avoid the term ADK. Historically, this term was overloaded, referring both the AOA protocol and the reference implementation board that Google provided for it. All the applications on the market that have "ADK" in their name are specific to the Google board running specific firmware. They are irrelevant to the IOIO.

 

Ok I could force the install of HelloIOIO.apk and now I can blink a led. If I can do some remarks, it would be more obvious if the first application found on the market (IOIO Hardware Tester) could work.

I'm not responsible for said application, nor for which applications get displayed first on Play. You are welcome to contact the owner of that app and suggest that they update their app to support AOA.

 

And also if HelloIOIO had some error message when the device is not plugged in ;-)

It is not an error for the device to not be plugged in, but your feedback is fair:

I'll make sure the UI widgets are disabled when the IOIO is disconnected and that descriptive toasts pop-up on connection, disconnection, and incompatible firmware version is detected. I'll try to release this update soon, since you're not the first to have been bitten by that.

 

Regarding latency, I'm gonna just measure it and see. The USB stack introduces some uncompressible delay too, and indeed running some code on the PIC24 might be possible (I don't know if that one even has a Linux C compiler).

There are PIC24 compilers (and IDE) for Windows / Linux / OSX.

If you can state your goal I might be able to advise you on how I would approach it.

[Emmanuel Michon]

Thanks for your support.

Regarding the work to achieve, I write floating-math-bloated 32-bit C-code on a Linux PC or ARM laptop, and would like to avoid a re-debugging phase on the target ;-) I'll see what I can do on the PIC24 directly.

[Ytai Ben-Tsvi]

I meant what are the I/O related timing sensitive requirements that you have?