Android for T&M products - Page 1
Forum section: electronics / projects

author: kerpal
author_rank: Contributor
timestamp: January 14, 2014, 02:19:08 pm
content: 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 decentCons: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 systemNew 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 takingNo more mouse-based or button/knob-based GUI. We are fully commitment to modern GUI, ala iOS/Android

author: djacobow
author_rank: Super Contributor
timestamp: January 14, 2014, 07:53:39 pm
content: 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.

author: dr.diesel
author_rank: Super Contributor
timestamp: January 14, 2014, 08:09:48 pm
content: 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.

author: AndyC_772
author_rank: Super Contributor
timestamp: January 14, 2014, 09:25:14 pm
content: 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.

author: dannyf
author_rank: Super Contributor
timestamp: January 14, 2014, 09:44:26 pm
content: 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.

author: dr.diesel
author_rank: Super Contributor
timestamp: January 14, 2014, 10:02:17 pm
content: Still lots of speculation here. But if a mobile type device, likely Android, but if a piece of long term T&M, probably Linux.

author: psycho0815
author_rank: Regular Contributor
timestamp: January 15, 2014, 08:30:23 am
content: Quote from: dr.diesel on January 14, 2014, 10:02:17 pmSorry 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.

author: codeboy2k
author_rank: Super Contributor
timestamp: January 15, 2014, 09:19:03 am
content: 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/TheADCserviceuser adcusergroup adcuserThese services can do the heavy lifting for your hardwareAfter 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-Peasymore information on the Android boot steps and the init.rc language is here:booting:http://elinux.org/Android_Bootinginit:https://github.com/android/platform_system_core/blob/master/init/readme.txt

author: dr.diesel
author_rank: Super Contributor
timestamp: January 15, 2014, 11:01:15 am
content: Quote from: psycho0815 on January 15, 2014, 08:30:23 amThis is a HUGE misconception. The only thing Linux about Android is the kernel, and it stops there.

author: psycho0815
author_rank: Regular Contributor
timestamp: January 15, 2014, 11:54:47 am
content: Quote from: dr.diesel on January 15, 2014, 11:01:15 amAgain 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.

author: Monkeh
author_rank: Super Contributor
timestamp: January 15, 2014, 12:00:37 pm
content: Quote from: psycho0815 on January 15, 2014, 11:54:47 amAnd I will continue to gleefully refer to it as Linux, because rms is a fruitcake.

author: psycho0815
author_rank: Regular Contributor
timestamp: January 15, 2014, 12:23:09 pm
content: Quote from: Monkeh on January 15, 2014, 12:00:37 pmNow that's an entirely different discussion.

author: Monkeh
author_rank: Super Contributor
timestamp: January 15, 2014, 12:24:20 pm
content: Quote from: psycho0815 on January 15, 2014, 12:23:09 pmThat it is.Remind me to toy around with a BSD userland again.

author: codeboy2k
author_rank: Super Contributor
timestamp: January 15, 2014, 12:57:26 pm
content: 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.

author: kerpal
author_rank: Contributor
timestamp: January 15, 2014, 02:55:53 pm
content: Quote from: codeboy2k on January 15, 2014, 09:19:03 amInteresting 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.

author: dr.diesel
author_rank: Super Contributor
timestamp: January 15, 2014, 02:59:46 pm
content: Quote from: kerpal on January 15, 2014, 02:55:53 pmIt's done all the time.

author: psycho0815
author_rank: Regular Contributor
timestamp: January 15, 2014, 03:12:18 pm
content: Quote from: dr.diesel on January 15, 2014, 02:59:46 pmAbsolutely. 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.

author: codeboy2k
author_rank: Super Contributor
timestamp: January 15, 2014, 06:56:35 pm
content: 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/

author: Bored@Work
author_rank: Super Contributor
timestamp: January 15, 2014, 07:21:33 pm
content: 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.

author: MarkL
author_rank: Unknown
timestamp: January 15, 2014, 08:32:24 pm
content: Quote from: kerpal on January 14, 2014, 02:19:08 pmTo 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.

author: Maxlor
author_rank: Frequent Contributor
timestamp: January 15, 2014, 09:07:35 pm
content: 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.

author: daveshah
author_rank: Unknown
timestamp: January 15, 2014, 09:16:02 pm
content: Quote from: Bored@Work on January 15, 2014, 07:21:33 pmThat'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.

author: codeboy2k
author_rank: Super Contributor
timestamp: January 15, 2014, 09:51:50 pm
content: 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.

author: Harvs
author_rank: Super Contributor
timestamp: January 17, 2014, 01:09:53 am
content: Quote from: kerpal on January 14, 2014, 02:19:08 pmI'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.

author: Someone
author_rank: Super Contributor
timestamp: January 17, 2014, 03:24:45 am
content: Quote from: mojo-chan on January 16, 2014, 03:06:01 pmAny driver you like but linux is not the first thought for most people making adevicerather than a host.Quote from: Maxlor on January 15, 2014, 09:07:35 pmThe 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

author: kerpal
author_rank: Contributor
timestamp: January 17, 2014, 04:43:38 pm
content: Quote from: Maxlor on January 15, 2014, 09:07:35 pmThe big guns were all going touch-screen last year, and I have to say, as a user for just one month, moving to touch really helped in usability. I agree with you that knobs and buttons are still useful for certain functions, which is why those companies are still leaving them there despite going touch-screen. There are too many analysis stuff that is way easier to navigate and adjust using the touch-screen that using the knobs.Based on all the feedback, I think the GUI part is the only item remained that made us look into Android. Existing GUI frameworks on WinCE or Linux just isn't updated enough.

author: kerpal
author_rank: Contributor
timestamp: January 17, 2014, 04:45:30 pm
content: Quote from: daveshah on January 15, 2014, 09:16:02 pmYou are right, that's one more point to consider.But looking at the Tektronix DPO4000 that we have, it takes several minutes to boot, so we are willing to sacrifice on that.But still, a good point.

author: kerpal
author_rank: Contributor
timestamp: January 17, 2014, 04:48:49 pm
content: Quote from: mojo-chan on January 16, 2014, 03:06:01 pmHm ... seems like your experience is exactly something we are trying to avoid.Which WinCE version was that? Is WinCE 7 any better, with Silverlight support?

author: kerpal
author_rank: Contributor
timestamp: January 17, 2014, 04:53:52 pm
content: Quote from: Harvs on January 17, 2014, 01:09:53 amSeems like development mess to decide which part of the code to run those at those special layers. This really concerns me, but I wonder if the new GHz range CPUs will negate any overhead when using Java. In other words, a native C++ code running fast on a sub 500MHz platform, is it comparable with a Java-based code running on a GHz CPU?Would they be equivalent?

author: kerpal
author_rank: Contributor
timestamp: January 17, 2014, 04:57:44 pm
content: Quote from: Someone on January 17, 2014, 03:24:45 amOh yeah, your last point on support for GPIB and LXI is spot on. We'll have to look into whether Android supports that.Anyway, the common comment is that Android is focus on mobile, while T&M is focused on measurement. That is what we are trying to break -- focused on measurement, but at the same time keeping up with the GUI trends to improve usability. LeCroy oscilloscopes seems to be heading that way, although development seems to slowed down.We can't win against the big boy's ASIC R&D, but we believe we can beat them at our market segment with this direction.

author: C
author_rank: Super Contributor
timestamp: January 17, 2014, 06:27:13 pm
content: Why just one processor?Do you really have to cram it all together?Take a scope for example, If you think of overlays, you could have some parts of the screen be updated by the gui processor and some of that could be bit map pictures out of the fpga.Say for example you built a scope, lets go big time and use a HDMI display and pushing it to HD limits just to make it harder.Say every thing on the front panel but the bnc connectors was part of the GUI processor section. So the GUI is handling the touch screen, knobs, buttons & switches.The BNC with it high speed requirements really needs a FPGA and once the data is in the FPGA's memory really could use a lot of parallel processing. It would take a very slow data rate for the GUI section to pass the needed control information to the FPGA section and it could pass along some more data saying put trace 1 in this window on the display.The GUI section could output Full HD and send it to a simple video overlay processor, a part of the FPGA section which would do the simple thing of using GUI data for all but the defined windows where it would use the the data created by the FPGA section, the wave form.Think of this you could stack a second board behind the scope's FPGA and have a second instrument or a second scope fpga system able to add it's traces to data windows to where they were needed if they were needed at the time.Want a 8 channel scope, just stack 4 two channel boards. Granted stacking scope boards would need some communications between scope boards for triggers and sample timing. Chanels 1 & 2 would have a hard time effecting any thing but 1 & 2.The GUI board could be a common part used in many different equipment.Want to use a normal PC & the GUI board? You would have two HDMI's that you would need to use a fancier overlay processor that had sync capability.C