| View previous topic :: View next topic |
| Author |
Message |
micsch
Joined: 06 Dec 2011
Posts: 4
|
| MISRA rule violation |
 Posted: Tue Dec 06, 2011 1:21 am |
 |
|
Hi,
I get a rule violation by MISRA (2004) when I use Pre-Processor directives like #FUSES, #device , #int_TIMER0 and so on.
The rule is:
[ MISRA 19.16 ] Preprocessing directives shall be syntactically meaningful even when excluded by the preprocessor.
How can I handle this?
Any help would be greatful.
| Code: |
//Configuration uC in Headerfile
#device adc=8 /*Aufloesung AD-Wandler in Bit */
#FUSES NOWDT /*No Watch Dog Timer */
#FUSES INTRC_IO /*Internal RC Osc */
#FUSES PUT /*Power Up Timer */
#FUSES NOPROTECT /*Code protected from reads */
#FUSES MCLR /*Master Clear pin enabled */
#FUSES NOCPD /*No EE protection */
#FUSES BROWNOUT /*brownout reset */
#FUSES NOIESO /*Internal External Switch Over mode disabled */
#FUSES NOFCMEN /*Fail-safe clock monitor disabled */
#FUSES NODEBUG /*No Debug mode for ICD */
#use delay(clock=2000000) /*System-Clock = Oszillator-Clock:4 = 500'000 kHz */
#use i2c(master, sda=PIN_C7, scl=PIN_C6, slow) /* Configure Device as Master */
|
and by the two ISR in the C-file:
| Code: |
#int_TIMER0
void timer0Isr( void )
{
}
#int_TIMER1
void timer1Isr( void )
{
}
|
|
|
 |
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Dec 06, 2011 2:33 am |
|
|
Tricky...
It may be complaining at the comments after the directives. It may be worried about the white spaces before, which are not allowed in strict C. It may be expecting only a well-defined set of directives, such as #define, #ifdef #else and other conventionally used preprocessor directives. The fact is that to CCS C, but not a generic C as possibly is expected by your MISRA test suite, these are syntactically meaningful. I'm not totally sure I know what the MISRA standard means by "exclusion by the preprocessor". Given, also that CCS, like so many other C compiler implementations these days integrates pre-processor functionality with the compiler, doing it all effectively in one pass.
How you deal with this is another matter. You have to take a view as to treat this as a warning, and work round it.
RF Developer |
|
|
micsch
Joined: 06 Dec 2011
Posts: 4
|
|
| Posted: Tue Dec 06, 2011 3:18 am |
|
|
Probably you are right. It seems that MISRA-rule does not know these directives and generates the violation. So there is not a possibility to fix it.
I will ask this in MISRA.org.uk, maybe they know what to do.
Many thanks. |
|
|
RF_Developer
Joined: 07 Feb 2011
Posts: 839
|
|
| Posted: Tue Dec 06, 2011 5:32 am |
|
|
This is another example that's covered by what Ttelmah pointed out
| Quote: |
"It is recognized that it may be necessary to raise deviations (as described in section 5.3.2) to permit certain language extensions, for example to support hardware specific features."
|
Configuring the fuses, just as with the ADC, is such a feature.
RF Developer |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
