Learning embedded systems

I would expect that attitude to be less prevalent with average Ada programmers than with average C programmers. The reason being that the Ada programmer probably has an idea why he or she is using the language in the first place.

"Because the DoD contract says so."

Ed

From my sig you will have gathered that I use Forth for most of the systems I design and build. Many of them are very mission critical. Yet, Forth does not have the incumberance of type checking, is fairly free of syntax (except for that which you build in yourself) and will permit you to make the biggest mess imagineable. However, because of the development process I use, the care that I take in executing that development process and the level of review that is incorporated within the design process I can readily produce fully certifiable embedded systems. I have also produced high integrity systems with languages other than Forth, including assembler, so choice of language is very little to do with the resultant system safety. It means that I will probably consume less system resource with my implementations than if I had used tools that cossset you.

Naturally, when choosing a compiler you should always verify that it behaves as documented and examine the output code from samples that you know what you would expect from the resultant. That means that many will choose compiler products from companies that have a proven track record of known good compiler writing.

Some of the language selection process will revolve around the availability of programmers with appropriate domain experience or something close to it. Those who develop critical systems should be aware of suitable constructs in their chosen language (eg the MISRA-C guidelines) and have tuned their checking tools to issue warnings when the code uses such constructs. Also, as I have stated before, reviews are so important to the development process (and I include testing as though it is a review - with a review of its own results) that missing them should be avoided at all costs.

I am sure you can do so in Forth and assembly, and I can do so in C and assembly. But you and I are not writing that critical code for the braking system, or the medical machinery. Even if we were, we are not quite as infallible as we like to think (but close). At the same time a well designed system will perform most checks at compile time, and detect what run-time checks are useless, thus approach the resource usage of the unchecked system. Especially when the input is generated by such paragons as you and I are, who know what the system can and cannot catch, and act accordingly. We will even deliberately install "can't happen" code blocks, whose primary purpose is to catch hardware failures, since our logical processes are perfect by definition.

I would rather trust my code written in C than Foo Q. Bars code written in Ada. But I will be even more trusting of my code written in Pascal. In general, though, I distrust all computers and other drivers on the road.

... snip ...

Are you seriously suggesting that Misra-C can rival Ada in security? All it can do is mitigate some of the more common failings and misuse of C. I have never read it, since they seem to want real money for a copy.

Actually process is more important than language. See IEC61508

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

Since you have not read it I would suggest heresy is inadmissible. Beside, my friend said it was perfect.

What is wrong with paying for a copy. You buy other tools I assume.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

The implementation of the tools and the Sw Engineering process are more important than the language.

I knew someone who said the same until we discovered his Modula 2 compiler was written (badly) in x86 assembler and the library was full of holes. The Modula2 system was bug written and unreliable. Of no use for safety critical code.

The SW process and the standard of the tools is more important than the language.

That seems fair enough... I left my Horse in the car park :-)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

You have a lot of examples that require special additions to compilers. Pseudo variables for registers, init pragmas, etc. That's a lot of effort on the compiler developers part just because some programmers want to avoid using assembler and inlined assembler. Each variant of an instruction set would need a new variant of the compiler, and maybe each RTOS would need a compiler variant. That could result in very expensive compilers. Then you'd have to learn every compilers own idiosyncrasies since no one is going to standardize this stuff.

And I don't think it'll be all that soon before compilers can deal efficiently with some of these issues. The compiler writers aren't spending their time worried about optimizing accesses to memory mapped registers.

I wasn't thinking about performance. I was thinking about merely having the ability to do what some OS functions need to do. Sure, if the compiler were tied to a specific OS then you could just use the libraries that came with the compiler. But normally people need to add or modify this stuff; cache flushing routines, task switching, instruction or IO synchronization, etc.

Sure, the compiler vendor could supply macros or functions for much of this, but every project has slightly different requirements about how the service libraries should work.

Petro-chemical process plant, Nuclear Power Stations, Railway Signalling and Safety Monitoring Systems, Anaesthesia Ventillators, Banking Smart Cards and various robotics equipment performing very critical functions have been in my remit. I have spent over 30 years constructing such systems and have always used a decent engineering process approach to achieve the system safety goals. So, yes I have been involved in the critical code generation segment. Be sure though, that there has always been a means, in hardware, to mitigate any remaining failures within the software. I am not saying that the software has ever gone wrong though (my first software, 4k of hand crafted machine code, ran 25 years with no failures and no need for modification).

Even if we were, we

I perform most of my checks well before the code is compiled (design reviews, static code inspections etc). You would be amazed at how many of the silly errors can be found this way.

As I look around this machine I have a hard time finding anything in regular use that required actual money. Apart from the OS, which came with the hardware, the only things I can think of are the editor (Textpad), the shell (4dos), and the printer utility (fineprint). I am renowned for my tight grasp on the currency of the realm and the size of the moths that breed in my wallet.

Hold on to those tools -- they'll be valuable antiques any day now.

Ed

^^^^^^^^^

Please make up your mind about what you want to rant about, for safety critical applications like car brakes and other industries, especially for STANDALONE items, safety bodies and other accreditation and testing facilities have stipulated MISRA-C for SAFETY as PART of the safety design and testing. It is only one small part of the whole picture.

Security is only one part of the safety design.

Please stop moving your targets, to me you are getting boring.

Well how do you know whether that at least the automotive and some parts of the medical industry are wrong then.

You are starting to sound more like a troll.

The Borland Turbo-C had most of these features two decades ago and many other compilers these days have at least some of these features.

Is this really a problem, since each variant of an instruction set would require a new variant of the code generator anyway :-).

Not really. The only thing that the compiler must be able to do is to save/restore the _application_ context i.e. registers used by the programming language. Much of this would already be required to implement the interrupt pragma. The only part that might need to be written in assembler is the actual task switch, when the task pointer is switched, but even this could be doable in a high level language, provided that you can force the compiler to generate only implicit register references, as I suggested with the init code.

These are perfect candidates for in-line assembly.

IMHO, the proper way to use in-line assembly is to use it for a linear sequence of instruction (or perhaps for a single hardware specific loop), but to do the program flow control things (e.g. if, for, while etc.) in a high level language, thus, the program remains quite readable.

I have nothing against assembly programming as such, I have written quite a lot of assembly work in the 1970's, but the problem with most assembly programs is that they are hard to read and hence hard to maintain. Of course the same applies to FORTRAN IV and earlier, in which the only control structure was the DO loop and all the other flow controls had to be handled by GOTOs.

Writing assembly and such old style FORTRAN programs is not a problem, maintaining them is. Of course, this will give some job security :-), but sooner or later you would like to do something new, unless of course, you are just going to retire.

Paul

NOT so

What about the bus specs?

Fare enough.

However you have not given any reason why MISRA-C should be free. There were costs in producing it.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

... snip ...

There were costs in producing the specifications for Pascal and for Ada, not to mention the costs of implementing them. IMO both are superior to MISRA in catching errors, yet both are available free of charge. The result is that I (and I suspect others) have very little urge to pay for MISRA specifications. I also conjecture that I can write sounder C code while ignoring MISRA than can most while adhering to MISRA.

So? Who paid costs for Pascal and ADA. BTW I thought the US Gov. bankrolled Ada

Will you sump up the costs for doing MISRA-C so others can have it free?

OK... you won't pay for the tools of your trade.

Please prove that. IE prove that in a way that would be usable in a court of law. For example:-

MISRA-C has been approved by the SAE and JSAE and all the main auto manufacturers. I can run automatic test tools on C code to show it is MISRA-C complaint. The contract requires MISRA-C compliance. Sorted.

Your option is? BTW You option must be as cost effective as the MISRA-C option is.

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\ /\/\/ snipped-for-privacy@phaedsys.org

I just double-checked on the price for the MISRA-C document, by going to the web site at:

I discovered that some old versions (1994) appear to be offered in PDF at no cost (but a short sign-up is required.) The newest version (2004, in PDF) is offered at 10 Pounds Sterling (US$19, I think.) The paper version is US$76, though.

...

I had (in the past) had little interest in paying for MISRA-C. I've seen so many attempts made in setting C coding standards, some good and some not so good, and have read a great deal as well as having tried out various ideas of my own. In programming and thinking about programming for 30+ years, I've developed about as much understanding as I'm likely to absorb. I've also been using C nearly constantly since 1978 and seen much in the time since then regarding good C coding practices. I doubt that the document would add much, at this point, to what I've already read and tried out.

...

On another note, without reading MISRA-C yet, it seems to me that it is just a little too narrowly focused on coding guidelines for a particular language, C. There are a number of good documents regarding software development strategies for medical instrumentation purposes and they cover a broader range of concerns that are very important and they are quite often free over the web. Before spending money on MISRA-C, it may be a good idea to survey what is available on the web first and to read and assimilate the better parts. If something is then still lacking in your practice and you feel that MISRA-C may yet help, go ahead.

But really, I think it's only a small part of a larger picture. And whether or not US$76 is worth it will depend.

...

Well, I've downloaded the free stuff from there. I suppose I'll try and find some time to see what I make of it.

Jon

... snip ...

You did note that I said conjecture?

But I have no contract or other reason, apart from curiousity, to investigate MISRA. Whether or not some code is MISRA compliant means very little to me. If it uses C I expect it is either so emasculated as to be fairly pointless, or has the fundamental faults of C. The moment I can create and use an arbitrary pointer into the midst of some object reliability is out the window.

Of course I may be totally mistaken. Without actual knowledge of what the thing really is I cannot be sure, only opinionated. What I do know is that C (and assembly) are unsafe languages without any real hope of being made both 'safe' and recognizable. 'Safe' is a relative term anyhow, closely related to frozen flying pigs in hell. To me attempts to so enhance C are isomorphic to finding the largest prime or an exact rational solution to x*x == 2.