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.
<t></t>