%$Header$

\chapter{\cdaazerolongtitle{}}

\label{cdaa0}

\beginchapterquote{``Without censorship, things can get terribly confused
                     in the public mind.''}{General William Westmoreland}

\section{Introduction}
%Section Tag: INT

In practice, preparing the ROM image of a microcontroller software product
is a complex process that exceeds the capabilities of standard development
tools such as compilers, assemblers, and linkers.  The specific 
elements of the process that exceed the capabilities of standard ``off-the-shelf''
development tools are:

\begin{itemize}
\item ROM checksums must typically be generated and placed at a specific
      location in ROM.
\item Suspicious conditions that may indicate a software error 
      should be detected.  Suspicious conditions include
	  versions of compilers or other development tools that are
	  not the expected versions, files which are not checked into
	  version control, extra files, missing files, etc.
\item Coding standards should be automatically enforced during the
      build process.  Violations of coding standards should prevent
	  a production build.
\item Product defects should be fed back into the tool set.\footnote{Product
      defects should also be fed back into the training for software
	  developers, and into the software process.}  If the root cause
	  of a product defect is found to be automatically detectable,
	  tools should be enhanced to prevent recurrence of the defect.
\item Redundancy should be eliminated or minimized in all of the
      materials---including the code---which are maintained as
	  part of software developments.  Examples of redundancy include:
	  \begin{itemize}
	  \item Network message lists are often redundant with respect to
	        the code.  Network message lists often are processed to
			form data tables in the code, and sometimes even influence
			the structure of the code.
      \item Software modules are often redundant with respect to
	        each other.  For example, it is common for task schedulers
			and real-time operating systems to contain lists of 
			function pointers.  These lists of function pointers
            must be maintained to be consistent with the functions
			(usually in different source files).  The maintenance
			of consistency should be automatic (the lists of function
			pointers should be maintained automatically).
	  \end{itemize}
\item Organizations often maintain ``bookshelves''---collections of
      re-usable software components.  Often, ``customizing'' the
	  software components (i.e. using them from the bookshelf)
	  is a task that exceeds the capabilites of the `C' preprocessor
	  or other simple tools.
\item Some mappings that are helpful in code are too complex to
      be performed by the `C' preprocessor or other simple
	  tools.  For example, if one accepts 1.6093 as the 
	  ideal conversion factor from miles-per-hour to 
	  kilometers-per-hour, the best rational approximation with
	  numerator and denominator not exceeding 255 is 243/151.\footnote{See
	  Chapters \cfryzeroxrefhyphen{}\ref{cfry0}, 
	  \ccfrzeroxrefhyphen{}\ref{ccfr0}, 
	  and \cratzeroxrefhyphen{}\ref{crat0}.}  The mapping from 
	  (1.6093, 255, 255) to (243,151) is too complex to be made
	  by the `C' preprocessor.
\end{itemize}

In this chapter, we present a solution based around the scripting language
Tcl.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\noindent\begin{figure}[!b]
\noindent\rule[-0.25in]{\textwidth}{1pt}
\begin{tiny}
\begin{verbatim}
$RCSfile: c_daa0.tex,v $
$Source: /home/dashley/cvsrep/e3ft_gpl01/e3ft_gpl01/dtaipubs/esrgubka/c_daa0/c_daa0.tex,v $
$Revision: 1.2 $
$Author: dtashley $
$Date: 2001/07/30 02:54:17 $
\end{verbatim}
\end{tiny}
\noindent\rule[0.25in]{\textwidth}{1pt}
\end{figure}

% $Log: c_daa0.tex,v $
% Revision 1.2  2001/07/30 02:54:17  dtashley
% INTFAC extension and command-line utility finished.
%
% Revision 1.1.1.1  2001/06/19 19:48:30  dtashley
% Initial import.
%
%
%End of file C_DAA0.TEX