Related
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.
Title basically surmises the question, but just to clarify. What language or languages are used for programming remotes for multimedia setups like home theater systems? Is it a scripting language? Are there SDKs?
Here's an example I'm pondering. Someone wants a high end theater installed. They get A/V consultants to come in and have the remote do something special, like dim the lights, turn the TV on in 5 minutes and switch inputs. All of this seems custom to the client. Does the A/V consultant go back to the shop, tell his requirements to the programmer and the programmer rights some assembly to make it happen?
You can buy programmable remotes which can learn some pretty advanced control sequences. Take a look at the links in this Coding Horror post which recommends Logitech harmony remotes
The language is most likely Assembly (maybe C if your lucky). Don't expect to see a remote that uses a scripting language. Scripting Languages are great for writing everyday programs but when it comes to writing software to interface to hardware you run into a wall. Scripting Languages try to protect you from low-level stuff (like pointers). When writing software for a remote you need low-level stuff.
I wouldn't expect to see anything like the .NET Mircoframework for the remote (unless the remote was made specially for that).
A remote is almost certainly perceived of as a device, not a programming platform. This means that the programming will be done in a way that is cheapest to fit into the device, since the cost of getting the programming done is much less than the cost of giving every device additional computational power. The remote is almost certainly not capable of being reprogrammed in any other way than swapping out a chip or larger component.
There are software development kits for programming chips used as microcontrollers, although they're not likely to have special features for remotes and the like. They're likely to come from the chip vendor, although I've seen third-party kits for sale. They may not be cheap: when you're going to ship a half-million units you're probably doing everything you can to get production costs down and not caring as much about the fixed costs.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have been using Fedora Linux for quite some time now for web development (and for other dev stuff as well). But just recently, someone told me that since I'm doing web development, I might as well use a Mac. I feel like Macs are overrated. Why should I (or should I not) use a Mac?
Ok, here is my 2 cents.
I am a PC guy, have been for years.
I purchased a MAC about 3 years ago, and installed the Macromedia Tools (Dreamwaver, etc).
Despite my best attempts, I just could not be productive -- I was just so used to the way things worked in Windows, the MAC OS (while very nice) felt counter-productive to me.
So, I am back to the PC (have been for years).
My point is, whatever OS you are USED to is the one you will be the most productive on, with the only exception being if there is a particular APP that is only available on another OS.
So, I would stick with what you know (apparently, LINUX), or be prepared to lose some productivity for a while.
I have been doing web development on Linux for years. Despite owning a Mac, I have never once needed to use it for web development.
VIM, Apache, MySQL, Inkscape, Gimp, GEdit, Firefox+addons
That is all I need.
I will test in IE and Safari and others, but that is testing, not development.
unless you can think of a reason, why should you?
I can think of one good reason, there's an OSX software called CSSEdit which could be the best CSS editor I ever used. It supports something similar to #region found in VS and also have a good hierarchy view on rules and classes.
I really enjoy using my MacBook Pro for all kinds of development, not just web development, but not for any of the reasons anyone has mentioned. Sure it has nice Unix underpinnings, and is very pretty to look at. The main reason I use the Mac and OS X for development is how well and consistently it works. The keyboard shortcuts are consistent across all applications, and the keyboard is laid out in a way that makes it very natural to use the operating system's commands. For me, it's much easier and faster to use the Mac Keyboard in conjunction with OS X for development, even on a laptop, than it is to use a mouse/keyboard on a desktop. I also don't have to worry about drivers or programs working, like I do with Linux (e.g. Adobe Flex).
I've been using Mac for web development for the past year and have recently moved over to Ubuntu Linux and am having a much better time.
Here's why:
Integrated package management: while macs have macports, this isn't integrated across the whole OS. With ubuntu I can type in a couple of commands (or use a GUI if I were so inclined) and have LAMP up and running in about 3 minutes flat. This is without the user of any shrink-wrapped 'LAMP Installations' like XAMMP or MAMP or EasyPHP, just the raw software itself. This becomes a lot more important when you start using tools like pear, phpunit, rubygems etc which are much less hassle to configure and get working on ubuntu than they were on the Mac.
Nice Terminal: Relevant only to Unix based developers I guess, but it has a nice multi-tabbed terminal (iterm on mac has this, but it became face-achingly slow for some reason) that expands to a complete fullscreen.
UPDATE: I'm still on Tiger. Leopard, admittedly has a pretty good terminal.
Easy Virtualization: Again, Mac may have options for this but I probably gave up trying to install them. I'm currently using wine and virtualbox for virtualizing windows and testing IE for web dev projects.
Nice Open Source Alternatives To Graphics Software: I don't like stealing software, and I can't afford photoshop etc. GIMP and Inkscape are good enough for me. Again these are available on the Mac, but the X windowing system that GIMP uses doesn't work so well on OSX. Flawless in ubuntu however.
Overall I'm just way more productive on a linux machine. This could be because I like things at the terminal rather than with GUI's, but the big win for me is definitely the ease of installing new programmer-relevant software with apt-get.
I personally don't think there are any cons (unlike when I have to develop on windows box GRRRRRR!). The pros are as follows
Test in any browser on on any platform
Apache built in (But I recommend MAMP)
Great native developer tools (Coda BBEdit et al)
A major con is the lack of Internet explorer. That being said, I have Internet Explorer 6 installed Via Wine, so I can use it like any other Mac program (in X11).
It also probably takes more work to get ASP setup on a mac, like installing mono, but even that is easy enough.
There is a lot of great web software that I LOVE on the mac, such as Coda, Transmit, CSSEdit and TextMate.
I'm a PHP programmer, and having developed on a Mac for 2 years, I've come to the conclusion I would rather be using anything else.
Since the original question was in regards to using a Mac instead of Linux for web development, that's how I've rephrased my pros & cons.
Pros of Mac over Linux:
Fully supported by commercial grade products (Adobe, for example).
Cons of Mac over Linux:
Larger than normal buy-in cost for a complete system.
Closed system - no hardware upgrades except maybe HDD & RAM.
Edit: In regards to the comments I've received, I've re-evaluated my response to be more in line with the original question.
It really doesn't matter when coming to the Web. Adobe's products are considered some of the best in the industry - such as Flash and Photoshop. You can easily get these on Windows too.
I think that web development is one of the things Linux is very good at, because you can easily setup all the standard server side components. On a mac you can do that too but MacPorts and Fink just don't are the same quality and so updated as Debian, Ubuntu, Fedora, etc.
One point for the Mac may be the availability of good commercial development products.
For web development it really doesn't matter what kind of operating system you are using. Even though I am using a Mac, web developers using Windows may have the advantage of running Internet Explorer native while the rest has to use virtual machines for that. But again, it doesn't really matter then.
The only pro-point I can think of is that 90% of the design folks are using Macs, so you would be able to keep up with the coolness-factor many of them are trying to pull-off.
Well if I remember correctly, you can't really do flash developmenton Linux. Plus, as much as people praise the merits of GIMP, I don't think it's quite on par with Photoshop / Illustrator in term of ease of use (heck there is a part in the FAQ that explain you how to draw a circle).
I tend to prefer Windows for whatever developpement though as I really like Visual Studio.
It's my impression that a lot of Ruby on Rails and other relatively new and cool languages have good support on the Mac. I often read about Silicon Valley hipsters (there's that word again) being Mac-centric.
Also, obviously, if you ever intend to get into iPhone development, you'd be all set.
CSSEdit + Adobe Dreamweaver + TextMate + Transmit FTP + Firefox with FireBug and FirePHP and you good to go on MAC ;)
I moved to MAC 2 years ago, no regrets.
It's certainly handy to have a Mac around, if nothing else to check for Safari compatibility, but most of the better tools I've encountered are pretty much platform independent (outside of the .Net world anyway, and even they have Mono).
All of the following are available on all the major platforms
Firefox/firebug for browser debugging (on Mac, Windows and Linux)
Eclipse or Netbeans for IDE (ditto)
Tomcat
Xampp is available on all major platforms in slightly different flavours and gives you most of the tools you'd need for a whole class of development.
The only reason I can see to tie yourself to a particular platform If you have a particular niche you need to target and the application only runs on that one platform. But as this is web development you're talking about you may well find yourself excluding most of the world.
After juggling with various environments. I finally have the following configuration.
Use Windows for Visual Studio Team System development.
Use WinSCP, Notepad++ on Windows to connect to a Linux machine via sFTP and develop PHP
Use terminal on MAC for mysql development. Sometimes I use putty on Windows as well.
Use MAC for Flash CS4 and Flex development.
Overall, in my context, I found Windows to be much stronger platform than MAC for web development.
Really, the issue is that Apple sells hardware and a user experience. With the Mac you would be able to bring the computer to any local apple store for rapid repair and tech support. They wrap the open-source BSD like Darwin OS with a convenient GUI that they control to present a unified experience. So it's just as powerful as you are used to an OS being but has amazing convenience for both software and hardware.
As others mentioned you can run IE with wine, so there's nothing you can't do on it for web development, plus there are great mac only webdev apps (read the other posts).
e.g. I develop on my mac using the full power of *nix (the differences are negligible, like if you need to use RC for anything and don't want to mess with OSX's launched). If anything goes wrong with the hardware I go to the local mall, they fix it asap, and I'm back to programming.
Do you really want to buy your Dell and mess with installing whatever OS then when it breaks talking with some guy in India before they'll let you ship it to Kazmandu for fixes?
Why not give it a try?
While developing any commercial web based application it is important to give "Look n Feel" and "Usability" its due importance. DUring development phase the application looks and works excellent on MAC but when run on Windows, it starts to show problems.
Considering the large number of target audience who use Windows or Linux, I feel that development of Web Applications is better done on Windows or Linux.
Pros: TextMate & CSSedit
Cons:
here is what I see that are good on Mac's for web dev
CSSEdit (only for Mac) - this package makes CSS editing so much easier. The X-ray function is a must have. Firebug has somewhat similar capability and free, but it's just not as well implemented as CSSEdit, and I searched for Windows equivalent and found none.
Probably better support with Adobe software than Linux :p
Coda or Espresso (only for Mac) are two other web developing suit I personally think are much better then Dreamweaver.
System is fairly hassle free. Less time dealing with system. More time for coding, or whatever it is that you want to do.
Exposé windows management is a great time saver too
Time machine back up is another gem. Easy to setup, and saved my butt quite a few times.
Colors system on Macs are better than Windows as far as I know
Parallels Desktop or VMWare are fast enough to debug IE, so no reboot or a separate computer necessary. (Sorry, not sure what the Fedora situation is though)
OS interface is much better than windows (again, no Fedora experience here). It takes about 2 weeks to get used to (from several friends experience). After that, there is usually no turning back.
There are cons of course, but right now I can only think of one:
Notebook's screen sucks… all TN panels. They are maybe good enough for average users, but for any color critical work, it's just no up to the snuff, so if you get a notebook, you wanna get a decent external monitor.
The Mac doesn't really have an edge over Linux for Web Development. If your comfortable and productive on Linux don't bother switching.
However, If the thought of having Unix with a pretty face and well thought out GUI appeals to you then the Mac is an excellent choice. I have one for development at work and use Linux at home for personal projects. For development work there isn't much difference. The difference is in all the non-development stuff.
For instance I absolutely love Quicksilver on the Mac. It's a wonderful interface to most of what I do. I almost never use it when doing code though. It comes in handy when I launch music or open a web page or play a video or any one of a hundred other things I do on that machine. The polish is nice but when it comes time to get serious I just pull up a shell and get just as productive as I am on Linux.
I cannot speak for myself, as I don't own a Mac (or have consistently worked on one), but I work in an environment full of Macs. And I can tell you, most of them are mac users that happen to be web developers as well. They are productive because they take advantage of whatever the features a Mac offers them, and can control their environment. This applies to all operating systems, but the switch involves a learning curve that you must be willing to accept.
You should also consider compatibility, when working on a team. We usually don't have any problems setting up the application environment or working consistently with the code between different OS. But if you need to do image edition stuff, work with very Mac specific tools or need specific software (IE comes to mind), you may be tied to the OS.
The short answer: it depends on how much effort do you require for adapting. The user experience in Mac seems to be the killer feature over deciding. Other than that, they are pretty much the same in term of productiveness, except maybe for the software some people has pointed out already.
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.
I need this info to decide on what I am going to do about my platform support of my systems in the coming year, but can't find any real info on that. Maybe someone has some just released information.
Thanks in advance.
There are four projects on the Delphi roadmap:
Delphi Weaver (Firebird support, enhanced RTTI, Windows 7 API)
Delphi X (Cross-platform)
Delphi Chromium (Quality)
Delphi Commodore (64-bit compiler, better multi-threading support)
You are looking for Delphi X, but it is unknown when it will come out. Delphi Weaver will be the next Delphi version.
This is as much as there is publicly available. Marco usually is well informed. But there are no release dates for the version.
Project Weaver
Focused on User Experience (new IDE Insight, Touch support),
Connectivity, improved Documentation,
Team Productivity, DataSnap with HTTP,
REST server, .NET Proxies for
DataSnap, Callbacks supported,
dbExpress with native Firebird
support, Aspect Oriented Programming
support, Subversion integration,
Windows 7 and Direct2D support, SOAP
1.2 clients, enhanced RTTI
Project Delphi “X”
Cross-platform support for MacOS and Linux, server and clients on Linux
and Mac
Project Chromium
All about developer productivity, Pascal code formatter,
documentation for the ToolsAPI, new
Databinding model, integrated DB tools
Project Commodore
64-bit Windows, compiler + RTL + VCL, multicore support, parallel RTL
Future (far)
Cloud computing, Web 3.0++, beyond RIA, Devices, sw appliances,
secutiry, compliance
Beyond the Beyond
Functional programming, declarative programming, natural
input, more platforms…
Nothing official from Embarcadero, but I think around 2010-2011 based on:
Embarcadero's CEO Wayne Williams said in interview with The Register:
Williams says cross-platform is now a
higher priority than a 64-bit
compiler, though both are planned, and
that we will see the first
cross-platform release next year.
Beside Robert Love commented at his blog which was about next Delphi versions:
Nothing was set in stone. These are
current plans and they may change.
Time frames where avoided, but one
comment was made in Q & A... They did
not see anything on this list taking
longer than 2011. So 2-3 years may be
practical since time frames were
really avoided, I would not plan on
anything right now.
We at twinforms provide support for Mac and Linux development using the current Delphi versions (for Linux and Mac, you need to compile the source using FreePascal). Have a look at the screencast that shows how to develop a cross platform application using Delphi and FreePascal - http://twinforms.com/products/wxformsdelphi/screencasts.php
A few things to keep in mind about Delphi forcasting:
At DelphiLive! Nick announced that they changed the way they are doing development now. Previously everyone was working on the next release. This made it harder to get bigger changes done in time and done well. So there would be one "code named" version they were working on, and that was it.
Now there are multiple code named projects that are not necessarily attached to a specific release. So for example the list of code named projects that everyone provided here isn't necessarily each a different release of Delphi. They will take whichever projects are "ready" when they have a release coming and include those.
If you want more information about the road map, you can check out a series of videos I shot at DelphiLive! or the DelphiLive! Recap and Product address.
As far as when we might expect the next Delphi release, I wrote a blog post about that based on information provided at DelphiLive! as well.
If you are going to use this information to plan your Delphi purchases, and you don't currently have Delphi 2009 then buy Delphi 2009 now (at least by Aug 24th). They have a great promotion going on, and you can get software assurance and then you will get whatever new versions come out in the next year.
Delphi 2009 is a fantastic release and you will want to come up to speed on generics and Unicode now so you can take better advantage of them in the next releases.
In Stack Overflow Podcast #61, Miguel de Icaza talks a lot about his work on Mono and briefly mentions Delphi, so one might speculate that any cross platform support is going to be built around Mono.
They tried this before with Kylix. Let's hope history doesn't repeat itself here.
The last thing we need is more proprietary development applications.