Intel Acquires WindRiver!
We interrupt our regularly scheduled program to bring you breaking news... Intel has acquired WindRiver Systems for $884 Million. I can certainly see where this makes sense for Intel. They've been pushing in the embedded space for quite some time with the Atom. And, WRS's offerings play well into an apparent Intel strategy for moving further into the Mil/Aero arena. The question that remains is what will this move do for Cavium, Raza, FreeScale, etc. that had been using WRS for their Linux partner?
Does this drive those companies to folks like MontaVista? Does this make MontaVista a takeover target for FreeScale or even IBM? Things that make you go hmm.... Clearly, the impact of this move will have reverberations into the market for quite some time. And, who will Green Hills have to bash now that WRS has been absorbed into the body? Only time will tell...
The link for the news is at: http://www.windriver.com/news/press/pr.html?ID=6921
Enjoy.
Living in Linux
With the economic downturn and the imminent demise of Windows Vista, more folks are looking seriously at Linux as a development platform for embedded systems. However, most of us live in a Micro$oft-centric world. We have Exchange servers, Outlook email, Word documents, Powerpoint presentations and a management infrastructure that only understands MS Windows. How can the developer who wants more tools and a more stable development environment survive in the typical corporate world?
Over the next several weeks, I'll be outlining the process of tooling up in Linux while not losing any of the key connections to your management infrastructure. This ranges from the hardware needed to run Linux, to the infrastructure connections to devices like printers and wireless, to the software needed to keep you in contact with the rest of your peers. I'll be outlining several alternatives along the way as well. So, if one approach isn't to your liking, you can try one of the others.
Before we get started, let me tell you the good and bad of Linux. The good is that there is never only one way to do anything in Linux. In almost 10 years of working with Linux, I've never encountered a roadblock so severe that there simply wasn't a way around it. Now the bad part: there is never only one way to do anything in Linux. There are usually at least 6 different ways to do the same thing in Linux. This means that you'll have to pick one approach and go with it until either you get things working, or you find that the technique won't work for you and you have to choose a different route.
That being said, I can assure you that you can live quite comfortably in Linux and still have complete connectivity with your peers. You can even skin the UI in Linux to make it look like Windows XP, Vista, or even OS/X. So, you won't lose the look and feel that you've become comfortable with and the IT wonks can't waltz by your desk and tell that you're not using the official O/S.
So, stay tuned to this channel as I outline what it takes to do embedded development in Linux...
Is Intel's Atom a Game Changer?
I had a friend of mine a few months back tell me that Intel's Atom processor was a "game changer" for embedded systems. The theory goes that Intel is now in the low-power marketplace and the days of processors like the ARM and Power cores are numbered. After I stopped laughing, I took some time to really think it through from his perspective.
He is in the consumer electronics biz. He makes DVRs. For devices that are always plugged in and generally always on, I suppose that the Atom could be a significant player. Previously, the most power efficient x86 variants like the P8400, were in the 25 watt range. The Atom drops that down to about 2 watts. That's very good for the processor. But, the Atom's southbridge like the ICH7 draws close to 11 watts by itself. So, this means that a current technology Atom design will be in the 10-15 watt range for just the processor and southbridge.
This is laugable when compared to an OMAP 3430 at less than 500 miliwatts. But, Intel is working on integrating the southbridge and producing a single SOC. That should bring the power requirements down even further. We'll have to wait and see what Intels latest deal with the SOC manufacturer TSMC reveals.
So, his point was well taken. For a number of platforms like DVRs, set-top boxes, TV sets, etc. having an x86-compatible device at even half of the power requirements of a typical laptop has some advantages. First of all, fanless operation becomes a real possibility. And, you can eliminate a lot of the hassles of cross development. Just use a standard x86 as the development platform and run native code.
However, from a "green" perspective, leaving even the Atom running 24/7 is not very efficient. There are already way too many devices out there where "off" is not really off. If we want the flexibility of instant on, then we have to be willing to pay the price of the parasitic power draw or come up with even better power management capabilities. Intel has the engineering talent to make something like this happen, but the legacy of the 8086 (introduced in 1978) may be working against them. Time will tell.
So, from the viewpoint of a battery-operated device such as a cell phone or handheld game device, I don't see the Intel Atom as much of a player -- yet. For devices with AC power available all of the time, yeah I think maybe the Atom is a game changer. It can certainly cut development costs and Intel is pricing these things aggressively. Aggressively enough to make it cheaper to use the 1.6 GHz Atom instead of that 300 MHz 486-based SOC I've been using for some industrial applications. BTW, I apologized for laughing...
Is XSCALE Dying?
Hmm... OK, it's been almost three years since Intel sold the XSCALE line to Marvell. Back just after the sale, there was a lot of noise about the Monahans part (PXA-320) and how power efficient it was, etc. We all waited, but the PXA-320 never really made the splash or the inroads into the cell phone market that it was supposed to.
In the mean time, TI has come out with multiple OMAP variants that are making news. One only needs to look at the BeagleBoard or the Gumstix Overo to see that OMAP is doing well. FreeScale has also made good progess with the i.Mx series. Good low-power processors that have a reasonable support infrastructure. So what happened to XSCALE?
My theory is that XSCALE suffers from Marvell's paranoia. The same paranoia that caused so many people to avoid Broadcom parts like the plauge. It's just too difficult to get information, data sheets etc. out of Marvell. Every time I've dealt with Marvell, it's been like pulling teeth to get any information out of them. I've got to get V.P. level signatures for NDAs that only last for 30 days so I can download data sheets with so many erratta that I have to keep re-upping the NDAs just to stay on top of it.
As a small unit production developer, I feel like Marvell is afraid that I'll steal their proprietary IP and produce a copy of their chip if they tell me what registers exist so I can port and O/S or a driver to their silicon. I just want to use the silicon. I need information to make that happen. If it's difficult to get the information, I'll use someone else's silicon who will provide me the info like TI or FreeScale.
OK, I've heard that for huge volumes, Marvell will provide great service. I don't doubt that for million unit quantities they will assign a dedicated resource to me. But, the majority of business volume in the U.S. is done by small businesses. And, if it's difficult to get data sheets as a small business, engineers who move to large business will still avoid the parts because of past experience.
So, I guess my point is that I'm not really seeing much buzz about XSCALE in the past couple of years since Marvell took it over. It's certainly not because it wasn't a good architecture. Look at all of the PXA-270 based phones that where produced when Intel ran the line. I believe that XSCALE is dying because of paranoia about data sheets falling into the hands of the open-source community.
My therory is that if Marvell wants XSCALE to stage a comeback, they need to change their data access policies. They need to embrace open-source and create a low-cost platform for the open-source developers to be able to port and experiment with. Without cooperation with the community, XSCALE will become a backwater eddy in the processor world and eventually die out due to lack of interest. I'm going to play with my BeagleBoard now...
Lack of Embedded System Jobs?
I recently wrote a couple of think pieces for IEEE and Embedded Intel Magazine discussing the sad state of affairs regarding the dwindling pool of embedded systems developers. Basically, my thesis was that many institutes of higher learning are no longer teaching CS majors what computers are all about from a low-level perspective (CPUs, caches, data busses and the like) and this is causing a shortage of embedded systems developers. This thesis has been backed up by folks like Jack Ganssle and the many of email responses that I have received from all over the world. Evidently, it's not just a U.S. problem, but a world-wide phenomena.
Nonetheless, I've also received a few emails stating that if there were jobs, then there'd be more demand and therefore more "bare-metal" engineers to fill the positions. That thought got me wondering. I believe that the reason that there are apparently no jobs is because the embedded systems development space is a stealth industry.
We inherently know that embedded systems are almost everywhere. However, as seen at ESC San Jose in the keynote presentation, not a one of the "man on the street" interviewees could identify just what an embedded system was, let alone identify one. The same applies to determining the size of the embedded job market. If you don't know what and embedded system is, how do you know what the jobs are?
The stealthiness of embedded systems is both good and bad. On the plus side, it means that embedded developers are doing their job correctly. On the minus side, no one can identify just what the job was -- let alone what skills it required and how to train/educate for it.
Now, I define an embedded system as one wherein you inherently know there must be a computer in the device someplace, but you're just not sure where. By being a well-designed embedded system, the user is oblivious to its existence. This makes it extremely difficult to define the scope of the embedded systems market precisely because we're doing such a good job at hiding computers everywhere.
As to whether or not there are jobs in embedded systems here in the U.S., I went to Monster and had a look. A quick search showed about 300 job openings for RTOS developers. Close to 1000 for firmware developers. 2,500 for embedded developers. Over 5,000 for systems engineers. 678 for embedded Linux developers, etc. Now, admittedly, there will no doubt be some overlap where there may be duplicate hits for the same opening. But, to say that there are no embedded systems jobs here in the U.S. is just plain wrong.
However, the problem is that in order to understand the scope of the job openings, you need to understand where embedded systems are used. This is one of the fundamental failings of the university system when it comes to designing their curricula. Since the academic community is seemingly no better at identifying embedded systems than the "man on the street", they woefully underestimate the demand for "close to the metal" understanding of computers.
And, as for those who say that all of the embedded jobs have moved to India and China, I'd say that that's a load of crap. Yes, there is a lot of embedded development going on in India and China. But, to say that there's no development left here in the U.S. is just ignorant of the real situation. If that was the case, then there wouldn't be representatives from large high-tech firms lobbying Congress for 195,000 H1B visas for "highly-skilled technical positions" for 2008. Now clearly, most of those H1Bs are not targeted for embedded developers. But, some of them are. And, those openings could represent several thousand jobs going unfilled.
Now, I *do* believe that there's a problem with the salaries that those companies are willing to pay. And, I feel that the proliferation of H1B visas helps depress the salary levels of developers which precludes otherwise promising students from pursuing careers in embedded development. That will be the topic of a future post though.
As Al Gore said at the 2007 ESC keynote, the future of the world and our ability to address the issues of global warming and energy conservation rests in the hands of the embedded developers of the world. Without embedded systems, none of the fancy technology in things like hybrid cars would ever work. So, we need more clever people now than ever before. And, we need to get the educators and the legislators involved to help address the misconceptions about the death of our industry.
So, to those of you who may be thinking of a career in embedded systems development, whether you're a CS, CE, EE or just someone who likes to make things work, don't be discouraged when the naysayers tell you there is no future in computers here in the U.S. The U.S. used to be the technical innovators in the world. We may have lost our edge, but the work is still there and we're still doing innovative stuff. But, we need you to participate.
But, that's just my opinion. What's yours?
Lack of Embedded Support for Debian-based Distros
Greetings!
I've noticed something over the past few months. Namely, none of the commercial distributions of embedded Linux support Debian-based distributions for development. Neither WindRiver, MontaVista, LynuxWorks, nor Timesys support any Debian-based installations. This rules out easily installing any of their commercial products on distributions like Ubuntu. Yes, I know that you can use alien. But, many of the commercial packages will simply refuse to install on non-rpm distributions. This limits you to SuSE and RedHat for the most part, and neither distribution is pushing the community like the Ubuntu folks as far as integration of hardware and new features.
Don't get me wrong. I'm glad that these vendors support Linux at all. I'm just disappointed that they are not supporting what is arguably the most popular Linux distribution in the world. I believe that this failing is keeping them out of colleges and universities where students and their institutions tend to favor the Ubuntu distribution. So, let's get with the program guys! It's time to realize that RedHat and SuSE do not constitute the bulk of development platforms and at least support one Debian-based distro.
Multi-Core: Solution or Problem?
We hear a lot of noise from the silicon manufacturers today about how multi-core processors are the wave of the future. Certainly, they do allow us to pack more performance into a single package. However, are they a good fit for embedded systems?
One argument is that with two or more cores at a lower voltage, we can run with a lower thermal dissipated power envelope. This is certainly true. Power consumption can certainly be lower in certain applications. And, with multiple processors, the potential is certainly there for doing more work with less heat and power consumption.
However, although multiple cores can make good sense from a hardware perspective, they can be a real problem from a software perspective. There are basically two approaches for operating systems in a multi-core environment. One is to partition the cores and run two separate operating systems. This can allow you to mix OS variants so you could have say, an RTOS on one core and a something like Linux on the other for the user interface. Naturally, this complicates the communications between the cores and requires partitioning the memory and assigning certain devices such as PICs to one OS or the other. Essentially, this becomes two uniprocessors in the same physical package.
The other approach is to run an symmetric multi-processing (SMP)-aware operating system. Unfortunately, there aren't too many of these on the market just yet. VxWorks, Linux, QNX and maybe a couple of others. Running an SMP-aware OS can simplify some things such as load balancing. Interrupts and processes/threads can migrate from one core to another based on work load. This can be good. But, it can also be very bad.
The problem comes in when, say, two threads that would have normally run A then B on a uniprocessor due to priority preemption, suddenly run simultaneously on both cores. The potential for race conditions is rampant. We must make sure that our code is not only logically correct, but
temporally correct as well.
Consequently, running on multiple cores requires a significant amount of thought on the part of the software designer. The use of synchronization primitives to ensure proper sequencing is imperative. This is especially true for operating systems like Linux that can schedule different threads from the same process on different cores simultaneously.
In order for us to get the most from a multi-core system, we need to take advantage of the blocking side-effects of certain primitives such as message queues and semaphores to make sure that we run not only the correct code, but the correct code at the correct time. This will require a significant amount of forethought on the part of the designer. This is also why so many SMP-type multi-core solutions will be buggy or fail entirely.
There is no silver bullet here. No language extensions or class libraries will save us from ourselves. We, as designers, must take the time to understand the nature of SMP and learn the proper use of synchronization primitives and how to enforce sequencing of code on multiple cores. Fortunately, with the availability of Intel's Core 2 Duos, multi-core test hardware is relatively cheap. Unfortunately, there are no texts or classes that teach how to write good, multi-core code. For the time being, experience will be the primary teacher.
So, if you believe that you're going to be writing multi-core aware applications in your future, you've got to get on multi-core hardware and start testing your understanding of the environment. Look at processor/interrupt affinity issues and get up to speed on synchronization primitives such as message queues, binary/counting/mutual exclusion semaphores, and condition variables to understand how their use can change the interleaving of code.
Finally, pick up a core duo machine, install Linux and start playing with multi-threading code using the POSIX threading services. Also, plan on attending some of the sessions at the Embedded Systems Conference in April. There will be several sessions there that will help you understand the issues. A little time spent experimenting now will save you weeks of debugging later.
Palm Foleo is Dead
Well... From my last post I reported that Palm had announced the development environment for for the Palm Foleo was stripped version of Wind River's WorkBench product. I also stated that I thought that shipping the Foleo with a 2.4 kernel was a mistake given that 2.6 has been around for over 3 years now. In addition, I commented that the WorkBench environment cost as much as the Foleo itself, so I didn't know how that was going to fly in the open source community. Well, less than 2 hours after I made that post, Palm canceled the Foleo and made the claim that part of the rationale for canceling the Foleo was that the development environment was "too different" from their current and previous products.
Palm now claims that they are going to take a $10MM hit to write off the Foleo and begin working on the Foleo II. When I spoke to the Palm folks at LinuxWorld, I had suggested that they have an ultra-cheap development environment based on standard GNU tools to entice the hobbyist and traditional Linux developers to write/port code to the platform. Maybe that's what they'll come up with for this next product.
In spite of the issues with the Foleo, I believe that the time has come for a non-x86 based ultra-portable that runs Linux. A product like the Foleo (or new Foleo II) could be the impetus for non-x86 Linux to really start to take off and start on-par with the x86 flavor. Let's hope that even though this one is dead, that the next product, whether it's from Palm or someone else, is better thought out with the needs of the Linux development community in mind.
