6. Single Chip 166 Family Considerations

6.1 Single Chip Operation

In high volume applications the 166 family is often used in a masked ROM mode, where the user's program is supplied to the chip manufacturer who incorporates it into the silicon. When fitted into the target system the

/BUSACT pin (/EA on 167/5/3/1) will be high, so that the CPU boots up into the ROMmed program. Execution from on-chip ROM is made via 32-bit fetches, so that even 4-byte instructions go through in 100ns. The end result is that a single-chip 166 will run approximately 20% faster than one operating in 16-bit non-multiplexed mode. It is worth noting that an expert 166 programmer will be able to reduce this differential by favouring 16-bit register-to-register instructions when coding. This applies equally well to C and assembler programs.

6.2 In-Circuit Reprogrammability Of FLASH EPROM

For prototyping masked ROM applications and medium volume production, some 167 variants have been available with on-chip FLASH for some time. The 64/128/256k FLASH area can be programmed without a Vpp pin as 5v is all that is required. Typically the FLASH is programmed by the processor itself, even when soldered down, with the program received via the serial port's bootstrap loader mode. To put the 167 into bootstrap mode a pull-down resistor on P0.4 must be present which is read as the CPU comes out of RESET (see section 1.2 for more information on pull-down resistors). The user's software can then receive the program as a HEX file and program it into the FLASH. It is important to note that many competitive CPUs which appear to offer the convenience of in-circuit reprogrammabilty in actual fact do not!

This self-programming ability can be very useful in cases where the FLASH CPU is to be used in mass-production, as the final program need only be put into the device at the end of the line. It also makes field software updates very straightforward. Hitex can supply simple programming routines written in C that the user can adapt freely. For further information on using the bootstrap loader, please refer to section 9.3.

The C167CS has a 256kb FLASH ROM, divided into 32kb blocks which are located at 0x00000-0x07FFF and 0x18000-0x4FFFFs. The FLASH memory can be written to up to 1000 times, enough for a considerable number of field software updates! To prevent overwriting of programs, password protection is possible and to defeat unauthorised reading of the FLASH ROM, data reads can only be made by code itself situated in the FLASH. It also has a special high-endurance 4kb region at 0x8000 which can be written to up to 100000 times and is intended for adaptive data, calibration information etc. that may change relatively frequently. It should be noted that a FLASH block cannot be erased or programmed while code is being fetched from any of the sectors. It is therefore necessary to perform these operations while executing from either the on-chip IDATA RAM or an external memory device.

6.3 Total Security For Proprietary Software

Once programmed it is possible to protect the FLASH area from reprogramming or any sort of access at all. The contents can thus be made totally secure, so that no unauthorised reading of what could be commercially sensitive software is possible. This total security can be important in rapidly advancing fields such as motor drives or engine controls, where many innovative (and secret!) techniques are used.

6.4 Keeping An External Bus

Even though you may be working on a genuinely single-chip design, it is always a good idea to leave port 0 available for use as an external bus. During the development phase, running in a true single-chip mode will mean that you will have to use a bondout-type emulator like a DPROBE. The low cost monitor debuggers will be of no use as they all require an external bus and considerable RAM

6.5 Hitex's In-Circuit FLASH Programming Utility Toolkit

Hitex can provide several free software kits which will allow user programs to be downloaded directly into either on-chip or off-chip FLASH EPROM via the bootstrap loader. These are supplied in component form with source code to allow users to modify them for inclusion in their own developments. The PC front ends are DOS or Windows and are designed for Microsoft Visual C. Other useful tools are HEX to binary convertors and bootstrap mode diagnostic programs. Experience has shown that most project plans do not allocate time to writing bootstrap and FLASH programming software and so these utilities will save you a lot of fiddling around!

166 Designer's Guide - Page

6.5 Accommodating In-Circuit FLASH Programming

The capability of programming FLASH EPROM (external and on-chip) after the 167 has been soldered down is extremely useful. To program the device, access to the serial port is required plus a pull-down resistor on port 0 bit 4 whilst coming out of reset. The following examples show two means of doing this.

The example in the left-hand diagram uses an RS232 link as might be connected via a MAX232 (or similar LT7011 etc.) to a PC. The 167's bootstrap mode is entered by sending a null byte with one start and stop bit until the device replies with an acknowledge byte of 0xC5 (0xD5 for the C164, 0xB5 for the 165/163/161). The user must then send a 32-byte loader program which then receives a FLASH programming utility which then receives the user's application program. As the integral bootstrap loader and the second 32-byte program are necessarily very simple, only binary code can be sent to them, which is not supported by any of the commercial compilers. A number of HEX to binary convertors are available to bridge the gap.

If a single-line physical communication layer such as RS485 or ISO-K is used the S0TX and S0RX are effectively connected together. The integral bootstrap loader in fact disables the receive side until the acknowledge byte has been completely transmitted, so that it will not be confused with the first byte of the initial 32-byte program.

The right-hand illustration shows a means of dispensing with a manually operated bootstrap switch. The serial connector has two additional pins that short the pull-down resistor to ground so that after the next reset, the 167 will enter bootstrap mode.

In-Circuit Flash

Programming Using

Serial Port Plug To Invoke Bootstrap Mode

In-Circuit Flash Programming

If it is not acceptable to have extra pins in the system's serial connector, the final example shows a possible solution. Here the serial port connector has a momentary press button switch that can ground the RS232 RX pin. This will cause the pull-down resistor on port P0.4 to put the 167 into bootstrap mode on the next reset. When the switch is released the serial port operation is unaffected by the presence of the resistor.

6.7 In-Circuit FLASH Programming Via CAN

In many applications it is desirable to be able to perform the in-circuit FLASH programming function via the CAN module. A software utility for this is available but as it is not included in the 167 itself it must be located in a protected section of FLASH EPROM.

166 Designer's Guide - Page

7. The Basic Memory Map

7.1 On-Chip RAM Regions

All 166 family members have RAM located on-chip. These areas are of varying sizes and are of two basic types: "IDATA" RAM is very closely coupled into the 166 CPU core and is strictly-speaking dual-ported, although this attribute is only utilised by the Peripheral Event Controller (PEC), covered elsewhere. XRAM is effectively off-chip RAM that just happens to be on the same silicon as the core. It is on the CPU's XBUS, along with the CAN peripheral.

7.1.1 166 Variants

The basic 166 has a single on-chip RAM area, known as "IDATA", located at 0xFA00. It is available as general purpose RAM. It also is used for the "registerbanks" and "SYSTEM" stack. Most C compilers allow the user to put specific data objects in this region through the use of the "idata" storage class qualifier. Being truly on-chip, no external bus cycles are emitted when this area is accessed. An interesting feature of the IDATA RAM is that it always appears to be a 16-bit non-multiplexed RAM running with zero waitstates, regardless of what the actual external bus mode is. It is thus always guaranteed to provide very fast data access. Curiously, it is very slow when used to hold program code, as in bootstrap loader utilities. Any EPROM also at the address of the IDATA will be ignored as it is effectively "behind" the on-chip RAM. Your linker file should be designed to make sure that code or data does not fall into this black hole.

7.1.2 167CR & 167SR, C165, Some 161 Variants

These devices have an enlarged IDATA RAM area, located at 0xF600. They also have a second 1KB RAM located at 0xE000, known as the "XRAM". This RAM must be enabled by the user in software by setting bit-2 in the SYSCON register. As the XRAM is really external to the core, its READ and WRITE cycles can be made visible (bit-1 in the SYSCON) so that they can be traced by a dual-ported in-circuit emulator. This visibility also means that it can be made available to other processors via the HOLD, HOLDA and BREQ pins. Thus in some applications a low cost derivative such as the 165 can be used as a co-processor for a 167, exchanging data via the XRAM.

The 165 has an enlarged on-chip IDATA RAM area, as per the 167. It does not have any XRAM though.

7.1.4 C167CS, C161CS

These devices have an enlarged IDATA RAM at 0xF200. They also have an 8KB XRAM located at 0xC000.

7.2 Planning The Memory Map

7.2.1 External ROM Applications

All 166 derivatives come out of reset at address zero. In the case of the 167 devices, the chip select 0 (/CS0) line goes low, to enable the program store (usually EPROM) before the first address is emitted. In the majority of 166 systems, the CPU uses the bus mode set either by the EBC pins or the data bus pull-down resistors and execution begins from an EPROM. Due to the internal architecture of the 166, the area from 0xC000 to 0xF9FF (0xC000-0xDFFF on the 167CR) is best used for memory-mapped IO devices. This is because the CPU always sets DPP3 to point at 0xC000 and, by using the "SDATA" data type in C, a very fast access can be made to this region. The area from 0xFA00 to 0xFFFF (0xF600 - 0xFFFF on 167) is occupied by the on-chip RAM and SFR block and hence any memory devices placed here will be ignored. A typical small-system memory map might be:

EPROM: 0x0000-0x7FFF, 16-bit non-multiplexed

RAM: 0x8000-0xBFFF, 16-bit non-multiplexed

IO: 0xC000-0xF9FF,(0xF5FF) 8-bit multiplexed

RAM: 0x10000-0x3FFFF, 16-bit non-multiplexed

Of course such a complicated map is not strictly necessary and is only given as an example! In some systems the CPU can have RAM at zero: all variants have a bootstrap loader built-in which can receive an application program via the serial port. This is often used to program FLASH EPROM during field program updates.

The bus interface supports hardware waitstates via asynchronous and synchronous READY signals - in the latter case the CLKOUT pin can provide the synchronisation. In addition HOLD is provided for use with external DMA

166 Designer's Guide - Page

controllers. Where waitstates are required, the SYSCON (BUSCONx on the 167) register can be programmed to make the CPU automatically insert the required number of waitstates without an external READY signal. Thus no external hardware is required to generate waitstates.

It should be noted that as the PEC pointers can only operate in the bottom 64K of the address space, it might be a good idea to place some RAM at 0x8000 in case any sizeable arrays are to be accessed via the PEC. It is not obvious from the databooks that any EPROM in the address ranges of the on-chip RAM, SFRs, XRAM and CAN peripheral is effectively hidden behind them. It is therefore important to prevent any useful software or constant data ending up in these address ranges through the proper configuration of the program linker.

7.2.2 Internal ROM Applications

The new availability of versions with on-chip FLASH has imposed some limitations on memory maps. With the C167CS, the 256k FLASH ROM is split into 32k sectors based at addresses 0x00000 and 0x18000. The group of sectors at 0x18000 are contiguous to 0x4FFFF. The basic requirement for on-chip ROM applications is that the /EA (external access) pin must be high. The user's program in ROM can of course enable the external bus from software. However Port 0 and optionally Port 1 must be left free for use as the data and address busses respectively. If a multiplexed bus is acceptable then just Port 0 needs to be left free but there is an approximately 40% increase in access times and a 573 (or similar) address latch is required. The code execution speed from internal ROM is on average around 18-25% higher than from the 16 bit non-multiplexed bus.

7.3 A Typical 167 System Memory Map

Below is a typical memory map for a 167 design. Where applicable, a sample line of C is given on the left hand side to show how data can be directed to the appropriate memory region or type.

Summmary Of Memory Areas In A Typical ROMless 167 Design

166 Designer's Guide - Page

7.4 How CPU Throughput Is Related To The Bus Mode

The overall throughput of the 166 family is highly dependent on the bus mode used. As a 16-bit machine, the 16-bit modes are obviously the most efficient: most instructions are 2-byte and so a complete instruction can be fetched with just one access across the bus. With the non-multiplexed mode no latching of the address is required and so the CPU can run to best effect. Branch instructions are 4-byte and so these require two accesses to fetch.

The on-chip FLASH 166 has a 32-bit internal bus so that even branches can be fetched in a single access. This configuration consequently has the highest throughput of all.

In the 8-bit mode a minimum of two bus accesses are required to fetch any instruction. Thus CPU performance is considerably reduced. However the fundamentally efficient design of the 166 core means that, even in 8-bit modes, the CPU throughput is still considerably higher than comparable CPUs such as the 68000 and 80C186.

With such a high clockspeed the access time of memory devices is crucial. At a 40MHz clock (20MHz CPU) 70ns devices are required for zero waitstate operation. A single waitstate reduces the access time to 120ns but can reduce CPU performance by 30%. To allow the use of low cost 100ns EPROMS however, it is best to reduce the clock speed to 16MHz and lose 20% performance rather than run with a single waitstate at 20MHz.

The change in CPU performance with bus mode, as observed on an embedded C test program, is summarised below:

Bus Mode Run Time (ms) Normalised

———————————————————————————————————————————

Internal ROM 15.90 0.82

16-bit nonmux 19.355 1.00

16-bit mux 24.424 1.26

8-bit nonmux 37.328 1.92

8-bit mux 46.545 2.40

80C52 12MHz 350.000 18.00

Notes: Taken at 20MHz, 0 wait states on a CB-step 166. The test program did not include any long operations so the performance advantage over the 8052 was reduced. If you use int or long maths, expect > 20 times advantage.

7.5 Implications Of Bus Mode/Trading Port Pins For IO

16-bit non-multiplexed, the fastest bus mode, is also the greediest in terms of processor pins. In this configuration both port 0 and 1 are solely concerned with the data and address bus, in that order. This allows a very simple memory system as the address pins of the EPROM are wired to P1 and the data pins to P0. As this is not multiplexed no 74x573 latch is required, although the ALE pin will continue to operate.

If the number of IO pins is critical, it is possible to free up the 16 pins of P1 by going to a multiplexed bus. The 16-bit variant is to be preferred for the reasons given above. Now P0 will emit the address followed by ALE going low to latch it into the 74x73. The data is then emitted to complete the access. This will slow the CPU down somewhat but by careful software design the effects can be minimised. Steps to take might be to place all frequently accessed data into the on-chip ("idata") RAM where the multiplexing will have no effect. The 16-bit modes do, of course, require 16-bit memory devices or at least HIGH and LOW 8-bit memories. In the latter case the BHE (byte-high enable) and A0 pins can be used to select between high and low devices, as in section 5.2.

If cost is important, the 8-bit non-multiplexed mode allows simple (and single) 8-bit devices to be used without an address latch. This mode is very popular - remember, the basic CPU throughput is so high on 166 family devices that some performance can be sacrificed to reduce cost.

Finally, the 8-bit multiplexed mode is really only provided for accessing 8051-type peripheral devices. Although the performance loss is around 200%, a 166 running at 12MHz will still outperform an 8031 device by a factor of 10-15, especially if 16- and 32-bit operations are frequent.

It should be noted that, even if an 8-bit bus is being used on the 166 variant, the upper half of port 0 cannot be used as general-purpose IO. The 167/5/1/3 have port 0 split into high (P0H) and low (P0L) sections which will permit this trick.

166 Designer's Guide - Page

8. System Programming Issues

8.1 Serial Port Baud Rates

8.1.1 166 Variants

While a 20MHz CPU clock will give maximum performance, it can be tricky to get "normal" baudrates from the serial ports.

Here are the approximations to the required baudrate at 20MHz and 16MHz:

Baudrates for 20 MHz

SxBR = 0x003F => 9600 Baud (9765.625 actual)

SxBR = 0x001F => 19200 Baud (19531.25 actual)

SxBR = 0x000F => 38400 Baud (39062.5 actual)

Baudrates for 16 MHz

SxBR = 0x0033 => 9600 Baud (9615.38 actual)

SxBR = 0x0019 => 19200 Baud (19230.77 actual)

SxBR = 0x000C => 38400 Baud (38461 actual)

SxBRG is the baudrate counter register of the 166.

At 16MHz the realisable baudrates are significantly closer to the target figures. The ideal solution is to use a special oscillator of, for example, 9.8304MHz to get exactly 9600 baud. However such devices can be expensive and in most cases the loss of performance in going to 16MHz can be tolerated, especially when the possibility of using cheap 90ns EPROMs is opened up.

8.1.2 Enhanced Baudrate Generator On 167 Variants

The 167 has an enhanced baudrate generator that allows the error resulting from 20MHz clocks to be virtually eliminated. The deviation increases with the baudrate and above 9600 can be quite significant. The S0BRS bit in S0CON enables this feature by applying a further 2/3 multiplier to the CPU clock frequency before it is fed into the baudrate generator, so that a closer approximation to the baudrate can be achieved.

8.1.3 The Synchronous Port On The 167

The 167 only has a single asynchronous serial port, with the 166's second port becoming a master/slave synchronous port. Unlike the synchronous modes in the 166's ports, the C165/7 can be both bus Master and Slave. This is intended as a means of allowing the CPU to make use of many industrial serial communication standards. These include Philips I2C, Motorola SPI, Profibus and others. Some software is required to configure the port to achieve this however. Detailed application notes cover these possibilities.

Note: If a second asynchronous port is essential for your application, Hitex can supply a simple software-driven UART routine on request. This is entirely adequate for user interfaces and other undemanding tasks up to 9600 baud. A two channel version is also available for the C161.

8.2 Interrupt Performance

The 166 family has two methods for servicing interrupt requests. The first is a conventional, albeit very fast, vectoring to a service routine for every request. The alternative mode is to just make a single-cycle data transfer from the peripheral requesting the interrupt, with a "normal" service routine only being called once every 255 (or fewer) requests.

8.2.1 Conventional Interrupt Servicing Factors

The 166-core's suitability for very high performance control applications derives from its combination of short instruction times and very fast interrupt response. The basic aim of the interrupt system is to get the program to the

166 Designer's Guide - Page

first useful instruction of the interrupt routine as quickly as possible - all stacking of current working registers (the "context switch") is assumed to have been done before this point.

In a conventional processor, the speed of this response is normally limited by the slowest/longest instruction in the opcode set plus the time to stack the current working registers. In the case of the 166 this might be expected to be the DIV instruction, which takes 800ns (25MHz). However this instruction is interruptible, so if an interrupt becomes pending during the execution of the DIV, the calculation is suspended so that the interrupt can be processed. Once completed, the DIV resumes. Thus the worst case interrupt latency time is not significantly influenced by the instructions in the pipeline when the interrupt is requested. The best case response time is 400ns when running from external ROM and the worst case is 900ns. In both cases a 16-bit non-multiplexed bus is assumed. For the FLASH device, the range is reduced to a range of 250ns to 400ns. See section 9.3.1 for more information on interrupt pin scan rates, which can affect interrupt latencies.

By virtue of the "SCXT" context switch instruction effectively stacking the processor state in a single cycle, having got to the interrupt routine, the first useful instruction can be executed 100ns later. Thus it takes around 1us for a 166 to be in a position to execute the first useful line of C in an interrupt service routine. The availability of potentially one register bank per interrupt service routine means that each interrupt source can be considered to have its own "virtual" CPU. Provided service routine run times are kept reasonbly short, this analogy is valid and can simplify the design of real time software.

To put these latencies in context, an 8031 takes about 10us to get to the service routine plus another 12us to stack the current register set. The 80C196 takes around 5us to get to the service routine.

The 80C186 gets to the interrupt routine in about 5us and then takes another 4us to switch context. The 68000 takes about 18us plus 8us to stack everything. This is one reason why the 68000 core is fundamentally unsuited to interrupt-driven real-time control applications.

Note: The 68332's fix for this poor real-time response is to bolt-on the dedicated time-processor unit (TPU). This uses a micro-coded co-processor to achieve what the 166 does using assembler or C. Users therefore have to learn not only the 68K instruction set but also send engineers on a TPU microcode course!

8.2.2 Event-Driven Data Transfers Via The PEC System

In addition to the normal event-interrupt routine mechanism, the 166 also supports a special data transfer only interrupt response mechanism. This allows a single byte or word data transfer between any two locations in the first 64k in just a single CPU cycle (100ns). It is very similar to DMA except that it is event-driven by interrupt sources. Typical applications would be to transfer A/D converter readings from the A/D results register to a buffer without CPU intervention. This PEC system thus allows simple, repetitive data transfers to be performed with virtually no CPU overhead.

The source and destination addresses are determined by source and destination pointers in the on-chip RAM and must be initialised by the user in C. The source pointer might be the A/D result register and the destination pointer an array in RAM. If the source and destination pointers are fixed, there is no need to ever call a normal interrupt service routine and the data transfer will continue ad-infinitum. The source and destination for PEC-transferred data must be in the bottom 64K, although this can be extended to any address by adding some external hardware.

PEC Usage Examples

(i) If the A/D converter result is to be transferred into a RAM array for later processing, the destination pointer must be incremented. Up to 255 transfers can be made before a conventional interrupt service is required; however all that has to be done at this point is to reset the PEC transfer counters to zero and set the destination pointer to the original values.

(ii) A table of values representing a sine wave are held in table. At the end of every carrier period, the associated interrupt request causes the value in the table indicated by the PEC's source pointer to be transferred to the duty ratio register of PWM module channel 0. The source pointer is then incremented by the PEC hardware to point to the next table entry. Every 128 carrier periods, the interrupt request is accompanied by a normal interrupt service routine, which sets the table pointer back to the start of the table. As a result of the foregoing, a sine-modulated pulse train appears on P7.0, with virtually zero CPU intervention. By careful software design, it is possible to completely automate the performance of complex tasks, so that the CPU is freed up for more demanding processing.

166 Designer's Guide - Page

8.2.3 Extending The PEC Address Ranges And Sizes Above 64K

In some applications, is it desirable to transfer very large arrays of data to a peripheral via the PEC. Such a situation can occur in inkjet printing systems whereby a 256kb bitmap image has to be moved byte-by-byte to a print-head attached to the 5MB/s synchronous port. The software generates the bit map image of an ASCII text string in a two-dimensional 256kb array through a low-priority routine. The first "row" in the array is filled and then transferred to the synchronous port with the PEC. During transmission, the second row of the array is filled and then it is transferred. Thus the processes of generating the bitmap and transmitting it occurs in parallel, with just a single 100ns cycle stolen by the PEC on each transfer.

The basic scheme creates two images of the RAM that will be PECed to the synchronous port - one that appears as a single 512kb area at 0x80000 and the other as an 8K "window" at 0xC000 but still into the same area. The large region is created by mapping chip select /CS4 to 0x80000, length 512K, via ADDRSEL4. When the image generation software addresses the RAM, data is moved though the top HC244 bidirectional bus transceiver that is also enabled by /CS4. For the PEC transfer, /CS3 is mapped to 0xC000, length 8K. The 8-bit port effectively sets the offset of the 8K window into the RAM. The PEC's source pointer is set to 0xC000 also so that READs from the RAM causes the lower HC244 to pass the data.

The net result of this is that the job of driving the print-head is entirely automatic!

8.2.4 Software Interrupts

In addition to the event and peripheral-driven interrupts, a large number of software interrupts are possible. These are a means of causing the program to vector to a specific routine very quickly. The priority of the service routine is the same as prevailed when the trap was triggered. They are extremely useful for writing real time operating systems.

In the 167, software traps can be assigned different priorities so that their service routines cannot be interrupted by less important events.

8.2.5 Hardware Traps

These are provided to allow programs to recover gracefully from major disturbances that may have caused branching to, or a word data access to, an odd address. Once in the appropriate service routine the user can decide how to deal with the upset. Of course, during program development, these traps can be a major aid to debugging - most apparent CPU oddities can be traced to the user having broken word-alignment rules or misuse of the stack!

8.2.6 Interrupt Vectors And Booting Up The 166

After reset the 166 starts to execute code from address 0, just like an 8051. The reset vector at zero is just one of a series of interrupt vectors that run up to 0x1ff on the 166 and 0x3ff on the 167. This appears to conflict with the need for the PEC system to use a RAM in the first 64k segment. If the PEC absolutely has to be used to address a

Extending The Addressing

Capabilities Of The PEC

166 Designer's Guide - Page

large memory area then some sort of memory map swapping will be required. In practice though, this limitation is rarely a problem for several reasons:

(i) The PEC source and destination addresses are often placed in the internal RAM area at 0xF600 for a 167 or 0xFA00 for the 166.

(ii) The RESET OUT pin can be used to cause a memory map switch. In the 166, the RESETOUT pin is often used to move the boot EPROM device up to 0x10000 after the EINIT instruction. Typically, the program comes off the reset vector, performs the basic SYSCON and BUSCON0 setup and then executes the EINIT instruction

(iii) Many 166 designs are based on a boot EPROM + FLASH EPROM that holds the application code. The boot EPROM might be only 16 or 32k whilst the FLASH EPROM might be 128kb and sit at 0x10000. The boot EPROM has to contain a table at 0x00000 to redirect the interrupt vectors up to 0x100000-0x101ff for example. This type of address translation is fully supported by the C compilers.

The boot EPROM also usually contains the FLASH programming routines and remains fixed during the life of the product. It is quite common to use the boot EPROM as a sort of PC-style BIOS where the application program can make calls into the "BIOS" to get low-level information. Again, this type of split memory map programming is supported in C.

A low cost 8-bit EPROM in an 8-bit non-multiplexed bus mode can be used to boot up the CPU, while the BUSCON1 and ADDRSEL1 registers define the FLASH area as 16-bit non-multiplexed so that full performance can be achieved. Note though that having the interrupt vectors in an 8-bit non-multiplexed region will increase the latency time by 200ns but, in view of the CPU's outstandingly short times, this is unlikely to prove a problem!

8.2.7 Interrupt Structure

To allow truly event-driven software, 14 different interrupt priorities are provided. Thus the response to any real time event need not be dependant on what the CPU is currently doing. In some CPUs different interrupt sources are grouped together so that they must have the same interrupt priority. For example, the 80C537's serial port interrupt is tied to the compare register 0 interrupt. Thus a real time interrupt on CC0 cannot interrupt a serial interrupt service routine, with the result that events may be lost or delayed. The user therefore cannot use an interrupt-driven serial port due to a CPU limitation.

In the 166, no such restriction is present so that system response and performance is improved, along with an easing of program planning. As a further refinement, if two interrupts of the same priority occur simultaneously, the user can tell the CPU to which interrupt source priority can be given. Thus the 166 interrupt structure is vastly superior to that found on similar processors and allows it to cope with a very large number of asynchronous events.

8.3 The Bootstrap Loader

8.3.1 On-Chip Bootstrap Booted Systems

It is possible to have a totally FLASH EPROM-driven system which receives updated programs via the bootstrap loader. This can be achieved as follows:

(i) Force the CPU into bootstrap mode via the methods given in the processor's databook.

(ii) Initialise the bootstrap loader with the appropriate character via serial port 0.

(iii) Send a 32-byte simple loader program to address 0xFA40 and then perform a jump to 0xFA40 (automatic!). This program should itself be able to receive a fixed number of bytes which are best loaded into the internal RAM.

(iv) A further loading program should be sent to the first program. This program should be a more sophisticated affair, able to receive an Intel hex file, perhaps, and able to program the FLASH EPROM. It should also set up the DPP registers and configure the external bus accordingly - as the CPU has not yet come out of a normal RESET, these normally automatic actions must be performed by the user.

(v) The application program as a hex file should be sent to the second program which blows it into FLASH EPROM.

(vi) The process should be completed by executing a SRST (software reset) instruction to start the newly-downloaded application program.

166 Designer's Guide - Page