Page 156 - Programming Microcontrollers in C
P. 156
Coding Tips for Microcontrollers 141
statements which identify all of the register locations, port addresses,
and bit names for the microcontroller. It is best if all of these pre
liminary data are placed in a header file specific to a device and then
it can be included at the beginning of programs for the device. This
approach is convenient because it gives the programmer the ability
to use mnemonics throughout the program. It also provides some
limited portability. If a second device in the same family has some
what different register and port locations, it is possible to write a new
header file for this second device and code written for the original
device will probably work with the second device when the proper
header file is included. We will discuss header files further as we
examine the programming of specific microcontrollers.
In this book, you will see the C programming language used to
develop code for embedded systems products. C is a powerful
language that can be abused and is often the subject of such abuse.
Don’t abuse this fine language. It is your responsibility as a
programmer to write code that is easy to read, easy to understand,
easy to debug, easy to maintain, and easy to use. Any fancy antics in
coding are uncalled for and not needed. Any group that is writing
project code should implement a shop coding standard that will direct
the way code is written. There are several organizations that have
prepared such standards. I cannot agree with all of the elements of
these coding standards that I have seen, but any coding standard is
better than none. Research the matter and find a coding standard that
comes close to suiting your needs and then modify it to meet your
needs exactly. And then use it.
I previously mentioned “group development.” I have seen many
small projects in which the software development was an afterthought.
There are still many projects that can fit into a few hundred bytes or
even a few thousand bytes. Such projects might not seem to require
the careful oversight implied by a shop standard. But they do! In the
development of software, you will find that the initial cost of the
software is dwarfed by the cost of maintenance. Therefore, any effort
put forth to help the maintenance of the software into the future is
effort well spent regardless of the size of the project. You will often
find that newer chips have massive memory spaces and with these
memory spaces available, the code will expand to fill them. This
expansion of the code is not necessarily bad if the expansion
accompanies improved operation and features. However, one