Using GCC for AVR in safetycritical applications

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi All!

We use gcc for AVR in safety critical applications and whatever application we make must meet the requirements of the IEC61508 standard. The standard is used to measure the quality of the finished product with regards to safety.

During the certification process the issue about the compiler used in the project will come up.

One need to show "Increased confidence from use". The aim here is to avoid any difficulties due to compiler failures which can arise during development, verification and maintenance of the application.

The compiler used must have demonstrated correct performance in many projects before being used in my project. compilers without operating experience or with any serious known faults are prohibited.

I have the fullest confidence in the compiler after using it for about two years without any problems whatsoever. My problem is that my boss asks questions about the reliability of the compiler.

Anyone out there willing to give me the names of commercial products using gcc for the AVR platform and experiences with the compiler.

Feel free to e-mail me offlist.

Thanks in advance!

Best Regards
Geir Tore Olsen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I found this really important. I think it'll be great to post all findings/references right here.

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yikes. There are pros using freeware as-is tools in safety critical apps. Be sure to hide your company's identity in your email.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi There!

Steve, you don't approve of using GNU software in safetycritical application? Could you pleace elaborate?

When comparing some of the comercial toolchains "out there" with what gcc for AVR can deliver, I have no problems recomending using it as a production tool, even for safety critical applications.

GCC is used as-is in quite a few systems. One example is VxWorks from Windriver. another is National Semiconductor, it uses for their DSPs.

Bear in mind that we do NOT use library functions that we havent tested extensivly trough use in other applications. Also one does NOT use the latest and greatest from CVS when making profesional software.

Best Regards
Geir Tore Olsen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Geir,

During the latest 3 month of avr-gcc developing I have found bugs
in the compiler, bugs in the library bugs in the CPU itself.
I have even found some in my own code ;-).

Not to say that AVR & gcc are bad products, on the contrary.
I still find them superior compared to most competitors.

Bugs are, however, a part of life. Some you'll find and eliminate, some
will still be in your system. That's why we still use watchdogs,
error logs and all that extra fluff to aid analyzing "what did happen".

I have seen really smart guys spending literally years to mathematically
prove a 2 liner of code is correct. Sometimes they succeed.

Until proper tools are developed, if they ever will, this boils down to milage.
gcc is probably the compiler with most milage of them all.
Also source is open, which makes it possible for more eyes to have a
really close look.

You will probably not find garantees from any compiler vendor out there so
do continue using gcc, we do.

After all, I'd rather spend some time i a life supporting device programmed
by use of gcc than MS tools & OS.

Feel free to look at our products (www.qe.se).

bengan

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Perhaps a freeware toolset is OK outside the US, since we have fools that litigate everything and other countries may not.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, Steve

Well, I do see your point, but what toolset would you use to be free of any possible lawsuit? Are there any commercial toolsets out there that gives you any such garanties?

Best Regards
Geir Tore Olsen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My Agency, FDA, deals with safety critical products and when it comes to compilers, which are considered to be off-the-self tools, we rely on compliance with standards as an indicator of quality. The GCC AVR compiler(s), unlike most commercial products, are fully ANSI compliant. Paying a lot of money for a tool does not guarantee quality. Also, how much you spend in development/design does not usually affect regulatory oversight. Juries are another matter. The best defense I know of for GCC is that C and C++ are open standards which are best enforced by thousands of open source developers versus one or two compiler hacks working out of someone’s basement.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI, there is nothing out there with a 100% guarantee. Please review the datasheets of the microcontrollers themselves. They usually contain a disclaimer that they are not supposed to be used in super critical life support systems. In other words, if I build an Anti-Lock Braking System using the AVR and an accident occurs, Atmel will say its my fault for using their chips. Regardless of whether the problem was the silicon, the compiler used, or my code, the final blame will revert to me.

Step #1 is getting the silicon vendor to sign off on your project as a proper use of their components.

--- Steve

admin's test signature
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Dear colleagues!

Correct me if I’m wrong, but I strongly believe that not compilers/utilities/tools but different level of testing/debugging is necessary/requires for safety critical applications. In most cases programmer’s error is more probable that compiler’s, doesn’t it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi There!

You are absolutely correct, but when your'e making application that need to be approved according to IEC61508, you also need to say something about the reliability of the compiler itself. Basically everything about the development process such as specification, design, test routines, bugtracking and last but not least, the toolchain must be documented to meet certain criterias. You wouln't belive the amount of documents the certification process requires.

Best Regards
Geir Tore Olsen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I do believe. ACP (ass covering procedure) has no limits as well as stupidity of applying them. Unfortunate decisions almost makes by big bosses whose knowledge is well below his willing of following standards or ACP!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Getoo, in your opener you said that your boss “asks questions about the reliability of the compiler” you are using. You could, with a straight face, tell your boss that the GCC compiler is completely reliable, because, after all, it dependable gives the same result for a given set of code. The accuracy, however, is another matter. Fortunately, accuracy has two meanings 1) freedom from mistake {correctness} and 2) degree of conformity to a standard {exactness}. You might want to conveniently ignore the first meaning and tell your boss, again with a straight face, that the GCC compiler is the most accurate compiler available for AVR software because it has the highest degree of conformity to national standards. Shading the truth occasionally deflects some heat.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi There!

Eugene, when I said my boss asks questions about the reliability of the compiler, he refered to the quote from the standard. It's not really him that ask the question, but the agency that will certify the application, and they WILL ask the question.

Last time we did one of these certifications we used gcc for x86 on a 386EX controller. At that time the compiler came up as an issue. According to my boss, it was easy to point to the fact that gcc for the x86 platform had a lot of field experience. It won't be that easy for gcc for the AVR platform. Hence my question about user experiences...

Best Regards
Geir Tore Olsen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How does one measure the quality of a compiler? Setting aside this issue of reliability versus accuracy, we have in this thread proposed several metrics which, in my opinion, are bogus. The most egregious is compiler monetary cost. To my knowledge, there is no evidence that cost correlates to quality. The expensive compilers I have used seem just as likely to have bugs as the cheap/free ones. To assert that the compiler one uses is “reliable” because it cost a lot is a sad argument. Another questionable claim is that of the quantity of commercial use. If commercial use is a “reliable” metric than Microsoft operating systems must be perfect and their compilers would have fewer bugs than all other compilers. This herd argument – but Dad, everyone else is doing it – just seems silly. But perhaps the term “commercial use” is just a synonym for ‘bug rate.’ After all, if we just knew how buggy compilers were, we could pick the least buggy one. Since we can’t know how many bugs a compiler contains, we have developed the palliative of ‘rate of bug occurrence.’ This comes in many guises. This thread seems to prefer the ‘number of known bugs’ divided by the ‘number of known commercial applications.’ The anal-retentive types in the military like ‘number of bugs identified since compiler creation’ divided by the ‘amount of compiler use.’ Of course neither of these bug rates tells you much because of the subtleties of, who keeps the count and, what type of bugs occur. For example, an extra space inserted before a right curly bracket is an innocuous bug while a miscalculated jump is a dangerous bug. So now we are talking about bug risk which of course means nothing without quantifying the application risk which of course means nothing because risk is a language often spoken but never understood.

So, what are we left with? Do we strictly adhere to a standard that confuses reliability and accuracy? Do we placate the inspectors with the argument “everyone else is using it and we spent $25000 USD for it and shell out $5000 a year in maintenance, it must be good?” Yeah, I would placate the inspectors where I could but I would also point out that the GCC compiler strictly meets standards and that the architecture of the AVR reduces the complexity of the compiler. Unlike the single accumulator architectures of this world, the AVR has an orthogonal structure that, relative to the 8051, simplifies compiler constructs and thereby reduces the potential for bugs. You who labor under the tyranny of regulators have my sympathy.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My take on tools is that if your employer (or you as a proprietor) get sued for a faulty product, and that is traced to a faulty tool, you have some chance of recourse and remedy with a commercial compiler. Maybe not a cottage industry compiler (no blood from a turnip). With a public domain compiler, or a public domain operating system (can you say Linux), you, the seller, are totally left holding the liability bag.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve!

I have yet to see any compiler or toolchain that didn't have a disclaimer that said something about liability. That basically means that it won't matter if the toolchain is freeware or commercial.

Best Regards
Geir Tore Olsen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ASFAIK uses Renesas for their SofTune-Programming Enviroment the GCC.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ASFAIK uses Renesas for their SofTune-Programming Enviroment the GCC.

And, you'll never get warranty by an compiler manufactor....