1. Home
  2. Electronics Design
  3. Android and real-time-adjacent monitor/control applications

Android and real-time-adjacent monitor/control applications

Android for monitor/control applications?

I built a few monitor/control systems for use around the house. For historical reasons, they're PALM 3C for high level functions like user interface, math and storage. Serial interface to a microcontroller for raw data acquisition and real hardware for the actual hardware interface and stuff that is too fast for the microcontroller.

As you can imagine, running 24/7, a PALM isn't gonna last more than a few decades. The pile of dead PALM 3Cs is becoming worrisome.

Serial ports have gone away. I experimented with Bluetooth to serial dongles on the hardware end and Bluetooth SPP on the PDA end. That works, but those PDAs are also EOL. Same problem with IR interfaces.

Enter Android.

I've been playing with App Inventor. The jigsaw puzzle analogy makes it easy to cobble together the control/interface part. My concern is the real-time aspects of the process. Anything truly real-time will have to be in the hardware outside the phone. But there are real-time-adjacent issues. App Inventor doesn't seem to have any facilities for atomic functions.

Previously, there wasn't much going on in a PDA.

With an Android phone, there's a LOT of stuff going on. There's a lot of hidden magic between the user and what can go in/out the Bluetooth. That might have significant implications for the size of the data buffers on the hardware end.

While I wouldn't expect precision timing, my app might malfunction if the processor went away for a long time trying to find a cell site or initialize the GPS or overlay an advertisement across the screen. We seem to have less and less control over the crap foisted on us with every Android release.

What's reasonable for easily developed real-time-adjacent apps?

I consider rooting the phone to be VERY undesirable.

There's a lot written about real-time Android. That's not what I'm considering. I'm interested in thoughts/experiences using a standard PHONE Android as a quick and dirty monitor/control interface.

Reply to
mike
Loading thread data ...

On Mon, 14 Mar 2016 02:41:01 -0700, mike Gave us:

Then make a different design choice (obviously) DOH!

Reply to
DecadentLinuxUserNumeroUno

On Mon, 14 Mar 2016 02:41:01 -0700, mike Gave us:

Look at this month's IEEE Process Applications issue..

Reply to
DecadentLinuxUserNumeroUno

I have been using B4A for a while. Much simpler to set up and use than the native Java based programming.

formatting link

Its a Basic-like language, and the compiler translates to Java, hiding all the gory details in the process.

Certainly its not 'real time', but on a modern phone response times sub-second for display updates and so on. Internal operations like looping to scan through a pile of data are very fast.

You do have to get used to the fact that all Android comms is done with asynchronous streams, so none of that is in 'real time', but its still pretty fast.

The processor never really 'goes away' when initialising a long process, you just get a flag set when its done and the result is ready, meantime you can be doing other stuff.

Reply to
Adrian Jansen

I have played briefly with "The App Inventor" also. Isn't this dev tool controlled by MIT, so at any time it may be gone and you have no way to develop new code?

Cheers

Klaus

Reply to
klaus.kragelund

That's true for most anything. At least it's free and the barrier to entry is near zero effort. It makes good use of the native phone functions. Looks like you can just drag one puzzle piece and have instant access to GPS position. That's KOOL.

Reply to
mike

Thanks for the link. Looks like it would be easy to use. I'd have to have a real need to justify the $59 plus the cost of keeping it upgraded.

I do like hiding the gory details. I spent a week trying to cobble together some linux tools around SDCC compiler for the PIC. I gave up when I discovered that I'd already pulled out all my hair.

Pretty fast is a vague statement. The first app I would port accesses a PIC with a 32 character serial buffer. There's not enough RAM to make it bigger. PALM 3C running compiled BASIC has no trouble keeping up, but it's not doing anything else beyond polling the serial buffer until it gets the entire message.

Right now, it's so predictable that I haven't implemented any error checking or recovery capability. Don't think that's gonna fly with a multitasking OS and an input buffer shorter than the message length. The buffer in the serial/bluetooth translator may save my bacon.

Reply to
mike

Your requirements are pretty vague too, so its hard to be specific. And as with all programs, there is more than one way to skin a cat. You would either have to specify exactly what you want to do, and get an expert opinion ( not mine ! ), or play with it yourself.

All I can say is that I never had a problem with speed and response issues in comms between several different programs on AVR processors doing low level stuff, and Android doing the high end, usually using Bluetooth to interface via a psuedo serial port.

Reply to
Adrian Jansen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.