Slashdot Mirror

The Freescale PPC e200 chips and the Renesas RH850 line.

usually gcc.

Not a single chip I've worked on has had a GCC compiler.

GCC has long had extensive support for PowerPC, including the e500 family. Renesas distributes gcc toolchains that support RH850.

It's either WindRiver's Diab or Greenhills. Former used on the mars rover.

Do you have some first hand knowledge in this area because the software for the Mars Exploration Rover (Spirit and Opportunity) was originally developed with Tornado 1.0.1 (a special release). Tornado 1.0.1 (1997) predates Wind Rivers' acquisition of Integrated Systems (Diab) by two years. I know from first hand experience that Tornado 1.x was shipped with gcc toolchains (including support for embedded PowerPCs).

You are right that there are more RTOS computers out there than the sum of all general purpose computers, including personal, handset and data center. However, you are most probably not right that any one RTOS covers more devices than Linux does. Hell, I strongly suspect that my thermostat is running Linux, judging by the web connectivity options it has. And Wind River, one of the biggest vendors in the RTOS space, has been offering https://www.windriver.com/prod...>its own flavor of Linux for years. Plus, Linux is an RTOS of sorts, don't you know? With the real time patch, Linux works pretty well at the millisecond range hard response level, and has pretty much invaded that space. Microsecond-level hard latency is still ruled by the specialized RTOS. Linux can do it (see Xenomai) but its something of a force fit. Most likely, the most common OS today is still "no OS". What do you think runs the tens of billions of controllers in dime-store toys? Not Linux, not any OS at all in most cases, these things are coded right on the metal.

Excellent survey of real time options for Linux

In a lot of bigger old companies OpenSource is a forbidden word. Working with AUTOSAR and ISO26262 at separate companies it's sad how many companies are reinventing the wheel on their own because: "Our competitors might steal our work." Our legal team forbid us from sending in bug reports to something as popular as Numpy because: "The information could reveal _____ proprietary information." Despite the fact that where it was found is such a niche of a niche of a part of the programming industry that I could hand out our source code and there may be 1000 people at 10 different companies that even knew what it did.

I'd love to see what VW, BMW, Benz, Caterpillar, Cummins, Ford, and Toyota are doing for their on-highway software certifications. Maybe provide some feedback. I'd like to share with them what I use, maybe they can improve it and save some time doing the same thing.

Go through the Fortune 500 and see how many companies have an active GitHub repository. Everyone on slashdot did a doubletake when Walmart opensourced its cloud ops. It seemed to be a shock that Walmart got as big and efficient as they did without some technology pulling the strings.

NXP just released a $35 development board that is hampered by terrible software and outdated business practices. Despite being "free" you need a license key that multiple people have trouble with. All of the Matlab and Simulink code they released is protected. However for the first time, ever, the GCC source code for e200 core PPC chips with VLE extensions has been released for free. Previously you had to have a WindRiver or GreenHills.

Who knows what random product or software people could come up with if they were allowed to work with peers doing the same thing. Even if it was for a sworn corporate mortal enemy.

they usually run at a minimum of 200MHz with a few megabytes for software because they run full-blown operating systems.

No. No. Just No.

The top of the line MPC57xx is only ranges from 32 MHz to over 300 MHz. Most of the ones that are currently in production are more than likely the MPC56xx or MPC55xx line. All of which are much more reliable than the 68ks. The highest end/safest ones run lock step cores with a 3rd core that compares the output to make sure that they're both calculating the same values.

For OS' it's running a RTOS of some sort, not a 'full blown OS'. There are a few different vendors: GreenHills, WindRiver, ETAS, etc.

For compilers it's either WindRiver's Diab or Green Hills. To my knowledge GCC doesn't work on the MPC5xxx line. I've been trying to talk my boss into sponsoring a grad student to get LLVM ported so we can at least do some prototyping without paying for a license.

And not if you're going to be using the eTPU, which requires a separate compiler.

With most of the control algorithms written in Simulink and the HAL done in C or C++.

What we need is standardized and open source ECUs that handle all the basic systems needed for the car to function.

I'll be the first in line.

So to recap:

• The dev boards start at ~$500+.
• Theres' no opensource compiler for the chips.
• There's no opensource RTOS for the chips.

A single small team *may* be able to make ECM for vehicles ~10+ years old but unless you have a lot of money to donate to a cause, a fully opensource everything for 2017 vehicles isn't going to happen.

they usually run at a minimum of 200MHz with a few megabytes for software because they run full-blown operating systems.

No. No. Just No.

The top of the line MPC57xx is only ranges from 32 MHz to over 300 MHz. Most of the ones that are currently in production are more than likely the MPC56xx or MPC55xx line. All of which are much more reliable than the 68ks. The highest end/safest ones run lock step cores with a 3rd core that compares the output to make sure that they're both calculating the same values.

For OS' it's running a RTOS of some sort, not a 'full blown OS'. There are a few different vendors: GreenHills, WindRiver, ETAS, etc.

For compilers it's either WindRiver's Diab or Green Hills. To my knowledge GCC doesn't work on the MPC5xxx line. I've been trying to talk my boss into sponsoring a grad student to get LLVM ported so we can at least do some prototyping without paying for a license.

And not if you're going to be using the eTPU, which requires a separate compiler.

With most of the control algorithms written in Simulink and the HAL done in C or C++.

What we need is standardized and open source ECUs that handle all the basic systems needed for the car to function.

I'll be the first in line.

So to recap:

• The dev boards start at ~$500+.
• Theres' no opensource compiler for the chips.
• There's no opensource RTOS for the chips.

A single small team *may* be able to make ECM for vehicles ~10+ years old but unless you have a lot of money to donate to a cause, a fully opensource everything for 2017 vehicles isn't going to happen.

As an ECU is an embedded, and likely a rather proprietary, platform, it is likely that an alternative compiler would not be available.

Try again.

I have no idea what embedded compiler they are using. At work we have been using VxWorks and gcc/g++, though it supports 2 others. The interesting bit is there are variants on VxWorks which are very traceable in functionality. Here is a link: VxWorks Cert They also have an MLS version.

Basically, use something like that, plus certified hardware, that meets all environmental and such, plus probably use all highly background checked employees, plus do a lot of code reviews and various forms of static analysis, plus do tons of automated and manual testing, and all the rest, and you should be able to make a fairly solid embedded system, provided you limit its job to a set of reasonable tasks.

Here is a possible solution to this kind of mess.
1) Tell regulators what you need to compile the system, hardware and software. Provide a copy if needed.
2) Let the regulators bring a team in to a closed area and carefully analyze things. Produce a final image with say a 256 bit cryptographic checksum.
3) Verify that delivered cars have that checksum on that embedded system.

Alternatively, you could do something like this:
1) Store all binaries on a secure central node that is US approved. It could be fairly small.
2) To load a binary to the secure central node you must have it first signed by the regulators.
3) To have a binary signed, the source must be reviewed, as well as typical operation, similar to the previous.

Of course nothing would really stop an aftermarket swap of that central node, unless it is also checked during boot.

More practically though, a more implementable solution is to simply have the EPA test drive cars from dealerships. A portable data collection system is very doable. Drive them for a few hundred miles.

there are no other commercial operating systems other than Windows anymore?

There's QNX and VxWorks.

Who exactly made the choice of tools to use in the first place?

Lots of people, here's a brief SAE technical paper on it: Caterpillar Automatic Code Generation

Why not choose non-proprietary hardware in the first place? Too simple?

As much as Slashdot hates to acknowledge it money makes things work. We pay a company to develop a compiler instead of hoping some volunteers do it for us. We pay a company to have parts of a toolchain in place so we don't have to.

Too simple? Too hard. There's no piece of open source hardware that comes close to what tractor ECMs could do a decade ago. The OSS community seems to be more interested in dev boards than actual finished products. This ECM is what drives a lot of the world of tractors. There are a dozen or so variations that have different pins populated with different IO but at its heart it's a 40(?) MHz Freescale MPC56XX chip with an eTPU to do all the fast timing.

But it exists because we paid engineers a lot of money to develop it. We paid more engineers to test it and even more engineers to write software for it all while paying outside companies for their tools to cut prototyping time. Vector CANape for CAN based calibration, Mathworks Simulink for model based control, Wind River for their diab compiler.

I would love to tear the ECM out of my VW TDI and replace it with one of our own. I could write a new controller for my car in an hour or two with our toolchain. Without the tool chain it's a PITA and I haven't bothered.

We treat our tools as tools. I don't question how or who designed my hammer when I use it to hit nails. I just care that it doesn't break and works as it is designed. The 'toolbox' I'm sitting on right now is the sum result of decades of development ahead of where open source is.

IF anyone wants to help develop a completely OSS ECM and toolchain for ECM development I have a laundry list of what is needed to catch OSS up with where industry was in 2005, but I'm not holding my breath.

"In the report, which will be released this week, the company details incidents of medical devices and management stations infected with malicious software at three, separate customer engagements."

Wouldn't it be safer to run these medical devices on a dedicated Real Time Operating System (RTOS). That isn't susceptible to acquiring malware through normal operation ref.

What about severs and web hosts / ECT.

Windows 7 UEFI secure boot??? enterprise use is way to big for that to get locked out.

Where is HP and DELL in this???

Supermicro??

Tyan??

Linux in Medical Devices (do really want MS windows to be the only choice there??)

http://blogs.windriver.com/medical/2011/11/using-linux-in-medical-devices-what-developers-and-manufacturers-need-to-know.html

Well, there are people working on overlapping windows on Android.

Would be kinda entertaining if at some point in future MS released Metro-only version of Windows at the same time as Google releases desktop version of Android.

Sorry but Intel does now sell operating systems: VxWorks. Also note.

...it's now used by companies like Nokia and Adobe...

...and Google and Palm, and...

TFA appear to be wrong. It runs VxWorks 5.2.

The confusion probably arose because Wind River also sells a Linux version, and the press sometimes confuses that with VxWorks.

In this case, RMS is wrong. If RMS was truly about "Free" as in "freedom" he would have chosen BSD style license, which has even less restrictions.

NT (like OSX) has a microkernel, but the operating system isn't just the microkernel. Most of OSX (for example) actually runs on UNIX which runs as a single application of the microkernel. NT also has an enormous number of kernel-entry points which means that it too is a monlithic-kernel-based system that happens to run on a microkernel.

A real microkernel-based system will have a lot of the userland facilities designed to take advantage of message passing and will probably look more like HURD or Squeak than it will like NT or NeXT. QNX and VxWorks are the only successful microkernel-based systems that I'm aware of, and frankly both of them are losing big to Linux, so we might have to say were the only successful systems in the future...

IPv6 partisans strongly discourage NAT...

It occasionally decides that one of the other machines has dropped off the LAN even though all other machines can see it and connect to it. When that happens, the only recourse is a reboot.

I found a bug like that once in eCos. Sometimes the embedded system would see other machines on the net, sometimes not. Turned out it was a bug where they had some union for sockaddr* structures in the driver and the space they were allocating for the structure wasn't the max size of all the union's parts, so the ARP table got corrupted. No ARP table entry for a machine, no way to talk to that machine. Apparently, it wasn't a problem if you used DHCP, but since our Linux Priesthood declared that /etc/hosts must be used ("a DHCP server would just be another thing that can break"), so nobody else ever caught it. (It was fun writing an /etc/hosts equivalent function, since eCos doesn't assume a filesystem, but I digress.)

You could fire up wireshark and see if your iCandy machine is sending out ARP packets asking for the machine it claims has disappeared. That's what nailed it down for me.

Of course, since eCos was open source, I had it fixed with the help of some forum posters inside of a week. No problems since. Wonder how that would work out with closed-source stuff, like VxWorks or uC/OS-II. Oh, yeah, they'll charge me $50k or so to get the source so I can fix it myself, or they'll make me send a complete set of test hardware and source code to them for them to look at, and they'll find it in a couple months, and the bug fix will be in the next version six months to a year after that. Can't say I miss those days.

Many of NASA computers on spacecraft use a long-tested version of realtime UNIX called VxWorks from Charles River. It doesnt nexcessarily have the fancy stuff in modern *nix's, but is fairly reliable. Even that has been known to fail.

The registered mark RTLinux, and RTLinux Pro, RTCore, and LNET, are now owned by Wind River. a.

If your company if comfortable with VxWorks, how about Wind River's offering...

http://www.windriver.com/announces/rtlinux/

is VXWorks, from Wind River ( http://www.windriver.com/ [windriver.com] ). It's a *nix-like real-time OS.

And as soon as SCO beats IBM, Novell, and AutoZone like bongo drums in court they're going after NASA. "All Your UNIX Are Belong To Us."

is VXWorks, from Wind River ( http://www.windriver.com/ ). It's a *nix-like real-time OS.

Yeah, you would never use linux. Instead, you would use a hard real time OS that are used heavily in jets or rockets.

The very successful Mars Rovers, which have no one around to give them a "three finger salute," are based on Wind River's VxWorks RTOS.

I believe the current ones would probably use C/C++ since they are using VxWorks according to Windriver. If they are using a RTOS now, I think moving to something like Java would be a huge jump. I could see them moving to embedded Linux though, it's becoming alot more popular in the embedded world

I have yet to see a "proper" non-academic microkernel which lets one part fail while the rest remain.

QNX, but it isn't open source.

VxWorks and a few other would also fit.

No, its VxWorks. See link here: (http://www.windriver.com/portal/server.pt?space=O pener&control=OpenObject&cached=true&in_hi_ClassID =512&in_hi_OpenerMode=2&in_hi_ObjectID=371)

Only 17 percent of embedded systems designers are currently using embedded Linux, and 66 percent say they are either not interested in using it or do not expect to be using it anytime soon

So, reading this backwards, a third of embedded systems developers are interested in embedded Linux and/or expect to be using it soon.

Compared with where the market was five years ago this is huge. Of the other two thirds, a large percentage goes to TRON and probably VxWorks. And if you want vendor-provided qualified platforms and support, you can get that from the same folks who make VxWorks.

Surely a change in survey results from a year ago is something to be curious about but there's no indication it's a trend.

I have been running FreeBSD since the 3.x days. Right around this time Linux became popular but I stuck with FreeBSD for several academic reasons. At that point one was as good as the other, but as time went on this changed. Linux started gathering a huge following and it really hit its stride. The developers made leaps in bounds in hardware support. Meanwhile, FreeBSD crawled from 3.x to 4.x, which was a great improvement to be sure, but not as rapid or large as what Linux had been offering.

Being locked into FreeBSD by familiarity and investment at that point I wistfully watched the GNU community race ahead. I wish something would start a similar firestorm of FreeBSD development. I thought nothing of it when Apple bought NeXT in 1996. The Rhapsody project, which was basically just adding some Apple technology to OpenStep, didn't interest me. When Steve Jobs announced Mac OS X in 1999, however, my ears perked up at the mention of my favorite Unix. Apple was going to update the very cores of OpenStep into something new FreeBSD was going to be a huge part of that.

Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD. Apple's pattern is to sync every major Mac OS X release with the latest major FreeBSD release. For example, Mac OS X v10.1 corresponded to FreeBSD 4.4 and Mac OS X v10.2 matched up with FreeBSD 4.7. By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. Mac OS X v10.3 contained bits of both FreeBSD 4.9 and FreeBSD 5.1.

Look at it this way, only after Apple started modifying FreeBSD 4.x and submitting their modifications did FreeBSD progress to the 5.x branch. The advanced VM and SMP code that allows Mac OS X to run so efficiently is the very same code that finally put FreeBSD on the level with Linux. I run FreeBSD 5.2 on a four-way Xeon box at work and thank Apple every day. If it weren't for the Mach micokernel from Apple we wouldn't be able to do these nice things with FreeBSD now or probably ever.

It's also kind of ironic how such a big deal was made by Wind River Systems buying out both BSDI and Walnut Creek Software. (Does anyone remember this?) The plan was to merge BSD/OS into FreeBSD and sell a special enterprise edition of the operating system while still maintaining the Open Source project. Sadly this fizzled out. No one ever predicted that Apple, of all companies, would ride in with the cavalry and pick up the pieces. Apple has done much more than Wind River ever managed to.

After such a long and precarious history FreeBSD is finally going somewhere and we no longer have to worry about the latest hardware support of when the next release will be. We're firing on all cylinders now, and within a couple more years there will be more FreeBSD installs than Linux or Solaris! I'm not so proud that I can't see what is behind this. Apple saved FreeBSD and I have no problem admitting or accepting that. I doubt many others who use FreeBSD do, but I just wanted to point it out.

Thank you, Apple, for saving FreeBSD.

" Does anyone know if the automated rovers/spacecraft use a commercial or OSS OS? Or does NASA roll their own? -j3rry"

The mars global surveyor (the oldest one launched) is running a modified version of WIN95 from what I've been told in the past.

The newer rovers use an operating system called VXWORKS made by windriver. VXWORKS is kind of like a single-user based UNIX real time operating system (however, it's closed source and proprietary)

Here's the page for VXWORKS:
http://www.windriver.com/products/device_technolog ies/os/vxworks5/

Wind River Systems built the POSIX compliant based OS into the Odyssey, Stardust and Rovers, so it's possible the MGS has a similar OS to those.

The OS is VxWorks and it's been used in Sattelites, Robots and for some reason Movie editing (probably a file management system)

http://www.windriver.com/products/device_technolog ies/os/vxworks6/

http://www.chron.com/cs/CDA/ssistory.mpl/special/0 3/mars/jump/2404308

I know some of their stuff (i.e. the MER rovers) use VxWorks. See http://www.space.com/businesstechnology/technology /mer_computer_040128.html and http://www.windriver.com/news/press/pr.html?ID=355

If you do not want anything do not compile it. simple

http://openwrt.org/
http://www.uclinux.org/
http://www.lynuxworks.com/
http://www.windriver.com/

Today one can not find BSDi among WindRiver's products (it used to be there just recently, according to Google, though), and customers in need of support for their earlier bought licenses are requested to contact BSDMall instead.

Duh...

Considering that it is the same company that did the Mars Rover software, this is a big thing.

For a company with such a high profile product to adopt Linux is only a good thing.

I wouldn't say their "metamorphosis", if they ever purported to want or aim to do such a thing, is complete - I mean they are still selling VxWorks right? I believe the top four platforms on their Product Directory are based on VxWorks, not Linux. I think they can fairly be described as an embedded software vendor that supplies Linux platforms, rather than an "embedded Linux vendor".

"Stability is crucial, so I'm leaning toward a Linux-based system"
You should be looking at embedded operating systems, such as VxWorks which is what some of the real car manufacturers actually use
I would consider the display of a car a fairly mission critical application, and you want a system that's designed for these kinds of tasks. This isn't something you can bodge up and whack on a small PC with an operating environment that hasn't been designed to do such things.
Linux is far too complex for something like running your car's display, there is simply too much that can go wrong.
It would also be well worth checking out what the laws are like in your part of the world, I know that where I am, if I replace my (airbag equipped) steering wheel with an aftermarket one that doesn't have airbags, my car is no longer roadworthy.
I sure hope you've got some deep pockets if you truly want to get this project rolling
Kai

"Stability is crucial, so I'm leaning toward a Linux-based system"
You should be looking at embedded operating systems, such as VxWorks which is what some of the real car manufacturers actually use
I would consider the display of a car a fairly mission critical application, and you want a system that's designed for these kinds of tasks. This isn't something you can bodge up and whack on a small PC with an operating environment that hasn't been designed to do such things.
Linux is far too complex for something like running your car's display, there is simply too much that can go wrong.
It would also be well worth checking out what the laws are like in your part of the world, I know that where I am, if I replace my (airbag equipped) steering wheel with an aftermarket one that doesn't have airbags, my car is no longer roadworthy.
I sure hope you've got some deep pockets if you truly want to get this project rolling
Kai

Linux is a resounding success.

BSD == failure
Linux == Success

Linux is a resounding success.

BSD == failure
Linux == Success

Glenn Flinchbaugh, Director of Wind River's Linux Program, will be speaking at SCALE 3x on the topic of Linux COTS Strategies. At Wind River he is responsible for coordinating product strategy, and engineering for their Linux offerings.

Glenn will discuss how the Linux COTS strategy enables telecom equipment providers to reduce costs and time on platform development and maintenance. He will detail the Linux-based COTS advantages that the end-user telecom firms realize, including greater openness and flexibility in the development tools; the greater range of architectures supported; and the appeal of open-source software availability.

SCALE will be at the LA Convention Center on February 12th and 13th, 2005. For a discounted conference pass use the promo code "NEWSP" or for a free exhibit hall pass use the promo code "FREE"

Uh, that's VxWorks by Wind River. (My DSL modem runs it, and I've got a buddy who works on embedded systems with that OS--I hear a lot of complaints about it from him, but that's another story.)

And as I recall, the problem with the rover(s? -- I don't remember if both rovers had this issue or just one) was that there was a scheduling conflict where a high priority task spawned a low priority task that blocked waiting for some event, and subsequently prevented a higher priority task from starting (that might have been a task related to filesystem stuff on the flash memory, now that I think about it).

I'm trying to find a link now. This link says the problem was with removing files in the DOS (do they mean VFAT?) filesystem in Spirit's 256MB flash memory (no mention of the same problem with Opportunity). Nothing about a priority problem. Huh. Where did I hear that?

And I don't mean Linux or *BSD. There are high-reliability OSs out there, and for life critical systems, why can't these vendors use a grown up OS like QNX or WindRiver's VxWorks.

I don't understand this obsession with using Windows in embedded situations! Especially critical systems. Why?? There are other OS's designed for safety, reliability and embedding. Why are these medical equipment companies ignoring these better alternatives?

IIRC, Wind River had a picture on their homepage of one of the previous Mars projects with a blurb saying that it ran VxWorks

IIRC, Wind River had a picture on their homepage of one of the previous Mars projects with a blurb saying that it ran VxWorks

Actually, Wind River announced that they are going to embrace Linux and have links on their site to Linux information.

Let's not lump all vendors together. Keep up with WindRiver, and you'll see they're working on Linux as well. For those who can't read, check here for a pretty picture of their view.

Mmmm, VxWorks, no memory protection goodness! Good OS otherwise though.

NOT! - "Feb...2004...Red Hat and Wind River Partner to Develop Linux Based Solution for Device Software Optimization"