MikroElektronika Forum

Since we're on the subject of reliability, two things:

1) Mikroelectronika specifically disclaims use of their software in developing life-critical applications. If, for example, a vehicle application caused large damages, in a court, this could be used as evidence that it's not for any kind of mission-critical application, whether it is life-critical or not. So it's probably a bad idea to use mikroC in anything that has serious damage potential.

2) If you are going to use one of the mE compilers, I would think that MikroPascal would be better at avoiding bad programming practices.

I don't see the niche for mE compilers in anything mission-critical, unless they want to specifically address these issues. I sure wouldn't want that kind of liability hanging over my head without a supplier who specifically claims that their product is suitable.

@Peter, @LGR,

Thank you for your reply. I notice the same issue with all of the MCHP products. Do you know of any third-party validation tools (not just MISRA-C, but more importantly like DO-187 Level A) for PIC32 and/or PIC24/dsPIC33?

So it's probably a bad idea to use mikroC in anything that has serious damage potential.

I agree and therefore I specificaly mentioned that we use other devices with other Tools for such applications !
Using mikroC for an instrument panel has no danger besides that it can stop to diplay or similar using it in telephone
or airconditioning system has no potential danger and I also think using C does not teach you bad programming habits.


@rmteo
Nothing that I am aware off besides that there is companies which use the Microchip tools with the automotive RTOS and plug in
from Vector which then is Automotive approved and the tool gaurantee is provided by Vector

@peter,

Thank you. VectorCast looks like a good solution.

This is an interesting tangential discussion.. I do agree that the current state of Me libraries renders them not Industrial Quality, as I have trapped them in infinite loops if noise is induced in the system. I found this to be the case in I2c and serial libraries, and posted to this effect some time ago. Hence the need to develop real libraries.

To revisit the original topic:
How about an interrupt driven ADC library? This would (once setup) deposit values into a set of variables on regular intervals in response to adc requests, and the resulting interrupts, upon completion.
If anyone is interested I'll post a first order approximation.
Bart