trunk/c_daa0/c_daa0.tex

%$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}
$HeadURL$
$Revision$
$Date$
$Author$
\end{verbatim}
\end{tiny}
\noindent\rule[0.25in]{\textwidth}{1pt}
\end{figure}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
%End of file C_DAA0.TEX
1	%$Header$
2
3	\chapter{\cdaazerolongtitle{}}
4
5	\label{cdaa0}
6
7	\beginchapterquote{``Without censorship, things can get terribly confused
8	in the public mind.''}{General William Westmoreland}
9
10	\section{Introduction}
11	%Section Tag: INT
12
13	In practice, preparing the ROM image of a microcontroller software product
14	is a complex process that exceeds the capabilities of standard development
15	tools such as compilers, assemblers, and linkers. The specific
16	elements of the process that exceed the capabilities of standard ``off-the-shelf''
17	development tools are:
18
19	\begin{itemize}
20	\item ROM checksums must typically be generated and placed at a specific
21	location in ROM.
22	\item Suspicious conditions that may indicate a software error
23	should be detected. Suspicious conditions include
24	versions of compilers or other development tools that are
25	not the expected versions, files which are not checked into
26	version control, extra files, missing files, etc.
27	\item Coding standards should be automatically enforced during the
28	build process. Violations of coding standards should prevent
29	a production build.
30	\item Product defects should be fed back into the tool set.\footnote{Product
31	defects should also be fed back into the training for software
32	developers, and into the software process.} If the root cause
33	of a product defect is found to be automatically detectable,
34	tools should be enhanced to prevent recurrence of the defect.
35	\item Redundancy should be eliminated or minimized in all of the
36	materials---including the code---which are maintained as
37	part of software developments. Examples of redundancy include:
38	\begin{itemize}
39	\item Network message lists are often redundant with respect to
40	the code. Network message lists often are processed to
41	form data tables in the code, and sometimes even influence
42	the structure of the code.
43	\item Software modules are often redundant with respect to
44	each other. For example, it is common for task schedulers
45	and real-time operating systems to contain lists of
46	function pointers. These lists of function pointers
47	must be maintained to be consistent with the functions
48	(usually in different source files). The maintenance
49	of consistency should be automatic (the lists of function
50	pointers should be maintained automatically).
51	\end{itemize}
52	\item Organizations often maintain ``bookshelves''---collections of
53	re-usable software components. Often, ``customizing'' the
54	software components (i.e. using them from the bookshelf)
55	is a task that exceeds the capabilites of the `C' preprocessor
56	or other simple tools.
57	\item Some mappings that are helpful in code are too complex to
58	be performed by the `C' preprocessor or other simple
59	tools. For example, if one accepts 1.6093 as the
60	ideal conversion factor from miles-per-hour to
61	kilometers-per-hour, the best rational approximation with
62	numerator and denominator not exceeding 255 is 243/151.\footnote{See
63	Chapters \cfryzeroxrefhyphen{}\ref{cfry0},
64	\ccfrzeroxrefhyphen{}\ref{ccfr0},
65	and \cratzeroxrefhyphen{}\ref{crat0}.} The mapping from
66	(1.6093, 255, 255) to (243,151) is too complex to be made
67	by the `C' preprocessor.
68	\end{itemize}
69
70	In this chapter, we present a solution based around the scripting language
71	Tcl.
72
73	%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
74	\noindent\begin{figure}[!b]
75	\noindent\rule[-0.25in]{\textwidth}{1pt}
76	\begin{tiny}
77	\begin{verbatim}
78	$HeadURL$
79	$Revision$
80	$Date$
81	$Author$
82	\end{verbatim}
83	\end{tiny}
84	\noindent\rule[0.25in]{\textwidth}{1pt}
85	\end{figure}
86	%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
87	%
88	%End of file C_DAA0.TEX
Name	Value
svn:eol-style	native
svn:keywords	Author Date Id Revision URL Header