Department of Computer Engineering

Chalmers University of Technology

Göteborg, Sweden

August 8, 1995

A Microcontroller-Based Development Platform for Regulator Applications

(En Microcontrollerbaserad Utvecklingsplatform för Regulatortillämpningar)

Carl F Trefil

Lars-Åke Johansson

Erik Hesslow

group 6210 Systems Engineering

Department of New Technologies

AB Volvo, Technological Development

The aim of this exam project was to investigate if it is possible to use a microcontroller-based hardware, BaseNode 167, as the hardware base for a development platform used for the designing and testing of regulators. The tools in the BSO/Tasking 80C166 tool chain were used to build and debug test applications. The O'Tool Executive and O'Tool IOS were used as in-target-computer support software. All the parts of the development platform were evaluated and necessary additional in-target-computer support software, CFT I/O Driver Package, was developed. The conclusion of the project is that the development platform is tricky to handle initially. The user must have a thorough knowledge of how to handle and utilise a microcontroller based hardware practically (or be willing to spend the time necessary to develop this skill). Nevertheless, the development platform may prove to be very powerful after a while. The knowledge, practices, and software developed during this project will hopefully make the use of the development platform a lot easier.

1. Useful hints when reading this paper *

2. The purpose of the project *

3. Problem formulation and restriction of the scope of the project *

4. The progress of the project *

5. A short description of the available parts of the development platform *

6. Knowledge, design practices, and software developed during the project *

7. Evaluation of the available parts of the development platform *

8. Is the microcontroller-based development platform suitable for the designing and testing of regulators ? (Conclusions) *

9. References *

Appendix A *

Appendix B *

Appendix C *

Appendix D *

Appendix E *

Appendix F *

Appendix G *

The structure of this paper is shown in Figure 1.

The terminology used in this paper is explained in Appendix E.

Earlier in their work a group called 6210 Systems Engineering (at the Department of New Technologies at AB Volvo, Technological Development) used PC computers when designing and testing regulator applications for use in various test vehicles.

A desire to implement these applications in a more realistic way, pointed at the need to use a microcontroller-based hardware. They had also an idea to use this microcontroller-based hardware environment as part of an actual development platform for regulators.

The purpose of this exam project is to investigate if these ideas are realistic.

The aim of this exam project is to investigate if it is possible to use a microcontroller-based hardware (from here on called ECU, Embedded Computation Unit) as the hardware base for a development platform used for the designing and testing of regulators.

At the outset of the project it was assumed that two other major parts were needed as well, to get a suitable development platform :

1) Application building tools, which can be used to build, load and debug the

2) In-target-computer support software, for example a real time kernel that supports

As a concrete test of the development platform, an AICC (Autonomous Intelligent Cruise Control) application is going to be implemented in the ECU. This application already exists in a version designed for PC. As this version has already been thoroughly tested, it is to serve as a template when developing the new microcontroller-based regulator application.

Finally all the hardware, application building tools and support software, which have been used, are going to be evaluated.

The already existing AICC application that is to serve as a template in this project, is an advanced form of cruise controller, which adapts the speed of the vehicle to the set speed and to the distance to the car in front. The cruise controller implemented in the application is to be used in buses or trucks, when driving on motorways and main roads.

This AICC application is the result of another exam project (refer to [18]).

The most important input signals to the cruise controller are the speed of the host vehicle, the distance to the vehicle in front and the differential speed between the two vehicles. Other input signals are fetched from the vehicle driver's pedals, the cruise control stick, the retarder stick and the time gap knob. Output signals are the desired accelerator and electric retarder levels.

The function of the regulator, which is embedded in the cruise controller, is to keep the real speed of the host vehicle as near the desired speed value as possible, as long as the real distance to the vehicle in front doesn't fall bellow the desired (safe) distance.

For test proposes, the cruise controller can also be manipulated by using the keyboard belonging to the PC in which it is executed. Input, output and regulator-internal signal values are, for the same reason, displayed on the PC screen.

The hope has been expressed that the described qualities of the old AICC application will be realised, and that the necessary in-target-computer support software, which isn't available on the market (for example an I/O driver package) will be implemented.

The development ECU BaseNode 167, developed at Mecel AB, is going to be used.

To build and debug the applications, the BSO/Tasking 80C166 tool chain is going to be used. A stand alone load program, viapc, has been delivered with the hardware from Mecel AB.

To make multitasking possible, the real-time kernel O'Tool Executive, which has been developed at Arcticus Systems AB, is going to be used. The O'Tool IOS package, from the same company, may possibly be used as a framework when realising the necessary I/O software.

At the time when this project was started, the knowledge of how to use the hardware, the support software and the application building tools was slight, nor were there any but dim ideas of where problems would arise. Therefore no strict time plan was drawn up. A first glance at the task indicated that detailed and extensive knowledge of the different parts was necessary.

Some of the problems that arose during the project, the approximate points in time when they arose, and the approximate time spent on solving each problem, are listed in the table below. The different stages of the project are also indicated here:

BaseNode 167 is a development ECU (Embedded Computation Unit), developed at Mecel AB.

The standard version of BaseNode 167 has two printed circuit boards (pcb) as major physical components:

1) The general purpose Controller Board, which contains the microcontroller

2) The I/O Board, which is adapted to the customer's specific needs and which

The Controller Board and the I/O Board are connected with three inter-board connectors.

A custom-made version of the ECU is used in this project. Due to the desired set of I/O connections, the I/O Board has been supplemented with an additional circuit board (not shown in Figure 3) where some of the signal conditioning circuits have been placed.

The Controller Board of BaseNode 167 contains the following physical units:

1) A microcontroller chip.

2) Two RAM memory chips, with the total size 256 kb.

3) Two flash programmable ROM memory chips (below referred to as "flash

4) An I/O interface (coupled to the inter-board connectors).

The subset of microcontroller qualities, which can be utilised by the microcontroller programmer when working with the ECU, is among other things determined by

1) ...how the address and data parts of the external bus are coupled to the

2) ...how the physical memory units are mapped to the logical address space. This

3) ...how the signal conditioning circuits for digital I/O, analog I/O (analog input and

4) ...in which mode the microcontroller is started. The appropriate mode can be

The heart of the ECU is the microcontroller C167CW from Siemens. The microcontroller is supplied with a 16 MHz signal, which controls the CPU clock frequency.

The general system configuration of the microcontroller is normally set by the execution of the C-start function at the beginning of the execution of the application. A default C-start function is delivered in a C-start file along with the application building tools. This file has to be adapted to the specific needs of the ECU, of which the microcontroller is a part. An adapted version, called "bn167_cs.s", is found in directory CALLE\MECEL\CSTART.

The external bus interface configuration of the microcontroller is determined by the states of the port P0 pins at power up reset. In this particular case these states are achieved by external pulldown resistors, which have been placed on the Controller Board. The result of this configuration is, among other things , that the bus mode is non-multiplexed, that the bus data width is 16 bits, and that no more than 5 Mbyte of memory space can be addressed.

Using a jumper on the I/O Board (refer to the sections called "Requirements when using the..." in Appendix C and D respectively), the microcontroller can be configured to start in two different modes:

1) Bootstrap Loader Mode, which implies that the bootstrap function of the

2) Normal Mode, which implies that the microcontroller starts to execute the code

For more information about the microcontroller refer to the section called "The microcontroller C167CW".

The version of BaseNode 167 used in this project has only a 512 kbyte physical memory space, of which 256 kbyte is RAM and 256 kbyte is flash memory.

When the stand alone load program viapc is to be used, flash memory sector 0 (32 kbyte of the available ROM memory) is reserved for the Base Block, which contains the code and constant data of the monitor part of viapc.

As the ROM memory in this case must be mapped (by hardware) to the lower part of the logical memory space (refer to the section called "Requirements when using the load program" in Appendix D), this sector corresponds to the memory range 00000h - 07FFFh.

The memory range corresponding to the flash memory sectors 1-7, can (with some restrictions, refer to Appendix D) be utilised to store the Application Block, which contains the code and constant data of the actual application.

When the memory is used as described in the paragraph above, the map between physical and logical memory space, appears as in Figure 2. For the sake of completeness, the figure has been supplemented with a view that relates these memory spaces to the way the microcontroller represents code and data addresses.

When an application is to be debugged, using a debugger from BSO/Tasking, the RAM memory must be mapped (by hardware) to the lower part of the logical memory space (refer to the section called "Requirements when using the debugger" in Appendix C).

The 2 kbyte internal RAM (IRAM) of the microcontroller, the internal memory of the on-chip CAN module and some reserved areas of the microcontroller, correspond to the memory range 0EF00h - 0FFFFh. When the ROM memory is mapped (by hardware) to the lower part of the logical memory space, this range overlaps a small part of the flash memory sector 1 (refer to Figure 2). This small part of flash memory is (or should be) hidden from the microcontroller and thus this part of the flash can't be used to store code and constant data.

In general, the I/O Board of BaseNode 167 contains the following physical units:

1) Power supply circuits.

2) Signal conditioning circuits for digital, analog, and capture/compare I/O.

3) Physical communication interface for RS232.

4) Physical communication interface for CAN.

5) Three inter-board connectors, which are used to couple the Controller Board and

The I/O Board is adapted to the customer's specific needs, concerning:

1) The number of units of each type of microcontroller I/O connections that is

2) The supply voltage.

The requirements on the configuration of the I/O Board used in this project, is shown in the table below :

Due to these requirements, the I/O Board has been supplemented with an additional circuit board (not shown in Figure 3) where some of the signal conditioning circuits have been placed.

The required I/O connections have been mapped to the I/O Board connection pins as shown in Figure 3.

The heart of the ECU is the microcontroller C167C from Siemens, or to be more precise, the engineering sample C167CW, which has several functional problems. For further information about these functional problems, refer to the errata sheet for C167CW [6].

Serial production of the improved variant C167CR was started in December 1994, after the start of this project.

Note the following qualities of the microcontroller:

* 16-bit CPU with four-stage pipeline, which gives a 125 ns minimum instruction

* The memory space is configured in a Von Newmann architecture, which means

* Multiple fast internal buses.

* Flexible external bus interface.

* 2 kbyte of fast accessible internal RAM.

* Interrupt system with 16 interrupt priority levels. Each interrupt priority level can

* 8-channel Peripheral Event Controller (PEC) with 250/563 ns typical/maximum

* Numerous on-chip peripheral subsystems (refer to Figure 4).

* On-chip CAN module, which implements the CAN 2.0 ISO standard for a physical

* Individual addressable I/O port pins.

The system modularity of the microcontroller is shown in Figure 4.

As shown in Figure 4, the microcontroller contains the following modules :

* CPU Core, which is the base of the controller.

(System Resources:)

* Peripheral Event Controller (PEC), which contains 8 channels that are used for

* Interrupt Controller, which administers the interrupts from all interrupt sources

* Bus Controller (BUSCTL), which contains the External Bus Controller (EBC).

* Clock generator (OSC), which filters the externally supplied clock signal to

(Peripheral Subsystems:)

* Parallel Ports (P0...P8), which have a width of 4 -16 bits, and which provide 111

* Asynchronous/Synchronous Serial Channel (ASC0).

* High-speed Synchronous Serial Channel (SSC).

* General Purpose Timer Units GPT1 and GPT2, which contain the general

* Watchdog Timer (WDT), which can be used as a fail-safe mechanism.

* Capture/Compare Units (CAPCOM1 and CAPCOM2), which contain 16 channels

* Pulse Width Modulation Unit (PWM), which contains 4 channels that are used to

* A/D Converter (ADC), which contains 16 analog input channels.

(Modules connected via XBUS:)

* CAN module, which contains 15 channels, of which one is input only.

The BSO/Tasking 80C166 tool chain is used to build and debug applications to be executed in microcontrollers belonging to the SAB 80C166 or C16x microcontroller families from Siemens.

Included in this tool chain is the following type of tools:

There are also some other tools included in the tool chain. Two of these, the Make Utility and the Steering Program, are described in the section called "Using the tool chain: calling tools". The library manager and the disassembler is of no interest in this context.

The tools in the tool chain are controlled by the use of options (for the tools which have got a more expressive and language-like set of options these are called controls). These options are supplied to the respective tool by writing them as command line arguments when calling the tool. This procedure is probably well known to you.

In the following subsections the purpose of the possible options for the tools in the chain are described briefly.

By default c166

* ...adapts the generated assembly code to the memory model Small.

* ...makes almost all possible code optimisations. These are based on both

* ...instructs the assembler to minimise the amount of symbolic information

* ...keeps the amount of information presented to the user as limited as possible.

You have to adjust the default behaviour of c166, when, for example, you want to

* ...adapt the generated assembly code to one of the memory models Tiny,

* ...optimise the generated assembly code in some other way.

* ...adapt the output file to create an application component, which is suitable for

* ...adapt the generated assembly code to a special type of library.

* ...make the interrupt handling more robust.

* ...get more information about the compilation.

The adjustments are accomplished by the use of compiler command line options.

If you are interested in learning a usable set of compiler options, study for example the macro "CFLAGS" in the makefile for the AICC application ( refer to Appendix G).

When designing an assembly source file, it is easy to make it more flexible by using conditional assembly. This is realised by inserting assembly language macro instructions in the code and preprocess the code using m166. By supplying a macro definition as a command line argument when calling m166, the user is able to include or exclude portions of the assembly code.

In practice just a few assembler controls are used as command line arguments. The controls that are used in this way, deal with the information about the assembly process which is presented to the user. Most of the assembler controls are instead inserted directly into the assembly code. This is for example done by c166, when generating assembly code.

Most of the controls needed to steer the link stage of l166 , affect which libraries to link to the supplied relocatable object files and the information about the link process which is presented to the user.

The amount of controls needed to steer the locate stage of l166 is by far the largest, compared to the amount used for the other tools in the chain. These controls are used to in order to

* ...couple link files containing interrupt procedures to interrupt vectors in the CPU.

* ...define which memory ranges that correspond to ROM memory (used for

* ...reserve memory ranges where no code or data should be placed.

* ...specify where the logically defined relocatable code and data sections shall be

* ...regulate the amount of information from the allocation process presented to the

No options were needed for the output format utilities.

The number of options/controls needed to steer the tools are, in most cases, too large to be put directly on the command line, when calling the respective tool. Therefore it is always possible to supply the options/controls via a steering file (an ordinary text file), by supplying the file name on the command line. The syntax of these files differs slightly, but as a rule of thumb it is always unwise to write more than one option/control on a single row in a steering file.

The stand alone load program viapc makes it possible to download applications into BaseNode 167. Here is a short description of this tool:

O'Tool Executive is a multitasking real-time kernel for microcontroller based environments. It is based on Ada concepts.

The real-time kernel version, which is used in this project, supports

1) parallel activities (processes), which when mentioned in this paper are referred

2) activation, abortion, and termination of tasks.

3) co-operation (synchronisation and communication) between different tasks

4) communication between interrupt handlers and tasks according to the mailbox

5) resource handling. A resource is considered to be an entity which can be used

6) dynamic memory. Different memory partitions are left to be managed by O'Tool

7) time handling. O'Tool Executive maintains an internal clock, which must be

8) exceptions. When O'Tool Executive is unable to deliver a service, an

Some of the services delivered by the real-time kernel are illustrated in Figure 5.

More details of this particular version of O'Tool Executive are presented in Appendix B.

The O'Tool IOS (O'Tool Input and Output System) package promotes a well structured, layered approach when designing an I/O driver, which implements an I/O operation by controlling the corresponding I/O device.

It also provides a Generic File and Device Access Interface, which conforms to the standard UNIX device and file access interface, a Device Management Interface, and an I/O Controller Interface.

When supported by O'Tool IOS, an I/O driver is supposed to be composed of two layers. The lowest layer is the I/O Controller layer, which is meant to manipulate the hardware device directly. The layer above is the Device Handler layer, which is meant to interpret the incoming data and prepare the outgoing data.

The relations between the above-mentioned interfaces and layers are shown in Figure 6.

Before using a driver to perform an I/O operation, a driver object must be created, i.e. a unique "copy" of the driver is produced and storage is reserved for the internal data that is needed by this "copy". This creation can be performed in the application by using the Device Management and the I/O Controller interfaces.

Furthermore the driver object must be initiated, i.e. the object is adapted to the specific operation that shall be performed, and it is coupled to the specific device that it is meant to control (if several devices of the same type exist).

A link must also be created between the application and the driver object. This is accomplished by opening an access path to the driver object in question. The path is identified by an unique file descriptor.

The initiation, the opening of an access path, and the following use of the driver object to achieve I/O can be performed in the application by calling the Generic File and Device Access Interface.

A driver object is composed of a Device Handler object and an I/O Controller object, which correspond to the two layers of the driver.

The routines necessary to create a driver object are:

* otool_IOC_NEW (...) , which belongs to the I/O Controller Interface, and

* otool_DEV_NEW (...) , which belongs to the Device Management Interface,

* otool_IOC_ATTACH (...) , which belongs to the I/O Controller Interface, and

Among other things the Device Handler and I/O Controller objects are given unique names, whose extensions are specified by calling the application, when the various objects are created. The base parts of the names are the epithets of the specific Device Handler and I/O Controller layers respectively.

The name of the Device Handler object is used to identify the driver object, when it has been created. This name is used when opening a path to the driver object.

The following routines belong to this interface:

* otool_OPEN (...) , opens an access path to a driver object and the

* otool_IOCTL (...) , initiates a created driver object and its device.

* otool_READ (...) , reads data from a device via the driver object.

* otool_WRITE (...) , writes data to a device via the driver object.

* otool_CLOSE (...) , deletes an opened access path to a driver object and its

When the application calls the last four above-mentioned routines, the device you want to manipulate is specified by using a unique file descriptor, which is fetched by using 'otool_OPEN'.

If you want to use the high level file descriptor controlled I/O routines, which are implemented in the C-library of c166 and whose function prototypes are declared in the include file "stdio.h", you have to couple them to a lower I/O layer. This is due to the fact that these I/O routines do not have any proper connection to any hardware devices. O'Tool IOS can be used as a framework when implementing the I/O drivers of the necessary lower I/O layer.

The connection between the C-library and the lower I/O layer is made via simple adapter functions, as shown in Figure 7.

However, the use of I/O routines from the C-library is not recommended, due to the amount of nestled function calls that are generated, when performing an I/O operation.

The findings of this project can be divided into four major parts:

1) Detailed knowledge of the requirements when building applications of

2) A makefile design practice, which is a suggestion of how to design a makefile

3) The developed support software additions, which consist of CFT I/O Driver Package.

4) An adapted version of the AICC application software, which is designed in

Those who are used to the protected programming environment of a personal computer (or work station), might be surprised when confronted with some aspects of the microcontroller-based programming environment of this project. Among other things it is much more difficult to get a simple test application running. Often, in the PC programming environment, the only thing you have to do when you want to build your application is to call the compiler, using a list of the files to compile as an argument. All the parts are compiled, linked together, and located without any further specifications made by the user. When you want to run your executable program just write the name of it, and the operating system takes care of the necessary loading of the program into the memory and then starts its execution. When you want to communicate with the outer world the libraries connected to the compiler often include the necessary communication routines. Otherwise you just write the name of a suitable, commercially acquired, communication library among the other file names on the command line, when calling the compiler. You will then have access to a number of powerful communication tools.

The above scenario is, as you well know, described in rather too positive terms. Nevertheless, it will serve as a good reference, contrasting the situation when you work with the clean, microcontroller-based programming environment of this project. In this case the meaning of "clean" is that you have not got any application building tools, which are adapted to the specific ECU that is used, and not much in-target-computer support software.

When you confront this clean environment, you will soon realise that some of the application building tools that are used need a complex set of instructions to function, especially the instruments used to link and locate the program code. This is due to the fact that

1) ...the application building tools of the BSO/Tasking 80C166 tool chain are

2) ...the microcontrollers (for example the C167CW used in this project), for which

The problem of how to steer the application building tools is discussed in the subsections below. The problem generated by the lack of in-target-computer support software, is discussed in the section called "How to perform I/O in an application".

As mentioned above, the BSO/Tasking 80C166 tool chain is used in this project to build and debug the applications.

This tool chain is briefly described in the section called "The BSO/Tasking 80C166 tool chain".

To build an application and generate a load file, which can be downloaded to the microcontroller of the ECU in some way or another, a lot of tools of the BSO/Tasking tool chain must be called. If there are a lot of source files and libraries to be processed and merged, it will be far too time-consuming to call the tools manually. Add to this the extensive, but nevertheless necessary, use of command line instructions to some of the tools, and the problem of keeping the result files from the tools up-to-date, without going through the whole application building process every time you change a detail in some part of the source code.

Thus it was soon realised that a tool was needed to administer the application building process. Two tools, which have the potential to fit this need, are included in the BSO/Tasking tool chain:

Perhaps, someone gets the idea to use PC bat files when building applications. This might be suitable for small applications, but all services that may be offered by a bat program (and a lot more) can be performed by mk166.

The need for a tool giving support to the task of administering the generated files when building an application, became obvious almost immediately during the work with the microcontroller-based programming environment. mk166 gives the necessary support.

mk166 is controlled by a makefile (an ordinary text file) supplied by the user. In this file the user defines the hierarchy of files which must be created, before the final load file can be generated. The user also specifies how the various files in the hierarchy are generated.

The contents of a steering file, the name of which is supplied at the command line when calling a tool in the makefile, can be written directly in the makefile. mk166 makes a temporary file out of the specified options/controls, and feeds this file to the tool when calling it. In this way all information about the application building process can be gathered in one single file.

Together with a close in-file documentation (including a header page and plenty of comments), a uniform structure in all makefiles, and an extensive use of macros, the use of makefiles becomes a powerful way of keeping track of the application components.

Here are some of the advantages:

* It is relatively easy to keep the application up-to-date, when changes are

* It is easy to inspect which application components that are used to build an

* It is easy to survey the structure of the application, in spite of the size of the

* It is easy to emphasize differences in structure between applications.

* It is easy to emphasize differences in the way applications are built. For instance,

* Re-usability is high, because of the uniform makefile structure.

The test applications, which were used to test the drivers of CFT I/O Driver Package, typically contain the application components shown in Figure 8.

A more general application can be built from a similar set of application components. However, the number of drivers, belonging to CFT I/O Driver Package (refer to the section called "Using CFT I/O Driver Package"), can vary between 1 and 6.

When building one of these test applications, the majority of the application components are compiled/assembled and then linked into one single relocatable link file.

The rest of the modules are either assembly code modules or relocatable link files, which each contains a low level interrupt handler (a task procedure that implements a Siemens Interrupt Task). After the assembly code modules have been assembled and linked into a relocatable link file each, all these application components are merged with the rest of the application during the locate stage. The low level interrupt handlers are also coupled to their respective interrupt vectors during this stage.

When building a more general application, which contains several I/O drivers, it is wise to link C code modules belonging to a single driver into a separate relocatable link file. This file is merged with the rest of the application during the locate stage. This gives the makefile a better structure.

The information flow generated, when building one of these test applications, has roughly the appearance shown in Figure 9.

To build and administer a test application, a makefile structure as shown in Figure 10 is appropriate.

If you are interested in learning about the details of how to write makefiles, refer to the makefile templates in Appendix F, or refer to the makefile for the AICC application (Appendix G).

It is quite easy to produce makefile templates. Different makefile templates are needed for applications with different general structures and for the different ways of building the applications.

There is one problem, though. Especially when you are expanding an old application (increasing code size, adding more I/O drivers, using additional C library services etc.), there is always a risk that the controls for steering the locate function become inadequate. This will make the locate function unable to allocate all code and data sections correctly. For the inexperienced user, this failure of the tool chain may be very time-consuming to correct.

The C library which belongs to c166, includes a minimum amount of the routines that are suggested in the ANSI standard. The supplied routines are only a portion of the functions which are suggested to have their function prototypes declared in the include files "stdlib.h", "stdio.h", "math.h" and "string.h". On the surface this seems to be all one needs to build sophisticated applications. There is, however, a problem, which is hard to solve for the inexperienced microcontroller programmer. The powerful functions declared in "stdio.h" have no bottom, in the sense that, when an actual I/O operation is to be performed, they call a dummy function. There is one such function for reading and another one for writing. The result is that all the high level file descriptor controlled I/O functions you normally have access to in a PC programming environment are useless, unless you have bought a complete I/O library, which can realise the functions needed in this upper I/O layer, defined in the C library of c166.

In this project there was no library containing the necessary lower layer I/O routines available. Two possible solutions to this problem existed:

1) To implement each different type of I/O operation as tightly as possible, by

2) To design a general I/O package, which gives a uniform interface to the various

Since the purpose of this project partly was to design a development platform based on BaseNode 167, the second solution was chosen. By choosing this alternative, the opportunity was given to test the O'Tool IOS package as a framework for the I/O drivers, which were to be implemented.

If you are interested in finding out how this choice worked out, please refer to the section called "Evaluation of the in-target-computer support software".

In this section the use of the developed package of I/O drivers, CFT I/O Driver Package, will be explained. Just a minimum of details of how the drivers work are included. When there is an obvious risk of using an I/O driver incorrectly, details are supplied to explain how the driver works internally.

The source files of the various I/O drivers are found in their respective sub-directories in the directory CALLE\IO_C167.

If you not are careful, there is always a risk that different program parts will interfere with each other. Potential sources of errors are:

1) Two program parts try to use the same resource (e.g. a timer unit) as if they

2) Two program parts make erroneous initiations of a shared resource (e.g. a CAN

3) A time critical interrupt-driven program part is disturbed by the other interrupts

It is therefore necessary to specify clearly which resources and interrupts that a distinct small program part requires. This is made below, when each type of I/O driver is presented. It is also helpful to make a summary of the total use of an entire application.

NOTE that the routines, which are used for creation and initiation of driver objects of a specific I/O driver, are not reentrant. Thus only one task a time should be able to call the initiation and creation routines of the I/O driver in question.

The described driver is called "ai_dev" (which is also the name of the Device Handler layer it contains).

"ai_dev" is used to measure analog signal levels.

Due to the difference in resources used, when performing analog input and analog output, these operations have been implemented as two separate I/O drivers.

* The Device Handler and I/O Controller layers of the driver are implemented in the

* The assembly file "ai_int.s" contains a low level interrupt handler for the analog

* Two out of four data structures needed when creating a driver object, have to be

* The files "macro.q" and "model.q" are needed when macro preprocessing

The driver supports the A/D Converter (ADC) of the microcontroller C167CW . Since the "W" version is an engineering sample of the C167C circuit, it has several functional problems. Therefore the more advanced functions of the ADC module cannot be used by the I/O Controller layer.

No error detection mechanisms in the module are supported by the driver.

The I/O driver uses the end-of-conversion interrupt generated by the ADC module. The interrupt is connected by hardware to interrupt vector No. 28h. The CPU interrupt level that is used is defined in the above-mentioned include file "ai_ioc.h". The low level interrupt handler, defined in "ai_int.s", must be called when an interrupt occurs.

Two out of four data structures needed when creating a driver object, have to be supplied from the application. Thus one structure of the type 'ai_ioc_IOCB_TYPE' and one of the type 'ai_dev_DCB_TYPE' must be defined for each object which is to be created.

The I/O driver supports the parallel use of up to 16 analog input channels and their corresponding driver objects. The Device Handler object of a driver object must be created before its I/O Controller object.

A call to the routine 'ai_ioc_init' must be made before any driver objects are created.

The name of the Device Handler object ("ai_dev", plus the specified extension) is used when opening a path to the corresponding created I/O driver object.

When using the I/O Controller Parameters, the user is able to influence

1) ...the conversion timing:

2) ...which port P5 pin (No. 0...15) to measure.

Default settings are: t_cc = 32 *TCL, t_sc = 1 *t_cc and that P5.0 is measured.

A call to the routine 'ai_channel_init' must be made after each separate driver object has been created and its parameters have been set to the desired values.

This is done via the Generic File and Device Access Interface, as the last step of the initiation procedure for each driver object.

When calling the read operation via the Generic File and Device Access Interface, an A/D conversion of the voltage, on the port P5 pin belonging to the specified driver object, is initiated.

The result of the A/D conversion is returned as a floating point value ( of the type 'float' ), which is put directly into the input buffer. Thus the total size of the input buffer, which is provided by the caller, must be equal to or larger than the size needed to store a variable of the type 'float' (4 bytes). You have to use a type cast in the application to get the floating point value out of the input buffer.

The result is normated to the range 0-5 V.

No write-operation is implemented in this I/O driver.

The described driver is called "ao_dev" (which is also the name of the Device Handler layer it contains).

"ao_dev" is used to output analog signal levels.

Due to the difference in resources used, when performing analog input and analog output, these operations have been implemented as two separate I/O drivers.

* The Device Handler and I/O Controller layers of the driver are implemented in the

* The assembly file "ao_int.s" contains a low level interrupt handler for the analog

* Two out of four data structures needed when creating a driver object, have to be

* The files "macro.q" and "model.q" are needed when macro preprocessing

The driver supports the Pulse Width Modulation Unit (PWM) of the microcontroller C167CW . The driver uses the PWM module to generate analog output values.

The I/O driver uses the output-value-accepted interrupt generated by the PWM module. The interrupt is connected by hardware to interrupt vector No. 3Fh. The CPU interrupt level that is used is defined in the above-mentioned include file "ao_ioc.h". The low level interrupt handler, defined in "ao_int.s", must be called when an interrupt occurs.

Two out of four data structures needed when creating a driver object, have to be supplied from the application. Thus one structure of the type 'ao_ioc_IOCB_TYPE' and one of the type 'ao_dev_DCB_TYPE' must be defined for each object which is to be created.

The I/O driver supports the parallel use of up to 4 analog output channels and their corresponding driver objects. The Device Handler object of a driver object must be created before its I/O Controller object.

A call to the routine 'ao_ioc_init' must be made before any driver objects are created.

The name of the Device Handler object ("ao_dev", plus the specified extension) is used when opening a path to the corresponding created I/O driver object.

When using the I/O Controller Parameters, the user is able to influence

1) ...on which port P7 pin (No. 0...3) to output the analog value.

By default port pin P7.2 is used.

A call to the routine 'ao_channel_init' must be made after each separate driver object has been created and its parameters have been set to the desired values.

This is done via the Generic File and Device Access Interface, as the last step of the initiation procedure for each driver object.

When calling the write operation via the Generic File and Device Access Interface, a change of the analog output voltage, on the port P7 pin belonging to the specified Device Handler object, is initiated.

The desired output value is specified as a floating point value (of the type 'float'), which the user puts directly into the output buffer. This is done by the use of type casts. The total size of the output buffer, which is provided by the caller, must be equal to the size needed to store a variable of the type 'float' (4 bytes).

The desired output value must be within the range 0-5 V.

No read-operation is implemented in this I/O driver.

The described driver is called "dio_dev" (which is also the name of the Device Handler layer it contains).

"dio_dev" is used to measure and output digital signal levels.

* The Device Handler and I/O Controller layers of the driver are implemented in the

* Two out of four data structures needed when creating a driver object, have to be

The driver supports the digital ports of the microcontroller C167CW.

The driver does not use any interrupts.

Two out of four data structures needed when creating a driver object, have to be supplied from the application. Thus one structure of the type 'dio_ioc_IOCB_TYPE' and one of the type 'dio_dev_DCB_TYPE' must be defined for each object which is to be created.

The I/O driver supports the parallel use of all digital port pins (and their corresponding driver objects) that can be manipulated using this driver. The Device Handler object of a driver object must be created before its I/O Controller object.

The driver requires no initiations before the driver objects are created.

The name of the Device Handler object ("dio_dev", plus the specified extension) is used when opening a path to the corresponding created I/O driver object.

When using the I/O Controller Parameters, the user is able to influence

1) ...which port pin to measure/affect : Port No. 2, 3, 5, 7 and 8 can be selected.

2) ...if the port pin is to be configured as input or output ( 0==>input, 1==>output ) .

3) ...if the pin driver circuit is to have a "push/pull" or "open drain" configuration

Default settings are: port pin P2.0 is used, input configuration, and "push/pull" configuration.

In the cases where just the input- or/and "push/pull"-alternative are available, the corresponding parameter settings are irrelevant.

When using the Device Handler Parameters, the user is able to influence

1) ...if the logical port value is to be inverted when reading ( 0==>no inversion,

2) ...if the logical port value is to be inverted when writing.

By default the input values are inverted and the output values are not.

A call to the routine 'dio_pin_init' must be made after each separate driver object has been created and its parameters have been set to the desired values.

This is done via the Generic File and Device Access Interface, as the last step of the initiation procedure for each driver object.

When calling the read operation via the Generic File and Device Access Interface, the signal level on the port pin belonging to the specified driver object, is immediately read.

The logical value corresponding to the result of the read op. is, after a possible inversion, returned as a 'char' value, which is put directly into the input buffer. Thus the total size of the input buffer, which is provided by the caller, must be equal to or larger than one byte.

The 'char' value in the input buffer has the value 0, if a logical FALSE was read, otherwise it has the value 1.

When calling the write operation via the Generic File and Device Access Interface, the signal level corresponding to the specified logical value is, after a possible inversion, immediately generated on the port pin belonging to the specified driver object.

The desired output value is specified as a 'char' value, which the user puts directly into the output buffer. The total size of the output buffer, which is provided by the caller, must be equal to one byte.

If the value of the 'char' variable in the output buffer is 0, it is treated as a logical FALSE, otherwise it is treated as TRUE.

The described driver is called "cap_dev" (which is also the name of the Device Handler layer it contains).

"cap_dev" is used to measure digital signal edge frequencies.

* The Device Handler and I/O Controller layers of the driver are implemented in the

* The assembly file "cap_ovfl.s" contains a low level interrupt handler for the digital

* An assembly file, containing a low level interrupt handler, has to be added for

* Two out of four data structures needed when creating a driver object, have to be

* The files "macro.q" and "model.q" are needed when macro preprocessing

The driver supports the Capture/Compare Unit CAPCOM2 of the microcontroller C167CW. The driver also uses the timers T6 and T8.

These resources are used to measure the digital signal edge frequencies.

The I/O driver uses the timer-overflow interrupt generated by the timer T8. The interrupt is connected by hardware to interrupt vector No. 3Eh. The low level interrupt handler, defined in "cap_ovfl.s", must be called when this interrupt occurs.

In addition to this, the I/O driver utilises the edge-detected interrupt from each capture/compare channel that is used. The interrupt vectors 36h and 37h are connected to the capture/compare channels corresponding to port pin P8.6 and P8.7, respectively. The low level interrupt handlers, defined in "cap_p8_6.s" and "cap_p8_7.s", must be called when the equivalent interrupt occurs.

The same interrupt priority level is used for all interrupts used by this driver. This interrupt priority level is defined in the above-mentioned include file "ai_ioc.h".

NOTE that this level has to be one of the highest used in the specific application, otherwise the driver will be disturbed and incorrect frequency values will be returned to the application !

A suitable interrupt group level is automatically given to each interrupt used.

Two out of four data structures needed when creating a driver object, have to be supplied from the application. Thus one structure of the type 'cap_ioc_IOCB_TYPE' and one of the type 'cap_dev_DCB_TYPE' must be defined for each object which is to be created.

The I/O driver supports the parallel use of up to 3 capture/compare channels and their corresponding driver objects. The Device Handler object of a driver object must be created before its I/O Controller object.

A call to the routine 'cap_ioc_init' must be made before any driver objects are created.

The name of the Device Handler object ("cap_dev", plus the specified extension) is used when opening a path to the corresponding created I/O driver object.

When using the I/O Controller Parameters, the user is able to influence

1) ...which port pin to measure: Port No. 7 and 8 can be selected. Which and how

2) ...if positive, negative or both pos. and neg. transitions are to be detected (

3) ...the total clock prescaler (relative the CPU clock) for the time measuring unit

Default settings are: Detection of positive edges at port pin P8.6 with the total prescaler 100 * 4.

NOTE that when the driver object is initiated, by calling 'cap_channel_init', the parameter value affects the clock prescalers for all created I/O Controller objects.

A call to the routine 'cap_channel_init' must be made after each separate driver object has been created and its parameters have been set to the desired values.

This is done via the Generic File and Device Access Interface, as the last step in the initiation procedure for each driver object.

When calling the read operation via the Generic File and Device Access Interface, the digital signal edge frequency on the port pin, belonging to the specified driver object, is immediately calculated from the last measurement made.

The result of the calculation is returned as a floating point value ( of the type 'float' ), which has been put directly into the input buffer. Thus the total size of the input buffer, which is provided by the caller, must be equal to or larger than the size needed to store a variable of the type 'float' (4 bytes). You have to use a type cast in the application to get the floating point value out of the input buffer.

The maximum and minimum frequencies that can be measured depend on the chosen clock prescaler:

The maximum correctly measured frequency cannot in practice be greater than about 1000 Hz, because of restrictions imposed by the real time kernel O'Tool Executive.

NOTE that in the following cases the returned digital signal edge frequency value may be incorrect:

1) The value 0.0 is returned, if the first frequency measurement has not been

2) The largest possible value that can be measured is returned, if the frequency is

3) The most recently measured value that was in range is returned, if the frequency

No write-operation is implemented in this I/O driver.

The described driver is called "asc_dev2" (which is also the name of the Device Handler layer it contains).

"asc_dev2" is used to perform the following asynchronous serial communication operations:

1) To filter the in-coming bytes so that only string messages, by default consisting

2) To output strings of any length.

This driver is, in the adapted AICC application, used to send commands to and receive data from the ODIN 2 distance sensor.

* The Device Handler and I/O Controller layers of the driver are implemented in the

* The assembly files "t_ascrx.s" and "t_asctx.s" contain low level interrupt handlers

* All the four data structures needed when creating the driver object, are in this

* The files "macro.q" and "model.q" are needed, when macro preprocessing

The driver supports the Asynchronous/Synchronous Serial Channel (ASC0) of the microcontroller C167CW.

No error detection mechanisms in the ASC0 module are supported by the driver.

The I/O driver uses the end-of-reception and end-of-transmission interrupts generated by the ASC0 module. The interrupts are connected by hardware to interrupt vector No. 2Bh and 2A, respectively. The CPU interrupt level that is used is defined in the above-mentioned include file "asc_ioc.h". When a receive interrupt occurs the low level interrupt handler, defined in "t_ascrx.s", must be called, and when a transmit interrupt occurs the low level interrupt handler, defined in "t_asctx.s", must be called.

NOTE that the same interrupt priority level must be assigned to the interrupts used by this driver. There is no restriction on the group levels of these interrupts.

All the four data structures needed when creating the (only) driver object, are in this case supplied from the driver. Thus the structures 'asc_ioc_type', 'asc_ioc_iocb', 'asc_dev_type' and 'asc_dev_dcb' have to be declared external in the application using the corresponding O'Tool IOS types for all of them. The interrupt handler 'asc_dev_ISR' also have to be declared external.

The I/O driver supports the use of the ASC0 module and its corresponding driver object. No parallel use of driver objects can be made ! The Device Handler object of the driver object must be created before its I/O Controller object.

The driver requires no initiations before the (only) driver object is created.

The name of the Device Handler object ("asc_dev2", plus the specified extension) is used when opening a path to the corresponding created I/O driver object.

When using the I/O Controller Parameters, the user is able to influence

1) ...if 8- or 9-bit data is to be used.

2) ...if 1 or 2 stop bits is to be used.

3) ...if a transmission rate of 19200, 9600, 4800, 2400, 1200, or 600 baud is to be

Default settings are: 8-bit data, 1 stop bit, 9600 baud.

No parity is generated and no communication error detection is implemented.

When using the Device Handler Parameters, the user is able to influence

1) ...the size (1...20) of the read messages.

Default message size is 9 bytes.

No initiation calls are needed after the (only) driver object has been created, and its parameters have been set to the desired values.

String messages are automatically received by the driver.

A message consists (by default) of 9 bytes, which are received in a sequence, and which are also followed by a line feed character. The line feed character is thrown away.

When calling the read operation via the Generic File and Device Access Interface, the last received valid message is put into the input buffer.

The total size of the input buffer, which is provided by the caller, must be equal to or larger than the size needed to store a message of the chosen size.

NOTE that the following situations exist:

1) If no valid message has been received at all, the read operation blocks the

2) If a new valid message is received while a read operation is being performed,

When calling the write operation via the Generic File and Device Access Interface, the driver starts to put out the string in the output buffer one byte at a time.

No filtering of the transmitted bytes is performed. The string in the output buffer, which is provided by the caller, can be of any length.

The described driver is called "can_dev4" (which is also the name of the Device Handler layer it contains).

"can_dev4" is used to perform CAN communication.

* The Device Handler layer of the driver is implemented in the C code file

* The assembly file "can_int.s" contains a low level interrupt handler for the CAN-

* Two out of four data structures needed when creating a driver object, have to be

* The file "can_reg.h" is included in "can_ioc2.c".

* The file "typedef.h" is included in both "can_ioc2.c" and "s_can167.c".

* the files "can167.h", "can_def.h", and "s_can167.h" are included in "s_can167.c".

* The files "macro.q" and "model.q" are needed when macro preprocessing

The driver supports the CAN module of the microcontroller C167CW.

No error detection mechanisms in the module are supported by the driver.

The I/O driver uses the interrupt generated by the CAN module. The interrupt is connected by hardware to interrupt vector No. 40h. The CPU interrupt level that is used is defined in the above-mentioned include file "can_ioc2.h". The low level interrupt handler defined in "can_int.s", must be called when an interrupt occurs.

Two out of four data structures needed when creating a driver object, have to be supplied from the application. Thus one structure of the type 'can_ioc_IOCB_TYPE' and one of the type 'can_dev_DCB_TYPE' must be defined for each object which is to be created.

The I/O driver supports the parallel use of up to 14 CAN objects (communication channels of the CAN module) and their corresponding driver objects. The Device Handler object of a driver object must be created before its I/O Controller object.

A call to the routine 'can_ioc_init' must be made before any driver objects are created.

The name of the Device Handler object ("can_dev4", plus the specified extension) is used when opening a path to the corresponding created I/O driver object.

When using the I/O Controller Parameters, the user is able to influence

1) ...the address of the CAN-message ( 0 to (2^11-1) ).

2) ...if read or write operation are going to be performed ( 0 ==> read, 1 ==> write) .

3) ...the data field length of the CAN-message (1 to 8 bytes) .

Default settings are: address =0, operation =read, and data field length =1.

NOTE that to change the communication rate one has to edit "s_can167.c". The high and low bytes (BTR1 and BTR0) of the Bit Timing Register, belonging to the on-chip CAN module, have to be given new values (refer to for example to [5] ).

A call to the routine 'can_object_init' must be made after each separate driver object has been created and its parameters have been set to the desired values.

This is done via the Generic File and Device Access Interface, as the last step of the initiation procedure for each driver object.

CAN messages are automatically received by the driver.

When calling the read operation via the Generic File and Device Access Interface, the last received message of the CAN object, belonging to the specified driver object, is put into the input buffer.

The total size of the input buffer, which is provided by the caller, must be equal to or larger than the size needed to store a message of the chosen size.

NOTE that the following situations exist:

1) If no valid message has been received at all, the read operation gives the return

2) If a new message is received while a read operation is being performed, the new

When calling the write operation via the Generic File and Device Access Interface, the CAN object, belonging to the specified Device Handler object, is initiated to send the string specified in the output buffer, as a CAN message.

The total size of the output buffer, provided by the caller, must be equal to the chosen size of the CAN message.

As is stated in the section called "Problem formulation and restriction of the scope of the project", one of the ultimate goals of this project is to test the developed support software additions by using them to implement a real-life regulator application. The AICC (Autonomous Intelligent Cruise Control) application, already developed for PC, is to serve as a template when developing this new microcontroller-based regulator application.

NOTE that, due to the lack of time and problems with the ODIN 2 distance sensor, this application was never tested as a whole! However, each component of CFT I/O Driver Package was thoroughly tested.

To save time when designing the new program code, a decision was made to use essentially the same functional structure and the same structure of program modules as in the old application, but to simplify it where it was possible.

Figure 11 shows the main functional structure of the AICC application. The source files of the application are found in the directory CALLE\AICC_NEW\APPLICTN.

The functional parts of the application shown above are implemented in the following way:

* "aicc_tck.c" , which contains routines for initiation and handling of the trigger

* "aicc_exc" , which contains exception handlers that are used when debugging

* "aicc_st.c" , which contains the System Start Function (in this case 'main'), that

* "aicc_tsk.c" , which contains the tasks needed to perform the regulator function:

* "aicc_ini.c" , which contains routines for creation and initiation of the needed

* "aicc_io.c" , which contains routines that call the created driver objects, via

* "aicc_ctl.c" , which implements the "Main controller" that contains the "Cruise

* "aicc_act.c" , which implements the "Actuator Controller" that contains the

* "aicc_pi.c" , which implements a PI regulator. This file is based on "pid.c" of the

* "aicc_def.h" , which contains application specific macro definitions related

* "icc_par.h" , which contains macro definitions, that define values for various

* "aicc_ini.h", "aicc_io.h", "aicc_ctl.h", "aicc_act.h", and "aicc_pi.h" contain

* O'Tool Executive

* O'Tool IOS

* All the described drivers of CFT I/O Driver Package (i.e. "ai_dev", "ao_dev", "dio_dev", "cap_dev", "asc_dev2", and "can_dev4") are used.

The libraries and source files of these support software components are merged with the application during the link and locate stage of the application building process. The corresponding include files are included in the application source files where necessary.

* "aicc_mk.mak" , used to control mk166 when building the application.

The table below shows the hardware resources, of the microcontroller C167CW, which are used by the application via O'Tool Executive, CFT I/O Driver Package and "aicc_tck.c":

The table above shows the interrupt vectors, of the microcontroller C167CW, which are used by the application via O'Tool Executive, CFT I/O Driver Package and "aicc_tck.c":

A simplified illustration of the various stages in the execution of the application is shown in Figure 12.

Since my knowledge of other microcontroller-based hardware is slight, I cannot make any comparisons between the ECU used in this project and other similar products that are available on the market. Furthermore, the adapted AICC application was never tested as a whole, and thus the behaviour of BaseNode 167 under real-life conditions is not known exactly.

The hardware reference manual of BaseNode 167 [1] was written before the final design of the ECU was settled. Therefore some of the information presented in this manual is out of date. The description of how to work practically with the ECU is very superficial.

No general C-start file, with a minimum of adaptations to the ECU, was delivered along with BaseNode 167. The supplied C-start file was restricted to be used together with an application adapted to the memory model Small.

In spite of the fact that only a few changes were needed, a lot of time was spent adapting the C-start file (which has a default configuration) delivered along with the BSO/Tasking tool chain.

The deficiencies in the hardware documentation and the initial functional problems of the I/O Board were compensated for by ample support from Mecel AB.

The Controller Board has no other functional problems than those associated with the microcontroller.

When this project started, no complete description of the microcontroller in question was available. The documentation initially consisted of the functional reference manuals of the SAB 80C166 family [2, 3] and some material, which described the additional qualities of the C167 family [4, 5].

No information about the fact that the microcontroller used was an engineering sample was given by Mecel AB. This fact was not revealed until a call was made, to Siemens in Stockholm, to ask for errata sheets [6] for the microcontroller. A new functional reference manual [7, 9], covering both C167CW and the improved variant C167CR, was sent from Siemens.

The functional reference manual of the C167 family is still under development. The documentation produced so far indicates that the final product will present both the general structure and the details of the microcontrollers in a comprehensible way.

The C167CW has functional problems in almost all its peripheral modules.

Due to the functional problems of the ADC module, the more advanced features of this module couldn't be utilised, when the I/O Controller layer of the driver "ai_dev" (belonging to CFT I/O Driver Package) was designed. Measures were also taken to compensate for functional problems in the on-chip CAN module, when the I/O Controller layer of the driver "can_dev4" (belonging to CFT I/O Driver Package) was designed.

It was hard to keep track of all the functional deficiencies of the C167CW. In the end it was established, that most of these deficiencies do not affect the I/O drivers that were developed. Nevertheless, all additional details about this tricky environment are confusing.

Most of the functional problems have been solved in the improved variant C167CR [8]. Thus the qualities of this microcontroller can be used without taking as many restrictions into consideration, as when using the earlier variant.

In my opinion, a microcontroller of the type C167C is both powerful and flexible, because of its various on-chip peripherals, and because of the uniform way these resources can be manipulated. It was hard to learn how to use the C167CW, but I suppose it is much harder to learn how to utilise the set of (external) peripherals needed to obtain a similar functionality. However one drawback is that the microcontroller just has one channel for asynchronous serial communication. It is desirable that two such channels are available, because otherwise an application that uses asynchronous serial communication can not be debugged using for example the debugger xvw166e v1.1.

My conclusion is that a microcontroller of the type C167C has the potential to serve as a part in the hardware base for a development platform for regulator applications.

All information (errata sheets and manuals) was immediately delivered from Siemens in Stockholm, when it was requested.

The documentation of the custom-made I/O Board, used in this project, is incorrect. Among other things the digital output pins have been mixed up.

The functionality of the I/O Board had not been verified, when it was delivered from Mecel AB. Some of the signal conditioning circuits belonging to digital input did not work, because of bad soldering. Furthermore, flexes were missing in the signal conditioning circuits belonging to analog input and analog output.

Since my knowledge of how to debug hardware circuits is slight, a lot of time was spent debugging the I/O Board.

After these initial functional problems, all services of the I/O Board have been working as intended.

In my opinion, the idea to split the ECU into a general purpose Controller Board and an adaptable I/O Board is promising. It is desirable, though, that the set of I/O connections, available as standard configurations of the I/O Board, will include analog output.

The documentation belonging to some tools requires a high level of background knowledge of how to manage microcontroller applications.

The tools worked well, with some exceptions.

No contacts were made with the product support of BSO/Tasking.

The manual of c166 [12] is quite difficult to understand, because

1) ...since the description of the software concept only describes the additions

2) ...the explanations, of what the various memory models (Tiny, Small, Medium,

3) ...the way the compiler transfers information, which is used to steer the

4) ...the situations (for example when floating point arithmetic or initialised bit

5) ...the large set of compiler options is very hard to survey. Both the purpose and

6) ...the limitations of the floating point arithmetic is not emphasised. For more

c166 works well, except that incorrect assembly code is generated in the following cases:

1) When a pointer (obtained by using the prefix operator "&" ) to a special function

2) When assigning the value of a single floating point constant, floating point

This incorrect assembly code causes a166 to produce error messages.

Sometimes when using floating point expressions in an application, the resulting application crashes after entering a specific expression. This happens every time the application in question is executed. This may be caused by bugs in the floating point libraries, or it may be caused by erroneous floating point library calls in the assembly code generated by c166. Work around: none.

The description of m166 [10] is quite easy to understand.

Perfect.

To be able to analyse for example a general C-start file (which is delivered along with the BSO/Tasking tool chain) or the files "macro.q" and "model.q" (which are delivered as parts of the O'Tool package), knowledge is required of how to interpret assembly language macros. Furthermore, to create flexible assembly code modules, which can be included in various applications that are adapted to for example different memory models, you have to make use of assembly language macros.

The description of a166 [10] is difficult to understand, because

1) ...it is assumed that the reader has a basic knowledge of the idea behind an

2) ...it is assumed that the reader has a basic knowledge of the real instruction set

3) ...it is hard to get a grip on the use of assembler directives. These constitute a

4) ...the large set of assembler controls is quite hard to survey. Both the purpose

Perfect.

The description of l166 [11] is quite difficult to understand, because

1) ...it is assumed that the reader has a basic knowledge of the idea behind the

2) ...it is assumed that the reader has a basic knowledge of what the various

3) ...the large set of l166 controls, is very hard to survey. Both the purpose and

The difficulty to get a grip on how to use the l166 controls was a great problem, because to locate more complex applications (for example the test applications which were used to test the various I/O drivers), an extensive use of controls is necessary.

It was not necessary to read this documentation.

Perfect.

The description of mk166 [11] is difficult to understand, because

1) ...it is assumed that the reader has a basic knowledge of how a typical makefile

2) ...some aspects of the behaviour of mk166 are undocumented.

When you have learnt how to use macros and implicit rules, you will experience how powerful mk166 really is. The undocumented aspects of the behaviour of this tool will not cause any problems, if you are careful to specify how each application component in the application is to be processed.

The description of xvw166e v1.1 (refer to the description of the text mode version in [13] ) is quite easy to understand. However, it does not cover the pitfalls of the debugger. For more information about these pitfalls refer to the section called "Useful hints when using the debugger" in Appendix C.

The debugger Cross View 80166 v4.0 r1 (the name of the executable is "xfw166e.exe"), which was delivered as a part of the BSO/Tasking tool chain, did not work at all. Instead the older text mode version xvw166e v1.1 was used in this project. The only way to steer this debugger is from the command line. Unfortunately the command language is awkward and the program has a lot of bugs.

In my opinion, it is therefore necessary to get hold of a working version of Cross View 80166 as soon as possible, if the BSO/Tasking tool chain is to be used in future projects.

No printed documentation was available, although such documentation is necessary to use the program.

viapc works well. The monitor part (Base Block) of the load program has originally been designed to work together with an application, Application Block, that has been compiled with the memory model Small. As the libraries and relocatable link files of the O'Tool package have been compiled with the memory model Large, some adaptations have been made to this monitor. The files, which constitute the adapted monitor, are found in the directory CALLE\MECEL\SOURCE..

The fact that the documentation was missing was compensated for by ample support from Mecel AB.

Note that the behaviour of O'Tool Executive and of O'Tool IOS under real-life conditions is not known exactly, because the adapted AICC application was never tested as a whole.

The general description of O'Tool Executive [14] is easy to read and well structured. This description is about the concepts behind, the theory of operation for, and the interface to the real-time kernel. Unfortunately, the description of how the interrupt handling works is out of date. The specification of which services of O'Tool Executive that are permitted in an interrupt handler is vague.

The microcontroller specific description of O'Tool Executive [17] is very hard to understand, and the requirements when using the real-time kernel are vague. The description of how the stack handling works, and of the relation between task priorities and CPU priority levels, is unclear. A lot of phone calls to Arcticus Systems AB were necessary to get the first test application, using O'Tool Executive, running.

The application example that was delivered along with the O'Tool package gave much necessary information about how to utilise the real-time kernel. However, for the inexperienced user, it was too complicated. It is desirable that the demonstrations of O'Tool Executive, O'Tool IOS, and O'Tool Monitor Printer Package (refer to Appendix B) are made in separate application examples.

Furthermore, the supplied makefile of the test application was neither adapted to mk166, nor well commented. It is desirable that well structured, commented, and correct makefile examples are supplied along with a support software package.

The fact that neither a PC program, which could communicate with the monitor functions in the C167CW (via ASC0), nor a specification of the communication protocol used was supplied [16], made the O'Tool Monitor Printer Package useless, when O'Tool Executive was initially tested.

The above-mentioned factors led to the application example never being built and executed.

The fact that the real-time kernel had apparently not been completely tested, before it was delivered, led to several distracting updates by Arcticus Systems AB during the project. As mentioned above, the O'Tool Monitor Printer Package was of no use. A hard part was to get a first simple test application, using O'Tool Executive, running.

However, if you are careful only to make permitted calls in the interrupt handlers you design, the real-time kernel will function very well.

The deficiencies in, for example, the microcontroller-specific parts of the documentation were compensated by ample support from Arcticus Systems AB.

The reference manual of O'Tool IOS [15] is hard to understand, because it is difficult to survey the described system when reading it. It is desirable that some of the ideas behind the system structure are revealed. If you are unfamiliar with advanced use of pointers and structs of the C language, this I/O driver framework will be hard to utilise. Nevertheless, the code examples included in the reference manual were very instructive when CFT I/O Driver Package was designed.

The example application that was delivered along with the O'Tool package was not very helpful, when the I/O drivers were designed, because for the inexperienced user, the driver example included was too complicated. The driver example also contained a lot of garbage code. It is desirable that a simple example driver is delivered along with an I/O driver framework of this type.

In my opinion, the basic concepts of O'Tool IOS (the layered driver structure, the uniform interfaces to the layers, and the call-back method) are very promising. During the design of CFT I/O Driver Package a lot of code and data structures have been reused, when creating new drivers.

The deficiencies in the documentation, were compensated for by ample support from Arcticus Systems AB.

No precise requirements on a development platform for regulator applications have been specified by the members of the group 6210 Systems Engineering. Nevertheless, I have identified the following qualitative requirements:

1) The development platform must support regulator algorithm implementations

2) The development platform must allow the regulator algorithms to be

3) The resulting regulator application must be easy to test and validate.

4) The resulting regulator application must be easy to modify and maintain.

5) It must be possible to execute several applications in a single ECU.

6) Extensive communication with a host PC must be possible (to be able to monitor

7) After some adaptations, it must be possible to use the ECU of the development

In this section, my opinion of how the above stated requirements are fulfilled is presented. Note that since the adapted AICC application was never tested as a whole, the behaviour of BaseNode 167, of O'Tool Executive, and of CFT I/O Driver Package (which is supported by O'Tool IOS) under a heavy work load is not known exactly.

The problems with the floating point library from BSO/Tasking seem to be relatively harmless in the sense that it is easy to check if an error will occur for the application in question. Requirement 1a might thus be fulfilled, if the improved microcontroller variant C167CR is used in BaseNode 167 and if this variant does not have any undocumented functional problems. However, there is an obvious risk that undocumented functional problems exist, since the C167 family of microcontrollers has only recently been introduced.

Since a microcontroller of the type C167C is very powerful, requirement 1b seems to be fulfilled, if the services delivered by O'Tool Executive are used with care. Time consuming services should, for example, not be used in more time critical processes and interrupt handlers.

The space requirements of O'Tool Executive, O'Tool IOS, and CFT I/O Driver Package are quite small. Thus requirement 1c seems to be fulfilled.

One of the first conclusions made during this project was that the available parts of the development platform did not fulfil requirement 2 (refer to the sections called "How to perform I/O in an application" and "Controlling the application building process"). The development platform was initially very hard to work with. The knowledge, practices, and software developed during this project will hopefully make it a lot easier.

The debugger xvw166e v1.1 has serious defects, and it is not possible to debug applications that use asynchronous serial communication using a debugger that also uses the ASC0 channel. Requirement 3 is thus not fulfilled. To solve this problem a working version of the debugger Cross View 80166 must be acquired. Furthermore, an external module for asynchronous serial communication will have to be added to BaseNode 167.

It is easy to add components to and update an application by using Make Utility mk166 in the manner described in the section called "Using the Make Utility". Thus requirement 4 is fulfilled.

A new application can easily be added, if applications are implemented as sets of tasks (parallel processes, which are supported by O'Tool Executive). The flexibility of CFT I/O Driver Package makes it easy to realize the additional communication functions that are needed. Thus requirement 5 is fulfilled.

This can be achieved by the use of CAN communication. The on-chip CAN module in a microcontroller of the C167C family enables several applications, which are executed in the microcontroller, to communicate via separate channels.

Since both the microcontroller and the I/O Board of the BaseNode 167 are quite flexible this requirement may be fulfilled.

The requirements on a good development platform for regulator applications seem to be fulfilled, with exception of requirement 3. If improvements are not made to remove this exception, it will not be possible to debug, for example, the adapted AICC application properly.

In any case, you will experience that the development platform, which has been investigated during this project, is tricky to handle initially. Nevertheless, it may prove to be very powerful after a while.

[1] Tri, V. C. (1994). BaseNode 167 Hardware Reference Manual (ProVIA-93703,

[2] Siemens AG. (1990). SAB 80C166/83C166 User's Manual (Original Version

[3] Siemens AG. (1992). Addendum to SAB 80C166/83C166 User's Manual

[4] Siemens AG. (1992, July). SAB C167 Preliminary User's Manual (Revision 1.0).

[5] Siemens AG. (1993). C167C Description of the On-chip CAN-Module (Advance

[6] Siemens AG. (1994, April 20). Errata Sheet C167CW (Release 1.1). München.

[7] Siemens AG. (1994, July). C167CR User's Manual (07.94 Advance Version).

[8] Siemens AG. (1994, October 28). Status Sheet C167CR (Release 1.2).

[9] Siemens AG. (1994, December 7). C167xR Specific Improvements (Advance

[10] Boston Systems Office/Tasking. (1993). 80166 Cross-Assembler User's Guide

[11] Boston Systems Office/Tasking. (1993). 80166 Cross-Assembler User's Guide

[12] Boston Systems Office/Tasking. (1993). 80166 C Cross-Compiler User's

[13] Boston Systems Office/Tasking. (1993). 80166 Cross View Debugger User's

[14] Arcticus Systems AB. (1991). O'Tool User's Manual (Release 3/Draft).

[15] Arcticus Systems AB. (1992). O'Tool IOS User's Manual (Third Draft). Järfälla

[16] Arcticus Systems AB. (1992). O'Tool Monitor Printer Package Appendix

[17] Arcticus Systems AB. (1995, March 14). O'Tool Microprocessor Appendix-

[18] Botling, F., Edlund, S. (1994, April). Design and Implementation of Actuator

In the description below it is assumed that the application is adapted to the memory model Large. However, if you neither are going to use the O'Tool package, nor the version of the monitor part (Base Block) of viapc that has been adapted to the memory model Large, you can choose any memory model you like. I recommend the memory model Large, though, since it is the most flexible one.

If you want to use the resources of the microcontroller and the services of the libraries from BSO/Tasking, the following requirements, among others, must be fulfilled:

* Since the memory model Large is assumed to be used, the C code files of the

* It is necessary to compile the C code files of the application using the compiler

* It is wise to compile the C code files of the application using the additional options

* If you want to force single precision floating point arithmetic in the application, all

* If you want the generated floating point code to be reentrant (i.e. the floating point

* The C-start file "bn167_cs.s", macro preprocessed with the control

* If floating point expressions are used in the application, the C-start file

* If initialised bit variables are used in the application, the C-start file

* All the libraries from the BSO/Tasking package that are used must be fetched

* Since the memory model Large is assumed to be used, the library "c167l.lib" has

* If floating point expressions are used, the floating point library "f166l.lib", must be

* If you want to print values of floating point variables, by using for example 'printf',

* If you want to read values of floating point variables, by using for example 'scanf',

* The interrupt handlers (for example Siemens Interrupt Tasks) must be coupled to

* The size of the internal RAM of the microcontroller must be specified to 2 kB.

* During the locate stage, the following memory ranges must be reserved to

* The code and constant data sections must be allocated to memory ranges

* If there are many nestled function calls involving functions that use floating point

NOTE that the requirements of the O'Tool package (if this is used) and the requirements of the downloading method used are added to the requirements stated above.

O'Tool Executive (often just called O'Tool) and O'Tool IOS are included in the O'Tool package. A third part in this package is O'Tool Monitor Printer Package, which contains routines for monitoring O'Tool Executive during the development of an application. The version of the O'Tool package used in this project is O'Tool/80C166 v3.60 .

The purpose of the following information about O'Tool Executive is to clarify the behaviour of some parts of the real-time kernel. Note that some information given here is not included at all in the documentation of O'Tool Executive [14, 17], and that part of the information is specific to the version of O'Tool Executive that is included in O'Tool/80C166 v3.60 (even when not stated explicitly).

* The System Reset Function is in practice equivalent to the C-start function. The

* There is no connection between task priorities (range: 0...63), which are internal

* The idea of virtual Interrupt Tasks that handle interrupts and communicates with

* The only routines that are permitted to call from an interrupt handler (or from the

* The following routines are not implemented:

* The interrupt priority level of the interrupt handler, which is used to increment

* The interrupt priority level of the interrupt handler, which is used to notify the

* The System Stack ( = User Stack, as defined for the BSO/Tasking tool chain) is

* It is desirable that the Internal System Stack does not overflow during the execution the

* All task stacks must be large enough to hold the variables of interrupt handlers that are

* There are limitations to how O'Tool tasks can use floating point arithmetic.

If you want to use the O'Tool package, the following requirements, among others, must be fulfilled:

* Some requirements are mentioned in the section called "Details of O'Tool

* Some important initiations of O'Tool Executive and O'Tol IOS have to be

* No interrupts are allowed during the execution of the System Start Function.

* It is necessary to compile the C code files of the application using the memory

* It is necessary to macro preprocess the assembly code files (which include

* The assembly code file "ot_cnf.s" and the library "olt167l.lib" must be linked to

* If O'Tool Monitor Printer Package is also to be used, the library "olt167l_.lib" must

* If O'Tool IOS is also to be used, the library "olt167li.lib", must be linked to

* The relocatable link files "ot_stkov.ll7", "ot_stkun.ll7", and "ot_flush.ll7" must be

* The sections of class 'OLIRAM' must be mapped to the internal RAM memory of

* The sections of class 'OLCODE' must be mapped to the same memory segment.

* Since the System Stack (= the ordinary User Stack, as defined for the

NOTE that the requirements of the microcontroller and the requirements of the downloading method used are added to the requirements stated above.

The debugger xvw166e v1.1 from BSO/Tasking (the name of the executable is "xvw166e.exe") is used to load an application into and debug this application in BaseNode 167. The application must have been formatted into a XVW166 load file (suffix .abs ).

The files needed to support xvw166e v1.1 are shown in Figure 14. The files "boot167.abs" and "mon167.abs" must be the ones designed specially for xvw166e v1.1. The file "reg167.dat" contains register declarations for the microcontroller C167CW.

xvw166e v1.1 can be used to download programs into the RAM memory of BaseNode 167. The bootstrap function of the microcontroller is used, i.e. the microcontroller must be started in Bootstrap Loader Mode, and the program is downloaded via the Asynchronous/Synchronous Serial Channel ASC0. The communication rate can be set to <= 19200 baud, via an option written as a command line argument, when calling xvw166e v1.1. A number of other useful options exist, which are for example used to choose COM port in the host PC, and to specify a file with macros that can be used as commands, when working with the debugger (refer to [13]).

The microcontroller is started in Bootstrap Loader Mode. Boot program is downloaded to the target computer, and is started. Monitor program is downloaded and started, by the boot program. The load file is downloaded and programmed into the RAM memory, by the monitor program. The monitor program then waits for the user to send commands, via xvw166e v1.1 in the host PC, e.g. to start the execution of the application. The only way to steer xvw166e v1.1 is from the command line. Some hints about how to do this are given in the section called "Useful hints when using the debugger".

If you want to download and execute an application by using the debugger xvw166e v1.1, the following requirements must be fulfilled:

* The RAM memory of the development ECU BaseNode 167 must be mapped by

* The application must not use the Asynchronous/Synchronous Serial Channel

* It is necessary to compile the C code files of the application using the additional

* It is wise to compile the C code files of the application using the additional options

* The C code file "end.c" must always be linked to the application. This file is

* The C code file "simio.c" must be linked to the application, when simulated I/O

* During the locate stage, the following memory ranges must be reserved to

* During the locate stage, all data and code sections must be allocated to memory

* The resulting absolute object file from the locate stage of l166 must be converted

* The microcontroller of the ECU must be started in Bootstrap Loader Mode. This is

* The debugger must be called with the option "-C 167" (among others). This option

NOTE that the requirements of the microcontroller and the requirements of the O'Tool package (if this is used) are added to the requirements stated above.

Note the following remarks about how to write an application that is to be debugged:

1) You must add a new line character ("\n") at the end of a string, which is to be

Note the following remarks about how to debug an application:

1) You can inspect the register contents of the microcontroller by using the syntax:

$register

2) You must initiate the necessary communication streams in the debugger, if you

3) If you place brake points in interrupt handlers, the behaviour of the application may be

4) The source files of the routines, in which you want to place brake points, must be present

5) If different PCs are used to build and debug an application, it is wise to specify in the

6) If you want to debug an assembler source file, this file must not have more than one code

7) If you have problems to place break points correctly in a routine, in spite of the fact that

Note the following pitfalls of xvw166e v1.1:

1) An erroneous result may be returned, when you are inspecting a structure (of type

2) An erroneous result may be returned, when you inspect bit-variables that are defined in

3) If you place a break point on the first bracket ( "{" ) of a function erroneous results will

4) An erroneous result is returned when you inspect the value of a variable, which is

5) If you try to evaluate an expression of the type "(pointer1-> pointer2) == pointer3" on the

6) It is impossible to put break points in other Siemens Interrupt Tasks than the one that

7) Often the debugger is unable to interrupt the application being executed in the

The stand alone program viapc from Mecel AB (the name of the executable is "viapc.exe") is used to load an application into BaseNode 167. The application to be downloaded must have been formatted into a load file with Intel Hex format (suffix .hex ). The files needed to support viapc are shown in Figure 17.

Two main downloading alternatives can be chosen via the menus of viapc (the program is supported by Microsoft Windows):

* The "Boot programs" alternative, which can be used to download programs into

* The "Application program" alternative, which is used to download a new

More detailed descriptions, partly based on hand-written notes supplied by Mecel AB, of the two downloading alternatives are given in the two following sections.

The microcontroller is started in Bootstrap Loader Mode. Boot program 1 is downloaded to the target computer, and is started. Boot program 2 is downloaded and started, by boot program 1. The load file, which consists of the Base Block and the Application Block, is downloaded and programmed into the flash memory, by boot program 2. The application signature is also written into the flash memory by boot program 2.

You start a loaded application by resetting the microcontroller and starting it in Normal Mode.

The microcontroller is started in Normal Mode. The reset vector of the Base Block points at a program reload initiation routine instead of the C-start routine (refer to Figure 18). The initiation routine determines (with the aid of an Application Signature) if an Application Block is present in the flash memory. If it is, a jump is made to the reset vector of the Application Block. If no Application Block is present, a jump is made to a command interpreter in the Base Block. The command interpreter waits for commands from the host PC and co-ordinates the reprogramming of the Application Block.

You start a loaded application by resetting the microcontroller and starting it in Normal Mode.

The interrupt vector table of the Base Block contains only jumps to the corresponding locations of the interrupt vector table of the Application Block. The only exception is the reset vector of the Base Block, as mentioned above.

The RS232 protocol of the Base Block uses no interrupts. This protocol cannot be used outside the Base Block.

If you want to be able to reprogram BaseNode 167, when an Application Block

is already present in BaseNode 167, you have to design the actual application in the Application Block so that it is able to receive the command "start reprogramming" from viapc in the host PC. When reprogramming is allowed by the application, any null character, which is received by the Asynchronous/ Synchronous Serial Channel ASC0, should be interpreted as this command. When this command has been received, an acknowledge character must be sent, by calling the routine 'putch', and then a jump has to be made to the Base Block, by calling the routine 'load_application'.

If the ASC0 channel is not used in the application, or is configured in an improper way, the configuration has to be adjusted before any commands can be received from viapc. The detection of the "start reprogramming" command is done by using the end-of-reception interrupt of the ASC0 channel.

If the end-of-reception interrupt has to be used by an I/O driver, which you do not want to adapt, you later have to use the "Boot programs" alternative, when loading a new application into BaseNode 167 .

An example of the above is implemented in the files "rs232int.c" and "shutdown.c", which are found in the directory CALLE\MECEL\OWN_SRC. In this example the routine 'config_rs232' is used to configure the ASC0 channel properly.

If you want to download an application by using viapc, the following requirements must be fulfilled:

* The ROM and RAM memories of the development ECU BaseNode 167 must be

* It is necessary to compile the C code files of the Base Block using the additional

* It is also necessary to compile the C code files of the Base Block using the

* The following C code files, which constitute the monitor part (Base Block) of the

* If you want to load a new Application Block by using the "Application program"

* During the locate stage, all code and constant data sections must be allocated to

* During the locate stage, the code and constant data sections of the Base Block

* During the locate stage, the following memory ranges must be reserved to

* During the locate stage, the ordinary interrupt vector table must be mapped to

* During the locate stage, the code section _ICALL (of class 'SHAREDRTLIB') must

* The resulting absolute object file from the locate stage of l166 must be converted

* When the "Boot programs" alternative is used in viapc, the microcontroller of the

* When the "Application program" alternative is used in viapc , the microcontroller

NOTE that the requirements of the microcontroller and the requirements of the O'Tool package (if this is used) are added to the requirements stated above.

Two simple makefile templates are presented in this appendix. The first template is accurate when you want to debug the application using a debugger from BSO/Tasking (for example xvw166e v1.1). The second is appropriate when you want to load the application using the stand alone load program viapc. These templates can also be found in the directory CALLE\MAKEFILE.

Warning! This makefile template may contain some syntax errors, because of the fact that one can not test a template...

Warning! This makefile template may contain some syntax errors, because of the fact that one can not test a template...

This makefile example can be used to build the quite complex adapted AICC application. Since the application uses the ASC0 channel of the C167CW, the stand alone load program viapc must be used to load the application into the ECU. This makefile can also be found in the directory CALLE\AICC_NEW\APPLICTN.