Page 364 - Programming Microcontrollers in C

Advanced Topics in Programming Embedded Systems (M68HC12) 349

the general program storage, must be completely erased. Therefore,
if you should want to change the contents of the phone book, the
whole block would have to be erased and rewritten. Another approach
that could be used is just to assume that you will have enough FLASH
to write over and discard the memory used and move the entry to
new memory whenever it is changed. This approach, however, is
wasteful of the memory.
The EEPROM does not suffer this problem. Any individual byte
in the EEPROM memory block can be written, read, or erased without
a problem. Also, the EEPROM can be erased and rewritten at least
10,000 times without deterioration. FLASH, on the other hand, is
specified to be able to withstand 100 erase/write cycles during its
lifetime. All in all, FLASH makes a good program storage memory
and EEPROM makes a better changeable nonvolatile memory.
The C compiler used in this chapter is that provided by Cosmic. This
compiler is essentially the same as that seen in Chapters 5 and 6 except,
of course, it creates code for the M68HC12 family of parts. One very
nice extension of the compiler is the ability to identify EEPROM in the
code. The approach followed here uses the following #pragma:

#pragma data[768] @eeprom
It identifies data as an array 768 bytes long that is stored in
EEPROM. At link time a command like

+seg .eeprom –b 0xd00 –m768
indicates that the EEPROM will be found at the address 0xd00 and it
will be 768 bytes long. The nice feature derived from this extension to
the C language is that any assignment to the data array will first erase
the byte and then store the data into the specified location automatically.
The fact that the HC12 component that is to be used for this project
contains a large amount of FLASH and little RAM leads to some
difficulty in writing code for use on this part. There are no development
environments that contain sufficient RAM to test a significant program.
Therefore, prior to executing the first byte of code on the target chip,
you must be more certain than normal that the code will work as
intended. I solve this problem by developing most of the code for the
final configuration to execute in a DOS environment and only after I
have a complete working program is there any attempt to move it into
the target system. Code developed in this manner was discussed in the