4 ms·
How often is Linux used these days in embedded devices (non-android)? In the past Windows driver support was so much better that Linux generally didn't have mu
by wmil 10y ago
How often is Linux used these days in embedded devices (non-android)? In the past Windows driver support was so much better that Linux generally didn't have much of a payoff.
- kminehart 10y agoReally? I would disagree. Linux really only falls behind on graphics drivers, at least from my experience. I suppose this being qt, that's probably what you are talking about.
- wmil 10y agoGraphics drivers are a big one. But things like touch screen drivers can be a problem. I haven't looked at the situation since 2011, so I'm not up to date.
- deleted 10y ago[deleted]
- mixedCase 10y ago>But things like touch screen drivers can be a problem. Android has helped a lot in this regard. While still not perfect, it's definitely much more mature.
- joezydeco 10y agoTouchscreen drivers are pretty much a commodity now. You see a lot of the same manufacturers over and over (Atmel, eGalax/EETI, FocalTouch, TI, etc). The problem is that every hardware designer hooks up a different GPIO line for the touch interrupt signal and so you're deep into the kernel to hook that all up. Devicetree has made this lot easier now, though. Then you have smaller issues like setting up calibration and TSLIB/filtering files, but that's a lot easier than it was five years ago. Multitouch can still be hairy depending on the target O/S.
- eloisant 10y agoThere's Sailfish, and it's based on Qt precisely. And Jolla is a Finnish company, just like the Qt Company. So they have a partner using their technology, it is that weird that the browser works on that platform first?
- noir_lord 10y agoConsidering the convergence between tablet style devices and embedded devices (in car systems, in flight systems etc) and the fact the car industry seems to be standardizing towards Linux probably a lot more than it used to be. Embedded stuff doesn't have the same life cycle turnover rate as consumer stuff though so the push will be fairly gradual.
- jeena 10y agoI have a forecast picture for you http://eecatalog.com/automotive/files/2013/11/IHS_fullsize.jpg http://eecatalog.com/automotive/files/2013/11/IHS_fullsize.j... it's a couple of years old (from 2013) but as far as I can tell it's definatelly going in this direction in the car industry at least. See also the members of https://www.automotivelinux.org/ https://www.automotivelinux.org/ and https://www.genivi.org/genivi-members https://www.genivi.org/genivi-members
- TickleSteve 10y agoIf the embedded device needs IP connectivity and it doesn't have any hard real-time needs, it tends to run one of the many forms of embedded Linux. So, yes... its pretty popular. In fact, its the default choice for most things.
- vidarh 10y agoHow far in the past are we talking? In the embedded devices I've worked on, Windows was never a consideration because trimming it down enough was a major concern, and as were licensing costs. Drivers, on the other hand, rarely came up as an objection to Linux - it doesn't take much volume before writing Linux drivers was the cheaper option, and if you have control of the hardware platform in the first place, picking options that worked well with Linux was easy enough. That said, it's 16-17 years since I did much embedded work.
- Aldo_MX 10y agoI always thought that Linux was actively avoided in embedded systems such as ATMs, Medical or Industrial Equipment, because the GPL forces you to release your source code.
- nitrogen 10y agoThat's a really old myth. Only if you intertwine your code with GPL code, use a GPL library, or modify GPL code do you need to release anything you write yourself. It is very very easy not to do any of those things. One gray area (gray because two camps both think it's black and white in opposite directions) is writing any code that runs in kernel.
- joatmon-snoo 10y agoIt's a problem with GPLv3, but for most other open-source licenses (e.g. BSD MIT) it isn't.
- posborne 10y agoVery often. Vendors such as NXP/Freescale, TI, Intel (and Chinese manufacturers on top of MIPS) all tend to target Linux-first. For some drivers (e.g. wireless), you sometimes need to work directly with that vendor (Qualcomm/Broadcom/...). In my experience, it is almost the default except in cases where you need 1) Hard real-time, 2) Very low power (most battery applications), 3) Very low cost. Those still go to MCUs where life is more difficult for anything complex (e.g. requiring graphics, a network stack). For most embedded use cases, Android is still not suitable as you have to jump through many hoops to get sufficient control over exactly how the device operates (you can make it work but the further away your device is from a phone/tablet, the harder it gets). Source: Worked in embedded design services until recently.