15-06-2011, 07:39 PM
20-06-2011, 08:18 AM
As Rule 8.7 deals with definitions, should the question be
There are a variety of methods by which special function registers might be defined, some (most or even all?) of which will involve language extensions in order to place the register at a particular location in the address space.
Could you please give an example of the kind of definition that you have in mind?
Quote:Does this rule apply to objects which cannot be defined at block scope, like special function register variables?
There are a variety of methods by which special function registers might be defined, some (most or even all?) of which will involve language extensions in order to place the register at a particular location in the address space.
Could you please give an example of the kind of definition that you have in mind?
22-06-2011, 07:40 AM
I think this issue is highly relevant, as you will find such registers in all safety-critical applications. Implementing and accessing them correctly is extremely important to program safety. Perhaps future MISRA-C versions could address how to declare/define such hardware registers explicitly?
In C language utopia, all tools would use the C standard-compatible way to define such registers:
#define PORT (*(volatile uint8_t*)0x1234U)
With this definition, one doesn't need any variable declarations at file scope and one can write fully MISRA-compatible C code for accessing registers:
#define PORT_MASK 0x80U
...
PORT |= PORT_MASK;
PORT &= (uint8_t)~PORT_MASK;
If everyone used this syntax, there wouldn't be any strange non-standard solutions, nor any questionable bit field implementations. So personally, I interpret 8.7 as if it does apply to special registers, because I see no reason why the above syntax can't be used.
So far I haven't heard any convincing arguments why it couldn't be used either. Hardware registers should not be linked so that cannot be the reason for non-standard extensions. I have actually addressed this issue with several tool vendors, and they all replied with some mumble about their debugger being unable to show those registers unless they make non-standard extensions. Why they can't make debuggers that are aware of a specific CPU's register map, without getting it handed to them through debug info files from the compiler, is beyond me.
In C language utopia, all tools would use the C standard-compatible way to define such registers:
#define PORT (*(volatile uint8_t*)0x1234U)
With this definition, one doesn't need any variable declarations at file scope and one can write fully MISRA-compatible C code for accessing registers:
#define PORT_MASK 0x80U
...
PORT |= PORT_MASK;
PORT &= (uint8_t)~PORT_MASK;
If everyone used this syntax, there wouldn't be any strange non-standard solutions, nor any questionable bit field implementations. So personally, I interpret 8.7 as if it does apply to special registers, because I see no reason why the above syntax can't be used.
So far I haven't heard any convincing arguments why it couldn't be used either. Hardware registers should not be linked so that cannot be the reason for non-standard extensions. I have actually addressed this issue with several tool vendors, and they all replied with some mumble about their debugger being unable to show those registers unless they make non-standard extensions. Why they can't make debuggers that are aware of a specific CPU's register map, without getting it handed to them through debug info files from the compiler, is beyond me.
22-06-2011, 01:33 PM
Quote:So far I haven't heard any convincing arguments why it couldn't be used either.Many micros have registers in a memory space that can't be accessed with a macro unless an extension (typically of the form of a qualifier) is used.
Some also require the use of extensions for efficiency reasons. For example, the 8051 (an many, many derivatives) have bit-addressable locations and registers which cannot be (efficiently) accessed using standards-compliant 'C' code.