Page 220 - The Art of Designing Embedded Systems
P. 220

A Firmware Standards Manual  207


                        Make and Proiect Files

                        Every executable will be generated via a MAKE file, or the equiva-
                   lent supported by the tool chain selected. The MAKE file includes all of
                   the information needed to automatically build the entire ROM image. This
                   includes  compiling  and  assembling  source  files,  linking,  locating  (if
                   needed), and whatever else must be done to produce a final ROM image.
                        An alternative version of the MAKE file may be provided to gener-
                   ate debug versions of the code. Debug versions may include special diag-
                   nostic  code, or might  have  a  somewhat different  format of  the  binary
                   image for use with debugging tools.
                        In integrated development environments (like Visual C++) specify a
                   PROJECT file that is saved with the source code to configure all MAKE-
                   like dependencies.
                        In no case is any tool ever to be invoked by typing in a command, as
                   invariably command  line arguments  “accumulate” over the course of  a
                   project . . . only to be quickly forgotten once version 1.0 ships.



                        Sfartup Code

                        Most ROM code, especially when a C compiler is used, requires an
                   initial startup module that sets up the compiler’s runtime package and ini-
                   tializes  certain  hardware  on the processor  itself, including chip selects,
                   wait states, etc.
                        Startup code generally comes from the compiler or locator vendor,
                   and is then modified by the project team to meet specific needs of the pro-
                   ject.  It  is invariably  compiler-  and locator-specific.  Therefore, the  first
                   modification made to the startup code is an initial comment that describes
                   the version numbers of all tools (compiler, assembler, linker, and locator)
                   used.
                        Vendor-supplied startup code is notoriously poorly documented. To
                   avoid creating difficult-to-track problems, never delete a line of code from
                   the startup module. Simply comment out unneeded lines, being careful to
                   put a note in that you were responsible for disabling the specific lines. This
                   will ease re-enabling the code in the future (for example, if you disable the
                   floating point package  initialization, one day it may need to be brought
                   back in).
                        Many of the peripherals may be initialized in the startup module. Be
                   careful  when  using  automatic  code  generation  tools  provided  by  the
                   processor  vendor  (tools that  automate chip select setup,  for example).
                   Since many processors boot with RAM chip selects disabled, always in-
   215   216   217   218   219   220   221   222   223   224   225