IOIO library v5.00 is released!

[Ytai Ben-Tsvi]

Hey IOIOers,

Almost a year since v4.00, and after hundreds of hours of work, I'm pleased to announce the release of the 5th generation of the IOIO software / firmware!

This version has a lot of stuff that I've wanted to include in a long time: new features (extensive motor control API and Android-host-mode support being the biggest), bug fixes, improved compatibility with Android devices and PC operating systems and more. This update applies to both the IOIO v1 and the IOIO-OTG. See the Release Notes for more details.

While I'm still catching up on updating the Wiki with all the new stuff, but in the meantime, if you're eager to check out the new features, the elaborate Javadocs and the example projects should give you a good start. Even if you're not planning on using any of the new features, I recommend you to upgrade and enjoy the improved reliability (and if for some reason you don't like it, you can always roll back, and make sure to let me know why!).

As a side-note, I've released a new version of IOIODude, which should work better on Linux / OSX than the previous one and a new version of the device bootloader (IOIO-OTG). If you're not currently having any particular problems with the ones you already have, I would recommend not to bother updating - nothing too exciting...

And another side note, firmware v5 is fully backward compatible with your existing apps compiled against earlier versions of IOIOLib, so you don't have to recompile them. If you do want to, however, there are no breaking changes in the API, so your code should compile cleanly against the new library.

So hurry up to the Downloads page and get started.

Special thanks to:

• Misha and Nadir for the Android-host-mode implementation.
• Kusti for the new version of PureJavaComm.
• Matthias for the new version of btstack.

As always, I'm happy for any kind of feedback, so you're all very much invited to reply to this post.

[Al B]

Thanks Ytai for getting this new release out.  I personally appreciate the effort and dedication you put to this crusade.

Quick question. Could I now run/test the ShoeBot application using the new v5.00 release (i.e. are the changes from the pwm-improvements branch in the v5.00 release as well)?

[Ytai Ben-Tsvi]

No, the changes from this branch are have not been directly merged, but equivalent functionality is now available through the Sequencer interface. The application will need to be slightly adapted to the new interface (using "FM speed"-type channels on a Sequencer instead of the current PwmOutputs).

On Fri, Jan 10, 2014 at 12:34 AM, Al B <cagi...@gmail.com> wrote:

Thanks Ytai for getting this new release out.  I personally appreciate the effort and dedication you put to this crusade.

Quick question. Could I now run/test the ShoeBot application using the new v5.00 release (i.e. are the changes from the pwm-improvements branch in the v5.00 release as well)?

--
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/groups/opt_out.

[Markus Kaczmarek]

Amazing!
Does this 

• Added APIs for synchronizing asynchronous I/O operations. For example, it is now possible to write to a DigitalOutput, and then read an AnalogInput that was sampled after the output pin changed its state.

mean that one no longer needs to open and close the digital out when multiplexing matrices? :):)

[Ytai Ben-Tsvi]

Yes!

The wait this works is:

digitalOutPin.write(xxx);  // set the output

ioio_.sync();

float value = analogInPin.readSync();

I'm trying to think of a good way to explain the semantics:

The first write will write to the pin asynchronously, i.e. it will send a message to the IOIO to set the pin state, which will eventually get executed sometime in the near future, after the method has already returned.

Then, the sync method send a "ping" to the IOIO and then blocks until the IOIO sends back a ping. So by the time the ping returns, we know for certain that the pin write has completed. Any message arriving from the IOIO after the ping is also guaranteed to have been generated after the ping has been sent, thus after the output pin has been set. Finally the readSync() method, unlike read(), will block shortly until a new sample has arrived from the IOIO, which is now guaranteed to be fresher than the setting of the output.

I hope this is semi-clear :)

Let me know if that works OK. It seems to in my tests.

--

[Markus Kaczmarek]

Wonderful, well explained and it sounds like just what I need!

I'm getting some strange results in Accessory mode (not at all in Bluetooth or regular ADB by USB). Pin 1 in every column occasionally gets a Lot higher.

Sounds like your solution resolves these kinds of debounce-oriented problems.. 

I'll try my luck with upgrading the firmware and I'll get back to you when I've tried it out. ^^

[kolbe]

Great news. I too appreciate the time you put into the IOIO. I'll update the Basic4Android library and put this new version through it's paces. I'm curious to use the synch methods... this might solve some issues I'm having. Also curious to see the results of  the improved protocol corruption handling. Last but not least I will be checking out the motor control API.

[Markus Kaczmarek]

Ah, I'm afraid there seems to be something missing.

The example apps are referring to IOIOLibAndroidDevice.

I'd download it but I'm on a slow connection and it's getting late.

I'll check it out tomorrow. Cheers!

[Ytai Ben-Tsvi]

Ooops... Good catch. Try again now, I pushed a fixed version.

[Markus Kaczmarek]

I'm sorry Ytai, but I'm afraid I might not have caught the whole problem at first.

Seems the IOIOLib has some strange properties I cannot understand. When I import everything in Eclipse the normal way and just select the whole package, for some reason the IOIOLib folder is imported as IOIOLibAndroid and doesn't contain the sub folders ioio.lib.api and ioio.lib.util.

This causes a whole lot of red exclamations and chaos.

Took me a while to figure out what to do, seems to suffice to just copy the sub folders manually after  importing and refreshing. ^^

[Ytai Ben-Tsvi]

I think what you call the "normal way" is the wrong way.

Please look at: https://github.com/ytai/ioio/wiki/Eclipse-Troubleshooting

It specifically mentions not to import directly from the zip and not to automatically copy the project to the workspace. Is that what you're seeing or is there another problem?

[Markus Kaczmarek]

Ah.. If I'd found That part of the wiki a bit earlier... o_O'

Ok, now it's all good except for the rather cryptic message "Resource already allocated" instead of the good old "Pin already opened" message.

Now I'm getting the following error output when trying to open a UART. 
This was tried with two versions of the same app, one old and (reasonably) bug-free. 

Also, I tried compiling them both with the old firmware package (330) and the new release.

The latter produces this in both cases, the previous not:

  

01-14 18:05:15.774: E/IOIOBaseApplicationHelper(15189): Unexpected exception caught

01-14 18:05:15.774: E/IOIOBaseApplicationHelper(15189): java.lang.IllegalArgumentException

01-14 18:05:15.774: E/IOIOBaseApplicationHelper(15189): at ioio.lib.impl.ResourceManager.alloc(ResourceManager.java:91)

01-14 18:05:15.774: E/IOIOBaseApplicationHelper(15189): at ioio.lib.impl.IOIOImpl.openUart(IOIOImpl.java:454)

01-14 18:05:15.774: E/IOIOBaseApplicationHelper(15189): at se.macke.droidpad.DPMainActivity$IOIO.setup(DPMainActivity.java:359)

01-14 18:05:15.774: E/IOIOBaseApplicationHelper(15189): at ioio.lib.util.BaseIOIOLooper.setup(BaseIOIOLooper.java:20)

01-14 18:05:15.774: E/IOIOBaseApplicationHelper(15189): at ioio.lib.util.IOIOBaseApplicationHelper$IOIOThread.run(IOIOBaseApplicationHelper.java:60)

This error points to the following line:

_midiOut = ioio_.openUart(null,new Spec(MIDI_OUTPUT_PIN,Mode.OPEN_DRAIN), BAUD,Parity.NONE,StopBits.ONE);

That is set up like this in the class body:

private static final int BAUD = 31250;

private static final int MIDI_INPUT_PIN = 6;

private static final int MIDI_OUTPUT_PIN = 7;

/**

* The output for MIDI messages

*/

private Uart _midiOut; 

[Ytai Ben-Tsvi]

Is it possible that your app tries to use the same pin for two different purposes?

[Markus Kaczmarek]

No, the pin is only used on one place. 

I tried a bunch of different pins with the same result, and I'm not getting this message when using the old package.

[Ytai Ben-Tsvi]

Interesting... Can you send a minimum piece of code to reproduce this?

[Markus Kaczmarek]

Sure.. Pretty straightforward:

/**

* This is the thread on which all the IOIO activity happens. 

*/

class IOIO extends BaseIOIOLooper 

{

private static final int BAUD = 31250;

private static final int MIDI_OUTPUT_PIN = 7;

/** The on-board LED. */

private DigitalOutput led_;

/**

* The output for MIDI messages

*/

private Uart _midiOut;

/**

* The stream used for sending the MIDI bytes

*/

private OutputStream _outputStream;

/**

* A class for handling keyboard input

*/

private ButtonScanner _buttonScanner;

/**

* A class for handling fader and knob input

*/

private PotScanner _potScanner;

/**

* Called every time a connection with IOIO has been established.

* Typically used to open pins.

* 

* @throws ConnectionLostException

*             When IOIO connection is lost.

* @throws InterruptedException 

* 

* @see ioio.lib.util.AbstractIOIOActivity.IOIOThread#setup()

*/

@Override

protected void setup() throws ConnectionLostException, InterruptedException 

{

Log.i(DEBUG_TAG,"setup");

led_ = ioio_.openDigitalOutput(0, false);

_potScanner = new PotScanner(this.ioio_, _inputHandler);

_buttonScanner = new ButtonScanner(this.ioio_, AACSmain.this, led_);

_potScanner.start();

_buttonScanner.start();

//Initializing the output

_midiOut = ioio_.openUart(null,new Spec(MIDI_OUTPUT_PIN,Mode.NORMAL), 

BAUD,Parity.NONE,StopBits.ONE);

_outputStream = _midiOut.getOutputStream();

//Increases the priority of the current thread

Thread.currentThread().setPriority(Thread.MAX_PRIORITY);

Log.i(DEBUG_TAG,"setup finished");

} 

/**

* Kills the threads

*/

@Override

public void disconnected()

{

try{

_potScanner.abort();

_buttonScanner.abort();

}

catch (NullPointerException e)

{

System.out.println("Nullpointer error");

}

}

/**

* Called repetitively while the IOIO is connected.

* 

* @throws ConnectionLostException

*             When IOIO connection is lost.

* 

* @see ioio.lib.util.AbstractIOIOActivity.IOIOThread#loop()

*/

@Override

public void loop() throws ConnectionLostException 

{

if (!out_queue.isEmpty())

{

try 

{

_outputStream.write(out_queue.poll().getMessage());

led_.write(false);

Thread.sleep(1);

led_.write(true);

} 

catch (IOException e) 

{

Log.e(DEBUG_TAG,"Problem with MIDI output");

} 

catch (InterruptedException e) 

{

// TODO Auto-generated catch block

e.printStackTrace();

}

}

}

}

/**

* A method to create our IOIO thread.

* 

* @see ioio.lib.util.AbstractIOIOActivity#createIOIOThread()

*/

@Override

protected IOIOLooper createIOIOLooper() 

{

return new IOIO();

} 

[Markus Kaczmarek]

You can just comment out the scanners, they're not causing any trouble. I just included them for the sake of being consistent with my code.

[Ytai Ben-Tsvi]

Yes, it's a bug. I'll fix it on the next release. In the meantime, just put an unused "P" pin for your UART Rx instead of null.

On Tue, Jan 14, 2014 at 1:40 PM, Markus Kaczmarek <markus.k...@gmail.com> wrote:

You can just comment out the scanners, they're not causing any trouble. I just included them for the sake of being consistent with my code.

--

[Markus Kaczmarek]

Ytai, you madman!

The performance increase is incredible with these sync and readSync-methods!

I've measured as little as 40mS between MIDI output messages compared to the previous 200+mS with opening and closing outputs.

Very,very well done. I applaud you. ^__^

[Ytai Ben-Tsvi]

Glad to hear! This is over Bluetooth I presume? USB is expected to get this number down to ~2ms or so.

--

[Markus Kaczmarek]

 I'm afraid not, this is over Accessory mode. Probably my code, I haven't put any time into optimizing.

I'll make a bunch of logging messages and try to find the bottleneck. 

[Synn Yong Tan]

Any tutorial or example for the motor control by using Android ?

[Synn Yong Tan]

Any tutorial or example for the motor control by using Android ? I already tried to write the app but the app is failed.

On Friday, January 10, 2014 1:41:17 PM UTC+8, Ytai wrote:

[Thomas Hermansson]

Good work with the new v5 lib.

Not sure if I am doing anything wrong, but after upgrading to the new lib and trying to use the CapSense functionality, then I get the following error. All other calls works fine (AnalogInput and PulseInput). Do I miss some dependencies?

//Thomas

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): Unexpected exception caught

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): java.lang.IllegalArgumentException: Resource doesn't exist: ioio.lib.impl.ResourceManager$Resource@43389b18

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): at ioio.lib.impl.SpecificResourceAllocator.alloc(SpecificResourceAllocator.java:50)

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): at ioio.lib.impl.ResourceManager.alloc(ResourceManager.java:147)

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): at ioio.lib.impl.IOIOImpl.openCapSense(IOIOImpl.java:370)

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): at ioio.lib.impl.IOIOImpl.openCapSense(IOIOImpl.java:361)

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): at se.tna.krypgrund.KrypgrundsService$1.initialize(KrypgrundsService.java:99)

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): at se.tna.krypgrund.KrypgrundsService$1.setup(KrypgrundsService.java:90)

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): at ioio.lib.util.BaseIOIOLooper.setup(BaseIOIOLooper.java:20)

01-18 17:03:09.511: E/IOIOBaseApplicationHelper(20095): at ioio.lib.util.IOIOBaseApplicationHelper$IOIOThread.run(IOIOBaseApplicationHelper.java:60)

[Markus Kaczmarek]

Tjena Tompa!

How are you setting up your CapSense? Sounds like a similar error to mine when trying to define a Null pin for UART.

Try with different settings in your openCapSense - call and see what happens! ^^

/M

[Ytai Ben-Tsvi]

@Synn: Check these out:

https://github.com/ytai/ioio/wiki/Motor-control

https://github.com/ytai/ioio/tree/master/software/applications/pc/HelloSequencer

https://github.com/ytai/IOIOPlotter

@Thomas: Good catch. Already fixed (on master). I will release a small bugfix 5.01 possibly tomorrow.

@Markus: Already fixed this too. This workaround does not apply to Thomas.

[Ytai Ben-Tsvi]

To all the people who reported bugs on this thread - I just released IOIOLib v5.01, please check it out - should address all those problems.

[Cavin Wen]

Hei,Ytai, I was wondering has this update support for newer devices running androird 4.4 KitKat? I was trying to connect my Note 3 to the IOIO OTG via USB, but it does not connect. However, it does connect through Bluetooth using IOIO Hardware Tester.

[Ytai Ben-Tsvi]

Version 5 did address some problems with KitKat devices. Give it a try.

--

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.