Do you have a question? Post it now! No Registration Necessary
Threaded View
Subject
- Posted on
posted on March 14, 2016, 9:41 am
Reply
Save
Print
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.
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.
Re: Android and real-time-adjacent monitor/control applications
I have been using B4A for a while. Much simpler to set up and use than
the native Java based programming.
https://www.b4x.com/index.html
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.
Re: Android and real-time-adjacent monitor/control applications
On 3/14/2016 3:18 PM, Adrian Jansen wrote:
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.
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.
Re: Android and real-time-adjacent monitor/control applications
On 15/03/2016 1:45 PM, mike wrote:
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.
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.
Re: Android and real-time-adjacent monitor/control applications
On 3/14/2016 3:50 PM, snipped-for-privacy@gmail.com wrote:
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.
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.
Site Timeline
- » Lithium ion first time charging
- — Next thread in » Electronics Design
-
- » Prototype filter design query
- — Previous thread in » Electronics Design
-
- » AoE x-Chapters, High-Speed op-amps section, DRAFT
- — Newest thread in » Electronics Design
-
- » Tax Refunds are less this year, must be Trumps fault
- — Last Updated thread in » Electronics Design
-
- » AoE x-Chapters, High-Speed op-amps section, DRAFT
- — The site's Newest Thread. Posted in » Electronics Design
-
- » Problem in ADV7611 with Interlace Input
- — The site's Last Updated Thread. Posted in » Field-Programmable Gate Arrays
-
XML Sitemap