eTPU_C is allocating my variables all over the place. Some are allocated out of order! What's wrong?Submitted by Kirk Zurell on Thu, 2007-11-22 14:58. eTPU_C
The compiler has specific rules about allocating variables, temporary locations, and registers.
Globals are allocated in low memory locations (from 0x0000 up). Locals are allocated in high locations (from 0x0400 down). These locations are reported in the listing file, at the left-hand side of declarations.
It doesn't. Internally, eTPU_C deals with bytes; this makes it easier for C programmers to work with eTPU_C. During code generation, eTPU_C makes a conversion to sub-word calculations, using different strategies to get at different bytes.
The only caveat you need to remember is this: code for operations on byte-sized values can be particularly expensive in terms of instructions. Whether it's warranted is a matter for the designer to decide.
The default SCM space for generated code starts at 0x200. This allows etpu functions 0-7 to be defined in the entry tables.
To allow more entries, this base rom space must be moved. This is done with
#pragma memory ROM [
#pragma memory ROM [0x8000-0x400] @ 0x400;
will allow for space for 16 entries in the eTPU function entry tables.
The compiler has defaults that apply to most eTPU programs, so device header files aren't strictly necessary to compile eTPU programs.
In some situations, you might want to create a header file with configuration statements that alter the compiler's default settings for code memory and parameter RAM. This file is typically described as the "device header file". It must be available to the compiler and BClink (if used).
It's possible to use a Host Service Request to perform initialization, but we don't feel it's the best way.
We recommend using the host interface macros to create an initialization routine to run on the host.
Here is one way:
This example shows a basic initialization process.
I declared a static local variable named the same as a function parameter. The compiler didn't catch the error. Is this a bug?Submitted by Kirk Zurell on Wed, 2007-11-21 16:14. eTPU_C
It's not a bug; it is a problem with the C language itself. The local shadows the parameter.
To refresh ERT1/2 with the value of the Capture registers, re-assign the chan register:
chan = chan;
To load ERT1/2 with the value of the Match registers, use the
How do I enable or disable match events/the ME flag/the PP (parameter preload) flag in an Entry Point?Submitted by Kirk Zurell on Wed, 2007-11-21 16:11. eTPU_C
Use the intrinsic functions
disable_match() to do this.
These functions generate no code. Look for the results in the listing file, in the entry point report following each part of the ETPU_function
if()/else if()/else structure.
Enabling matches during a thread
Note: some additional entry report lines deleted for space
In general, no. Remember that the bodies of this top-local-scope statement are individual eTPU threads. The compiler treats them as run-to-completion code, and may optimize them differently.
To share programming between more than one thread within an eTPU function, create a C function and call it from all relevant threads.
C includes a register data type. Does eTPU_C allow register allocations? How do I access the P register from C?Submitted by Kirk Zurell on Wed, 2007-11-21 16:07. eTPU_C
eTPU_C does offer register-like types, with a few catches. You can use these types to access hardware registers directly, if necessary.
The traditional register alerts the compiler to allocate very fast storage (ie., a processor register) for a variable. It's a suggestion, and not mandatory. register might be useful on a system with lots of similar general-purpose registers. On eTPU, using register types is less of an advantage.