On 11/6/2015 7:07 PM, James Cameron wrote:
> I'm puzzled at this. While the underlying parts of a system may have=20
> real-time requirements, there doesn't seem to be much need to extend=20
> the real-time design process all the way up to the human interface,=20
> unless you're dealing with split second decisions, such as playing a=20
> musical instrument or rocketry range safety controls. The=20
> garbage-collected languages have a wider standard deviation of=20
> latency, but they can still be characterised and described. If you=20
> need to infect the rest of the system with the real-time moniker,=20
> don't forget the underlying operating system.=20


A few years ago, I was using Java on Android to receive serial data=20
(over bluetooth) from a PIC-based circuit.  I can't remember the specs,=20
but pretty sure it was only under 100 bytes per second. Simple app that=20
read the incoming data and put it on the screen.  It was very=20
problematic, dropping bytes regularly.  I had an experienced app=20
developer at the time who was working with me on this, and he chalked it=20
up to be a limitation of Java.  Others also suggested I should instead=20
use the NDK for that type of app.  This will be a big part of what I'm=20
doing -- receiving continuous test data from embedded projects -- but on=20
a PC this time, and can't see how Java would be much better on a PC.  I=20
agree, the OS is a also a potential problem, but I'm somewhat stuck with=20
that (as that's what my customers have), and I expect most average PC's=20
would have more than enough HP to handle this.  So maybe I don't need=20
full real-time, but definitely better than the Java I know.

Cheers,
-Neil.

--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.