Slashdot Mirror

The notable exception is the Arm's thumb instruction set (it's cool).

sorry but I run linux on MMU less processors every day.

info

oh and here as well as the thousands more sites about it indexed on www.google.com..

Linux can run on MMU-less processors quite well, and has done so for a long time now.

"dedicated enthusiasts were desperately trying to assemble a working laserdisc system, in order to archive all the data collected just 20 years earlier."

Send me their phone number. They can have my barely-used laserdisc player, if they agree to transcribe all my laserdiscs to Blu-Ray dual-layer DVD for me. ;-)

According to their reputation, ARM's chips are endowed with an almost magical ability to run on bright sunlight or the energy released by rubbing a cat. An ARM processor, two lemons, and some copper wire are all that's needed to build the latest PDA, it seems.

Like many myths, this one is rooted in reality, but that reality has changed and the myth has expanded

MikroBitti, Suomen Kuvalehti, Dr Dobb's Journal, Software Development, Embedded Systems Programming, C/C++ Users Journal, National Geographic and Time

Quite a few... Some interesting examples can be found among the various motherboard chipsets. Let's say that a manufacturer makes 2 identical chips, except one supports firewire and one doesn't. They sell the firewire-enabled chip for, say, $5 more than the non-firewire version.

Usually, the two chips are identical, or are at least created that way (Created two separate dies would cost a ton of money, and wouldn't be worth it for such a small change). Most companies will destroy a critical component on the chip after it's been made to disable Firewire on the cheaper chip, but some go the ultra-cheap route and sell the same chip at both price points. Basically, the firewire support in the firewire chip is an 'undocumented feature'.

The firewire example was something I completely made up, but 'disabling' the more expensive features isn't that uncommon. I read about this in this article (the relevant info is just after the Moore's Law sidebar and gives another example).

Making these cars more expensive doesn't make them more disposable. It makes their mechanics more valuable. Like in Stephenson's _Snow Crash_, we might just wake up as a nation of mechanics (and 1337 pizza delivery). Different subsystems in the cars interacting in diagnosable and tweakable configs means work for humans diagnosing and configuring. And when the logic, sensors and actuators are all field programmable, American cars might be the platform in which parallel processing, dataflow, evolved realtime optimizations.

Actually, this is somewhat misleading. The top players listed are Microsoft (Windows CE), Wind River, Symbian, Palm. QNX, OSE, and Green Hills. But Microsoft, Symbian, and Palm are really selling into handheld devices, not hard real-time control. (The phone and PDA markets are much bigger than real time control, though.) Wind River's VRTX is the dominant player by a big margin, especially in low-end embedded control. QNX is next, and is usable on a broad range of platforms. Wind River is more of a specialist maker catering to the military Ada market.

Following these seven come LinuxWorks and MonteVista, who are moving up. These are the main Linux-based offerings.

Also confusing the issue is Windows XP Embedded, which is basically a Windows XP from which you can delete stuff you don't need. This sells more into point-of-sale applications than hard real time control.

Ahhh! Sorry about the broken links. Try these functional ones.

The first one again
and the follow up

Thomas

Ahhh! Sorry about the broken links. Try these functional ones.

The first one again
and the follow up

Thomas

It's called tertiary logic and is discussed as a solution here

...Add to that 250 million 32-bit chips the much greater number of 16-bit processors, estimated at over one billion per year. Then add another billion eight-bit processors, and another billion four-bitters

From here.

32/16/8/4 bit processors aren't going anywhere any time soon, just off the desktop.

Installing Linux on your iPod might result in a crippled showthing but broadband routers is another thing.

Cheap hardware - even if you get network card, a bootdisk and an old 486 in a dumpster it's going to be a pretty clumsy server...

Manufacturer independence - an independent firmware might protect us from sofware dowgrading and value-added upgrades to a more expensive router with the same hardware.

Useful purposes - two ethernet ports and a soldered on a serial port and some i/o would for example enable a heart-beat checking device with a small webserver able to take over from a crashed web-server and tell you whats wrong. Or you couldn't afford the juice to keep that P100 server you got for free running while you were on vacation and used the router device to controls startup and shutdown of your server together with a small relay for power...

ISO9000

Okay, a lot of pro-Linux studies have their own problems (frankly, I don't put much stock in "studies" any more, especially vendor-funded ones).

I've been drooling over embedded platforms for nearly a decade--jeeze, I hate the look of that word combination, but, moving right along...

The truth is that I'm a fan of all of them. Here, in no particular order, are some links.
Lynx is a link on the bottom left at this page.
An old standby, which really isn't that different from GNU HURD.
Sun's "telephone system"
This might very well be the most generic.
I even like this kind of thing, which displaces quite a bit of O/S purpose.

And why shouldn't I! Why shouldn't you? Well, the truth is that neither is a rhetorical question. That is my point. There are too many specific considerations, many of which are important, to declare dogmatically that any one operating system ought to be embedded--or even embedded "most often". This is not efficient executive decision-maker thinking. This kind of "debate" is about topics that permit/encourage the deadness of brains of said executives. (And we wonder why tech equity share prices stay in the gutter?)

I believe this is the link you're looking for, not open cores.

"Most computer crashes are caused by an INTERACTION of two pieces of code that did not know about each other and were never tested."

A majority of crashes are at the kernel level. How do you suppose one would go about "introducing" their code (drivers), and ensure compatibility. with an OS which is not open source?

"1) accept a restricted operating system that will never be able to compete with a commercial system like Windows."

Yep - unix, linux, OS X - they are all so "restricted" and shrouded in a veil of secrecy. Ha. Must be why they are not "commercial", right?

2) Never install a program that was not A) created by the same company/group that wrote your operating system, B) specifically designed for your particular computer, and C) designed to be used with and thoroughly tested against all the other software that is currently installed on your PC.

You highlighted this while reading your Getting Started with Windows XP booklet - didn't you?

"That is what companies do when they make non-pc computer equipment (cars have tiny computers) and is the reason why such things do not crash."

You are referring to what is called an embedded system - your reasoning/comparison is sorely invalid.

And here's the direct link

A DAC or a pot would be a tremendous waste. What you want (as several people have mentioned) is Pulse Width Modulation. You can adjust the brightness by adjusting the duty cycle. I'd recommend an PIC or some such.

There are various solutions to this problem. It sounds like the Linux kernel people are trying priority inheritance via the messaging system (local sockets). QNX has had that for over a decade. Because QNX does almost everything, including all I/O, by message passing, it has to do this right. In the UNIX world, message-passing was added quite late, in BSD, and X is one of the few interactive programs that uses socket communication on the local machine. Sockets are used mostly to talk across the network. So support for time-critical local sockets isn't very good. UNIX pipes were the original UNIX interprocess communication mechanism, and they were intended as batch-like devices. Sockets look, and work, a lot like pipes. This legacy is the real cause of the problem.

Of course, the reason Linux users actually want this feature is so that they can play their pirated MP3s in the background while using X-windows.

The best answer is in an article I wrote, available here: More than one way to make a difference

You can also find more info about my Peace Corps experience here: Two Years, Two Months

The requirements you listed are spot-on. Note that if you don't have knowledge of Spanish or French, having a science or engineering degree can do just as much to help get you in to the Peace Corps. (Most applicants are liberal arts majors without any technical skills that the Peace Corps needs.)

I could see 3 or 4 months, but 2 years of my life to be a volunteer?

Two years is nothing -- a small fraction of your normal life span -- especially when you consider the impact those two years could have on your life. Think about it: What would you do with those two years in the U.S.? Work a nine-to-five job so you can buy that new computer and a big screen TV? I'd prefer to spend the time traveling the world, making friends, learning a new language, and discovering places I've only seen in National Geographic. But that's just me. If you can only commit three months, try the GeekCorps.

I pointed out that the embedded systems journal uses the motto "Thinking inside the box".

Nine people looked at me blankly. One doubled up laughing. Spot the geek!

It's awfully fun reading desktop programmers commenting on an article in a project management magazine.

Here's a few facts about your new-model car. The BMW is extreme with 70 electronic modules but the typical 2003 vehicle has 20 or 30 microprocessor-controlled modules, and the number is rising every year. These range from a door-switch module with 8K of code, through an engine controller with 256K/32K of ROM/RAM, to a navigation system at 8M/8M. Very few of these modules have a manufacturing cost above $100.

The OS in automotive controllers varies from a simple event loop at the low end through OSEK-compliant kernels in the midrange to QNX and its friends in the most complicated systems. If there's Linux in a controller, it will be as well-hidden as the Linux in Tivo. Engine and transmission controllers are designed for hard real-time operation and emphatically do not use anything remotely resembling a desktop or palmtop OS.

Software development starts with the premise that once it's built, you can't change the it, ever. This has enormous consequences for the way automotive code gets made. Most companies spec the hell out of these products, use a strict waterfall development process, are afraid to venture beyond the C language, and test endlessly. They are scared of agile methodologies and even of RUP. Productivity is pretty low, but on the other hand, the products are reliable.

Now, both the article and /. responses are full of misconceptions. There's not really much question about whether an OS vendor shares its source code. The real concern is reliability. There's not much question about who develops embedded software. Detroit is lousy with contractors. One billboard I see on my commute shows a toy car with the caption "about the only vehicle that doesn't run on our software. -- EDS" The GM guy's comment about 10 year old software has the obvious answer: his teenager's 1993 Chevy.

Win CE gets no respect from embedded software developers for several reasons. Chief among them are poor responsiveness, poor stability and code bloat. Typical comment, from an SAE conference presenter: "If you put an embedded system into a car, you still have a car. If you put a PC into a car, you have a PC with wheels."

Rather than rant any further, let me suggest reading any of the books on Jean Labrosse's site, EE Times and Embedded Systems Programming. And have fun! Embedded is where you can see software affect the real world.

There's an article in the latest issue of Embedded Systems Programming about using visualization tools for debugging. Well worth reading.

-Mark

...nerds and stuff that matters? It seems like a "-1 Offtopic" story. At least the submitter could have found this article which is basically the same story but from a software engineer's perspective.

There is a way to protect it from radiation though

Actualy, all solid state memory experiences errors due to cosmic ray particles, against which you CAN'T shield- eventually, some of these high-energy suckers will get through- and the problem gets worse the higher you go.
The chance for a given memory to fail due to this reason is called MTBF- Mean Time between Failures (actually, there's a broader definition, but I'm using the one related specifically to memory).
In addition, the more memory you have, the more errors you will have for the same MTBF- for example, if the MTBF is 1000 years for a single MB of your ultra-shielded memory. For 1000 MB, that means almost certain failure once a year! and you are talking about MUCH larger memory sizes!!
To conclude- in space, no one can hear you scream... ;-)
To Probe further:
Cosmic Rays
An article called "Can Hardware Be Trusted"

Despite everything I said above, there has been research on fault-tolerance in space, which might help you. You can look at the homepage of the Stanford REE project for more details
You might also be interested in these slides (PDF document) of a research project called Fault-Tolerant Computing for Radiation Environments.

Hope this helps :-)
Astromage

Don't buy into the megahertz myth. Just because the clock speed is greater means nothing. I'd still bank on the pentium.

Until recently, ARM chips designed for handhelds didn't do harware floating point math!

The Pathfinder mission was widely regarded as a huge success. Several days into the mission the system began restarting intermittently. The bug was located and corrected, and is a great lesson in real-time operating systems, priority-based preemptive scheduling, and (the fix) priority inversion.
There's lots of information on the web, and it makes a good read, even if you're not into operating systems.
For example
What really happened on Mars
Introduction to Priority Inversion"

In the March issue of Embedded Systems Programming there was a good opinion piece about how hardware engineers are becoming more and more like programmers these days. This is clearly oriented toward digital/logic hardware folks implementing designs in FPGAs and PLDs as opposed to high frequency analog engineers.

Bottom line: the line between "software" engineers and "hardware" engineers is becoming more blurred.

Andy

My company recently went down the path of evaluating several embedded linux suppliers, including Hard Hat Linux, LynuxWorks, RTLinux, and others. This evaluation was for an embedded communications platform.

There are many "real-world" issues that will arise when considering Linux instead of some of the more established embedded OS players (WindRiver/pSOS, Green Hills, Keil, QNX, et al -- see Embedded Systems Programming magazine for a pdf summary of embedded OS providers). These real-world issues, which will vary in importance among organizations for various reasons, include:

• Existing non-linux OS usage (e.g., WindRiver)
• Staff familiarity with Unix-like programming (most embedded developers know traditional RTOS-like architectures, not unix IPC methods or socket programming)
• Ease/difficulty with which already-written application software can migrate to a new OS
• OS support for preferred hardware devices (processor, communications peripherals, flash, etc. -- writing drivers from scratch isn't desirable)
• Internal corporate or organizational resistance to change (don't underestimate this one, folks!)
• Product life cycle phase
• Existing customer experience(s) with any previous OS-related behavior that may change under linux (customers like seeing behaviors they've seen before, not something new)
• Hard real-time versus soft real-time requirement(s)
• Communications stack and protocol requirements

In short, development in the embedded world tends to have many more complications associated with it. That's not necessarily bad -- in fact it often makes it more technically challenging and thus professionally satisfying -- it's just something that ought to be recognized, acknowledged, and taken into account when OS decisions are being made.

Andy

I know you weren't dogging C/C++, but I would like to take this opportunity to point out that for embedded development on a microcontroller, or development on any non-PC platform C is a God send. Programming for PCs is only a small fraction of the whole pie.. by small I mean out of "100 million or so PCs shipped each year; (there are) 6 billion processors that go into embedded systems " - Jack Ganssle Just check your Palm, cellphone, microwave, car, sound card, video card, stereo, fridge, ac unit, gas pump, coke machine, etc.. if you don't believe me ;)

The embedded market is enormous and C/C++ aren't going away anytime soon.

JOhn

For those too busy fawning over OOP here is some help:

http://www.embedded.com/1999/9908/9908feat1.htm

And if you're a bit too enamored with the C++ new operator try this:

http://www.scs.cs.nyu.edu/~dm/c++-new.html

And to see how STL guy A. Stepanov feels about OOP proponents see this:

http://www.stlport.org/resources/StepanovUSA.html

Although I have met quite a few talented (and effective) practicioners of OOP, much more often I run into hyper-political, resume-stacking, rabid and incompetent advocates of OOP. Mostly, they never finish what they start.

Who cares what Grady Booch and his two quack partners say anyway? I mean besides the rabid advocates...

Check out Circuit Cellar Ink , and Embedded Systems Programming. Both of these are pretty decent techie print rags. Good stuff, by and for hackers.

for embedded system there's zillions of OS, like QNX/NTO and more at http://www.embedded.com
--
BeRoute

The two primary resources I'd recommend looking into are:

- Embedded Computing
- ARRL
- RAC

...those are just some starting points. Embedded computing applications have the hardware designed for rugged environments, and amateur radio is a handy technical resource for do-it-yourself electronics. Remote relay stations are the norm, not to mention other extremes.

Search engines are your friends, particularly Google.

de VE3SLG

Note - I don't work for these mags, nor am I being paid by them, etc. I am promoting them merely because I think they're awesome.

Circuit Cellar Ink is an excellent magazine focusing on hardware and software interaction. Articles on embedded computers and software/firmware implementation, with real life examples of what techs in the business are doing. Current issue deals with making a MIDI sustain pedal, details of dual-slope analog-digital converters, Infrared Device technology and how to use it in your own projects, and other informational articles such as description of the current status of HDTV. One really awesome article that ran 1 or 2 months ago dealt with an engineer homebrewing his own microprocessor based on the Z-80 instruction set, but with little goodies thrown in. Way cool. Someone in an above thread mentioned they liked the ads in some good computer magazines. Same with this magazine, all sorts of embedded-related ads. Oh yeah, this mag is big on the PIC and Basic Stamp. If you don't know what these are, take a look!

Another good one is embedded systems programming . I haven't had the time to read the current issues in-depth, but I keep meaning to do so. Going through my father's collection back a few years, there are some majorly good articles here. This mag devotes itself, obviously, to embedded systems programming. Current issue deals with communication issues, real-time stuff, embedded web servers, etc. Another good thing is their tech columns, which deal with real-life examples of coding. They've had a series aimed at moving C coders (like me) to C++ through specific examples. Also mathematical applications, such as a multi-part indepth review of Z-transforms and Fourier Transforms, and DSP programming, and how to implement these in your systems. Way cool stuff, too, IMHO.

Just for browsing the net, an amazing source of info is from Don Lancaster's Lair . Rightly named the guru, this guy is a tech genuius (sp), and does all sorts of great stuff like working with PIC's inside and out, programming in raw Postscript to make his printer act as a peripheral computer, and other stuff. Go check out his page. Now! Engage.

"In a world without walls, who needs Windows" - Someone from LinuxToday