The SAB80C166 has two methods for servicing interrupt requests. The first is a conventional, albeit 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 256 (or fewer) requests.
The C166-core's suitability for very 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 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.
The speed of the 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 C166, this is the DIV instruction which takes 900ns. However, this instriction is interruptible such that if an interrupt becomes pending during the excution of the DIV, the the calculation is suspended so that the interrupt can be processed. Once completed, the DIV resumes. Thus the worst case interrupt latency time is based purely on the characteristics of 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 100ns. In both cases, a 16 bit non-multiplexed bus is assumed.
For the FLASH device, the range is reduced to 250ns to 400ns.
By virtue of the single cycle context switch instruction, having got to the interrupt routine, the first useful instruction can executed 100ns later. Thus it takes 1us for an SAB80C166 to be in a position to act upon an interrupt request.
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 4us to get to the service routine.
The 80186 gets to the interrupt routine in about 5us and then takes another 4us to switch context. The 68000 takes about 18us plus 8us. 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 custom microcoded co-processor to acheive what the SAB80C166 does using normal opcodes - or C. Users therefore have to learn not only the 68000 instruction set but also send engineers on a TPU microcode course!
In addition to the normal event-interrupt routine mechanism, the C166 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 only a single CPU cycle (100ns). Typical applications would be to transfer A/D convertor readings from the AD results register to a buffer.
This PEC system 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, initialised by the user. Typically, the source pointer might be the AD result register and the destination pointer an array in RAM. If the source and destination pointers are fixed, there is no need to ever generate a normal interrupt service routine.
If either is an array, where for example, the AD convertor result is being transferred into a RAM array for later processing, the destination pointer must be incremented. Up to 256 transfers can be made before and 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 source and destination pointers to the original values.
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. An good example is the generation of continuous three phase 50Hz sine waves via a PEC-driven CAPCOM, with only a 1% CPU load.
Example:
Use the PEC program to read A/D results register into a RAM buffer.
In addition to the event and peripheral-driven interrupts, a large number of software interrupts are possible. These are a means for 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 C165/7, software traps can be assigned different priorities so that cannot be interrupted by less important events.
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 use having broken word alignment rules or misuse of the stack!
After reset, the C166 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 C166 and 0x3ff on the C165/7. 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 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:
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 acheived. 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!
It is possible to have a totally FLASH EPROM-driven system which receives updated programs via the bootstrap loader. This can be acheived as follows:
One simple problem facing anybody writing the primary and secondary boostrap loader programs is how to actually get them into the processor. The C166 compilers and assemblers produce either object or HEX files, neither of which can be sent directly to a processor in bootstrap mode. The problem is that first loader program expects to receive a binary stream, based at 0xfa40. In the example above, the first program also expects to receive a binary representation of the program, based at 0xf600. A first 32 byte loader program can also be had, along with a program which simply transmits "Hello!" back down the serial port.
Hitex can also provide its BC167 HEX file to "based" binary file convertor - the .img output file is a 32 byte program based at 0xfa40 and the .bin output file based at 0xf600. Also available is the simple BOOTTX program which will initialise the bootstrap mode and send the first 32 byte program. All of these utilities are supplied on a "freeware" basis without proper support!!
All this software is held on the Hitex BBS on 01203 690026, if you wish to download it.
The situation with the stack on the SAB80C166 looks somewhat odd at first: with only 256 words for the "system" stack available, programmers used ot CPus like the 80c186 might imagine that running out of stack is very likely. In fact, this is rarely the case, due to the multiple register bank RISC architecture and the provision of a potentially huge number of local stacks, based on the MOV reg,[Rx+] and MOV reg,[Rx-] instruction.
In traditional CPUs, function parameters are pushed onto the stack by the caller where they are either moved off the stack into local RAM or operated on directly in situe. Also, the return address must be stacked. This has two side-effects:
With the C166, only the return address is pushed onto the system stack with any parameters being moved onto the user stack, usually created via general purpose register R0. In practice, the caller will leave parameters where they were, i.e. in general purpose registers. The combined effects of both these actions is to drastically reduce the size of system stack required plus considerably reduce the processing overhead for function calling in C.
In the case of interrupts, the traditional approach of stacking the current register set is possible but is not the best way: again, the multiple register bank architecture allows the context to be switched in one cycle and with hardly any stack use at all, other than for the return address and last register bank base address (Context Pointer - CP). The special C166 keyword "USING" performs this. On exit from the service routine, the context (register bank) is restored.
To allow truely 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 SAB80C166, 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 SAB80C166 interrupt structure is vastly superior to that found on similar processors and allows it to cope with a very large number of asynchronous events.
In many projects, power consumption is critical, particularly in battery powered applications. Ultimately, it is the "processing power per milliamp" that is important in this situation.
By way of an example, here are some run times for a benchmark program stated alongside the current consumption of the CPU at the time:
CPU Speed Runtime Current Idle Current-----------------------------------------------------C165: 16MHz 10.333s 52mA 4mA80C188EB: 16MHz 32.718s 93mA 63mA
Assumptions:
C165 max current is 70mA at 20MHz (62mA at 16MHz)
80C188EB max current is 90mA at 16MHz
Note: The C165 typical current consumption is around 40mA at 20MHz.
It can be seen that although the current consumption ofthe two devices is similar, the CPU throughput of the 80C188EB is about 1/3rd of the C165's. If the clock speed is reduced by 1/3rd to compensate then the following is observed:
CPU Speed Runtime Current Idle mA-------------------------------------------------C165: 5.05MHz 32.718s 19mA 1mA80C188EB: 16MHz 32.718s 93mA 63mA
To put this in perspective, if the clock of the C165 was reduced to 5.05MHz to yield approximately the same throughput as the 80C188EB, the current consumption would be around 19mA. The C165's idle power consumption would be around 1mA.
This rough calculation is valid as the C165's current consumption is approximately proportional to its clock speed. The fact that several hand-held instruments already use the SAB80C166 family shows that other people have done these calculations as well!
![[Back]](back.gif)
![[Contents]](cont.gif)
![[Next]](next.gif)