eTPU_C

eTPU_C

eTPU_C is allocating my variables all over the place. Some are allocated out of order! What's wrong?

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.

eTPU_C

eTPU is word-oriented. How does this affect eTPU_C?

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.

Byte-wide operations

eTPU_C

What defaults are built in to the compiler?

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 [size] @ base_address;

For example:

#pragma memory ROM [0x8000-0x400] @ 0x400;

will allow for space for 16 entries in the eTPU function entry tables.

eTPU_C

The documentation talks about a device header file and #pragma memory declarations. Where are they?

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).

eTPU_C

How should I initialize globals and static locals?

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:

Host Initialization

This example shows a basic initialization process.

eTPU_C

I declared a static local variable named the same as a function parameter. The compiler didn't catch the error. Is this a bug?

It's not a bug; it is a problem with the C language itself. The local shadows the parameter.

eTPU_C

How do I re-read the Capture registers into ERT1/2? How do I read the Match registers into ERT1/2?

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 read_match() intrinsic.

read_match();
eTPU_C

How do I enable or disable match events/the ME flag/the PP (parameter preload) flag in an Entry Point?

Use the intrinsic functions enable_match() and 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

eTPU_C

Can I use goto to jump between sections of the if()..else if()..else in an eTPU function?

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.

eTPU_C

C includes a register data type. Does eTPU_C allow register allocations? How do I access the P register from 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.

Syndicate content