Hi I have one requirement to be done like example first bit of register should be made 0(reset ) and MSB 4 bits need to be made 1 every time.
I can do this in two steps using :
int val=0x0f;
val |=0xf0;
val &=~(1<<0);
printf("val is %d\n",val);
I am expecting two lines of code to be framed in 1 logic.I am trying but looking for some good logic from experts.
I got one logic like val = (val |=0xf0) & ~(1<<0); but cant use this type of logic since some coding standards used are MISRA.
Please can any one give me some better logic.
Thanks in advance.
It is entirely unclear what you mean, so here's some MISRA code review:
int is not MISRA compliant. Use a fixed-width integer type, preferably from stdint.h.
0x0f literals like these are not MISRA compliant. All literals need to have an u or U suffix, even hexadecimal ones.
val |=0xf0; is not MISRA compliant. You aren't allowed to use bit-wise operators on signed types.
val &=~(1<<0) is not MISRA compliant. There is an important MISRA rule stating that the result of the ~ operator must always be cast to the intended type (called underlying type or effective type depending on MISRA version). Furthermore, MISRA does not allow you to use shift operators on signed types.
printf is not MISRA compliant. MISRA doesn't allow stdio.h in production code.
Otherwise, the code is readable and clear. Apart from the fact that int is not 8 bits wide, so your talk about setting the MSBs doesn't make any sense.
Naturally, if you try to merge this non-compliant readable code into an unreadable one-liner, it will remain non-compliant. You have to start by making the original code MISRA compliant. Might be wise to actually run it through your static analyser.
unsigned val = whatever();
val = (val | 0xF0u) & ~1u;
The nested assignment is unnecessary. I don't have a MISRA copy handy, but I think this should pass. The use of unsigned literals and types is because MISRA disallows bitwise operations on signed integers.
Related
I'm using "IAR RL78" and "RL78-R5F10BGG" microcontroller. I also have enabled MISRA C 2004 in IAR.
I wanna define one of my functions as "inline". This inline function is supposed to be used in various c file. So I have defined the function in one of my
header files and include that header file in all c files which need the function. But my problem is because of MISRA C 8.5 rule after compilation. It says:
Error[Pm123]: there shall be no definition of objects or functions in a header file (MISRA C 2004 rule 8.5)
The following is the definition of the inline function in common.h header:
static inline int16u SET_BIT(int16u int16uVar, int16u int16uBitIndex);
#pragma inline=forced
static inline int16u SET_BIT(int16u int16uVar, int16u int16uBitIndex)
{
int16uVar |= ( (int16u)1u << (int16uBitIndex) );
return int16uVar ;
}
What's the problem?
Is there any way to get rid of this problem?
MISRA-C:2004 does not cover C99, so you simply cannot use inline at all.
And because of this, the rule about function definitions in header files strikes bluntly even at inline functions. There is no way you can conform to MISRA-C:2004 with the posted code - you will have to create deviations from several required rules.
My recommendation is to upgrade to MISRA-C:2012, which has an explicit exception for this scenario (rule 5.9):
Exception
An inline function with internal linkage may be defined in more than one translation unit provided that all such definitions are made in the same header file that is included in each translation unit.
MISRA-C:2012 also requires that all inline function must declared as static (rule 8.10).
MISRA-C:2012 is a much better document in almost every way. IAR have got support for the 2012 version too and their MISRA checker should be a separate plug-in not related to the specific MCU.
Unrelated to your actual question (int16u)1u << is completely wrong and dangerous.
If you actually must have signed types (most often you don't), then you must first carry out the shift on unsigned type, then convert to signed.
This is not just needed for MISRA-C compliance, but to fix a blatant C bug that invokes undefined behavior on 8 and 16 bit MCUs, when you left shift data into the sign bit.
Correct code should be int16uVar |= (int16u)(1u << int16uBitIndex); and I believe this also sates the MISRA-C:2004 requirements about casting to the underlying type after the operation.
Also note that creating your own "garage standard" integer types is frowned upon in general - since you are using C99 you should be using stdint.h and nothing else. This is also the MISRA-C:2012 recommendation.
Thank you Lundin for your helpful reply.
About the second part of your reply, I should say that in our coding style we use int16u for unsigned int types. that is
typedef unsigned int int16u
So I'm shifting the unsigned int not signed int. there is a typing error in my question and that is, I have written
int16uVar |= ( (int16u)1u << (int16uBitIndex) );
but the correct line in my code is
int16uVar |= ( (int16u)1 << (int16uBitIndex) );
I do apologize.
In simple terms, inline is not part of C90 (as covered by MISRA C:2004)
However, there is a workaround, if you adopt MISRA Compliance... this introduces the concept of Deviation Permits, and the MISRA team conveniently provide you with such a Permit for using inline (Permit/MISRA/C:2004/1.1.C.1)
Of course, most compilers simply ignore the inline qualifier anyway...
Declaration of Interest: See profile!
Suppose I have
typedef struct {
unsigned short bar : 1;
} foo_bf;
typedef union {
unsigned short val;
foo_bf bf;
} foo_t;
How do I correctly assign a value to this bitfield from an type e.g uint16_t?
uint16_t myValue = 1;
foo_t foo;
foo.bf.bar = myValue
Running PC-Lint, this turns into a MISRA error:
Expression assigned to a narrower or different essential type.
I tried to limit the number of used bits without any success.
foo.bf.bar = (myValue 0x1U)
Is there any chance to get it MISRA complient if I have to use a uint16_t value as origin?
MISRA-C's essential type model isn't really applicable to bit-fields. The terms narrower and wider refer to the size in bytes (see 8.10.2). So it isn't obvious if a static analyser should warn here or not, since the rules for essential type do not address bit-fields.
EDIT: I was wrong here, see the answer by Andrew. Appendix D.4 tells how to translate a bit-field type to the matching essential type category.
However, using bit-fields in a MISRA-C application is a bad idea. Bit-fields are very poorly specified by the standard, and therefore non-deterministic and unreliable. Also, MISRA-C 6.1 requires that you document how your compiler supports bit-fields with uint16_t, as that is not one of the standard integer types allowed for bit-fields.
But the real deal-breaker here is Directive 1.1, which requires that all implementation-defined behavior is documented and understood. For a MISRA-C implementation, I once actually tried to document all implementation-defined aspects of bit-fields. Soon I found myself writing a whole essay, because there are so many problems with them. See this for the top of the iceberg.
The work-around for not having to write such a "bit-field behavior book" is to unconditionally ban the use of bit-fields entirely in your coding standard. They are a 100% superfluous feature anyway. Use bit-wise operators instead.
Appendix D.4 of MISRA C:2012 is usefully titled "The essential types of bit fields"
For a bit-field which is implemented with an essentially Boolean type, it is essentially Boolean
For a bit-field which is implemented with a signed type, it is the Signed Type of Lowest Rank which is able to represent the bit field
For a bit-field which is implemented with a unsigned type, it is the Unsigned Type of Lowest Rank which is able to represent the bit field
The Unsigned Type of Lowest Rank of a single-bit unsigned integer would be uint8_t (aka unsigned char) - assuming that the tool does not interpret a single-bit as being boolean...
Beyond observing that this looks like a mis-diagnosis by PC-Lint, a workaround that avoids any possibility of doubt would to cast:
foo.bf.bar = (uint8_t)myValue
As an aside MISRA C:2012 Rule 6.1 gives guidance on the use of types other than signed/unsigned int for bit-fields...
In the following code from core_cm4.h why is there a double cast ((uint32_t)(int32_t)IRQn)?
For example in the following function:
__STATIC_INLINE void NVIC_EnableIRQ(IRQn_Type IRQn)
{
NVIC->ISER[(((uint32_t)(int32_t)IRQn) >> 5UL)] = (uint32_t)(1UL << (((uint32_t)(int32_t)IRQn) & 0x1FUL));
}
What is the purpose of this?
Since CM4 software implements negative interrupt sources for core, you have to cast value first to 32bit signed integer and later to unsigned 32bit to make proper right shift with padding zeros on the left side of number.
CM4 uses -15 to -1 as CM4-Core sources and from 0 to next as vendor specific sources.
By looking at that snippet, it is clear that whoever wrote it was confused over how implicit type promotion rules work. In addition, the >> 5UL looks very fishy and when I see that I immediately suspect that this code base suffers from a poor understanding of MISRA-C; possibly they are using a bad static analyser which spits out false positives.
A visit at Github proves my suspicion to be correct, there's comments stating that the intention is to follow MISRA-C:2004.
MISRA-C demands that no dangerous, implicit type promotions may occur. The casts are some failed attempts to silence a static analyser, without an understanding why the tool gave those warnings.
Correct, MISRA-C (2004 and 2012) compliant code would be this:
NVIC->ISER[((uint32_t)IRQn>>5UL)] = (1UL << ((uint32_t)IRQn & 0x1FUL));
(MISRA-C has a requirement that complex sub-expressions must use parenthesis despite what operator precedence there is.)
This code is still messy, so it should preferably be rewritten for readability, into something that will produce exactly the same machine code:
uint32_t ISER_index = ((uint32_t)IRQn >> 5UL);
uint32_t shift_n = ((uint32_t)IRQn & 0x1FUL);
NVIC->ISER[ISER_index] = (1UL << shift_n);
Side note:
MISRA-C:2004 demanded that the result of the shift expression should be immediately cast to the "underlying type" (MISRA term). Thus one could also have written (IRQn_Type)(IRQn >> 5UL) and it would still be MISRA-C:2004 compliant.
However, there is nothing in MISRA preventing you to adding your own cast to a different type, such as uint32_t, before the shift. This is a better thing to do, since it eliminates the implicit promotion entirely.
For those who are confused about how the implicit type promotions work in C, see Implicit type promotion rules.
Assuming IRQn is an integer (any signed integer type) in the range you say, then (uint32_t)(int32_t)IRQn is exactly the same as (uint32_t)IRQn.
The author of the code possibly didn't understand C type conversion rules; which are based on values, not representations. Converting -3, for example, to uint32_t always gives UINT32_MAX - 2 regardless of which data type the -3 was. It's the value of "negative 3" that matters.
(The other answer explains the difference between using a cast and no cast at all).
I have a bare-metal program(driver) which reads/writes some memory-mapped registers.
e.g:
void foo_read(uint64_t reg_base, uint32_t *out_value)
{
*out = READREG(reg_base + FOO_REG_OFFSET);
}
reg_base is the base address of the memory-mapped device (64-bit
address)
FOO_REG_OFFSET is the offset of the register (#define FOO_REG_OFFSET
0x00000123). Register "foo" is 32-bit "wide".
READREG is defined like this:
#define READREG(address) (*(uint32_t*)(address))
As you can guess MISRA 2008 is not happy with the cast from unsigned long long to pointer (5-2-7/5-2-8 are reported). My question is: what is the best/appropriate way to access memory and get rid of MISRA warnings? I've tried to cast to uintptr_t before casting to pointer, but This didn't help.
Thank you.
OK a few things here - first of all, your definition for READ_REG is missing a volatile -- it should be something like
#define READREG(address) (*(uint32_t volatile *)(address))
Secondly - and this is CPU-specific of course - generally speaking, reading a 32-bit value from an odd address (offset 0x123) won't work - at a minimum it will be slow (multiple bus cycles), and on many architectures, you'll hit a processor exception. (BTW, please note that pointer arithmetic doesn't come into play here, since the 2 values are added before being cast to a pointer.)
To answer your original question:
what is the best/appropriate way to access memory and get rid of MISRA
warnings
Well -- you are violating a MISRA rule (you have to in this case, we've all been there...) so you will get a warning.
So what you need to do is suppress the warning(s) in a disciplined, systematic and easily identifiable way. In my opinion, there is no better example and explanation of this than in the Quantum Platform (QP) Event-driven framework's code, which is open source. Specifically:
Check out the QP's MISRA Compliance matrix for examples of how this is handled -- for example, just search the PDF for the Q_UINT2PTR_CAST macro
Check out the QP's actual source code - for example, the macro that wraps/encapsulates such "int to ptr" casts (this way they are done in a manner that is easy to identify, and easy to change/suppress warnings for in a single place)
Lastly, check out the PC-Lint config file qpc.lnt, where you can see how/where the warnings are suppressed in a single place. THis is explained in this app note, section 6.3:
6.3 Rule 5-2-8(req)
An object with integer type or pointer to void type shall not be
converted to an object with pointer type.
The QP/C++ applications might deviate from rule 5-2-8 when they need
to access specific hard-coded hardware addresses directly. The QP/C++
framework encapsulates this deviation in the macro Q_UINT2PTR_CAST().
The following code snippet provides a use case of this macro:
#define QK_ISR_EXIT() . . . \
*Q_UINT2PTR_CAST(uint32_t, 0xE000ED04U) = \
I don't have time to talk about MISRA warning suppresions, compliance issues, etc. but the above gives you everything you need.
P.S. Not sure which MISRA guidelines you are referring to -- for C, there are the 2004 & 2012 guidelines, and for C++, there are the 2008 guidelines (I know, it's almost 2017!)
It has been established in another question on this website that there is no literal suffix for short in C and that one can do the following:
short Number = (short)1;
But what is the difference between casting it and not doing so:
short Number = 1;
Does it ever matter which you use and how does the compiler handle them differently?
There is no difference in effect of the implicit cast and the forced cast, the forced cast is largely "documentary" - it says "I did this deliberately".
The explicit cast makes it clear to a potential maintainer, they the type is deliberately short and should not be changed to match the initialiser. It may also serve to silence compiler or static analysis tool warnings. However if you provide an initialiser that is too large for a short - it will silence any warning of that too.
The explicit cast is perhaps more useful in macro definitions such as:
#define DEFAULT_CONDITION ((short)1)
short condition = DEFAULT_CONDITION ;
The behavior of the code is the same in both cases.
But some code checkers/compilers could warn if you assign an int to a short (with an implicit conversion).
Most tools I know don't do that for literal values though. They check if the known literal actually fits into the smaller type.