The use of Ada as a production language for Electronic Controllers has
expanded the issue of reusability beyond what many of us are accustomed.
When a group of similar EC projects are initially designed, the Ada
development environment encourages the separation of target system control
procedures in a way that encourages reusability with a minimum of change.
Much of system generation can be managed as reusable packages. Ada provides
an environment in which the system generation and linkage design level is no
longer separated from the application programming level; partitioning of
responsibility changes complexion. The system generation and the
application are compiled within an architecture imposed by the Ada
compilation. The packaging of Separate reusable system features supports
effective response to unanticipated needs within the development cycle,
anticipating changed system requirements in varying EC applications. The
packaging of system features in reusable containers by the Ada compiler in
many cases allows the design of an EC system to be a configuration management
responsibility outside the software development effort.
A methodology which leads to timely support of brassboard changes and
integration of advanced parts during the development cycle of a particular EC
within a family of applications is described. EC generation consists of a
three step Build in addition to the link and target load actions. The three
Build steps are System generation, Communications and I/O generation. The
System generation step consists of compilation of those packages well defined
by the initial Target processor and memory partitioning design. This
provides static definition of the hardware and execution environment for the
EC and is a straightforward coding assignment for an experienced EC
programmer. The Ada compiler elaborates the packages defining global
addresses and types. During this step the library routines needing import
are referenced.
The Communications and I/O generation step consists of compilation of those
packages which are relatively well defined and provide a definition of the
external communication environment for the EC. All control software for
hardware which is likely to be upgraded in response to enhanced requirements
is configured into the EC at this step. During development this
configuration will be changed by the addition of control routines for
alternative Communications and I/O or by the addition of remote communication
requirements to the design. This build step is in general not at all
straightforward nor static during the life of a project and should be
delegated to an experienced programmer analyst.
Application generation consists of grouping applications into execution
levels. At each execution level the procedures and declarations are packaged
together into units with common resource needs. Applications Executive,
Function Bodies, and Procedure Bodies are developed as separate compilation
units. If, for example, the executive package TASK_EXECUTIVE_PKG containing:
package TASK_EXECUTIVE_PKG is
SOME_GLOBAL : SOME_TYPE ; -- An Executive Specification contains Variable
declarations
procedure PROCEDURE ; -- and Procedure and/or Function declarations which
are Global to
procedure FUNCTION ; -- all the Application Packages at this execution
level.
end TASK_EXECUTIVE_PKG ;
package body TASK_EXECUTIVE_PKG is
procedure PROCEDURE is separate ;
function FUNCTION is separate ;
package TASK1_PKG is procedure TASK1 ;
end TASK1_PKG ; package body TASK1_PKG is separate ;
package TASK2_PKG is procedure TASK2 ;
end TASK2_PKG ; package body TASK2_PKG is separate ;
package TASK3_PKG is procedure TASK3 ;
end TASK3_PKG ; package body TASK3_PKG is separate ;
end TASK_EXECUTIVE_PKG ;
This format allows the division of application development between two
classes of developer. An intimate knowledge of the system structure and the
data global to an implementation level provides meat for one class of
developer, the EC programmer analyst. An intimate knowledge of an
implementation level and the data local to an Application Task provides meat
for the second class of developer, the EC systems analyst. This build step
is in general the least straightforward step in the build process and shouls
be delegated to and experienced EC systems analyst familiar with the
engineering systems controlled by the EC. The Separate units, though, are
conveniently assigned to contract programmers.
The Applications Executives interface by means of packages which contain
type and variable declarations global to more than one application level
but are not global to the EC. Application procedures and functions
statically defined for the Application by the design specification will in
general appear in the interface package. Only the procedures and functions
which will be changed as the Applicaiton Tasks change need be maintained
Spearately.
Transmission Electronic Controller (TEC) - an Example Ada EC:
The TEC Systems Build is implemented with the Softek Ada86 Development
environment for the i80186 Target from a command procedure called
TEC_BUILD.COM in directory [alexander.tec]. TEC_BUILD.COM in turn executes
the assembly of imported assembly routines, the three build steps, the link,
and the target load actions. Ada Libraries are specified as
[alexander.tec.library] for TEC_SYSTEM and TEC_IO, and [alexander.tec.softek]
for TEC_APPLICATION.
The three build steps are System generation using a command procedure
TEC_SYSTEM.COM, Communication and I/O generation using a command procedure
TEC_IO.COM, and Application generation using command procedure
TEC_APPLICATION.COM. The listings from each build step are sent to the
directory [alexander.Print] with a .out extension; the listings are named
according to their build source, eg. the first compilation unit in TEC_SYSTEM
is SYS01.OUT.
I. System generation using a command procedure TEC_SYSTEM.COM
1. System Location
1. HW_ADDRESS_PKG.ADA
2. MATH_UTILITY_PKG.ADA
3. INTERRUPT_CONTROL_PKG.ADA
4. GLOBALS_PKG.ADA
5. VECTOR_TABLE_PKG.ADA
6. INTERNAL_CONTROL_REG_PKG.ADA
7. INTERRUPT_HANDLERS_IMPORT_STUB.ADA
2. Actualization
1. MAIN_DRIVER.ADA
3. Importation of ASM86 modules
1. STATIC_RAM_TEST.ASM
2. STARTUP_TIMER_INTERRUPT_HANDLER.ASM
3. INTERRUPT_HANDLERS_IMPORT.ASM
4. DMA_INTERRUPT_HANDLERS_IMPORT.ASM
5. FP_MULTIPLY.ASM
6. FP_DIVIDE.ASM
II. Communication Utility and I/O generation using a command procedure
TEC_IO.COM
1. Data Port Utility Location (Standard ID)
1. COUNTER_INTERFACE_PKG.ADA
2. COUNTER_OUTPUT_SPEC.ADA
3. COUNTER_OUTPUT_BODY.ADA
4. COUNTER_INPUT_SPEC.ADA
5. COUNTER_INPUT_BODY.ADA
6. STEPPER_INTERFACE_PKG.ADA
7. STEPPER_OUTPUT_SPEC.ADA
8. STEPPER_OUTPUT_BODY.ADA
9. STEPPER_INPUT_SPEC.ADA
10. STEPPER_INPUT_BODY.ADA
11. DISCRETES_INTERFACE_PKG.ADA
12. DISCRETES_OUTPUT_SPEC.ADA
13. DISCRETES_OUTPUT_BODY.ADA
14. DISCRETES_INPUT_SPEC.ADA
15. DISCRETES_INPUT_BODY.ADA
2. Serial Communications Utility Location
1. SERIAL_COMMUNICATIONS_SPEC.ADA
2. MPSC_CONTROL_SPEC.ADA
3. ADDRESS_MANIPULATION_SPEC.ADA
4. DMA_INTERRUPT_HANDLERS_IMPORT_STUB.ADA
5. MPSC_CONTROL_BODY.ADA
6. ADDRESS_MANIPULATION_BODY.ADA
7. SERIAL_COMMUNICATIONS_BODY.ADA
III. Application generation using a command procedure TEC_APPLICATION.COM
1. High Hertz Application Location
1. INTERFACE_LOW_AND_HIGH_PKG.ADA
2. HIGH_HZ_EXECUTIVE_SPEC.ADA
3. HIGH_HZ_EXECUTIVE_BODY.ADA
2. Low Hertz Application Location
1. INTERFACE_LOW_AND_BACKGROUND_PKG.ADA
2. LOW_HZ_EXECUTIVE_SPEC.ADA
3. LOW_HZ_EXECUTIVE_BODY.ADA
3. High Hertz Application Location
1. BACKGROUND_TASKS_EXECUTIVE_SPEC.ADA
2. BACKGROUND_TASKS_EXECUTIVE_BODY.ADA
3. BACKGROUND_TASKS_EXECUTIVE_PROC.ADA
IV SYSTEM GENERATION USING A COMMAND PROCEDURE TEC_SYSTEM.COM
The Build Command file, TEC_BUILD, is structured to keep the control of set
library in the individual generation command files. The user is advised to
use a bypass to avoid recompiling static portions of the TEC. The label
UNIT: is included in all the TEC command procedures for use as a bypass.
Once the Assembly routines imported from DECA were assembled, the UNIT:
label was moved past the Assemblies to a position just preceding the
TEC_SYSTEM batch invocation. Once the Sytem generation was complete, the
UNIT: label was moved past the TEC_SYSTEM batch invocation. Once the
Communication and I/O generation was complete, the UNIT: label was moved
past the TEC_IO batch invocation. Only the invocation of the TEC_APPLICATION
batch is needed to integrate the Applications.
1. System Build
The Ada compiler elaborates those packages defining global addresses and
general types. Every attempt has been made to package global definitions
such as memory mapped ports and general structure typing to the System step
in the TEC build process.
The packages in this step have been arranged with the specification and body
in the same file, where possible, for speed of compilation when changes
become necessary. There are currently five packages in the System Build
group:
1. The port representation declaration package, HW_ADDRESS_PKG,
contains the address declarations for the predefined port map (the actual
representations are contained in the individual packages of the I/O build
step).
2. The interrupt representation package, INTERRUPT_CONTROL_PKG,
contains the opcode assignments for the i80186 interrupt enable/disable
commands.
3. The interrupt vector assignment package, VECTOR_TABLE_PKG, defines
a record type which assigns the predefined interrupt address map.
4. The record type representation package, GLOBAL_PKG, contains
structure definitions for predefined data and control record types used at
the I/O build step and contains generic definitions for some indexing
functions.
5. The register representation package, INTERNAL_CONTROL_REG_PKG,
defines a record type which assigns the predefined register address map.
What few ASM86 requirements needed to ensure the effective utilization of
specific hardware features of the i80186 microcontroller are implemented at
the System build level:
1. The fixed point arithmetic import stub, MATH_UTILITY_PKG.ADA,
contains the declarations for the math functions written in ASM86, while the
fixed point arithmetic interface directives, DIVIDE.DRF and MULTIPLY.DRF,
provide the ASM86 subroutine references for functions in FP_DIVIDE.ASM and
FP_MULTIPLY.ASM.
2. The interrupt handler import stub, INTERRUPT_HANDLERS_IMPORT_STUB.ADA,
contains the declarations for the vectored interrupts written in ASM86, while
the interrupt handler interface directive, INTERRUPT_AHNDLERS_IMPORT.DRF,
provides the ASM86 subroutine references for functions in
INTERRUPT_HANDLERS_IMPORT.ASM.
2. System Package Descriptions
1. Hardware Address Representation Package -
The port structure of the TEC consists of five(5) Port base addresses and the
associated input, output, and control offset addresses:
1. 0000 -- Address base for Interrupt Vector Table
2. 3000 -- Address base for E2PROM
3. 4000 -- Address base for Internal Register Block
4. 7000 -- Address for base of Interface Board containing -
1. Muli Protocol Serial Controller register offset
2. Analog to Digital Controller offset
3. Discretes offset
4. Stepper offset
5. Counter offset
5. D000 -- Address base for ROM
2. Interrupt Representation Package -
1. Procedure SET_INTERRUPT_ENABLE_FLAG
2. Procedure CLEAR_INTERRUPT_ENABLE_FLAG
3. Interrupt Vector Record Type Assignment Package -
1. timer0 Interrupt Record Entry
2. timer1 Interrupt Record Entry
3. timer2 Interrupt Record Entry
4. dma0 Interrupt Record Entry
5. dma1 Interrupt Record Entry
6. int0 Interrupt Record Entry
7. int1 Interrupt Record Entry
8. int2 Interrupt Record Entry
9. int3 Interrupt Record Entry
4. Record Type Representation Package -
Those record types decided upon as representative of the I/O structure of the
TEC.
5. Register Representation Package -
Representations for control and data ports:
1. interrupt control
2. timer control
3. chip select control
4. dma control
6. Fixed Point Arithmetic Import Stub -
1. function FIXED_POINT_MULTIPLY
2. function FIXED_POINT_DIVIDE
7. Interrupt Handler Import Stub -
1. procedure HANDLE_HIGHHZ_INTERRUPT
2. procedure HANDLE_LOWHZ_INTERRUPT
V I/O GENERATION USING A COMMAND PROCEDURE TEC_IO.COM
The TEC I/O generation, one of three build steps, consists of compliation of
those packages which are afairly well defined by the selected Target
processor and memory partitioning design described in the Software Top Level
Design Document for the GE HMPT-500 Transmission Electronic Controller. This
Document provides a definition which may change during the development of the
TEC as new interface needs become apparent.
1. I/O Build
The Ada compiler elaborates those packages defining I/O protocols. I/O is
broken into four package groups, the Serial Group and the three Standard
Groups.
The interface packages in this step have been arranged with the specification
and body in the same file, where possible, for optimum speed of compilation
when changes become necessary. The Serial I/O Build froup is a direct import
from DECA. The ASM86 import DMAINTERRUPTHANDLERSIMPORT provides the context
management for DMA interrupts.
There are currently three packages and an assembly import stub in the Serial
I/O Build group, and fifteen packages in the Standard I/O Build group. Each
of the three Standard I/O groups consist of an Interface Package in one file,
an Import Package in two files, and an Output Package in two files.
2. I/O Package Descriptions
1. Serial I/O Group Packages -
Serial I/O Group consists of seven(7) Packages:
1. SERIAL_COMMUNICATIONS_SPEC
2. MPSC_CONTROL_SPEC
3. ADDRESS_MANIPULATION_SPEC
4. MPSC_CONTROL_BODY
5. ADDRESS_MANIPULATION_BODY
6. DMA_INTERRUPT_HANDLERS_IMPORT_STUB
7. SERIAL_COMMUNICATIONS_STUB
2. STANDARD I/O Package Group -
Standard I/O consists of three(3) Groups of Packages. Multiple types are
defined for TEC DATA in support of Ada's Boolean requirements that "a BOOLEAN
true assignment shall set the ZERO BIT false and shall set the SIGN BIT true"
and that "a BOOLEAN false assignment shall set the ZERO BIT true and shall
set the SIGN BIT false". This leads, in particular, to a TYPE declaration
for toggling the Watch Dog Timer, the Failure and Warning Lights, the Hex
Character Control Bits, and the MUX Input Control Bit. Individual Unchecked
Conversion functions are instantiated to support I/O for each of the required
TYPEs:
1. The Discretes Group
1. DISCRETES_INTERFACE_PKG
2. DISCRETES_INPUT_SPEC
3. DISCRETES_INPUT_BODY
4. DISCRETES_OUTPUT_SPEC
5. DISCRETES_OUTPUT_BODY
2. The Stepper Group
1. STEPPER_INTERFACE_PKG
2. STEPPER_INPUT_SPEC
3. STEPPER_INPUT_BODY
4. STEPPER_OUTPUT_SPEC
5. STEPPER_OUTPUT_BODY
3. The Counter Group
1. COUNTER_INTERFACE_PKG
2. COUNTER_INPUT_SPEC
3. COUNTER_INPUT_BODY
4. COUNTER_OUTPUT_SPEC
5. COUNTER_OUTPUT_BODY
3. I/O Processes
1. Serial I/O Group Packages -
Consult DECA.
2. Discretes Processes -
1. procedure DISCRETES_GET in package DISCRETES_INPUT_PKG
2. procedure DISCRETES_PUT in package DISCRETES_OUTPUT_PKG
3. procedure WATCHDOG_PUT in package DISCRETES_OUTPUT_PKG
4. procedure FAILURE_PUT in package DISCRETES_OUTPUT_PKG
5. procedure WARNING_PUT in package DISCRETES_OUTPUT_PKG
6. procedure CHARACTER_LATCH in package DISCRETES_OUTPUT_PKG
7. procedure CHARACTER_UNBLANK in package DISCRETES_OUTPUT_PKG
8. procedure GET_ALL_A_TO_D_INPUTS in package DISCRETES_OUTPUT_PKG
3. Counter Processes -
1. procedure ENG_COUNTER_GET in package COUNTER_INPUT_PKG
2. procedure TRANS_COUNTER_GET in package COUNTER_INPUT_PKG
3. procedure ENG_COUNTER_PUT in package COUNTER_OUTPUT_PKG
4. procedure READBACK_ENG_COUNTDOWN_PUT in package
COUNTER_OUTPUT_PKG
5. procedure TRANS_COUNTER_PUT in package COUNTER_OUTPUT_PKG
6. procedure READBACK_TRANS_COUNTDOWN_PUT in package
COUNTER_OUTPUT_PKG
4. Stepper Processes -
1. procedure STEPPER_GET in package STEPPER_INPUT_PKG
2. procedure STEPPER_PUT in package STEPPER_OUTPUT_PKG
VI APPLICATION GENERATION USING A COMMAND PROCEDURE TEC_APPLICATION.COM
Application generation consists of grouping applications into execution
levels. At each execution level the procedures and declarations are packaged
together into units with common resource needs. Applications Executives,
Function Bodies, and Procedure Bodies are developed as separate compilation
units.
This format allows the division of application development between two
classes of developer. An intimate knowledge of the system structure and the
data global to an implementation level provides meat for one class of
developer, the EC programmer analyst. An intimate knowledge of an
implementation level and the data local to an Applications Task provides meat
for the second class of developer, the EC systems analyst. This build step
is in general the least straightforward step in the build process and should
be delegated to an experienced EC systems analyst familiar with the
engineering systems controlled by the EC. The Separate units are
conveniently assigned to contract programmers.
1. Application Executive Description
The Applications Executives interface by means of packages which contain type
and variable declarations global to more than one application level but not
global to the EC. Application procedures and functions statically defined
for the Application by the design specification will in general appear in the
interface package. Only the procedures and functions which will be changed
as the Application Tasks change need be maintained Separately. If, for
example, the execution level consists of three applicaitons which interact by
shared parameters, the application executive might be specified as an
executive package TASK_EXECUTIVE_PKG containing:
package TASK_EXECUTIVE_PKG is
SOME_GLOBAL : SOME_TYPE ; -- An Executive Specification contains Variable
declarations
procedure PROCEDURE ; -- and Procedure and/or Function declarations which
are Global to
procedure FUNCTION ; -- all the Application Packages at this execution
level.
end TASK_EXECUTIVE_PKG ;
package body TASK_EXECUTIVE_PKG is
procedure PROCEDURE is separate ;
function FUNCTION is separate ;
package TASK1_PKG is procedure TASK1 ;
end TASK1_PKG ; package body TASK1_PKG is separate ;
package TASK2_PKG is procedure TASK2 ;
end TASK2_PKG ; package body TASK2_PKG is separate ;
package TASK3_PKG is procedure TASK3 ;
end TASK3_PKG ; package body TASK3_PKG is separate ;
end TASK_EXECUTIVE_PKG ;
2. Application Package Descriptions
1. High Hz Executive Processes -
This interrupt level will not be interrupted:
1. procedure NIT_INCR in package HIGH_HZ_EXECUTIVE_PKG
2. procedure NIT_DECR in package HIGH_HZ_EXECUTIVE_PKG
3. procedure STEER_COMMAND_INCR in package HIGH_HZ_EXECUTIVE_PKG
4. procedure STEER_COMMAND_DECR in package HIGH_HZ_EXECUTIVE_PKG
5. procedure STROKE_COMMAND_INCR in package HIGH_HZ_EXECUTIVE_PKG
6. procedure STROKE_COMMAND_DECR in package HIGH_HZ_EXECUTIVE_PKG
7. procedure TOGGLE_WATCH_DOG in package HIGH_HZ_EXECUTIVE_PKG
8. procedure WRITE_STROKER in package HIGH_HZ_EXECUTIVE_PKG
9. procedure WRITE_STEERER in package HIGH_HZ_EXECUTIVE_PKG
10. procedure WRITE_CHARACTER in package HIGH_HZ_EXECUTIVE_PKG
11. procedure MAP_DIRECTION_OF_STEER_COMMAND_NAME in package
HIGH_HZ_EXECUTIVE_PKG
12. procedure MAP_DIRECTION_OF_STROKE_COMMAND_NAME in package
HIGH_HZ_EXECUTIVE_PKG
13. procedure HIGH_HZ_EXECUTIVE in package HIGH_HZ_EXECUTIVE_PKG
2. Low Hz Executive Processes -
This interrupt level will be interrupted by the High Hz Executive:
1. procedure READ_MUX in package LOW_HZ_EXECUTIVE_PKG
2. procedure LOW_HZ_EXECUTIVE in package LOW_HZ_EXECUTIVE_PKG
3. Background Processes -
This interrupt level will be interrupted by any Interrupt, whether Executive
or Communication:
1. separate package body INTEGRATED_80186_FUNCTION_INITIALIZATION_PKG
in package BACKGROUND_TASKS_EXECUTIVE_PKG
1. procedure INITIALIZE_TIMERS
2. procedure INITIALIZE_INTERRUPTS
3. procedure INTEGRATED_80186_FUNCTION_INITIALIZATION
2. separate package body MEMORY_TESTS_PKG in package
BACKGROUND_TASKS_EXECUTIVE_PKG
1. procedure EPROM_TEST
2. procedure MEMORY_TESTS
3. separate package body BACKGROUND_TASKS_EXECUTIVE in package
BACKGROUND_TASKS_EXECUTIVE_PKG
About the Author, Ronald C. Alexander
Mr. Alexander received his BS in Mathematics from the University of the State
of New York in 1978 and his BS in Electrical Engineering from the University
of Portland in 1979. From 1973 to 1977, he served on submarines in the
Atlantic. During 1979, while at Bonneville Power Administration (BPA), he
developed a Nuclear Power Plant Utilization Simulator for use on the BPA's
CDC Computer. Since starting with the Department of Defense in 1980, he
developed numerous automatic test procedures using Hewlett-Packard ATS-1000
test systems at Naval Undersea Warfare Engineering Station (NUWES), Keyport,
WA, and in 1981 developed the NUWES ATS-1000 Users Course. From 1982 to 1984,
Mr. Alexander worked in the Large-Scale Integrated Device Evaluation Group of
the Transient Radiation Effects and System Generated Electromagnetic Pulse
Branch at Harry Diamond Laboratories, Adelphi, MD. From 1984 to 1991, Mr.
Alexander worked as a embedded software integration engineer at Intel Oregon
Site Systems Manufacturing, G.E. Ordnance Systems, Northrop Precision
Products Division, and BITE Inc. specializing in attitude and heading
reference systems.
@ resume