Freescale Semiconductor Application Note
AN2848
Rev. 1, 08/2008 Table of Contents
This application note is intended to help the
modulatemicrocontroller systems engineer to design and implement code for the Enhanced Time Processor Unit (eTPU). This application note provides an overview of the programming project, with suggestions on how to make partitioning and top level design decisions and avoid common pitfalls and problems. RESOURCES
Websi tes
www.ashware
www.bytecraft
www.eTPU
Training
Programming the eTPU
Presented by Ash Ware and Freescale. See
www.ashware.
Publications
eTPU Reference Manual
Byte Craft eTPU C Compiler User’s Manual 1Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2Architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3Function Design – Hardware. . . . . . . . . . . . . . . . . . . . . . 6 4Function Development – Tools . . . . . . . . . . . . . . . . . . . . 7 5Function Design – Software . . . . . . . . . . . . . . . . . . . . . . 8 6Host Interface Design . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7Simulating the eTPU Function  . . . . . . . . . . . . . . . . . . . 12 8Summary. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Programming the eTPU by:Mike Pauwels
TECD Systems Engineering
Overview
1Overview
The eTPU is an autonomous slave processor offered on various families of Freescale microcontrollers. It is an enhanced version of the TPU, which has enjoyed one of the longest successes of any microcontroller peripheral. Despite its popularity in specific markets, widespread adoption of the TPU was hindered by a lack of high-level language support and limited availability of development tools.
The eTPU was designed from the start to be supported by a high-level language compiler, and as such has become accessible to and adopted by a very wide range of customers even before the silicon had been qualified. Many of these customers had previous TPU experience, and approaching the eTPU with an understanding of the limitations of this type of device, found that they were pleasantly surprised at the increased capabilities of the eTPU. However, the great expansion of resources inspired some of these users to add features until they finally overwhelmed the capabilities of the device. Other users, never having worked within the tight constraints of the TPU, discovered th
e limitations of the device trying to implement overly ambitious designs approaches, and were obliged to scale back or even restart their plans. This application note will offer some guidelines to help users streamline their design process without running headlong into resource limits.
2Architecture
The eTPU is a slave co-processor tightly coupled to up to 32 I/O channels, each associated with an input and an output signal; see Figure1. The eTPU processing engine executes code from a code memory, using parameters in a data store which is simultaneously accessible to the host.
Architecture
Figure1. eTPU Block Diagram
The input/output channels of the eTPU each have a pair of Match and Capture units interfaced to one of two timer/counter (TCR) registers. Logic in the channel enables the hardware to detect or drive pin transitions with a high degree of timing precision. Details of the channel architecture is a topic for a subsequent note, but a block diagram is given in Figure2.
Architecture
Figure2. Channel Block Diagram
The hardware associated with each channel is controlled by a number of registers, which determine actions associated with the input and output pins and eTPU service requests. These registers are accessed by a special purpose eTPU engine that can be programmed in C. The engine has a program store for the engine software and a data store for function parameters. The memory blocks, whose size varies with the MCU, are designed to be shared by two eTPUs, as well as being accessible to the host. Software threads in the engine can be started by channel actions, and very complex control systems can be implemented that, once started, can operate independently of the host.
Host action is required to setup the functions in the eTPU engine and channels, and the host may be incorporated to a greater or lesser extent in the closing of an eTPU control loop. The host controls the eTPU by writing the function code into the control store, writing the operating parameters into data store, and configuring the basic functionality of the individual channels.
Architecture Let’s look at how this architecture works by considering a classic example; see Figure3. If the user wanted a Pulse Width Modulated (PWM) output signal on one of the channel pins, he wou
ld need a TCR and comparator to cause the output to transition high at some point in time. When that transition occurs, he would want another transition to be scheduled at a time equal to the time of the first transition, plus a high time determined by his software.
The first transition will cause a request for the engine to service the channel. The engine executes an instruction thread, which has been loaded by the host into the program memory, to calculate the high time for the pulse. The parameters for this calculation would also have been provided by the host in the data store. The engine would set up channel hardware to make a low transition when the high time expires, at which time another service request can be issued to the engine to service the low time. If the low transition executes a similar instruction thread, the process can continue forever without real time intervention by the host. If the host changes the operating parameters in the data store, the PWM can be modulated.
Figure3. Controlling a PWM
If PWM were the most complex function required of the eTPU, this note would not be needed. In fact, systems have been implemented in automotive engine control where the eTPU detects the engine position and speed, controls fuel, spark, transmission shifting, and emission control valves, and drives several additional sensors and actuators.  Fuel pulses have been designed to modulate the distribution of fuel in the cylinder, and multiple spark pulses are generated to ensure complete, clean burn of the fuel. In other eTPU applications, communication pulses have been produced, and complete closed loop motor control systems implemented. Along the way, a number of difficult problems posed by the unique nature of the
Function Design – Hardware
eTPU have been discovered and solved. This application note contains some of the wisdom of prior experience for the benefit of new engineers.
3Function Design – Hardware
The first step in applying the eTPU to a timing and control problem is to determine if the application fits within the capabilities of the eTPU. To do this requires a working understanding of the architecture of the timing channels. Here is a summary of the general capabilities and limitations of t
he channel hardware:•RESOLUTION – The channel hardware can set a pin high or low, or toggle it immediately or at some time in the future. This occurs when a free running counter/timer matches a register value.
The size of the register is 24 bits, and the counter can be incremented as fast as ½ the frequency of MCU system clock. This is the finest resolution available for timing.
•MAXIMUM TIME – The timer/counter can be slowed by prescaling, and the TCR range is 24 bits.
If the TCR resolution is 100 nanoseconds, then the counter range is about 1.67 seconds. More
significantly, signal timing can incorporate software counters, enabling virtually any maximum time length.
•MINIMUM TIME – The channel has two match comparators, and a pulse can be set to start at one time and end at another after only a single tick of the selected counter/timer. Thus, the minimum time pulse that can be produced is 2 times the system clock.
•INPUT LIMITS – The above limits are virtually the same for input transition measurements.
•TIME BASES – While there are two time bases provided, the range of one counter is sufficient to enable virtually any combination of pulse times. The second one can be driven by an asynchronous external source, or be controlled by special Angle Clock circuitry provided in the eTPU. The Angle Clock is a subject of a future note, but in general it is a system where the angle of a spinning shaft can be tracked and the extrapolated angle can be used to time input or output events.
•INTERACTION OF EVENTS – The channel hardware can be configured into a number of operating modes, where, for example, output pulses can be timed by two different time bases, input pulses windowed by timers, or outputs can be used to enable timers all without direct software intervention.
•SYNCHRONIZATION – Since all channels operate from the same timer/counters, software can be used to synchronize inputs and outputs with quite complicated algorithms. For example, a spark pulse can be made to start at a projected time before the firing angle, and fire exactly on the angle, tracking as closely as possible the variation in speed of an engine.
•LATENCY – Since the channels have only two action units for each pin, the eTPU requires software intervention before a third transition can be acted upon. This means that while it is
possible to accurately produce or measure a narrow single pulse, a third transition can only be
produced or detected after the eTPU engine has begun to service the channel. The minimum time required by the eTPU engine to service one of the edges and reset the channel for the third edge is highly dependent on the configuration and activity in the rest of the eTPU system. However, even with no other eTPU activity, this time cannot be reduced to less than 10 CPU clock cycles.
The second step is to select a channel mode appropriate for the task. The eTPU provides 13 preprogrammed modes for channel operation. The following summary may help in system design:

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。