If you suspect a “volatile” problem, many compilers support an option like -fvolatile, which will treat all variables in a module as volatile. This will kill your performance, but at least it can help you track down the problem quickly.

Further, if you are working on a memory-mapped device, you _must_ ensure cache coherency. This is a major cause of race conditions in device drivers.

Thanks for the article.

My preferred method is to declare registers as ‘extern’ in the C (or C++) code, then actually define their locations as absolutely-located entities in a linker file or an assembly file. This method is also tool-dependent, but since there’s almost always a way to achieve this goal it’s fairly safe. It can be cumbersome if you try to define registers one-by-one, which is why I generally make up a ‘struct’ type for each peripheral (or peripheral type, if the microprocessor designer was kind enough to make duplicate peripherals identical but for offset), then declare entire structures in the C code and in the linker script or assembly.

Another method is to make up header files with appropriate defines:

#define p_led_reg ((uint8_t *) 0×00080000)

etc. This gets more complicated with C++ (the compiler will complain about old-style casts, or outright throw an error), and even more complicated yet if your code is a mix of C and C++. But it’s a method that will work with just about every tool chain that I’ve encountered.

Probably the best way to do this of all is to make sure that you choose a form for addressing your registers that is tool-independent outside of the actual register definitions (header files and possibly linker scripts &c.) and make sure that those register definitions are well encapsulated and easily identifiable so that if you do have to do some mad thing like changing tool chains in mid stream, the surgery will be limited to the pertinent header files, in stead of being splattered over your whole code base.

I always use const when I have data that is tightly coupled, such data in a structure or array that is all constant. This is in addition to using const as a ‘do not overwrite this data’ declaration for read only hardware registers.

Always good to refresh the old memory on volatile and const usage though.

The bulk of the objection to volume2′s using access functions seems to be “less convenient, less clear, and leads to bigger and slower code”. Is that a fair summary?

If the syntax of updating ‘volume’ were were identical to using volume1 in the source code, would the ‘less convenient, less clear’ objections go away?
If the speed and size difference could be eliminated by correct use of compiler flags, would those objections go away?

Put another way, are all of those objections potentially soluble by careful use of a programming language like C++ or C#?

Some of the issues comparing the two approaches are discussed, but some are not. If all of those objections go away, then IMHO we should consider the other side of the argument.

The code to actually *update* volume in volume1 is in every part of the program that updates it, but the code to actually *update* volume in volume2 can be forced to exist at only one place. Depending on the development system, it may be possible to choose to distribute the update code to all the update sites using volum2 by changing a few compiler flags and/or a single piece of source code. So, not only are the two approaches functionally different, the scope to change the functional behaviour of the program during developmnt is different.

This wasn’t discussed as a difference, and I think it can be important.

A contrived example: If the debugging system does not support ‘data watchpoints’ but only a limited number of breakpoints, the difference may become extremely significant. An intermittent problem might be hard to find, and access functions may be better than direct data access. One approach might be to augment the code around the setting of volume to log a little bit of extra information to help diagnose the error. For example, the return address of the code attempting to update the variable is available (maybe in a link register, or on a stack). None of the other code would need to be changed, so the ‘Heisenberg effect’ of making code changes is likely more limited in the case of accessors than global data.

I am putting the case that writing code which makes it easy to take a defensive approach, in the absence of other issues, is inherently worth considering as a ‘good thing’.

I don’t accept the “you should just get yourself a better debugger and development system” response. That seems equivalent to saying, “make the world work in a different way, and you would have a solution to that development problem”. IMHO, it is a smaller problem to write robust code than make the world work in such a way that all development problems can be sidestepped.

I have not seen any solid, evidence based, research that supports the view that access functions are inherently less clear than assignment. Maybe someone can direct me to it? I tend to think both sides of the debate are ‘religious war’ stuff in the absence of evidence.

I am willing to suggest that the fact that there *is* an explicit difference between local variables and ‘globals’, where locals can be assigned directly, and all ‘global’ data must be ‘accessed’, might actually help.
Of course, some programming languages allow that syntactic difference to be hidden, so that may be a mute point.

I especially accept a concern over ‘lack of syntactic clarity’ is important, but that may depend on the language used. If ‘lack of syntactic clarity’ is the main objection, then it may also be an argument for some languages and against others.

I am simply aiming to ensure a more complete set of issues are considered, and clarify the previous objections.