Slashdot Mirror

I wish it was mostly C++. It may be C++ in the higher power MPU world...

You put your finger on it, it is strongly dependent on how powerful the embedded platform is. This may alarm you

In that survey, C++ and C are in a dead heat. Obviously, C++ will be ahead of C next year and Python will probably be even further ahead. Shudder.

For my part, I was coding embedded for a 16KB part in C++ back in 1999, I think the compiler was Wind River. The development environment was the lap of luxury, that is, source level debugging using one of those JTAG wigglers. Operating system just coded inline, maybe about 300 lines. I had no idea this was unusual, so thanks much to whoever had the foresight to set that environment up.

The embedded world isn't like that any more. Now people think that a NUC is embedded. Now you typically run Linux, I think Linux is even running in my thermostat now. It certainly is running in all my TVs. Yes, there are still tiny embedded processors out there, particularly in toys, but it's a rapidly shrinking world, and there isn't a lot of new blood flowing into it. That may explain why you see a lot of attachment to old ways of doing things, like straight up C. And you see a lot of EEs in there, I think you know pretty much how open to change they tend to be.

using the backslash for directory paths when every other OS used normal slashes

You overlooked one other OS that matters here: CP/M.

When MS-DOS was first developed, it was not the first DOS on the market; the majority of the business market was using Z-80 processor computers running CP/M. (Home users were on Apple II computers, mostly. Some business users used an Apple II with a CP/M card!) Anyway, MS-DOS looked and worked almost exactly like CP/M. MS-DOS programs were not that different from CP/M, I think deliberately to make it easier to port. The similarities were enough that the company that made CP/M threatened legal action over them. (Bob Zeidman checked the source code and he says no stolen code was present.)

Anyway, the important thing is: CP/M used forward slash as the punctuation for command-line program arguments. Thus, so did MS-DOS.

And nobody was really thinking too much about directory separators because CP/M, and MS-DOS 1.x, did not have directories. They used floppy disks, and those disks just had one directory. Just a flat list of files.

When MS-DOS 2.0 came out, someone was thinking of the slash for directories, because there was an actual command that you could put into your config.sys file that let you switch the character used for command-line switches. This was SWITCHAR and if you set it to - you also set the directory separator to forward slash. It was undocumented! It was never officially supported! And I think MS-DOS 3.0 dropped it and it never returned. (But in Windows, even today, you can just use forward slash as a directory delimiter and it works.)

I think that Microsoft had the opportunity to push on this. Just say "old MS-DOS apps that are using the old APIs can continue to use forward slash for command-line switches, but any program that works with directories should use the dash. It's The New Standard." I think they could have pulled it off, with some grumbling but nothing serious. But either someone at Microsoft was timid, or else they had an argument about this with IBM and lost, I don't know.

But way back in the dawn of time, compatibility with CP/M was the reason why forward slash was reserved as the command-line switch marker.

P.S. I think the registry was a good idea. Having a little database to store options, and have some kind of daemon that owns it, avoids race conditions and is just good sense. However, using an opaque and fragile binary database format was insanity. They could have used a simple text-based format (like .ini files... or, heck, S-expressions!) and saved the world a lot of pain. Or, at least made their binary database less fragile and documented it completely so that third parties could write registry checker tools that could fix corrupted registries or whatever.

Ideally they should have used JSON for the registry, but I'm pretty sure the registry pre-dates Javascript, let alone JSON as an interchange format.

Do you mean the "Figure-8" free return trajectory and free return trajectories invented by the noted physicist & programmer and Dr. Jack Crenshaw, who was actually using a computer?

C++ exceptions are commonly trotted out as the replacement for C's goto cleanup statement, and for desktop userspace, I might agree. Page 2 of your second link mentioned that exception support has a cost but didn't quantify it. Instead, it said "buy our e-book for $24.95". So all I have to go on is a personal anecdote, namely that the last time I tried adding exceptions to a C++ project that hadn't previously used them, it added 64K of code to the executable.

Many of the issues that people have with using C++ on embedded systems are bunk. Here [1] is a recent discussion about C++ on embedded systems. Specifically to your point about C++ being too bloated [2] argues that the language itself isn't really.
[1] http://app.content.ubmtechelec...
[2] http://www.embedded.com/design...

I wonder if they are some of the same people as these (reading about theiur team it does not sound unlikely): http://www.embedded.com/electronics-news/4397737/X86-emulation-coming-to-ARM-processors

Well, that link speaks of people from Elbrus, and this page from Eltechs' web site says "The MCST Binary Translation Team has 200+ man-year experience in developing binary translators. They implemented a number of x86 to e2k (a Russian CPU)". The "e2k" is probably the Elbrus 2000, for which they implemented an x86-to-native binary translator. The MCST (Moscow Center of SPARC Technologies) referred to by the Elbrus 2000 page is probably the same MCST referred to by the Eltechs page.

So, yes, probably the same people.

More relevant links to asynchronous/clockless computing:
http://www.embedded.com/design...
http://www.technologyreview.co...
http://www.scientificamerican....
http://www.nytimes.com/2001/03...

My guess would be this is for I/O.

These customers have lots of I/O that, if you can do high performance optimized operations on a general CPU how useful would that be ?

Think of something like liberouter or NetFFPGA embedded on the CPU die.

Or maybe the FPGA is used to implement calculations like crypto and hashes like CRC32C. Instead of building them into the silicon, why not make it possible to do research by loading new versions of it.

Maybe you just need to look around on the Internet what other companies are doing with these, it might also give you hints:
http://www.embedded.com/electr...

No need for an atomic clock on every computer. NTP can only give you accuracy to within a few milliseconds, but PTP can give you better than 100us, albeit with some specialized networking equipment. A GPS receiver can act as the master reference for a facility, and give you absolute time to within tens of nanoseconds.

In places where Intel doesn't have a product or doesn't have an interest. That is like saying Linux is #1 in routers, don't mean much sense old Bill don't sell routers. We are talking about a $100 tablet that will run Firefox and do Youtube...you don't think Chipzilla is gonna notice that?

The simple fact is Intel didn't shell out 1.25 billion to AMD because it is a company of straight dealing nice guys, it paid out because it knew that one look at all the kickbacks they had been giving the OEMs (one even saying they were addicted to Intel payoff like cocaine) so it isn't like they have a problem shelling out serious bucks to crush a potential threat.

And lets be honest here folks...most folks do not know, nor do they give a wet fart about what an OS is, they want the web and they want Youtube. A $100 Tegra ARM will give them that and still be able to take notes, check their webmail, go to FB, all the things my GF and the other 99.999% of the population want to do when they are out and about. Hell at a price like that I'd buy the damn things as stocking stuffers for the family. And more importantly Intel isn't stupid, they know this. Most folks even after all those "Intel inside" commercials honestly can't tell you what the hell their PC is running.

So I'd say we wait and see, because we have been promised $100 netbooks running ARM before, remember? Where are they? Certainly not in my local Walmart. Hell if I was Intel I'd crush these things like a bug, it just makes good business sense, even if it isn't ethical.

More likely than not the data from the sensor runs on a CAN bus.

The CAN bus is highly fault tolerant and resists noise excessively well compared to many other buses. The wire and transmission is rarely the problem. Bad programming usually is.

To read more about the CAN bus this is a nice article: http://www.embedded.com/columns/murphyslaw/13000304?_requestid=96168

And finally, the issue with the Toyota cars in the recent recall seems to be mechanical, not electronic.

Agreed... well... mostly. If I personally were building an HDCP stripper and selling it, I would do exactly what Hauppauge did. Anything else would get my license revoked and potentially open me up to civil and/or criminal penalties. If, however, I were the sort of person who would build and sell illegal cracking tools, I would just include a ROM with thousands of stolen keys. For that matter, if I understand some of the early papers on the subject correctly, it might even be possible to include the entire set of all possible valid keys....

This may be short-lived, though. Intel is replacing HDCP's worthless key exchange with HDCP 2.0. Translation: when content providers decide to mandate 2.0 support, all your existing TVs, Blu-Ray players, etc. will have to be replaced. Of course, given how many hundreds of millions of people that would affect, if they do mandate it, I expect riots, looting, and the biggest shift from purchased content to pirated content that the world has ever seen. We'll see whether greed or common sense wins out in the Blu-Ray consortium....

http://embedded.com/columns/technicalinsights/218401508?pgno=1

"Calculating trajectories for Apollo program"
"Jack Crenshaw describes what he and team members did to research trajectories for the Apollo missions."

larger cost savings can be had by just selecting equipment that uses less electricity and produce less heat in the first place

So true.

http://www.embedded.com/215901024?cid=NL_embedded

energy efficiency improvements over the last 40 years in computers totaled "2,857,000 percent" thanks to semiconductor-enabled scaling.

Most times when people think about using flowcharts, they really should create state transition diagrams http://en.wikipedia.org/wiki/State_diagram/ to discuss, describe, and document behavior. Statecharts are an improvement on earlier state transition diagrams and are included in the latest UML specification.

Some Statechart references:

1. Samek, Miro; Montgomery, Paul: State-Oriented Programming. Embedded.com. 2000-08. http://www.embedded.com/2000/0008/0008feat1.htm/
2. Samek, Miro: Practical Statecharts in C/C++: Quantum Programming for Embedded Systems. CMP Books. 2002-07. http://www.amazon.com/exec/obidos/tg/detail/-/1578201101/002-2659023-9156009/

I have read all the comments on this UML thread with interest. Most of my experience is in embedded systems and I have been trying to learn all I can about the various high level software modeling environments, both model driven (MDD) ones, such as UML and model based (MBD) ones such as Mathworkâ(TM)s Matlab/Simulink combo and National Instrumentâ(TM)s Labview. Why? For a number of reasons: (1) the day of the individual code developer is coming to an end with more and more development done by large teams often separated geographically around the world (2) systems, especially in the embedded world, are be coming more complex and require millions of lines of code running on multicore CPUs (3) as I learned from lectures by Richard Feynman at Caltech, the key to unraveling a systemâ(TM)s complexity is drawing pictures that clearly delineate patterns and relationships and (4) even if you get the code right, it seems to me the entire project could come to a halt if the system design and the relationships between entities are flawed.
An article on online at Embedded.com (MDD and IDEs: making the twain meet in embedded systems design) describes a bidirectional framework that allows developers to move back and forth between two environments, an embedded IDE for code development and an MDD such as UML at the system definition level. I was particularly struck by the following statement in the conclusion of the article:
>>>>>>>>>>>>>>>>>>>>>>>>>
The MDD tools within this bidirectional environment can then generate production quality C, C++, Java, and Ada source code automatically from the UML models, which can be fed into the IDE's C/C++, Java, and Ada compilers, and object code then transferred to the target. The developer can then take programs running on the target, set breakpoints on the graphics in the modeling environment, and have the program stop at the same point in the IDE's source-level debugger. Working from the other direction, a developer can load and debug the code in the IDE environment and set break points as well.
>>>>>>>>>>>>>>>>>>>>>>>>
Maybe the author is overstating the case but the move toward such merged IDE/MDD environments seems to be gaining ground: the one described in this article was developed for use with the open source Eclipse IDE. But I have heard that Wind River is moving in the same direction with the the Tornado IDE it has for both its Linux OSes as well as its Vxworks RTOSes. And Green Hills Software at one point was working with one of the UML providers to create a bidirectional framework between the UML system level environment and its proprietary MULTI IDE for developers using its Integrity, Velocity and micro-Velocity RTOSes.

I have found such tools to be invaluable. I had code like this:
class Lock {/*...*/};
void Foo( Mutex& m )
{
Lock(m);
// ...
}

This is valid syntax, but I intended to use that lock instance for the duration of the function, so the first line should have read "Lock lock(m);". Multithreading is tricky enough, and I looked at the real code for a long while, reading right over this bug. PC-Lint found it for me right away (thankfully, it was already tuned, and I should have been using it before running my code).

But even though PC-Lint is pretty good, it ain't perfect. I have found that it has some trouble with advanced C++ templates (e.g., policy-based design). I have submitted bug reports for many of these problems, and they do seem responsive in working them in to the patches.

Finally, here's an article from 2006 discussing the available static analysis available tools for C, C++, and Java and describing how and why to integrate it into your development process.

Ars Technica has a good article on this debate

RISC vs. CISC - the Post-RISC Era, and Bibliography

In defence of RISC

The majority of software written for any chip is compiled by a relatively small number of compilers, and those compilers tend to use pretty much the same subset of instructions. The UNIX portable C compiler for example used less than 30% of the Motorola 68000 instruction set.

I cannot believe that this troll was moderated insightful.

I would love to see you repeating the above statements in front of the _software_engineering_ teams in charge of A380. You can replace A380 with
any advanced means of transportation or any advanced defense system.

Creating and running pieces of code is easy and perhaps this is the reason people think that it is not a rigorous engineering principle. However,
creating code for critical applications is something very very different comparing to e.g. writing a Facebook application. The first has to abide by numerous standards and constrains and ensure strict reliability and performance guarantees. Hell, even a Facebook application may be a critical task and have to conform to high standards if millions of dollars of revenue depend on it.

Since you are also a civil engineer, no doubt you heavily rely on CAD applications to create structurally robust designs and you are not manually applying statics for every brick and column in your design. So ,in the end you depend on the rigorousness of the CAD software engineers to ensure the rigorousness of your structural designs.

Software is one of the most complicated human artifacts and the fact that humans can successfully create such artifacts (spare me the Windows jokes pls) is the proof that we apply engineering principles.

Someone else has a nice argument on the subject too
http://www.embedded.com/columns/embeddedpulse/159904927?_requestid=904565

http://www.embedded.com/story/OEG20030610S0041

maybe it is not intended to run windows

Could these computers have MicroSoft's Windows as the OS?

This opening of the front side bus also means that you'll be able to plug FPGAs into it, which could be very cool. One way to solve the gigahertz slowdown is to specialize hardware: think co-processor that can be reconfigured in seconds to fit the particular task at hand, like video encoding.

Not quite. Many embedded devices still use Windows. It generally isn't possible to know what operating system a device is running on, unless you specifically take the time to research it, or you happen to see it crash.

I don't have FDA experience but for industrial machinery, chemical plant safety systems, and the like, the standard followed is IEC 61508. Unlike ISO 9000, IEC61508 has various hard requirements for failure probabilities and measuring said probabilities. It also has specs like the highest possible reliability than can be assumed in engineering calculations for a device and what has to be done to mitigate failures. It occupies 7 binders on my shelf and provides the basis for how to develop systems that have a verifiably low chance of killing people. A fascinating intro to IEC 61508 is presened in the online edition of Embedded Systems Programming http://www.embedded.com//showArticle.jhtml?article ID=19201765

Check out "Embedded Systems Design" at http://www.embedded.com/ - I think you may find that what you mean by microcontroller design is covered by this. It's not that the field has gone away, it's just been renamed.

Corba is too complex and slow. redFox from redPlain is lighter faster better than Corba implementations. Check it out at http://www.redplain.com/ or read about it in Embedded magazine Jan 2006 http://www.embedded.com/

In my opinion, something such as a fly by wire system that people's lives depend on need to be proved to be correct. It can be done, and can even be somewhat automated. There's at least one high-integrity Ada development system with an automated proof checker. One such system is SPARKAda. There's also the Motor Industry Software Reliability Association's set of C programming guidelines, plus C compilers that can auto-check for compliance with many of those rules.

I think we are going to see the clock go away, replaced with "Data Ready" lines, which will also help heavily in determining the bottlenecks in a given system (Hint: it's the system that is taking the longest to put up the "Data Ready" flag).

In the embedded world, you'll see VxWorks, TI's BIOS, QNX, Enea's OSE, etc. Just as likely, embedded developers will roll their own operating system if they use one at all. In many of these applications, 1 MB of memory is overkill, and much of the code is in C.

From an embedded programmer's perspective, Linux can be bloated and slow overkill.

But they are mostly behind schedule

"A new survey released at the Embedded Systems conference reveals that more than half of all current embedded design projects are running behind schedule."

"The survey -- dubbed the "2006 State of Embedded Market Survey" -- indicated that some 55 percent of current embedded design projects are late or have been cancelled."

How accurate can any survey be when over half the projects are late and/or are being canceled? Bad mojo in the field of EL and not a good time to take a survey on Embedded Linux me thinks. As was stated in the blurb, EL is everywhere....

The numbers aren't that far off from 2005, but what about the years before that? Project running behind schedule are a bit less from 2005, but cancelations are also a bit up. Dunno, maybe I'm just looking for something to weaken the argument that EL is losing ground. I've always seen it as the grass-roots to keep pushing what I see as the future of operating systems, Linux....

I would start with embedded.com at http://www.embedded.com/showArticle.jhtml?articleI D=163700590 Some BSD variants and uCos weren't included, but it's still a great survey of the embedded OS space.

I'd suggest reading Software Safety by the Numbers at http://www.embedded.com/showArticle.jhtml?articleI D=19201765 on IEC 61508 for safety critical industrial software or getting a copy of RTCA DO-178B from http://www.rtca.org/ for avionics.

Here's one that goes back further than most of us here; The Friden March.
http://www.embedded.com/98/9802fe2.htm

Just scroll down to the sectio titled "The Friden Algorithm", now that's Ooold school, when your desktop had gears!

Embedded.com has this interesting article on Stanley: http://www.embedded.com/showArticle.jhtml?articleI D=174904699

They had another article on 11/18/05, that suggested that the biggest problem faced by the Stanley team was not designing the software but keeping the bugs out of the software: http://www.embedded.com/showArticle.jhtml?articleI D=174400407

It seems that engineers face an uphill challenge in getting this technology into our cars. The problem is more one of reliability and safety than artificial intelligence.

Embedded.com has this interesting article on Stanley: http://www.embedded.com/showArticle.jhtml?articleI D=174904699

They had another article on 11/18/05, that suggested that the biggest problem faced by the Stanley team was not designing the software but keeping the bugs out of the software: http://www.embedded.com/showArticle.jhtml?articleI D=174400407

It seems that engineers face an uphill challenge in getting this technology into our cars. The problem is more one of reliability and safety than artificial intelligence.

For just programming in general, and embedded systems specifically, go for Embedded Systems Programming. Even if you don't plan on working on embedded systems, the articles target a lot of topics that I wish 'regular' programmers studied.

It's essentially a 'free' trade magazine, and all the articles are online (check out Jack Ganssle's column - Here's an example on worst case analysis.)

Beyond that, Dr Dobbs is the only other 'general' programming mag I'd recomend. Beyond that, pick up some that specifically address your industry, languages, APIs, and interfaces. There are a ton of C, Java, C++, web, exnterprise, database, etc magazines that will be interesting and useful to you.

Please note that we are moving ever more toward an embedded future.

-Adam

For just programming in general, and embedded systems specifically, go for Embedded Systems Programming. Even if you don't plan on working on embedded systems, the articles target a lot of topics that I wish 'regular' programmers studied.

It's essentially a 'free' trade magazine, and all the articles are online (check out Jack Ganssle's column - Here's an example on worst case analysis.)

Beyond that, Dr Dobbs is the only other 'general' programming mag I'd recomend. Beyond that, pick up some that specifically address your industry, languages, APIs, and interfaces. There are a ton of C, Java, C++, web, exnterprise, database, etc magazines that will be interesting and useful to you.

Please note that we are moving ever more toward an embedded future.

-Adam

Embedded Systems Design is a magazine and a web site that covers that field. Realizing that many embedded s/w engineers are really dual-hatted EEs, they have had some "basics" articles over the last few years.

1 par (element=0; element<SIZE; element++) {
2 seq {
3 par (element2=0; element2<SIZE-1; element2++) {
4 ifselect(element>element2) {
5 if(uList[element] > uList[element2])
6 comp[element][element2] = 1;
7 } else ifselect (element<=element2) {
8 if(uList[element] >= uList[element2+1])
9 comp[element][element2] = 1;
10 }
11 }
13 position[element] = SUM_OF_DIGITS(comp[element]);
14 sList[position[element]]=uList[element];
15 }
16 }

Cooling and power requirements aren't the only issue, since at those types of frequencies you are likely to be interfering with radio frequencies, unless you have really good shielding.

The real future is asynchronous CPUs, that are actually clockless. They generate much less heat and consume much less power. The only reason that they aren't replacing the current batch of chips fast, is that all chip design and testing processes are built around clocked CPUs.

A few articles on the subject:
  - Will Self-timed Asynchronous Logic Rescue CPU Design?
  - Computer Chips Without Clocks

I prefer 'functional' languages over the 'dysfunctional' ones.

What I _want_ is a functional language that I can use to generate real-time code for an embedded dsp. What functional languages are options for me?

There's an interesting article that talks about PPL, which might be interesting, but since I'm entirely ignorant about embedded systems in general and embedded DSPs in particular, I don't know if this helps.

Two other languages that might interest you are:

• Stratego, and
• Q. Q is pretty nice. It is a losely typed, interpreted Haskell with strong support for A/V control (including DSPs). The author is a professor in the Music Information department of the University of Mainz in Germany, so the audio libraries are correspondingly rich. If you like Haskell but hate Haskell's IO, Q is for you. The only downside is that it is interpreted.

--- SER

Java needs C? http://www.embedded.com/showArticle.jhtml?articleI D=10700608
news to those guys a I guess...

oh wait you're wrong, It is a Full Fledged object Oriented langauge. They have OSes, written entirely in java, and since java is the native bytecode the code runs a lot better on an OS written in java. Like in the cellphone in TFA linked above.

Here's the JAVA FAQ also, it might help you learn what Java is, and isn't.
http://www.ibiblio.org/javafaq/javafaq.html

Rewired, amputee lifts arm with mind

I just read this article recently in Embedded Systems Programming magazine. http://www.embedded.com//showArticle.jhtml?article ID=55301875 After a detailed explanation of the hardware protection features built into the x86 (since the 80386), the author makes the following statement towards the end of the article: "Too bad Microsoft doesn't use this feature. Windows has been plagued by buffer-overflow bugs that could easily be prevented by the processor's segmentation features. Alas, even though these features have been built into every x86 chip for more than 15 years, Microsoft has never used them. Instead, Windows creates a "flat" memory system with no segmentation, no tasking, no bounds checking, and no privilege protection, and then struggles to duplicate all those features in software. The result has been famously ineffective."

read this for an old hands view. Basically you are sacrificing most of what is known about good design practice for a marginal benefit.

Cisco's Big F--king Router has an IBM ASIC with 188 RISC cores.

Jack Ganssle just had this interesting piece over at Embedded.com:
http://www.embedded.com/showArticle.jhtml?articleI D=57702644/
As a mid-40's umemployed embedded software developer, I too am at the "fork in the road". Having worked at many companies for the past 23+ years, I've gained alot of different experiences and talents. Yet, they pale in how the industry as a whole has litterally exploded. I quit my last job becaue of: a) commute times; and b) frustration working for a "niche" company that was slowly sinking. So, after some deep soul searching, I decided to "take the fork" and I signed up for Massage Therapy classes. Quite a turn for a "dyed in the wool, 3rd Generation engineer", but companies today are "obsessed" with quarterly earnings and Wall Street Reactions. What's missing is "true" innovation and "vision". It still exists,but because everyone is trying to create "the next big thing", and stumbling aaround in the dark, they loose out on opportunites. Having a good mix of experienced (i.e. older) as well as younger workers is what makes a company strong. We've given this up for the sake of the almighty dollar. Whatever happened for "an honest day's work for an honest day's salary?".

Also, this Wired article mentions "Although Metro told activists the chips worked only while customers were inside the store, activists discovered that a kiosk used to deactivate the chips didn't completely disable the tags."

Katherine Albrecht of CASPIAN fame has also mentioned that three out of four articles she microwaved in order to destroy their tag caused the articles to catch fire.

http://www.embedded.com/showArticle.jhtml;jsession id=Q4OT1EN155QXSQSNDBGCKHSCJUMEKJVN?articleID=5120 0678

Here is a slightly better written article on the same topic...