Slashdot Mirror
Ask Slashdot: Which OS For an Embedded Display Unit?
First time accepted submitter spouse writes "We are a small Software Design team of 8 developers, working with home brewed Linux to make our ARM7, ARM9 and Intel based embedded products work. Now we want to develop our first 7 inch touch screen tablet-like device serving as control panel for a set of our 'black box' devices. We see Android as a possible choice due to the tablet like character of our applications. We will need App management and the GUI elements. We do not need all the apps out there in the store, we do not need any telephone/sms/email/webbrowser support. Will we end with modifying Android just as much as our own Linux derivate to make things work? Does it make sense to build the hardware of the touch panel based on google reference design to minimize the effort? Are there any experiences out there? Who has done that before and what are the experiences of that? How hard is it to make a product really work with Android? What is the right choice here? Shall we try?"
Check out Angstrom.
Do you and your developers feel comfortable with Java? If not, don't go there. Also this sounds like a control application... it seems like Android is too much for that.
Seeing as how you won't ever be upgrading the software on your devices, Android seems perfect. You guys will fit right in!
After BeOS didn't make it as a desktop, they focused on embedded applications.
http://en.wikipedia.org/wiki/BeOS
> How hard is it to make a product really work with Android?
Depends on what you're trying to do. Not to difficult to use Apps for Android to get Android to wirelessly interface with a adruino attached to a led display.
Using it to launch a NASA rocket likely would be quite a bit more paperwork.
... the hell would you invest engineering resources in building a "tablet like" device that's going to be a proprietary frontend for wherever your real magic is taking place? Android is a great choice, given your requirements list, but for God's sake call one of the 5,000,000 companies in China that make tablets from $50 to $300 and ask them to ship you a crateful. Go to CES next year and walk the small booths - you will not be able to walk under the weight of business cards from companies like this. FCC approvals, full BSPs done for you already, available ex stock FOB Shenzen.
If any commercial 7" tablet fits your needs, check some brands/models out there and create a custom version of Android + your app. If it doesn't (probably not rugged enough, or the touch screen not bulletproof....) get them, strip them and modify them. If you are planning to sell more than 100k units and you have enough $, get serious, contact a factory and ask for some redesign for you. In both cases, you can use a stripped android + your app. OR you can start with something like this: http://www.geek.com/articles/gadgets/get-your-own-open-source-touchscreen-device-for-69-2011023/
The latest trend is to use ANY OS but develop your actual apps with HTML5 et all. That way in the end you aren't tied to a specific OS and if you need to change later you can. All you would need is hardware drivers rather than a new software stack. There are many cross-platform touchscreen oriented web-frameworks you can use as well.
If you have no intention of supporting Market apps then skip Android and go custom or use some other tailored OS. If you already have a customized Linux then leverage your existing knowledge and slap a micro version of X on it with a custom mouse driver for the touch interface.
Consumer-focused, one-size-fits-all operating systems are terrible for control applications (timing problems, bulkware, etc) and don't really give you anything in return. It's a bit like handing your wallet to a hooker and watching them walk away.
Having some experience in this area my suggestion is to use off the shelf hardware if you at all can. For most of these specific market "black box" control applications you'll never sell enough to bring the cost low enough to do a ground-up design at a reasonable price, plus it locks you in to the current state of capabilities. It will be much more cost effective to use existing Android tablets, write an app for them to do your control and talk back to your black box over a network (a private network if you must). This will allow you much more flexibility than linking the control interface directly with the black box. In the pro a/v and automation category where I do some of this work almost everything has gone this direction and it makes it much easier and faster to design/upgrade.
I hear the new windows is supposed to be able support ARM...
I always thought doing the embedded OS part was easier than the GUI part. Getting a GUI running on an embedded device can be a real PITA. Building the driver for the touch screen, faking a touch screen to look like a mouse (because they're super different) - all a real PITA. The chip vendor will give you a Linux port 90% of the time, just reconfigure it for your memory footprint.
The question for me isn't which OS are you going to use. It's an embedded platform, with presumably *1* application that matters - what will make that application easiest to a) write b) maintain c) make sense?
The question is amusing, interesting even - but I'm not totally sure its relevant to what you want to create.
The I/O options on Android leave much to be desired. Extensive hacking would be required to get anything to work from the micro-usb port.
Plus the built in controls that allow the user to easily go to the home page and enter the settings would be difficult to remove. There is no way to lock the device down and you would spend too much time making a custom environment.
Chrome is better suited than Android on any day of the week.
Keep it small and simple so it boots fast. We use a bunch of them from board and chip
vendors. The one from Atmel seems fine.
Is that not something QNX was supposed to be good at - except now it is a phone OS as well .....
You are thinking of using a phone OS as control app platform, RIM will be using a RT control platform in a phone.
Go figure.
Dennis Onstenk
Agreed. We did an in house design of one and just the engineering costs added about $500 to each unit when spread out over 30,000 units. We most likely will not sell that many but it's a goal and the figure used to do costing. We used our own in house code which is very mature. We're going with an already made and industry certified ( we need too many certs but this means we only have to pay to get it certified for shipboard use) Atom processor based touch screen which is larger, has more features and is about 10x faster than our in house design. Since there are at least 10 vendors of similar products we won't be locked into the architecture of the in house design, porting the firmware will not add to much cost and these are *less* money than our in house design if engineering costs for the final product are figured in.
I'd go on a Vegan diet but the delivery time from Vega is too long. --brownkitty
fast, light tool kit?
If that's not suitable, try XForms.
"I don't know, therefore Aliens" Wafflebox1
The economic reality dictates that you have Meego/Maemo/Tizen or Android as options at the moment. Qt or Android UI framework go well with touch, but Android might have a bigger community oriented at touch input devices.
...or Tizen were my first ideas. But maybe there are smaller alternatives if you plan to run only your frontend, some olf then not being even linux based (bsds, qnx, others?)
If you want Flash for any reason (think ads) then I consider the ARM/Linux combination to be a no go. X86/Linux works OK but the ARM/Linux combo isn't. Technically there's some support out there for it but in reality it's many versions behind, not optimised and in general it won't work well.
Either avoid Adobe Flash (HTML 5 is better anyway imho) or avoid the ARM/Linux combo. This information is mainly relevant if you plan on serving up adds from a kiosk. Advertisers often expect you to support Flash.
That way you can use your existing toolkits and expertise. I think you will find that the jump to add touch functionality will be less than the jump to a different universe.
My dick, faggot.
Oh yeah. FRIST PSOT!!
He said embedded devices, not nanotech, so your dick would be way too small for the application.
Depending on how much ram / flash, and how embedded an environment you want, I would consider Freescale running Qnx.
There's a company in Toronto I could recommend that could help you. Feel free to contact me.
Don't be a commie open-source faggot.
Because it is much better to be a commie fanboi who worships a dead man who had no business getting a liver transplant in the first place.
I know this doesn't directly answer your question but it may help.
If you absolutely need things like task scheduling, web server, xml parsers and more goodies, then yeah consider an OS. But seriously, if all you are doing is writing some stuff to a display and doing a bunch of control "under the hood", you dont need an operating system at all. In fact, an OS could prove to be a hindrance, driving up complexity and hardware costs.
I know you said you are using ARM8/9, but maybe you dont even need that. Cortex-M3 devices are cheap, offer plenty of horsepower, and demo kits are $100. You definitely sound new to embedded in general, and one of the most common mistakes one makes when designing their first embedded system is not getting your hardware requirements straight.
As others have said, Android sounds perfect for your requirements.
I'd love to see an Android distro geared towards this kind of use. Like how CyanogenMod (and others) is a great Android distro for phones, a more bare bones distro without the phone, messaging, general bloat, etc, would be perfect for more bespoke applications like yours. I don't have the skills to start that kind of project but maybe you guys do?
Why not give it bluetooth or wifi and then write an Android app to allow any android tablet/phone to control your "black boxes"?
Qt Embedded for Linux is very nice. Lighter than you would think with no x server.
Some people are sort of touching on this, but why bother? What's keeping you from making an Android application that does this, then charge for that, let the users pick their own tablet, maybe recommend a tablet that you could sell to them.
If you sell tablets with the app preinstalled, you can market it as "It controls all this, AND PLAYS ANGRY BIRDS!!!!"
Even if you go the route of making a custom android for your custom tablet, you still have to make an app to run on it. Why not skip the tablet R&D and just make the app?
Cross Linux From Scratch: http://trac.cross-lfs.org/
Whenyou are done with the basics you can put whatever you want on top of it.
Being an engineer I definitely know the drive to want to do it yourself all the time. But when it comes to business, RESIST THE URGE! Just because you can doesn't mean it is a good business decision. Also, your architecture seems dated and not really future proof. Why not make your black boxes IP enabled? Create a standard IP API to control your black boxes and then just network everything. Then you create a web app to control your black boxes. You will be able to control your black boxes from your phone, a standard tablet attached to the black boxes, or from your computer. Why limit yourself to a single control panel and why waste time building and programming a custom control panel? Do you really want to support that custom control panel? Or would you rather buy a new tablet if the first one breaks and then go back to focusing on your black box magic.
...but on the hardware side I'd definitely go with the reference design, especially if your quantities aren't huge. In today's world hardware requirements change rapidly, and so does the availability of silicon. A chip that's just-past-bleeding-edge today may be obsolete, or at least hard to get, in a year or two - then you're looking at a re-design. Whereas if you're on the reference design path and a key piece of silicon becomes scarce, you have a bigger, faster, more experienced, better funded team working on the next reference design. And by studying a reference design, using it, and gaining experience with it, you'll be in a better position to design your own hardware from scratch down the road if the need should arise. Also, using an already-proven design will allow you te get to market faster, as well as leaving more resources for the software, documentation, marketing, support, etc.
'The Economy' is a giant Ponzi scheme whose most pitiable suckers are the youngest among us and the yet-unborn.
As others have pointed out, with the current prices of Android tablets from China, you'd have to be insane to even think about trying to cobble together your own solution. If you really have to make it look custom, buy a crateload of $100 (retail-price) tablets, take them apart, and mount their innards in your own enclosure. I seriously doubt whether you could buy the LCDs *alone* for what you'd pay for the whole tablet, let alone the touchscreen and everything else.
Once you've got the tablet running Android, 90% of your development work is done. Decide how you want to connect it to the rest of your system-- wifi, bluetooth, or hardwired. If you go the 'hardwire' route, you have two choices:
* the headphone jack. Forget its official purpose -- with a tiny bit of added hardware ( http://www.sparkfun.com/products/10331 -- I think this is actually a commercial version of an opensource project) and some host software, it's a serial port. Get a hold of the tablet's source, reverse engineer its schematic a bit so you can figure out what GPIO pins the 3 TRRS pins (not including ground) are connected to, and it's a a bitbang-able SPI interface.
* USB. Some actually use a crossbar chip to let you connect pins from the USB port to one of the CPU's UARTs, but don't even waste your time. Just check out the open-source schematics for "IOIO" ( ready to use reference board available from http://www.sparkfun.com/products/10748 ), which will give you more i/o options than you'll know what to do with.
Actually, there might be a third option by the time you read this. TI released a chip explicitly intended for use in Android tablets with zigbee (for home automation, industrial control, etc). If you hunt around Shenzhen and/or Silicon Valley enough, chances are you'll be able to find someone who already has a series in the design pipeline, if not manufactured and ready to buy today.
The point is, you'll never get hardware cheaper than for what you can buy off the shelf cheap Chinese Android tablets, even if you don't care about 99.9% of their capabilities. In return, you'll get a nice, ready to use host OS you can use to implement whatever higher-level display protocol you want to create. You don't have to use the tablet for anything besides an intelligent LCD host. Best of all, if you interface through something relatively vendor-agnostic, like IOIO, you won't even be tied to any single source in the future (as long as you aren't planning to disassemble them and reassemble them in your own enclosures, of course... then you'd be totally dependent upon a specific tablet).
Write control application in html. Let clients use whatever they like. "Certify" androing browser/ipad/firefox/ie and you are golden.
Who logs in to gdm? Not I, said the duck.
The value in building the tablet in-house is so the company's product is not strongly coupled to the ebb and flow of availability of 7" tablets for $60, much less the availability of a particular model/configuration to list in a manufacturing BOM.
Qt is somewhat archaic, hardly any active support, but works and has it's own framebuffer with minimal footprint. Android looks nice; it is also unfortunately bloated for true embedded interface purposes. If the complexity of the interface application requires multiple screens and RTOS functionality, then you're practically stuck with a distro. If all you need is an interface then keep it simple.
-- lhs
Unless you want to do it all over in the near future, you need a long-term stable OS. That rules android right out, as it still is more of a tech-demo than an OS. It definitely is a work-in progress. Best guess: Use Debian stable, x.org, a long-term stable window-manager like fvwm and make sure there are open-source drivers for the graphics.
As for language, I would recommend doing most of it in a scripting language like Python and embed any low-level stuff with C. I cannot recommend Java for anything. It is neither a scripting language, nor a high-performance low-level language. The libraries offer a lot but very often hide critical details in a failed attempt to be cross-platform. As such it does everything but nothing well. And it tends to make matter far more complicated than needed. You can also easily hire any number of incompetent Java coders, but hardly any good ones as the good coders use other languages.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
What's the best platform for my project that Tivo-izes Linux?
Don't blame me, I voted for Baltar.
...but on the hardware side I'd definitely go with the reference design, especially if your quantities aren't huge. In today's world hardware requirements change rapidly, and so does the availability of silicon. A chip that's just-past-bleeding-edge today may be obsolete, or at least hard to get, in a year or two - then you're looking at a re-design. Whereas if you're on the reference design path and a key piece of silicon becomes scarce, you have a bigger, faster, more experienced, better funded team working on the next reference design. And by studying a reference design, using it, and gaining experience with it, you'll be in a better position to design your own hardware from scratch down the road if the need should arise. Also, using an already-proven design will allow you te get to market faster, as well as leaving more resources for the software, documentation, marketing, support, etc.
Very true, the hardware will become an issue down the line as the next generation eclipses this one.
A smart strategy is find a tablet that works for you, order 2 years worth of units, sell your products.
Then create your next generation of fabulicious.
I have 10 years experience in product design and it happens all too often.
You could also contact a product design firm for assistance, such as www.ideinc.com, tell them Tem sent you.:-)
I always used Debian for ARM, but a lot of people liked Angstrom. This was before the whole "tablet" and "multi-touch" craze started. The thing is now that all these tablets are available and so cheap I'd question why you wouldn't just modify a tablet?
I don't know why you are asking this on Slashdot, given that you could have assigned any of your developers to look into the topic for a day and come up with a better answer (since he will understand your requirements).
As far as my experience with embedded goes, yes, Android is a fairly easy system to work with. Might not be as stable as MicroC/OS or some other real-time system, but it is easy to work with. But once again, it depends a LOT on the details of your project.
"First they came for the slanderers and i said nothing."
We have a similar situation and what we did was create the control interface to our blackbox using HTML/Javascript and JQuery Mobile. The blackbox hosts a simple web server with a services API written in Perl. The control interface now can be loaded as a Chrome app on a desktop or laptop, packaged as an installable app for Android or iPad using PhoneGap, or function as a "web app" on pretty much any mobile device that is wifi capable. Granted our "blackbox" resides as part of a wireless hotspot running OpenBSD and was designed to allow other devices to connect to it from the ground up.
Our first customer is using the $500 iPad 2's as their interface device of choice, but the fact that the controls are HTML/JS and worked on any smart phone they tried during the demo phase was a huge plus. Our system is replacing a system they deployed 10 years ago that never really worked all that well, mainly because most of the hardware and software was proprietary. And it was a huge problem because a lot of the equipment was frankly outdated before they even went live. This time around we got the contract simply because we took the "workstation" part out of the equation. So long as it can run a webkit browser our system will work.
"The problem with socialism is eventually you run out of other people's money" - Thatcher.
Because here at ./ if you ask us a question, there will be a thousand different answers, each increasing the complexity of any solution another thousand fold. And, on top of that, you'll be feeding the trolls, and giving mirrors to the narcissists. Dont do that. Instead, you already sound reasonably intelligent, you can come up with a descent answer without all the self esteem bashing they like to do here.
We have dozens of these projects at my company, and this is the simplest way. There are plenty of vendors in China that will give you a good deal on an ARM5/9/11 or Cortex touch device. You plunk Android on it and then build a native app, or as we often do, build on HTML5 app with a native middle-layer and JavaScript bridge. Pretty simple process. Main concern is the vendor, because build quality can vary widely from the Chinese fabrication plants.
My company builds hardware like this as well, when it makes sense. We could build you this app for a very reasonable price, *wink*.
I have worked on an embedded kiosk with NFC+3G for cash card transactions and all these Chinese tablets are an absolute NO - NO. We tried 20 models and there are too many problems making the $100 price tags totally irrelevant. We finally found a great product from Genesi (genesi-usa.com) called Efika smartbook ($200) and smart top ($100). You'll get surprisingly good quality, great engineering design and pretty good software software. It runs Ubuntu Arm customized a little but you can run Fedora Arm etc. Has inbuilt 3G,WiFi/BT but you can opt out of those for $40 cut in prices i think. Their new models have touchscreens - though i would not recommend touchscreens for anything non-consumer item as they always have issues if the usage is high or the atmosphere is industrial/outdoor etc. Better to go with external bluetooth touchpads (indl quality) or numeric keypads so that it can be replaced without opening up the machine. The form factor of smartbook is also great for doing arm development on the move or normal office/home use. FYI, I have no relation with Genesi - just a recent customer.
It's funny how the submission suffers from the syndrome where you flood a bunch of questions at the end.
I don't know why you've been modded interesting, unless it's the schadenfreude of it all. What kind of business thinking is "We most likely will not sell that many but it's a goal and the figure used to do costing."???? I'll tell you: it's the business thinking of people who enjoy pissing money down the drain. Jesus.
Read the other Android article published today and go for something open source instead. Maemo, Moblin, Meego, Tizen, Mer or just plain Debian.
Don't forget product lifespan though. We used bought in units but found that we were having to re-engineer the product every 6 months as hardware ceased to be manufactured. In the end we got a Taiwanese company to design and manufature the hardware to our spec with a guaranteed 5 year lifespan. Lifespan may not be important to you, but if it is you have to ask any manufacturer how long they can supply a particular product.
Make your black box join a wifi network or blutooth.
Then make apps for Android and iPhone that can control your device.
That way the customers can choose which device they want to control your device with.
As a default device you can tape som generic Android tablet to your device.
Same idea as http://ardrone.parrot.com/parrot-ar-drone/en/
Of course I realize that your application is probably much more serious than a flying toy, but the basic idea is good for many applications.
I'm not surprised no one has mentioned Microsoft's embedded OS. They provide both WInXP Embedded, WinCE 6 and now WEC7 which is the sequel to WinCE6. The advantage of XP Embedded is that it is like having an XP system where you configured what will and will not go into the OS ahead of time. If you're developing Windows-based solutions, this is handy. However, the price is very hefty on it per unit, which is why many vendors go WinCE 6 or WEC7. With those two you get a much less feature filled OS, lighter weight and lower on resources, but still capable of Windows development. C++ and C# are the primary languages used on these platforms, though you can really run any language that has been ported to them. There is also Silverlight integration, albeit through C++ not C# for speed. You deploy a BSP (board support package) that you compiled with all the features you need onto the embedded device, which includes the programs you wrote. The advantage of a Windows-based system over Android or iOS are: 1) winapi if you're already familiar this can be handy, it is also elaborate, 2) its windows, many users are already familiar with it, 3) you can develop and debug remotely via Visual Studio which is one of the best IDE, compiler and linker tools available and also well supported, 4) the drivers for any combination of cameras, displays, usb devices, and boards just work versus Android or Linux where more often than not they don't and you have to write your own drivers, this lets you pick the cheapest hardware and run with it with minimal effort, 5) vast well written documentation on MSDN, this is one of the things MS has done right versus the mess of docs Google has that are out of date, missing or confusing, 6) easier to figure out (most developers know C/C++ so you won't have a hard time finding programmers, same is becoming true for C#), whereas android has an unusual api that isn't well documented and is frequently being broken by Google as it releases new SDKs because they don't grasp the concept of backwards compatibility, iOS on the other hand is developed mainly in ObjC, which is also unusual and requires you to learn a new language used nowhere else (other than on Mac). Hope this helps. Someone needed to say it, people on /. are too biased against MS to consider it with all seriousness as a good business solution.
I have debian with e17 using the illume theme running on the notion ink adam tablet and I'm really impressed how well it works.
The packages in debian unstable are new enough for a proper installation of e17 and bootstrapping debian for armel is also piece of cake using multistrap.
maybe worth looking into it.
You're showing your dick to a faggot?
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
how many of those 47,826 vendors ships source code? have you any fucking idea how hard it is to get these companies to fucking well understand the GPL, dickhead? i've been dealing with these companies for eighteen fucking months, and they just don't give a flying fuck. not to mention the simple fact that they themselves are supplied with GPL-violating binary-only distributions, they have absolutely no software expertise whatsoever; their ODM software suppliers can't keep hold of their own developers because the supply of software engineers in China is so in demand.
it takes about three to four months of careful negotiation, with about a 1% hit rate (i.e. 99% of them don't understand english except phrases like "the money has been transferred" and "we want to order XX,XXX units", and those that do understand don't give a shit) we've found THREE suppliers who comprehend the GPL, and that was only after explaining it to them. of those two suppliers, one STILL doesn't give a shit, one of them was so terrified of the consequences that they terminated sales of the product, and the other one is, thank god, still in the running, is willing to work with us and we will supply their next software *for* them. ... but that was after 18 months to 2 years of searching. now, are you _seriously_ suggesting to these guys that they spend allll their time and money doing exactly the same thing? i think you'll find that they're better off actually designing their own hardware and writing their own software.
anyway, to answer the actual question: use openembedded to custom-build an angstrom linux distro. it's been around for over 10 years, now, so is a pretty mature development platform, and has some superb recipes. ask on the openembedded lists or irc, be patient and you'll get the advice you seek.
You can't go wrong with OpenEmbedded. BitBake recipes are ideal. It doesn't really sound like you need something as full-blown as Android, but I may be wrong. You say you need app management-- it would be nice to have some more details here, e.g. will the end-user be installing and removing apps on his or her own? I ask because it sounds like it's the only feature specific to Android you would actually use. I bet maintaining a BitBake repo would work just as well in your situation, but I'm just guessing. I would take a look at the Gumstix Overo platform.
Small, capable, can probably build it for any processor you need it for.
From their website: "You’re a developer. You know applications. Building apps is what you do. But when you need to turn your app into an appliance, you come see us. That’s what we do. Using Workbench, our easy-to-use online configuration and build system, you can be ready to deploy in under an hour, completely free. ... Our open-source software platform is a great fit for all kinds of devices: digital signage, kiosks, point-of-sale/point-of-service devices; So let us handle your OS. And you can get back to what you do best—making great apps."
Open Embedded can be a bit of a learning curve, but it's probably the right choice for an Arm Linux based device. We've used it here with Gumstix and Tegra2 system on module. Of course for the GUI software we use our own commercial tool called GL Studio that's designed for creating C++/OpenGL HMIs.
(Blatant plug: www.disti.com)
NetBSD is a great embedded OS. In fact, many of the above suggestions include code from the NetBSD project.
"Of course it runs NetBSD!"
-d
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
A great thanks to all posters on slashdot. This was a blow of answers that you gave me, many different aspects popped up, even some that were not on our list yet. Gives us different opinions to think about. We will certainly consider your input, and I am sure we are closer to a decision now than before reading the answers.
I've started a project that seeks to do something similar. My application is home automation. I'm using an Android Tablet and an Arduino to control a light switch and sense the environment. I've decided to use Android widgets as the UI since it gives the user flexibility to customize the layout. https://code.google.com/p/the-ultimate-light-switch/
I started a project that seeks to do something similar. My application is home automation. I'm using an inexpensive android tablet connected directly to an arduino (no ADK needed) to control a light switch and sense the environment. More info here: http://code.google.com/p/the-ultimate-light-switch/
http://pygame.renpy.org/
http://xkcd.com/801/
Contrary to the popular belief, there indeed is no God.
DO or DO NOT.
There is no TRY!