Android for T&M products

[kerpal]

In the Test & Measurement world, the common embedded operating systems used are Linux, FreeROTS, Wind River vxWorks, Windows CE, etc.

With Android undergoing massive development (way more development than others such as WinCE), plus the recent direction to deploy Android on cars, does it make sense for companies like NI and Rohde to use Android?

I've google'd it, but the data is pretty out of date.

The reason I ask is because I work a for smaller firm in the same industry, and we are wondering which OS upgrade is the best given today's situation and development.  So, for discussion sake, I've picked Windows CE 7.0 vs Android as a comparison, and listed the pros and cons here as a start:

Windows CE 7.0:
Pros:

• Allows code to be written in C++, which is a good language to write optimized DSP code, and also perform low-level hardware access.
• Tools set is pretty decent

Cons:

• Frustrated with limited API (it is always a subset of the desktop version)
• Available GUI frameworks are pretty much outdated (outdated as in pre-MultiTouch era).  Let's assume that developing a modern UI is a crucial requirement for the next project, so investing into WinCE 7.0 might be a stumbling block with limited modern UI framework.

Anroid:
Pros:

• It is new and undergoing aggressive development.
• It is developed to support Multi Touch and advanced graphics from the ground up, so MT support is rich, unlike the older OSes which can only provide "plug-ins" or "extentions" to a mouse-based operating system
• New hardware support (Quad Core CPUs, Bluetooth LE, NFC, etc ... let's assume we want this in a future T&M product)
• Rich, modern GUI support.

Cons:

• Java may not be the best language for a computationally-intensive product.  Android does provide an NDK to allow code to be written in C++, but the additional layer of translation will be an overhead, and is even not recommended by Android.
• Probably unable to access hardware freely like we could on the older OSes which are created for this purpose.

Any thoughts and opinions are appreciated in the decision making.  To summarized a bit, here are some of our requirements and considerations:

• We are a niche firm, so are not bounded by the rules and direction that larger companies like NI and Rohde are taking
• No more mouse-based or button/knob-based GUI.  We are fully commitment to modern GUI, ala iOS/Android

[djacobow]

This is an interesting question. I am sorry that nobody more knowledgeable has responded yet.

I'm afraid I'm not such a person, but it seems that because Android is a flavor of Linux, you could create your own kernel-mode drivers for talking to your hardware and you could put hard dsp in those if necessary. Alternatively, in the worst case scenario, you could hack the kernel itself if it were required.

I'd spend some time on the Google doc pages for people porting hardware devices to Android.

[dr.diesel]

Since we don't know specifics about your intended target, it is somewhat hard to advise.

As you've already said, WinCE isn't even a blip when compared to Android on the mobile front, but is your device to compete in this area?  Are you going to deploy smart phone/tablet apps as a companion to this device as well?  Do you need hardware IO/touch screen/wired networking/wireless/bus support?

You didn't mention cost, although it's cheap to buy WinCE licenses, it's not free.  If you end up manufacturing these in the millions it's a valid consideration point.

If I had to pick based on what you've said above, Android it is.

[AndyC_772]

If you're trying to produce a piece of T&M equipment, I'd argue that for the reasons you've highlighted, running Android on it could be a huge mistake.

A piece of T&M kit is not a mobile phone. It's not a device which is sold on how nice it looks, and on how many completely different uses it can be put to. It's not a fashion accessory, nobody will be playing games on it, and more than likely, no third parties will ever write software for it.

The product needs to do one thing, and to do that one thing exceptionally well to the exclusion of all else. Its UI needs to be effortlessly responsive, and anything which gets in the way of its one and only software application accessing the UI controls and underlying hardware can only be a hindrance.

As you've probably gathered, I'm very much opposed to the use of PCs and phones as T&M devices. A PC is a useful logging and post-processing tool, of course, but as a way to operate a measurement device directly, clicking on things with a mouse (or, worse still, poking at pictures on a screen with a fat, greasy finger) sucks compared to real knobs and buttons.

You refer to a GUI not involving knobs or buttons as "modern", but I'm afraid I disagree. Such a GUI has its place on a phone, for entirely practical reasons, but not on a piece of T&M gear. Choose a UI that really works well, not just one that's fashionable this week.

[dannyf]

I think you got it right (I would have used WP8): WP8 allowed better use of existing code. Android has easier development tools, particularly when it comes to a GUI.

I would go with Android myself.

[dr.diesel]

Still lots of speculation here.  But if a mobile type device, likely Android, but if a piece of long term T&M, probably Linux.

[psycho0815]

Still lots of speculation here.  But if a mobile type device, likely Android, but if a piece of long term T&M, probably Linux.

Sorry for the nitpicking, but android, underneath all the gui goodness is still embedded linux. So in theory you schould be able to do anything you can do on any other linux-platform.
That said i have no idea whether android could be run with a realtime kernel. But then i guess most of the realtime stuff would propably be done in an asic or fpga anyway.

[codeboy2k]

I would not be afraid to use Android here.  You can highly customize it, and it is indeed a fully embedded Linux with a well known and easy to program UI.  Normal Android startup launches the Android custom init code (like every desktop Linux has init, process id 1) but this Android's init is custom and very different from the Linux init (I like it, actually!) It reads it's own init.rc file, which does a bunch of set up, initialization, starts daemons, sets networking parameters and some system properties that can be read globally (from sh scripts, C code and java), and launches the Android runtime.

Anytime in the init.rc you can launch your own executable that was written in C and make a service from it.

service myservice /system/bin/TheADCservice
 user adcuser
 group adcuser

These services can do the heavy lifting for your hardware

After launching the services and setting properties, it starts the Android zygote process (the dalvik vm) and the Activity Manager, which starts reading the XML files to launch the core apps that make up the Android platform on a mobile device.

For your embedded device you can remove a lot of that, and just continue with the Zygote and the Activity Manager, and launch your own custom Android Activities that make up your UI.  You do not need anything else, and you can present one simple UI written in Java using the standard Android API. The UI application reads and intereracts with the services in C.  Your UI app never needs to exit.

Easy-Peasy

more information on the Android boot steps and the init.rc language is here:
booting: http://elinux.org/Android_Booting
init:       https://github.com/android/platform_system_core/blob/master/init/readme.txt

[dr.diesel]

Sorry for the nitpicking, but android, underneath all the gui goodness is still embedded linux.

This is a HUGE misconception.  The only thing Linux about Android is the kernel, and it stops there.

[psycho0815]

Sorry for the nitpicking, but android, underneath all the gui goodness is still embedded linux.

This is a HUGE misconception.  The only thing Linux about Android is the kernel, and it stops there.

Again with the nitpicking, but the only thing Linux about any Linux Distribution is the kernel, as Richard Stallmann likes to point out.
The rest is mostly GNU-Tools X-Windows and Stuff. Admittedly Linux has become almost sinonymous with GNU/Linux these days, it's still technically wrong.
Btw most non-X GNU-Tools can be run on Android if you have a shell. 

[Monkeh]

Sorry for the nitpicking, but android, underneath all the gui goodness is still embedded linux.

This is a HUGE misconception.  The only thing Linux about Android is the kernel, and it stops there.

Again with the nitpicking, but the only thing Linux about any Linux Distribution is the kernel, as Richard Stallmann likes to point out.
The rest is mostly GNU-Tools X-Windows and Stuff. Admittedly Linux has become almost sinonymous with GNU/Linux these days, it's still technically wrong.
Btw most non-X GNU-Tools can be run on Android if you have a shell.

And I will continue to gleefully refer to it as Linux, because rms is a fruitcake.

[psycho0815]

Sorry for the nitpicking, but android, underneath all the gui goodness is still embedded linux.

This is a HUGE misconception.  The only thing Linux about Android is the kernel, and it stops there.

Again with the nitpicking, but the only thing Linux about any Linux Distribution is the kernel, as Richard Stallmann likes to point out.
The rest is mostly GNU-Tools X-Windows and Stuff. Admittedly Linux has become almost sinonymous with GNU/Linux these days, it's still technically wrong.
Btw most non-X GNU-Tools can be run on Android if you have a shell.

And I will continue to gleefully refer to it as Linux, because rms is a fruitcake.

Now that's an entirely different discussion.

[Monkeh]

Sorry for the nitpicking, but android, underneath all the gui goodness is still embedded linux.

This is a HUGE misconception.  The only thing Linux about Android is the kernel, and it stops there.

Again with the nitpicking, but the only thing Linux about any Linux Distribution is the kernel, as Richard Stallmann likes to point out.
The rest is mostly GNU-Tools X-Windows and Stuff. Admittedly Linux has become almost sinonymous with GNU/Linux these days, it's still technically wrong.
Btw most non-X GNU-Tools can be run on Android if you have a shell.

And I will continue to gleefully refer to it as Linux, because rms is a fruitcake.

Now that's an entirely different discussion.

That it is.

Remind me to toy around with a BSD userland again.

[codeboy2k]

RMS may indeed be a relentless, stubborn fruitcake, but he does raise some valid points. Without the FSF and the GNU Project, none of the tools that make up the core of a modern distribution based on the Linux Kernel would exist, in their current form.

Sure, you could argue that someone else would have just written those tools instead, but that's not how it went down. The developers of the GNU Project did indeed develop many of the original core utilities and necessary development tools that make up a "GNU/Linux" distribution (RMS coined that term).  However, I put that in quotes because I do not believe that a modern Linux distribution contains mostly GNU code anymore, and it is a disservice to everyone else who is not part of the GNU Project but also contributed to the development of a modern Linux distribution to call it "GNU/Linux" .  So I will always call it Linux or a Linux distribution, no matter how much RMS jumps up and down.

[kerpal]

I would not be afraid to use Android here.  You can highly customize it, and it is indeed a fully embedded Linux with a well known and easy to program UI.  Normal Android startup launches the Android custom init code (like every desktop Linux has init, process id 1) but this Android's init is custom and very different from the Linux init (I like it, actually!) It reads it's own init.rc file, which does a bunch of set up, initialization, starts daemons, sets networking parameters and some system properties that can be read globally (from sh scripts, C code and java), and launches the Android runtime.

Anytime in the init.rc you can launch your own executable that was written in C and make a service from it.

service myservice /system/bin/TheADCservice
 user adcuser
 group adcuser

These services can do the heavy lifting for your hardware

After launching the services and setting properties, it starts the Android zygote process (the dalvik vm) and the Activity Manager, which starts reading the XML files to launch the core apps that make up the Android platform on a mobile device.

For your embedded device you can remove a lot of that, and just continue with the Zygote and the Activity Manager, and launch your own custom Android Activities that make up your UI.  You do not need anything else, and you can present one simple UI written in Java using the standard Android API. The UI application reads and intereracts with the services in C.  Your UI app never needs to exit.

Easy-Peasy

more information on the Android boot steps and the init.rc language is here:
booting: http://elinux.org/Android_Booting
init:       https://github.com/android/platform_system_core/blob/master/init/readme.txt

Interesting points.  Thanks for pointing out the possibilities with Android.  I'll definitely look further in that direction.

Doing all the measurement stuff in C++ and the GUI stuff in Java seems like a good idea at this point.  It opens up the possibility with catching up with the modern GUI stuff, while maintaining good performance at the analysis side.  I wonder what others may think about having to deal with 2 languages in a project.

[dr.diesel]

I wonder what others may think about having to deal with 2 languages in a project.

It's done all the time.

[psycho0815]

I wonder what others may think about having to deal with 2 languages in a project.

It's done all the time.

Absolutely. Especially if you count all the markup languages as well.
Professionally i only write bussinesapplications but even then it is not unusal to, for example write some module of a project in cobol because it has to interface with some really old legacy stuff and do the rest in Java. And then of course theres all the xml/html-stuff but YMMV whether or not those are languages.

I know from our automation-guys, that they would normally do all the low level stuff in C/assembler/SPS and the UI and networking and such in something more highlevel.

So yeah i'd say that's pretty common.

[codeboy2k]

One further advantage is that you can also develop your UI on a desktop using the Android emulator, and even set the screen width you need to match your actual device in production (i.e. it doesn't have to look like a phone anymore )

I actually run Android X86 using VirtualBox on my desktop rather than the Google supplied Android ARM emulator (which is slower since it emulates an ARM CPU on top of x86).  I can run emulated device drivers and test the UI with that. I have custom screen widths at my startup so I can start up an Android system with a number of different screen widths as needed for development.  It works great!

http://www.android-x86.org/

[Bored@Work]

I would think twice about using Android. The thing is, it cold-boots slowly on top of the Linux kernel. You can pretty much tune the kernel to boot up very fast by following the book. But the Android framework coming up on top is another story. You'd have to creatively fine-tune it. Or you have to have your instrument constantly powered and just put the OS in sleep mode.

[MarkL]

In the Test & Measurement world, the common embedded operating systems used are Linux, FreeROTS, Wind River vxWorks, Windows CE, etc.

[...]

The reason I ask is because I work a for smaller firm in the same industry, and we are wondering which OS upgrade is the best given today's situation and development.  So, for discussion sake, I've picked Windows CE 7.0 vs Android as a comparison, and listed the pros and cons here as a start:

To me, the contrast in all these choices is more about open vs. closed source.

When you have access to the source code for everything that's running on your new hardware, you have far more control over your own destiny (and whether that be success or failure).

I also work at a small company that does embedded systems, and we repeatedly encountered situations where we had little to no leverage in getting our closed-source suppliers to fix problems because of our relatively low volume.  A couple of times we even got answers to the effect, "Ok, yes that's a bug.  Now... How many more of these widgets/licenses are you going to buy if we fix it?"  That really drove home the point that we were at the mercy of larger companies and our ultimate disposition didn't really matter much to their bottom line.

So, if you're Agilent or R&S sized, have your pick based on other criteria.  But for a small company, I would also carefully consider the support relationships and commitments in cases where you're essentially delegating control of your product.

[Maxlor]

When you're talking about T&M equipment, you're talking about a closed system where the software has a singular purpose. What advantage does Android give you there? You probably don't want an ecosystem with apps and whatever. So why not just stick to plain Linux? Development would become much more flexible in terms of tools you can use, and at this point there are probably more devs familiar with the low level details.

Yeah, GUI-wise it'll be easier to develop a nice touch-driven app on Android... but imo knobs and buttons work a lot better for T&M equipment than a touch screen.

[daveshah]

I would think twice about using Android. The thing is, it cold-boots slowly on top of the Linux kernel. You can pretty much tune the kernel to boot up very fast by following the book. But the Android framework coming up on top is another story. You'd have to creatively fine-tune it. Or you have to have your instrument constantly powered and just put the OS in sleep mode.

That's a very good point. Most Android devices take at least 20-30 seconds to boot, whereas pure Linux can easily be made to boot in under 5 seconds.

[codeboy2k]

I just booted my Android emulator.. It displayed a # prompt after 1 second (!) and then had the UI running in 5 seconds.

It's not that slow.  Android bootup on mobile phones is slow because it's doing all that security sandboxing crap that it does on the SD card. it's bind mounting stuff, making symlinks, setting a whole lot of property strings into the properties database, and who knows what else before it shows the UI.   I expect that an embedded Android controlling a T&M equipment would not have so much to do.

It also depends on the processor , and a slow processor is going to boot slow, but any modern ARM is going to be fast enough.

Granted, you don't need the whole "eco-system" of Android, but there is a distinct advantage to having access to that eco-system, and the numerous websites and developers out there that are using the Android API and blogging about how they accomplished something.  Plus books and programmers are readily available.

I am a proponent of lightweight systems, and I don't like bloat, so I am advocating tuning any Android platform used for an OS in T&M into a lean machine. It can be done.  And you retain all the advantages of using a well known and familiar platform.

[Harvs]

Cons:

• Java may not be the best language for a computationally-intensive product.  Android does provide an NDK to allow code to be written in C++, but the additional layer of translation will be an overhead, and is even not recommended by Android.
• Probably unable to access hardware freely like we could on the older OSes which are created for this purpose.

I've been doing quite a lot of development with Android of late for communicating with industrial embedded applicaitons, I like it but it's quite different from your scenario.  Just one point though about computationally intensive applications.  The NDK is really meant for running legacy code, not high performance.  Android does have RenderScript, which to a degree is somewhat like CUDA for nvidia.  You need to have a look at it to see if it's suitable for your application, but it does provide a mechanism to achieve computationally intensive tasks that (in some cases) can utilize both multi-core cpus and the gpu in a hardware agnostic manner.  However, gpu support is fledgling and depends on Android API version and hardware.

[Someone]

Avoid WinCE. It's horrible. We used it on a product with touch interface and it was just a disaster. Trying to get the OS to boot quickly, have a 3D accelerated GUI so it looks like it was written this century and keep power consumption down was a nightmare.

Android is ideal. You can customize it to your needs easily as it is completely open source. Native code works perfectly, no performance issues, well supported and easy to interface to Java if you want to write you app in that. Full access to all hardware, and you can use any Linux driver you need.

Any driver you like but linux is not the first thought for most people making a device rather than a host.

When you're talking about T&M equipment, you're talking about a closed system where the software has a singular purpose. What advantage does Android give you there? You probably don't want an ecosystem with apps and whatever. So why not just stick to plain Linux? Development would become much more flexible in terms of tools you can use, and at this point there are probably more devs familiar with the low level details.

Yeah, GUI-wise it'll be easier to develop a nice touch-driven app on Android... but imo knobs and buttons work a lot better for T&M equipment than a touch screen.

The underlying OS just provides a shortcut for developing various features, android focuses on UI and mobile phone oriented needs while a piece of electronic test equipment is usually more concerned about its features as part of a larger automated system. So you'd want strong support for one or more of operating as a device over:
USB, GPIB, SCPI, LXI, serial