Azul was having some issues reading data coming back from a custom script running on an Arduino Mega, so I thought I'd make a small script which demonstrates how to do asynchronous reading.

The script requires no hardware, because it uses a Virtual Serial Port (COM77_uart).

I used the swing gui, because its better at displaying python errors, although the webgui has a better send interface (swing one grows for some reason :P)

Anyway I type in one, and messages are printed in Python.  I selected 'X" as a delimeter between messages, but it could be anything the serial device sends.

Hope this helps

[[home/GroG/serialMsgs.py]]

Going through this simple example, I found some "good" & "bad"

The Good

This addByteListener is great !  
And this is why..  the interface is extremely simple - just the name of the service.
String interfaces can be easily supported in HTTP GET requests - so to add a byte listener you could do this:
       

                   http://localhost:8888/api/services/serial/addByteListener/python

Another exiting thing is Serial has two methods of communication - the regular pub/sub and an optimized native Java callback - this one method determines if it can use the optimized callback or drops back to the pub/sub automatically.  Very cool !

	public void addByteListener(String name) {
		ServiceInterface si = Runtime.getService(name);

		// if (si instanceof SerialDataListener && si.isLocal()){
		if (SerialDataListener.class.isAssignableFrom(si.getClass()) && si.isLocal()) {
			// direct callback
			listeners.put(si.getName(), (SerialDataListener) si);
		} else {
			// pub sub
			addListener("publishRX", si.getName(), "onByte");
			addListener("publishConnect", si.getName(), "onConnect");
			addListener("publishDisconnect", si.getName(), "onDisconnect");
		}
	}

Now The Bad

This is out of Spec !!!

addListener("publishRX", si.getName(), "onByte");

it should be publishByte !!  If the callback is expected on onByte !!!

I think it grew into publishRX because at some point it became desirable to publish both tx & rx bytes.
But most subscribers would typically want to consume rx bytes .. and I think would expect to find a publishByte

Should I fix it ?