Tech Note for ADA Electronic Controller by Ronald C. Alexander, E.E.
(descriptions of GE proprietary material are by reference only)This Note released for GE Ordnance Systems presentation to IEEE Computer Society Meeting 10/87
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.
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
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.