AN2848 Freescale Semiconductor / Motorola, AN2848 Datasheet - Page 10

• Manufacturer Part Number: AN2848
• Description: Programming the eTPU
• Manufacturer: Freescale Semiconductor / Motorola

Function Design – Software
10
•
•
•
•
•
•
•
•
•
The Applications Programmers Interface (API) needs to be designed as part of the eTPU function.
An eTPU function cannot be considered complete without the means to initialize and exchange
data with the host. Remember that the eTPU is a 24-bit processor while the host and memory
system is organized around 32 bits.
Use 24-bit data types if possible, particularly when indirectly referenced. The eTPU does not have
a byte size addressing mode. Significant code is generated by the compiler to dereference byte
pointers. An array of (int24) words will take up more data memory, but save significant program
space and execution time. Note, however, that the machine can handle arrays of bits quite
efficiently.
The eTPU data memory can be read by the host in two locations. One of these locations returns
the 24-bit data automatically sign extended. Accesses by the host to these addresses will not affect
the upper 8 bits of the parameter. Using this alternate address space can simplify parameter
passing between eTPU and host.
Reconsider the use of nested subroutines. The eTPU has a single return address register and must
store off the value the when a second call is made.
Use the library functions where possible. They have been designed to balance proper operation
with minimum code size. If you find a source code change in a library that reduces the code size,
it possibly has an undesirable side effect. Proceed only if you understand the consequences.
Reconsider parameter-driven channel configurations. The TPU had a convenient instruction:
config := p. The eTPU does not an equivalent instruction, mainly because the channel
configuration options are much more numerous than in the TPU. If you need the option to invert
your pulse from high going to low going, implement that option. However to replicate the original
config subinstruction has been found to be expensive on the eTPU.
Be careful about auto variables (in the current version of the compiler). These are the non-static
temporary variables declared within a function. A problem arises when the function can be
instantiated on both eTPU engines. The compiler will allocate an absolute address for these
variables, and if one instance of the function is running on each engine simultaneously, there is a
possible collision in accessing the variable and consequent corruption of the data. If a function
can be instantiated to run on either engine, the only work around at this time is to declare all local
variables as static. A compiler extension is currently being reviewed to correct this problem.
Another compiler extension is under construction to modify the scoping of variables for groups of
functions. When a user tries to group a number of channels to perform one coordinated function
on several pins, for example an H-driver, and then instantiates a number of these groups, the C
language does not provide a convenient scoping for the variables local to a group. The Byte Craft
eTPU_C compiler will provide an extension to handle this situation. Details of the extension will
be provided in a later note.
Whenever a thread is entered or the CHAN register is written by the eTPU code, the ERTx
registers are updated from the channel capture registers. Since these registers are also used to read
and write the match registers, the user should take care in all accesses of the channel match and
capture registers.
Programming the eTPU, Rev. 0
Freescale Semiconductor