Related
I am planning to implement Hiawatha web server on a non-linux platform which is uC/OS-II RTOS.
I need help to port the Linux dependent API's to RTOS platform.
Kindly let me if there are already build libraries that I can use to port Linux on RTOS.
Thanks in Advance
Any code that uses more than just the standard C library will require some porting effort - the extent to which non-standard and OS specific libraries and calls are made will determine the effort required or even the feasibility of such a port.
Most Linux code of any complexity will require a POSIX API and networking code will probably use BSD sockets. Multi-threaded code would likley use pthreads. uC/OS-II has neither of these; it deals with only scheduling, timing, synchronisation and inter-process communication; it is a scheduling kernel, not a full OS in the same sense as Linux - it does not even have a file system - a requirement of most Linux code. Of course adding additional libraries and extensions may provide some or all of what you may need.
Moreover uC/OS-II's simple one-thread-per-priority-level scheduler would make typical Linux multi-threaded code hard to schedule in the manner intended. Most RTOSes (including uC/OS-III) support round-robin/time-sliced scheduling of tasks at the same priority level, but uC/OS-II does not; possibly making it unsuitable for this task.
Something more sophisticated that uC/OS-II may be in order, or perhaps using code more suited to uC/OS-II perhaps. eCos for example is a far more complete RTOS for embedded systems; it is open-source and includes a POSIX API, file-system support and a socket API. It would be far easier to port Linux code to that. Equally there are many lightweight embedded webserver examples that are probably more suited to uC/OS-II and other simple RTOS or even no OS at all. LwIP for example is a TCP/IP stack for small embedded systems for which uC/OS-II ports exist and for which there are web server examples.
The point is that Linux are uC/OS-II are not comparable; one requires < 10Kb of code, the other has a minimal foot-print of about 4Mb! To get Linux code to run on such a system will require you to add a lot of additional code to provide the missing services, and it may not be feasible on your target platform.
[Edit: 08 July 2012]
Have you considered using Micrium's own TCP/IP stack and μC/HTTPs web-server add-on? It is likley to be better integrated to uC/OS-II and provide better performance than non-RTOS specific third-party code.
I have an application which I need to port on Linux. I was thinking to use Free Pascal the problem is the application uses Windows API's to perform tasks such as serial port communication etc... Is there a msdn for linux users or a book covering how linux works internaly if there are apis.
I am very confused.
Well, it's sad to say but if your code in very Windows-dependend (not VCL depended!) then probably it'll be faster to write the application from the begining rather then porting it.
But if it's only serial port matter then give a try to multiplatform SynaSer library, find it here: http://synapse.ararat.cz.
hope this help :)
Robert Love has a book on Linux Systems Programming - that will cover this area and Love's books are generally good, so it is worth looking at.
It's not entirely clear from your question, but if your concern is that there are specific calls to hardware controlling functions in your Windows application that make it difficult to port I would suggest that is a misplaced fear. Both Windows and Linux operate on the principle that the application level programmer should be kept away from the hardware and that all that should be handled by the operating system kernel and only be accessible to applications via system calls. As the kernels of different operating systems face similar demands from users/applications, they tend to have system calls that do the same sorts of things. It is necessary to match the system calls to one another but I can see no reason why that should be impossible.
What may be more troublesome is that your Windows application may rely heavily on the Windows executive's windowing code/API. Again finding analogues for your code is not impossible but is likely to be a bit more complex e.g. in Linux this stuff is generally not handled in the kernel at all (unlike Windows).
But then again, your code may be written against a portable toolkit/library like Qt which would make things a lot easier.
Good luck in any case.
If the program contains GUI code you must use linux libraries like GTK/XLIB in order to create windows, forms, buttons, etc...
Windows specific functions (like EnterCriticalSection, WaitForSingleObject or _beginthreadex) must be replaced with equivalent linux api functions (a nice tutorial can be found here:
"www.ibm.com/developerworks/systems/library/es-MigratingWin32toLinux.html") or you can use libraries such as w2lpl or wine
A useful library for this kind of problems i've found at http://www.adontec.com/windows-to-linux-port-library.htm
I've had great experiences just using WINE. (https://www.winehq.org/)
You don't really port your app at all. You just make sure it doesnt violate some of the basc constraints of WINE and just run it as is. WINE (though is says it is not) is an emulator of the windows API's and will just do the translation for you. It's pretty complete in its coverage of the API's.
was wondering - if knowing The Linux way of life or the Linux architecture, would give a better frame of mind for programming on embedded devices especially when they have some kind of OS in them.
Just want to be sure that I did not miss a major thing :)
Note:
I come from a windows background, can program in C and C++.
Passionate and finally want to get started into Embedded programming. I would like to start by doing typical hobbyists project at home.
It would be nice if anyone would also comment on BeagleBoard as a starting point for me.
"Embedded" is a fuzzy word. There are two categories:
There are realtime embedded systems: microcontroller/microprocessor applications that are intimately communicating directly with the hardware on a low abstraction level. Typical applications are control systems/automation, industrial, automotive, medtech, household electronics, data/telecom communications etc.
And then there are fluffy embedded systems: various laptop:ish computers, embedded linux, embedded windows, phones and phoney operative systems, anything involving internet, human-machine intefaces etc.
People working in both categories will firmly state that they are working with embedded systems, while the latter kind are often just doing another flavour of desktop applications. Depending on which category you are aiming for, Linux may or may not be a merit. The telecom branch for example, overlaps both of these categories, and they are often using embedded Linux even for non-fluffy applications.
In either case, *nix may be used as the development platform, so knowing it won't hurt.
Yes and no. Mostly yes.
Lundin correctly described the "two worlds of embedded" (although the border between them is very fuzzy).
If you're writing for "higher embedded", like Android, or other devices that run Linux, then definitely expert knowledge of Linux will be of much help. You still need to know some "bare bones" and don't get scared when you see the likes of &=~ operator in C, but knowing Linux - the Linux of the old, where you configured stuff by editing files in /etc, where you compiled your own kernels for everyday use, where you would build software from tarballs, that's what helps. Knowing modern Linux - Gnome, gconf-editor, Synaptic and the likes will not be of much help.
Then next, if you're programming devices without OS, in the middle area - fast and strong enough to run C programs, but not the OS, you still need Linux. Because crosscompile. You don't need actual Linux. Cygwin is okay for that. MinGW may suffice. Still, you will probably need to be able to build your own crosscompiler (based on GCC), linker, debugger, make tools, and the rest of "backbone" of the IDE. Unless your chip supplier is awesome and provides a complete toolchain with IDE.
Only when you're into tiny processors, you don't need Linux. Stuff like car alarm remote, christmas lights blinker, car tire pressure sensor, battery level monitor - stuff that can have 16 bytes RAM, 1KB EEPROM, and the rest of CPU to match, you will need to use an IDE that works with this CPU, no OS, no C compiler, nothing remotely close to Linux - the IDE will most likely be Windows based.
I'd say you really do not need to know Linux for embedded programming. Many companies developing embedded software do it on windows and have no contact with other OS.
But sure, knowing more makes you more versatile, and general knowledge makes you a better engineer. This includes different OS as many other things.
When it comes to BeagleBoard, it depends on the kind of application you are interested in.
If you want to understand the low-level, I would start on a simpler processor and learn how to use peripherals, hardware interrupts, debouncing signals... There is an educational point in doing this yourself some time.
I suppose you can also skip that and start with an ARM-A8 and possibly an embedded OS, it's just not the path I followed.
What I am about to say may cause a flame war, but...
I have found that Linux is a much more productive development environment than Windows. At my previous job, we were developing firmware for managed switches and industrial automation equipment, which ran an embedded Linux operating system. All the developers had both Windows and Linux boxes, as the user interface software only ran on Windows. We all used Linux for developing, though, as it was simply easier.
At my current job, the only choice is to run Windows, but to make it more productive we are running Cygwin, which provides a Linux-like environment. It is very difficult to develop software on Windows that is not specifically for Windows.
As for developing for an embedded system without an OS... I have an Arduino that I play with occasionally. I have programmed it both from Windows and Linux, and have found the experiences fairly similar. Using Arduino's own tools, Windows seems to run a bit more smoothly, but if you want to hack on it and make something interesting, you're better off using Linux.
Personally (and this will likely provoke some nasty comments), I feel that Linux is best for doing productive work, and Windows is best for playing games.
So basically, this all boils down to this: Try using Linux for developing your project. You will probably find it to be a much smoother, more productive experience. If you don't like it, you don't have to keep using it. But the experience will probably be worth it.
Edit (due to question rewording): Knowing the "Linux way of life" is unlikely to help much when coding for an embedded project that is not running Linux itself. As I understand it, the Unix philosophy is about two main issues:
Each tool should do one thing and do it well (don't make something that tries to be everything).
Whenever possible, data should be plain text (allows for simple piping through processes and searching for content).
If you are working on a system without an operating system, you are writing code for a compiler and not likely working with a full shell at any point. You also are unlike to have any sort of file system. So both of these points are moot; you are not likely to gain anything concretely related to embedded programming by studying Linux, although it certainly couldn't hurt :-)
I really think if you want to learn a little about embedded sphere you should not start by using an OS directly. Prefer to have hands on a small low level project then add an OS if it's really needed for your final application.
I don't think setting up an OS into an embedded device will be easier than starting from scratch. It will bring you some functionalities (that I am not sure you really need to learn embedded) but it will bring you lot of hard debugging time in case of problems in the OS port.
I have been doing embedded programming for 10 years, currently for networking equipment and before that Apache helicopters. Both companies had POSIX-like operating systems on the target, but not embedded Linux directly. My current company uses mostly Windows for individual developer environments. However, we do have a few Linux boxes hanging around for special purposes. My previous company used a mix of Windows and Sun Solaris Unix. So wherever you go, you may not use Unix or Linux on your day to day computer, but you are likely to come across it at least occasionally.
On the other hand, I've known developers who have programmed on Linux for embedded Linux targets their entire careers. It really depends on the company, as smaller or newer companies have a tendency to use Linux more than corporations. However, using embedded forms of Windows on targets is very rare in my experience. I know devices are out there, but I've never personally met a developer who worked on one.
Anyway, Linux is free to use and has other benefits besides being good for a job. There's really no downside to giving it a try for a couple of months, other than giving up some of your time.
Linux is growing in embedded... see latest research:
Top 10 trends for the embedded software and tools market in 2011 - VDC research
Android Becomes Number One in U.S. Smartphone Market Share
Knowing the Linux way of life will definitely be a plus in embedded domain provided the kind of apps you are interested in are contained in the above mentioned links.
understanding Linux architecture will be over kill (although basic overview is good) before just starting in embedded field
e.g. to cut a tree you don't have to invent an axe - just start using one, then gradually you could learn to sharpen the axe
Its better to get started small - get hands-on, and focus on specific areas as is the need of the hour. grow with your work and work keeping your goals in mind
you will surely gain much faster and not get stuck in self loop - R&D to do R&D ;)
Only if you want to embed Linux! And as an embedded systems developer of some 22 years, I would suggest that Linux is unsuitable and unnecessary for a very large proportion of embedded systems projects.
Understanding the workings of an RTOS, and real-time priority based pre-emptive scheduling and IPC mechanisms would stand you in better stead. Take a look at this for example.
I'm moving from windows programming (By windows programming I mean using Windows API) to Linux Programming.
For programming Windows, the option we have is Win32API (MFC is just a C++ wrapper for the same).
I want to know if there is something like Linux API (equivalent to WINAPI) that is exposed directly to the programmer? Where can I find the reference?
With my little knowledge of POSIX library I see that it wraps around part of Linux API. But what about creating GUI applications? POSIX doesn't offer that. I know there are tons of 3rd party Widget toolkits like gtk, Qt etc. But I don't want to use the libraries that encapsulates Linux API. I want to learn using the "Core Linux API".
If there are somethings that I should know, please inform. Any programmer who is familiar with both Windows & Linux programming, please map the terminologies of Linux world so that I can quickly move on.
Any resources (books,tutorials,references) are highly appreciated.
I think you're looking for something that doesn't exactly exist. Unlike the Win32 API, there is no "Linux API" for doing GUI applications. The closest you can get is the X protocol itself, which is a pretty low level way of doing GUI (it's much more detailed and archaic than Win32 GDI, for example). This is why there exist wrappers such as GTK and Qt that hide the details of the X protocol.
The X protocol is available to C programs using XLib.
What you must understand is that Linux is very bare as to what is contained within it. The "Core" Linux API is POSIX and glibc. Linux is NOT graphical by default, so there is no core graphics library. Really, Windows could be stripped down to not have graphics also and thus not have parts of the win32 API like GDI. This you must understand. Linux is very lightweight compared to Windows.
For Linux there are two main graphical toolkits, GTK and Qt. I myself prefer GTK, but I'd research both. Also note that GTK and Qt exist for Windows to, because they are just wrappers. If you go take a look at the X protocol code for say xterm, you'll see why no one tries to actually creating graphical applications on top of it.
Oh, also SDL is pretty nice, it is pretty bare, but it is nice if your just needing a framebuffer for a window. It is portable between Linux and Windows and very easy to learn. But it will only stretch so far..
Linux and win aren't quite as different as it looks.
On both systems there exists a kernel that is not graphical.
It's just that Microsoft doesn't document this kernel and publishes an API that references various different components.
On Unix, it's more transparent. There really is a (non-GUI) kernel API and it is published. Then, there are services that run on top of this, optionally, and their interfaces are published without an attempt to merge them into an imaginary layer that doesn't really exist.
So, the lowest GUI level is a the X Window System and it has a lowest level library called Xlib. There are various libraries that run on top of this one, as you have noted.
I would highly recommended looking at the QT/C++ UI framework, it's arguably the most comprehensive UI toolkit for any platform.
We're using it at work developing cross platform apps that run on windows, osx and linux.
It also runs on Nokia's smart phone Operating System Maemo which has recently been merged with Intel's Moblin Linux OS, now called MeeGo.
This is going to sound insane since you're asking about "serious" stuff like C++ and C (and the "core linux API"), but you might want to consider building in something else. For instance:
Java Swing (many people love it! Others hate it and call it obsolete)
Mono GTK# (C# or VisualBasic or whatever you want, lots of people say it's pretty cool, but they're not not that many people)
Adobe AIR (ActionScript, you might hate it)
Titanium (totally new and unproven, but getting a lot of buzz in the iPhone world, at least)
And many other possibilities, some of which let you work on multiple platforms at once.
Sorry if this answer is not at all what you're looking for. The "real" answers on Linux are "pick a toolkit," which is also no answer at all :)
Have a look at Cairo. This something roughly similar to GDI+ and is under the hood of some of of the few usable GUI programs for Linux i.e. Firefox or Eclipse (SWT). It wraps most the natsy and ancient Linux stuff for you into a nice API that runs on most Linux installations without locking you into a entire subsystems like GTK or QT.
There is also the docs for the two different desktop platforms: Gnome and KDE that might help you down that road.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Now I'm sure we're all well aware of the relative merits of Linux vs Windows Desktop. However I've heard much less about the world of embedded development. I'm mainly interested in solutions for industry and am therefore uninterested about the IPhone or Android and more interested in these two OSes.
What are the relative trade-offs between the two platforms in the embedded world? If you were considering building a box for a specific project with custom hardware, a partially customised OS and a custom app then which would you choose and why?
I would assume that Windows CE wins on tools and Linux wins on both cost and possibly performance. However this is just utter speculation. Does anyone have any facts or experience of the two?
I worked for several years at a company that provided both CE and Linux for all of their hardware, so I'm fairly familiar with both sides of this equation.
Tools: Windows CE tools certainly are better than those provided by Linux, though the linux tools are certainly getting better.
Performance: Windows CE is real-time. Linux is not. The linux kernel is not designed for determinism at all. There are extensions that you can add to get sort-of real time, but CE beats it.
Cost: This is an area of great misunderstanding. My general experience is that CE is lower cost out of the box ($1k for Platform Builder and as low as $3 per device for a shipping runtime. "What?" you ask? "Linux is free." Well, not really so much, especially in the embedded arena. Yes, there are free distributions like Debian. But there are plenty of pieces that you might need that aren't in that free category. UI frameworks like QT, Java runtimes and media codecs just as a start. Also, most Linux distributions with a commercially-backed support system (e.g. MontaVista) are far from free.
Source Availability: Linux proponents may like to say that CE is a bad choice due to lack of source code. All I can say is that in over a decade of working with CE, half of which spent doing custom kernel and driver work for custom boards, I've only ever had need for source that didn't ship with CE (they ship a vast majority of it) once. I like having source too, but Microsoft provides support, so in the rare case you might think you need that source, you can get them to fix the problem (the one time we needed source, Microsoft provided a fix, and for free - which is their model under CE.
Does this mean that CE wins every time? No. I wouldn't suggest that at all. If you are a Linux shop and you have lots of Linux experience and code assets, you'd be foolish to run out and go CE. However, if you're coming into it from scratch CE usually has a lower TCO. Developers with Win32/C# experience are more prevalent and consequently less expensive. You also get a lot more "in the box" with CE than most other distributions, meaning faster time to market if you don't already have these things done in-house already.
I'll speak for the Linux side, at least for the category of software I'm familiar with (which is RF data collection equipment). Or industrial apps vs. consumer apps.
Windows CE (and its associated tools) IMH fairly recent E) is strongly biased to creating a "Windows Experience" on a small screen. The user input mode emphasizes mouse-like actions. Logons, application selection, etc. all try to be as similar to standard Windows as possible.
If a user is driving a lift truck, or filling a picking cart, or moving material from one place to another, there's a problem.
And it's a moving target - particularly on the .NET side. The Compact .NET runtime is seriously handicapped, and important libraries (like networking, data handling, and UI) are incomplete and versions too often deprecate the previous version. . CE seems to be the stepchild in the Windows family (possibly because there's not a lot of active competition selling to the hardware integrators.)
A nice stable rows-and-columns Linux console is a pretty handy context for many (in my experience most) high-use apps on a dinky screen.
Not much good for games on your cell-phone or Zune, though.
NOTE:
I think ctacke probably speaks accurately for the hardware integrator's side. I'm more aligned with the players further down the pipe - software integrators and users.
Choice is often made largely on perception and culture, rather than concrete data. And, making a choice based on concrete data is difficult when you consider the complexity of a modern OS, all the issues associated with porting it to custom hardware, and unknown future requirements. Even from an application perspective, things change over the life of a project. Requirements come and go. You find yourself doing things you never thought you would, especially if they are possible. The ubiquitous USB and network ports open a lot of possibilities -- for example adding Cell modem support or printer support. Flash based storage makes in-field software updates the standard mode of operation. And in the end, each solution has its strengths and weaknesses -- there is no magic bullet that is the best in all cases.
When considering Embedded Linux development, I often use the iceberg analogy; what you see going into a project is the part above the water. These are the pieces your application interacts with, drivers you need to customize, the part you understand. The other 90% is under water, and herein lies a great deal of variability. Quality issues with drivers or not being able to find a driver for something you may want to support in the future can easily swamp known parts of the project. There are very few people who have a lot of experience with both WinCE and Linux solutions, hence the tendency to go with what is comfortable (or what managers are comfortable with), or what we have experience with. Below are thoughts on a number of aspects to consider:
SYSTEM SOFTWARE DEVELOPMENT
Questions in this realm include CPU support, driver quality, in field software updates, filesystem support, driver availability, etc. One of the changes that has happened in the past two years, is CPU vendors are now porting Linux to their new chips as the first OS. Before, the OS porting was typically done by Linux software companies such as MontaVista, or community efforts. As a result, the Linux kernel now supports most mainstream embedded cpus with few additional patches. This is radically different than the situation 5 years ago. Because many people are using the same source code, issues get fixed, and often are contributed back to the mainstream source. With WinCE, the BSP/driver support tends to be more of a reference implementation, and then OEM/users take it, fix any issues, and that is where the fixes tend to stay.
From a system perspective, it is very important to consider flexibility for future needs. Just because it is not a requirement now does not mean it will not be a requirement in the future. Obtaining driver support for a peripheral may be nearly impossible, or be too large an effort to make it practical.
Most people give very little thought to the build system, or never look much beyond the thought that "if there is a nice gui wrapped around the tool, it must be easy". OpenEmbedded is very popular way to build embedded Linux products, and has recently been endorsed as the technology base of MontaVista's Linux 6 product, and is generally considered "hard to use" by new users. While WinCE build tools look simpler on the surface (the 10% above water), you still have the problem of what happens when I need to customize something, implement complex features such as software updates, etc. To build a production system with production grade features, you still need someone on your team who understands the OS and can work at the detail level of both the operating system, and the build system. With either WinCE or Embedded Linux, this generally means companies either need to have experienced developers in house, or hire experts to do portions of the system software development. System software development is not the same as application development, and is generally not something you want to take on with no experience unless you have a lot of time. It is quite common for companies to hire expert help for the first couple projects, and then do follow-on projects in-house. Another feature to consider is parallel build support. With quad core workstations becoming the standard, is it a big deal that a full build can be done in 1.2 hours versus 8? How flexible is the build system at pulling and building source code from various sources such as diverse revision control systems, etc.
Embedded processors are becoming increasingly complex. It is no longer good enough to just have the cpu running. If you consider the OMAP3 cpu family from TI, then you have to ask the following questions: are there libraries available for the 3D acceleration engine, and can I even get them without being committing to millions of units per year? Is there support for the DSP bridge? What is the cost of all this? On a recent project I was involved in, a basic WinCE BSP for the Atmel AT91SAM9260 cost $7000. In terms of developer time, this is not much, but you have to also consider the on-going costs of maintenance, upgrading to new versions of the operating system, etc.
APPLICATION DEVELOPMENT
Both Embedded Linux and WinCE support a range of application libraries and programming languages. C and C++ are well supported. Most business type applications are moving to C# in the WinCE world. Linux has Mono, which provides extensive support for .NET technologies and runs very well in embedded Linux systems. There are numerous Java development environments available for Embedded Linux. One area where you do run into differences is graphics libraries. Generally the Microsoft graphical APIs are not well supported on Linux, so if you have a large application team that are die-hard windows GUI programmers, then perhaps WinCE makes sense. However, there are many options for GUI toolkits that run on both Windows PCs and Embedded Linux devices. Some examples include GTK+, Qt, wxWidgets, etc. The Gimp is an example of a GTK+ application that runs on windows, plus there are many others. The are C# bindings to GTK+ and Qt. Another feature that seems to be coming on strong in the WinCE space is the Windows Communication Foundation (WCF). But again, there are projects to bring WCF to Mono, depending what portions you need. Embedded Linux support for scripting languages like Python is very good, and Python runs very well on 200MHz ARM processors.
There is often the perception that WinCE is realtime, and Linux is not. Linux realtime support is decent in the stock kernels with the PREEMPT option, and real-time support is excellent with the addition of a relatively small real-time patch. You can easily attain sub millisecond timing with Linux. This is something that has changed in the past couple years with the merging of real-time functionality into the stock kernel.
DEVELOPMENT FLOW
In a productive environment, most advanced embedded applications are developed and debugged on a PC, not the target hardware. Even in setups where remote debugging on a target system works well, debugging an application on workstation works better. So the fact that one solution has nice on-target debugging, where the other does not is not really relevant. For data centric systems, it is common to have simulation modes where the application can be tested without connection to real I/O. With both Linux and WinCE applications, application programing for an embedded device is similar to programming for a PC. Embedded Linux takes this a step further. Because embedded Linux technology is the same as desktop, and server Linux technology, almost everything developed for desktop/server (including system software) is available for embedded for free. This means very complete driver support (see USB cell modem and printer examples above), robust file system support, memory management, etc. The breadth of options for Linux is astounding, but some may consider this a negative point, and would prefer a more integrated solution like Windows CE where everything comes from one place. There is a loss of flexibility, but in some cases, the tradeoff might be worth it. For an example of the number of packages that can be build for Embedded Linux systems using Openembedded, see.
GUI TRENDS
It is important to consider trends for embedded devices with small displays being driven by Cell Phones (iPhone, Palm Pre, etc). Standard GUI widgets that are common in desktop systems (dialog boxes, check boxes, pull down lists, etc) do not cut it for modern embedded systems. So, it will be important to consider support for 3D effects, and widget libraries designed to be used by touch screen devices. The Clutter library is an example of this type of support.
REMOTE SUPPORT
Going back to the issue of debugging tools, most people stop at the scenario where the device is setting next to a workstation in the lab. But what about when you need to troubleshoot a device that is being beta-tested half-way around the world? That is where a command-line debugger like Gdb is an advantage, and not a disadvantage. And how do you connect to the device if you don't have support for cell modems in New Zealand, or an efficient connection mechanism like ssh for shell access and transferring files?
SUMMARY
Selecting any advanced technology is not a simple task, and is fairly difficult to do even with experience. So it is important to be asking the right questions, and looking at the decision from many angles. Hopefully this article can help in that.
I have worked in projects that involved customizing the software of an OEM board and I wouldn't say that Linux is cheaper. When buying a board you also need to buy the SDK. You still need to pay even for the Linux version. Some manufacturers offer both Windows CE and Linux solutions for their boards and there isn't a price difference. For Windows CE you also need the Platform Builder and pay for the licenses, but it is easier to go without support.
Another important issue is if you are building a User Interface or a headless device. For devices that require an LCD screen and human interaction is much easier to go with Windows CE. If on the other hand you are building a headless device, Linux may be a sounder option - especially if network protocols are involved. I believe that Linux implementations are more reliable and easier to tweak.
With Linux you are never on you own and you are never dependent on one single entity to provide permissions. There are many support options and you have the freedom to choose your support options for any part of the system through many competing sources.
With Windows CE you must adhere to the license and restrictions as set forth in the complex license agreements that must be agreed to. Get a lawyer. With windows CE you have only one proprietary source for OS support and you will proceed only as they see fit to support and provide what you need. You may not agree with their position, but will not have any recourse but to bend to what they prescribe. The costs of incremental components, modules, development kits, licensing, and support tend to pile up with proprietary platforms. In the longer term, what happens when the vendor no longer desires to support the platform and you do not have the rights to support and distribute it yourself? What happens when the vendor moves to newer technology and wants you to move along with them even though you may not be ready to make the move? $$$
Our experience with Windows solutions in general is that they tend to become more expensive over time. What was originally considered lowest TCO gravitates quickly towards and solution that is encumbered and costly to maintain and support. Licenses have to be re-negotiated over time and the new technologies, often unneeded, are forced into the picture at the whim of the provider for the sake of THEIR business needs. On top of that, the license agreements are CONTINUALLY changing--get a lawyer.
With Linux you have the freedom to provide in-house support and expertise without being encumbered against distributing the solution as you need. You also have the freedom to continue to use and support technology that original providers no longer want to support. Having the source code and the RIGHTs to do with it what you want (GPL, LGPL) is a powerful attractor when it comes to business continuity and containing costs while providing access to the very latest technologies or technologies that fit your needs.
I have developed network drivers that work both on RT Linux (to be more specific, Linux preemptive kernel with RT patch) and Windows CE. My experience was windows CE was more stable in terms of real-time response. Frame timings also showed that windows CE had less jitter.
On RT Linux, we had all sorts of problems. For example, when user moved the mouse; our frames were being delayed. Guess what, certain variants of x-windows disable interrupts. You may also feel that you are safer on console screen only. If you have VGA frame buffers enabled, you are doomed again. We had only one problem with windows CE in terms of jitter again. The problem happened when the USB controller was set to an incorrect mode in the BIOS and windows CE was using lots of time for polling.
To be honest, windows CE had more support. On Linux, you are on your own. You have to read every possible mailing list to understand what problems you may hve.
a partially customised OS
Is much easier to achieve if the OS is open source (and you have the expertise).
Android is a good option for some embedded systems.(it's linux based)
You have many experts that are able to develop on this system.
You have access to many libraries in java or C.
but it uses lot of memory and energy.
What we often forget with paid / licenced software is that you have to deal with licenses. It takes time and energy! Then you have to track if you pay it correctly. It involves many different people with different skills and it costs in decision.
This cost is often not included in the studies that show that open-source/free is more expensive than paid software.
With "free software" it's way easier to deal with licenses and you spend less time on dealing with these issues. Personally I prefer to avoid unnecessary communications with your legal / financing team every time you change some pieces of the software.