Please note that Cypress is an Infineon Technologies Company.

The document following this cover page is marked as “Cypress” document as this is the
company that originally developed the product. Please note that Infineon will continue
to offer the product to new and existing customers as part of the Infineon product
portfolio.

Continuity of document content

The fact that Infineon offers the following product as part of the Infineon product
portfolio does not lead to any changes to this document. Future revisions will occur
when appropriate, and any changes will be set out on the document history page.

Continuity of ordering part numbers

Infineon continues to support existing part numbers. Please continue to use the
ordering part numbers listed in the datasheet for ordering.

www.infineon.com
 AN60486

PSoC® 1 M8C ImageCraft C Code Optimization

Author: Archana Yarlagadda
Associated Project: No
Associated Part Family: CY8C2xxxx (All PSoC 1 devices)
Software Version: PSoC Designer™ 5.4
Related Application Notes: AN75320, AN60630, AN2017

If you have a question, or need help with this application note, contact msur@cypress.com.

AN60486 shows you how to optimize PSoC 1 C code to be faster and smaller and covers PSoC Designer project and
ImageCraft compiler settings that help you to do so. In addition, it offers several guidelines for efficient coding. This
application note assumes that you are familiar with PSoC 1, the PSoC Designer Integrated Design Environment (IDE),
and programming in C. For introductory information, refer to AN75320 – Getting Started with PSoC 1.

Contents Introduction
Introduction ....................................................................... 1 There are several ways to reduce the amount of flash
Project-Level Optimization ................................................ 2 (ROM) used in a PSoC Designer project. This can
Setting 1: Relocatable Code Start Address .................. 2 sometimes allow you to use a smaller PSoC device, which
reduces cost.
Setting 2: Configuration Initialization ............................ 3
Setting 3: Sublimation and Condensation .................... 4 The ImageCraft compiler Standard version is included with
Setting 4: Treat const as ROM Versus Treat const as PSoC Designer. You can also buy the Pro version, which
RAM ............................................................................. 6 offers more optimization, on the ImageCraft website. The
code snippets included in this application note can be
ImageCraft Pro Compiler Options ..................................... 6 used with both compilers. The examples shown were
Tips and Guidelines........................................................... 6 compiled with the Standard version; the additional
Guideline 1: Avoiding Function Calls in Interrupt optimizations that can be obtained using the Pro version
Service Routines .......................................................... 6 are also covered.
Guideline 2: Limiting Math Functions ........................... 8 To use the techniques explained in this document, you
Guideline 3: Using Array Indexing Versus Pointer ...... 10 should know how to develop and build PSoC Designer
Guideline 4: Using Switch Statement Versus If-Else projects and have a basic knowledge of C programming.
Statement ................................................................... 11 Refer to AN75320 to get started with PSoC 1.
Guideline 5: Writing Part of Code in Assembler ......... 12 While developing a PSoC Designer project, if you want to
Guideline 6: Manipulating Bits in PSoC 1 ................... 12 find out how much ROM space it is using, look at the
Guideline 7: Calculating C Code Flash Usage and Build tab in the Output status window, as shown in Figure
Execution Time ........................................................... 13 1. The code space used in this example is 543 bytes.
Conclusion ...................................................................... 15

www.cypress.com Document No. 001-60486 Rev. *E 1

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Figure 1. PSoC Designer Build Message Showing ROM Figure 3. Relocatable Start Code Address Selection
and RAM Usage

The following sections discuss project-level optimization

settings, followed by some coding guidelines.

The address you place in the text box is based on the size
Project-Level Optimization of the boot code, which you can find in the map file (.mp),
Several PSoC Designer code optimization settings are as shown in Figure 4.
available at Project > Settings. Figure 4. Map File in PSoC Designer
Setting 1: Relocatable Code Start Address
When a PSoC Designer project is built, the ImageCraft
compiler converts the C files into assembly files. The
assembler then converts them into relocatable object files.
Finally, the linker combines the relocatable object files to
produce the executable .hex file.
In addition to your code, the .hex file includes auto-
generated initialization code (boot code). This is followed
by a set of NOP instructions that act to reserve some flash
bytes for possible expansion of boot code. See Figure 2.
You can save flash by forcing your code to be located
immediately after the boot code.

Figure 2. Flash Map for PSoC Designer Project

Start
0x0000

BOOT

End
NOP
NOP
The map file shows the start and end addresses of
Start different areas of code, as shown in Figure 5. The boot
code is in area “TOP,” and your code is in area “lit.” You
PROGRAM can set the Relocatable code start address in Figure 3
CODE to the end address of the “TOP” area to use the flash
space most efficiently. For example, the default setting is
End 0x190 (start of “lit” area). If you change it to 0x151 (end of
“TOP” area), you can gain 63 (0x190 – 0x151 = 0x3F)
more bytes in ROM.
PSoC Designer lets you specify the start address of your
portion of the code by choosing Project > Settings. In the
window that pops up, select “Linker,” as shown in Figure
3.

www.cypress.com Document No. 001-60486 Rev. *E 2

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Figure 5. “lit” and “TOP” Area in .mp File Figure 7. Configuration Initialization Selection

Figure 8. Code Difference Between Loop and Direct Write

If the relocatable code start address is set to a value less

than the end of “TOP,” an error message is displayed. For
example, if the value is set to 0x150 and the boot code
ends at 0x151, then an error will be displayed, as Figure 6
shows.
In Figure 8 you can see that for each register write, the
Figure 6. Error When Relocatable Code Address Is Less Direct write method uses one more byte (MOV reg[expr],
Than Boot Code Size expr = 3 bytes) than the Loop method uses (addr, value =
2 bytes). But the Loop method also includes the table
read function, which uses 94 bytes. Therefore, if there are
more than 94 registers to be loaded (this is usually the
case in all but the simplest PSoC Designer projects), the
Loop selection uses less flash. The number of registers
initialized using the configuration table shown in Figure 8
depends on the number of resources (user modules) used
in the design. The greater the number, the more registers
Setting 2: Configuration Initialization will be initialized. So, if the design includes many user
modules to save flash and you are willing to sacrifice
Another option for code optimization is controlling how
some time at startup, use the Loop method. But if you do
PSoC registers are initialized at startup. Register values
not have many user modules in the design or desire a
can be set using two methods: Loop or Direct write, as
faster device startup, select the Direct write method.
shown in Figure 7. This option is available by choosing
Project > Settings and then selecting “Chip Editor” in the
window that appears.
With the Loop method, a table with register addresses
and values is created, and a function writes the values in
the table to the respective addresses. With the Direct
write method, register writes are done directly, with one
MOV instruction for each register.
The selected method is coded in the auto-generated file
PSOCConfigTBL.asm. The code for the two methods is
shown in Figure 8.

www.cypress.com Document No. 001-60486 Rev. *E 3

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Setting 3: Sublimation and Condensation If all functions in all user module APIs are used in a
project, then a “no dead symbol found” message is
Sublimation and condensation are compression
displayed, as Figure 12 shows.
techniques provided by the ImageCraft Standard version.
These can be set by choosing Project > Settings and Figure 12. Sublimation with “no dead symbol found”
then selecting “Compiler” in the pop-up window, as shown Message
in Figure 9.

Figure 9. Sublimation and Condensation Selection

Condensation
When you select the Condensation option, a function is
formed for segments of code that are repeated in a
project, and each instance of that code is replaced with a
function call. In the simple example shown in Code 1, the
same code is repeated three times in various locations of
the project. When condensation is enabled, a single
instance of the code is converted into a function, and
Sublimation wherever the instance occurs, it is replaced by a function
When you select the Sublimation option, the compiler call to that function, as shown in Figure 13. All such
deletes the unused functions in the user module APIs created functions/procedures are placed at the end of the
(interface code), which saves space. code and below the label “<created procedures>,” as
shown in Figure 13. As you can see, the created
For example, you can place a PGA and a PWM user procedure for Code 1 starts at the label “<created
module in a project and call only the “Start” function for procedures>”; therefore, wherever the instance is used, it
both user modules. As shown in Figure 10 and Figure 11, is replaced with a call to the label “<created procedures>.”
you can save 142 bytes of flash by eliminating the other The functions at location “0520” and “052B” below
unused functions in those user module APIs. “<created procedures>” are other duplicate codes in the
project that are converted to callable functions.
Figure 10. ROM Usage Without Sublimation
Code 1
/* Instance one */
shadowRegs[PORT_2] |= 0x01;
PRT2DR = shadowRegs[PORT_2];

/* Instance two */
shadowRegs[PORT_2] |= 0x01;
PRT2DR = shadowRegs[PORT_2];
Figure 11. ROM Usage with Sublimation
/* Instance three */
shadowRegs[PORT_2] |= 0x01;
PRT2DR = shadowRegs[PORT_2];

www.cypress.com Document No. 001-60486 Rev. *E 4

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Figure 13. Condensation for Code 1 in .lst File Figure 14. “text” Area in .mp File

Figure 15. Condensation When “text” Area Is Less Than

256 Bytes

Figure 16. Condensation When No Duplicate Code

Is Found

With the Condensation option, you can save a

considerable amount of ROM space, as Figure 17 shows. Figure 17. Condensation on Code 1 (Code 1 is part of a
To apply condensation to the code, the code in the “text” bigger project whose text area is more than 256 bytes.)
area (located in the .mp file, as shown in Figure 14) should
be more than 256 bytes. If the “text” area is less than 256
bytes, the message “program code in ‘text’ area too small
for worthwhile code compression” is displayed (Figure 15).
If no instances of duplicate code are found for
condensation, the message “no worthwhile duplicate
found” is displayed (Figure 16).
Note The information displayed in Figure 15, Figure 16,
and Figure 17 is for different codes to emulate different
scenarios during code condensation.

Note Though condensation reduces ROM space

considerably, it replaces duplicate codes with function
calls, thus adding delay to the program execution.

www.cypress.com Document No. 001-60486 Rev. *E 5

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Setting 4: Treat const as ROM Versus Treat Tips and Guidelines

const as RAM
Several coding techniques can make your firmware more
This option (see Figure 9) reduces RAM use by leaving
efficient. These methods work with PSoC Designer
constants in flash (ROM); it does not significantly reduce
projects and PSoC 1, and they can be applied to similar
flash use. Use the Treat const as ROM option for most
8-bit processors, IDEs, and compilers, such as PSoC 3
projects. The Treat const as RAM option is mainly used
and PSoC Creator™.
for backward compatibility with previous versions of the
ImageCraft compiler.
Guideline 1: Avoiding Function Calls in
Interrupt Service Routines
ImageCraft Pro Compiler Options When compiling C code for an interrupt service routine
In addition to the optimization options that the ImageCraft (ISR), the ImageCraft compiler pushes onto the stack all of
Standard compiler offers, ImageCraft Pro includes a few the virtual registers (registers used by the compiler to
other options, as Figure 18 shows. store temporary values) that will be used by the ISR. If the
ISR code includes a function call, the compiler cannot tell
Figure 18. ImageCraft Pro Compiler Options which registers will be modified by the called function. The
ImageCraft C compiler uses up to 15 virtual registers to
store temporary data on the stack.
In PSoC chips with RAM greater than 256 bytes, 4 page
pointers are also stored and restored along with the
15 virtual registers. The example in Code 2 does not
require any virtual registers to be saved by the compiler
(Figure 19). The same functionality, when implemented
using a function call, as shown in Code 3, uses an
additional 15 virtual registers, as shown in Figure 20. Each
register requires the following additional overhead code:
MOV [2 bytes] + PUSH [1 byte] + POP [1 byte] + MOV
[2 bytes] for a total of 6 bytes per register. Code 3 uses an
additional 90 bytes and involves a delayed or longer ISR
execution because of the many MOV/PUSH instructions.
Code 2
BYTE bVar1;
The Sublimation and Condensation options offered in
ImageCraft Standard are the same as the Eliminate #pragma interrupt_handler
unused user module APIs and Enable code SleepTimerHandler;
compression options in ImageCraft Pro respectively.
ImageCraft Pro also offers an option to Eliminate user void SleepTimerHandler(void)
unused functions, which is very useful when your project {
is huge and user unused functions are difficult to spot. A bVar1 = 1;
simple scenario would be a project revision; unused APIs }
tend to remain in the code, consuming ROM space. When
this option is enabled, the compiler will make sure that
unused APIs are not placed in the code and the ROM
space is available for other uses.
One more option available in ImageCraft Pro is Optimize
for speed. When this option is enabled, the code is
compiled for faster execution. ROM usage may increase
or decrease, depending on where optimization has been
applied. For instance, smaller loops in code are expanded
to sequential instructions, increasing ROM usage.
Redundant assignments or move operations are removed,
reducing ROM usage.

www.cypress.com Document No. 001-60486 Rev. *E 6

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Figure 19. Code Generated for ISR Without Function Call

(Code 2) Figure 20. Code Generated for ISR with Function Call
(Code 3)

Code 3
BYTE bVar1;
void TestFunc()
{
bVar1 = 1;
}

#pragma interrupt_handler
SleepTimerHandler;

void SleepTimerHandler(void)
{
TestFunc();
}

www.cypress.com Document No. 001-60486 Rev. *E 7

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Figure 21. ROM Usage for Code 4

Guideline 2: Limiting Math Functions
In many cases, a C compiler implements simple math
calculations with inline assembler code. However, for
complex calculations, the compiler may instead add one or
more math library functions to your code. This may not be
immediately obvious. Depending on the operation and
variable type, even a simple C operator such as “+,” “-,”
“*,” “/,” “%,” “>,” and “<” may require a library function to
implement.
Although they are very efficient and useful, library
functions can occupy a lot of code space, which you may
not anticipate. In many cases, you can avoid overusing Code 5
library functions by carefully managing the data types and
unsigned int iTest1, iTest2;
operations in your code.
void main(void)
When a program uses integer arithmetic, math library {
functions are added, depending on the size and type of iTest1 = (iTest2 << 1) + iTest2;
the variables used (8-, 16- or 32-bit; signed or unsigned). }
Details about the byte usage of different functions are
located in the Libraries User Guide at Help >
Figure 22. ROM Usage for Code 5
Documentation > Designer Specific Documents.
The base arithmetic functions (that is, functions that are
always used) include integer addition, subtraction, and
shift. When other operations, such as multiplication, are
used, code for those operations is also included.
S h i f t a n d Ad d I n s t e a d o f M u l t i p l y o r D i vi d e
Tricks like bit shift and add, instead of a multiply or divide
for unsigned integers, save code space. In unsigned
integers, a single bitwise shift right is equivalent to division
by 2, and shift left is equivalent to multiplication by 2. By A vo i d P o w er F u n c t i o n s
using shift and add, as shown in the Code 5, you can
avoid including multiplication and division library functions. Power functions also add math library functions. Power
operations can be reduced to multiply or divide operations,
In the following two snippets of code, which give the same for example, 42 = 4 × 4. As explained in the previous
result, the Code 4 implementation uses 55 bytes more section, a multiply or divide can then be implemented
than Code 5, as shown in Figure 21 and Figure 22. This using shift and add. Thus, you can save code space in
difference is due to the addition of a “__mul16” function programs that have limited power functions by reducing
to the code. the implementation to shift and add where possible.
Code 4 A vo i d F l o a t i n g - P o i n t M a t h
unsigned int iTest1, iTest2; Floating-point math with 8-bit processors almost always
void main(void) requires library functions. In addition to the function for the
{ basic math operation, utility functions for rounding,
iTest1 = iTest2 *3; normalization, and checking special conditions may also
} be added to the code. Refer to the Arithmetic Libraries
User Guide for more information about floating-point
libraries. To give you an estimate, the code space required
for the floating-point functions follows (also available in the
Arithmetic Libraries User Guide).
Comparison (*_fpcmp) = 109–125 bytes
Addition (*_fpadd) = 461–478 bytes
Subtraction (*_fpsub) = 468–485 bytes
Multiplication (*_fpmul) = 406–558 bytes
Division (*_fpdiv) = 432–449 bytes

www.cypress.com Document No. 001-60486 Rev. *E 8

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

The floating-point math functions use the integer math Figure 24. ROM Usage for Code 7
libraries as the base. This means that the integer math
libraries are also required when using floating-point math.
Instead of using floating-point math, the variables can be
scaled to use integer math directly in cases where the
range of the variable is known.
For example, in the following two pieces of code, the
range of the variable is known to be two digits after the
decimal. Thus, if you multiply all of the floating-point
numbers by 100, you can use integer math instead of
floating-point math. In the example, the integer-math
method in Code 7 uses 761 bytes less than the floating-
point equivalent in Code 6, as shown in Figure 23 and
Figure 24.
Code 6 Use a Lookup Table Instead of Calculation
int iTest2, iTest3; Sometimes it may be more efficient to use a lookup table
float fTest1; (LUT) instead of doing calculations. There are multiple
void main(void) tradeoffs, such as speed, accuracy, and code space. The
{ choice is based on the type of application.
fTest1 = iTest2 * 2.42; For example, the project given in AN2017 – PSoC 1
if(fTest1 > 7.5) Temperature Measurement with Thermistor offers an
{ option for the floating-point and LUT method
iTest3 = 2; implementation. The use of a LUT in place of floating-point
} math in this project saves 4187 bytes of memory (3779
else bytes for the lookup table and 7966 bytes for the floating-
{ point equation), but accuracy is the tradeoff.
iTest3 = 1;
} Maintain Consistency in Data Type
} When choosing a data type for a variable, choose the
smallest data type required for the function. For example,
choose BYTE instead of int if the maximum value of the
Figure 23. ROM Usage for Code 6
variable is not greater than 256. Similarly, choose
unsigned variables instead of signed variables, as
applicable. For example, consider Code 4 if the variables
“iTest1” and “iTest2” do not exceed 255 in the program.
Then you can declare them as “unsigned char” instead of
“unsigned int,” as shown in Code 8. The ROM usage is
shown in Figure 25. Code 8 consumes 84 bytes less than
Code 4.
Code 8
unsigned char cTest1, cTest2;
void main(void)
Code 7 {
cTest1 = cTest2 *3;
int iTest1, iTest2, iTest3; }
void main(void)
{
iTest1 = iTest2 * 242;
if(iTest1 > 750)
{
iTest3 = 2;
}
else
{
iTest3 = 1;
}
}

www.cypress.com Document No. 001-60486 Rev. *E 9

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Code 9
Figure 25. ROM Usage for Code 8
typedef struct
{
int iData;
BYTE bData;
}sData;

typedef struct
{
sData myArray[10];
}sArray;

sArray myTest;
sData* myPtr;

When you know the positive and negative range of a void main(void)
signed variable, you can offset the variable to bring it to {
positive values and thus use unsigned math functions. myPtr = myTest.myArray;
Similarly, if the variable is expected to have a value myPtr->iData = 100;
between –10 and +10, offset the variable by 10, so that }
the code 0 corresponds to –10, and 20 corresponds to
+10.
Figure 26. ROM Usage for Code 9
Maintain consistency in the data type used, because
typecasting is expensive in terms of code space. If you
absolutely need to use typecasting in the program,
typecast the variables to use the same math libraries to
save code space for the math libraries.

Guideline 3: Using Array Indexing Versus

Pointer
In the array-indexing method, ImageCraft directly
accesses each address using the index. No computation
is needed because the address remains constant. In the
case of pointer accessing, each access is based on the
pointer, which is a variable. Thus, the compiler must Code 10
perform more computation to get the address.
typedef struct
When the access method is used repeatedly, the {
difference in the type of access leads to a significant int iData;
variation in memory use. BYTE bData;
}sData;
For example, consider the following two code examples.
Code 9 uses 25 bytes more than Code 10, as shown in typedef struct
Figure 26 and Figure 27. So a careful observation of the {
type of access method used (array indexing versus sData myArray[10];
pointer) is important for code optimization. There are }sArray;
numerous variations in the type of access and variable
types. The key is to make sure the address is a constant, sArray myTest;
in which case the compiler directly replaces the address. sData* myPtr;
When the address must be calculated during run time, the
compiler uses more code space. In general, the “->” void main(void)
operator is expensive in terms of code space. {
myTest.myArray[1].iData = 100;
}

www.cypress.com Document No. 001-60486 Rev. *E 10

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Figure 28. ROM Usage for Code 11

Figure 27. ROM Usage for Code 10

Code 12
Guideline 4: Using Switch Statement Versus BYTE bTest1, bTest2;
If-Else Statement void main(void)
{
For case decisions, you can use either a switch statement
if(bTest1 == 4)
or an if-else statement. The difference between the two is
{
that the switch statement always does a 16-bit bTest2=1;
comparison, whereas the if-else statement bases its }
comparison on the variable type. In the case of a single- else if(bTest1 == 3)
byte variable (BYTE), the ImageCraft compiler produces {
more efficient code using an if-else construct compared to bTest2 = 2;
a switch construct. This is because an 8-bit comparison }
needs less code space than a 16-bit comparison. else if(bTest1 ==2)
The switch statement uses 9 additional bytes, plus 5 bytes {
for each case. For example, a four-case switch statement bTest2 = 3;
with a default clause, as shown in Code 11, uses (9 + 4 × }
4) = 25 more bytes than the equivalent else
Code 12, as shown in Figure 28 and Figure 29. {
bTest2=4;
Code 11 }
}
BYTE bTest1, bTest2;
void main(void)
{ Figure 29. ROM Usage for Code 12
switch(bTest1)
{
case 4:
{
bTest2 = 1;
break;
}
case 3:
{
bTest2 = 2;
break;
}
case 2:
{
When the case decision is for a 2-byte variable (WORD),
bTest2 = 3;
the resulting code size is nearly identical for either
break;
implementation.
}
default:
{
bTest2 = 4;
}
}
}

www.cypress.com Document No. 001-60486 Rev. *E 11

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Guideline 5: Writing Part of Code in Guideline 6: Manipulating Bits in PSoC 1

Assembler No data type is defined for “bit” variables in PSoC 1. To
Writing a program in assembler avoids compiler manipulate bit/bits of a variable, a mask can be used with
interpretations and allows complete user optimization. logical operators or by direct assignment to the variable.
Though writing an entire program in assembler is tedious The mask can be a constant based on the manipulation
and cumbersome, converting only part of the code to requirement. Code 14 and Code 15 show how to
assembly language can optimize the code size and manipulate bits in a variable.
performance. Consider Code 11 with assignment to the
“bTest2” variable in assembly, as Code 13 shows. Code Code 14
13 consumes 12 bytes less than Code 11, as Figure 30
shows. BYTE bTest1, bTest2, bTest3;
void main(void)
Code 13 {
BYTE bTest1, bTest2; /* To set first, sixth and eighth bit
void main(void) of the variable */
{ bTest1 = (0xA1);
switch(bTest1)
{ /* To clear the second and the
case 4: seventh bits the variable */
{ bTest2 = bTest2 & (0xBD);
asm("MOV [_bTest2], 0x1");
break;
} /* To invert the second, fifth and
case 3: eighth bits in the variable */
{ bTest3 = bTest3 ^ (0x92);
asm("MOV [_bTest2], 0x2"); }
break;
} If a variable has more than one bit definition and one or
case 2: more bits must be manipulated without affecting other bits
{ in the variable, then use the logical operators to
asm("MOV [_bTest2], 0x3"); manipulate the bits. These operations use XOR, AND, and
break; OR instructions. The corresponding .asm code for Code
} 14 is generated in the <projectname>.lst file (Workspace
default: > Output Files) as follows.
{
asm("MOV [_bTest2], 0x4"); /* To set first, sixth and eighth bit
}
of the variable */
}
} bTest1 = bTest1 | (0xA1);
__text_start|_main|_main:
62 D0 00 MOV REG[0xD0],0x0
Figure 30. ROM Usage for Code 13 2E 03 A1 OR [bTest1],0xA1

/* To clear the second and the

seventh bits the variable */
bTest2 = bTest2 & (0xBD);
62 D0 00 MOV REG[0xD0],0x0
26 02 BD AND [bTest2],0xBD

/* To invert the second, fifth and

eighth bits in the variable */
bTest3 = bTest3 ^ (0x92);
62 D0 00 MOV REG[0xD0],0x0
51 04 MOV A,[bTest3]
31 92 XOR A,0x92
53 04 MOV [bTest3],A
address: 8F FF JMP address

www.cypress.com Document No. 001-60486 Rev. *E 12

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Note The instruction MOV REG[0xD0],0x0 sets the Guideline 7: Calculating C Code Flash
RAM page number of the global variable Usage and Execution Time
“bTest1/bTest2/bTest3.”
When code memory usage and program execution time
If the size of a variable is a single bit or if all the bits are a concern, knowing the flash usage of a function or a
defined in the variable are being assigned/manipulated piece of code and its execution time can be useful in
simultaneously, then use direct assignment to manipulate manually optimizing the code.
them, as shown in Code 15. This uses the MOV
instruction, which is one cycle faster than the XOR, AND, To find out the code size of a function, refer to the
and OR instructions. <projectname>.mp file in Workspace > Output Files. The
.mp file provides details on code memory usage by code
Note To find out how many cycles an instruction takes to areas and the functions/constants defined in the areas. It
execute, refer to the Assembly Language User Guide, also provides details on RAM usage by RAM areas and
Appendix A5, “Instruction Set Summary,” in PSoC the address of global variables defined in those areas, as
Designer at Help > Documentation > Compiler and shown in Figure 31.
Programming Documents. Figure 31. Address and Memory Details in .mp File

Code 15

BYTE bTest1, bTest2;

void main(void)
{
/* To clear the first and the second
bits and set the third bit of a three
bits variable */
bTest1 = 0x04;

/* To invert the variable */

bTest2 = ~ (bTest2);
}

The corresponding .asm code follows:

BYTE bTest1, bTest2;

void main(void)
{
/* To clear the first and the second
bits and set the third bit of a three
bits variable */
bTest1 = 0x04;
__text_start|_main|_main: Note Refer to the C Language Compiler User Guide,
section 6.9, and the Assembly language User Guide,
62 D0 00 MOV REG[0xD0],0x0
section 5.1, for details on the code/RAM areas.
55 02 04 MOV [bTest1],0x4
To find out the code size of a function, search for the
/* To invert the variable */ function name in the .mp file. If you have not placed the
bTest2 = ~ (bTest2); function in a custom area, by default all the user-defined
62 D0 00 MOV REG[0xD0],0x0 functions are placed in the “text” code area (Figure 32).
Figure 32 shows the start addresses of “main,” “function1,”
}
and “function2” defined in Code 16. To find out the code
51 03 MOV A,[bTest2] size of “main,” subtract the address of the following
73 CPL A function (“function1” in this case) from the address of
53 03 MOV [bTest2],A “main.” The size of “main” is 55 bytes (0x034E – 0x0317 =
address: 8F FF JMP address 0x0037), “function1” is 9 bytes (0x0357 – 0x034E =
0x0009) and “function2” is 9 bytes (0x0360 – 0x0357 =
Note Instruction MOV REG[0xD0],0x0 sets the RAM 0x0009).
page number of the variable “bTest1/bTest2.”

www.cypress.com Document No. 001-60486 Rev. *E 13

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Code 16
while (1)
int bTest; {
void main(void) }
{ address: 8X XX JMP address
bTest = ++bTest;
} The JMP instruction takes five CPU cycles for execution. If
the CPU clock is 24 MHz, then the execution of the JMP
void function1(int a) instruction takes:
{ a++;
1
return; 5 × 24 µ𝑠 = 0.208 µ𝑠
}
At this rate, the CPU executes approximately one (JMP)
void function2(int b) instruction per 0.208 µS = (1/0.208) = 4.8 million
{ b--; instructions per second.
return;
} Example 2:
Consider an example for simple addition as follows.
Figure 32. Flash Calculation Using .mp File
void main(void)
{
BYTE bTest1, bTest2;
while(1)
{
bTest1 = bTest1 + bTest2;
}
}

The corresponding .asm code follows.

BYTE bTest1, bTest2;

while(1)
To calculate the code execution time, you need to know {
the execution time of individual instructions. To find out the bTest1 = bTest1 + bTest2;
execution time of individual instructions, refer to the address1: 52 01 MOV A,[X+1]
Assembly Language User Guide, Appendix A5, address2: 05 00 ADD [X+0],A
“Instruction Set Summary,” in PSoC Designer at Help > }
Documentation > Compiler and Programming address3: 8X XX JMP address1
Documents. The “CPU clock cycles” column of the table
provides the number of CPU clocks required to execute The execution of the previous code takes a total of 6
the instruction. Multiply that value with the CPU clock (MOV) + 8 (ADD) + 5 (JMP) = 19 clock cycles. This is on
period to find out the execution period of an instruction. average 19/3 = 6.33 cycles per instruction. If the CPU
The following examples illustrate the calculation of clock is 24 MHz, then the execution of the entire code
execution time with different codes. takes:
Example 1: Take an empty “while (1)” loop as follows. 19
24,000,000
𝑠 = 0.792 µ𝑠
void main(void)
{ At this rate, the CPU executes one instruction per 0.792/3
while (1) = 0.264 µS or (1/0.264) = 3.79 million instructions per
{ second.
}
}

The corresponding .asm code for the empty “while (1)”

loop generated in the <projectname>.lst file follows.

www.cypress.com Document No. 001-60486 Rev. *E 14

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Conclusion About the Author

These guidelines can help you optimize your code. Some Name: Archana Yarlagadda
of them are specific to the ImageCraft compiler, and some
are general. Following these suggestions during and after Title: Applications Engineer
firmware development helps optimize the code space. All Background: Applications Engineer at Cypress with
the code snippets and snapshots have been tested and focus on PSoC
captured for the CY8C28xxx device and ImageCraft
Standard compiler version 7.0.5. The results will be similar Masters in Analog VLSI from University
for other PSoC 1 devices as well. of Tennessee, Knoxville
Besides following these guidelines, when working with a Contact: msur@cypress.com
smaller flash-size device, a good practice is to watch the
code size increase during project development. Whenever
there is a huge increase in the code space, look at the
map file (Figure 4) to see if any unexpected functions are
being used by the latest part of the code. Knowing the
exact part of the code that causes the flash increase
makes it easier to optimize your code.
For further details on compiler and project optimization
options, refer to the ImageCraft C Compiler Guide and the
ImageCraft Assembly Language Guide.

www.cypress.com Document No. 001-60486 Rev. *E 15

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Document History
Document Title: PSoC® 1 M8C ImageCraft C Code Optimization – AN60486
Document Number: 001-60486

Revision ECN Orig. of Submission Description of Change

Change Date

** 2994124 YARA 07/27/2010 New Application Note.

*A 3330339 YARA 07/27/2011 Rewritten based on customer feedback
*B 3565784 MSUR 03/29/2012 Updated all the snapshots to latest Designer version
Added a section to describe compiler options of ImageCraft Pro
Changed ‘Technique’ word to ‘Guideline’ to match AN60630
Changed Code 1 to reflect a common use case of Condensation
Added Codes to Guideline#6 and #2 (Maintaining Consistency in data type
Updated all sections to comply with the latest PSoC Designer.
Updated abstract.
Updated template.
*C 4088730 MSUR 8/6/2013 Added link to AN75320 – Getting Started with PSoC 1
Added Figure 12
Updated the links on how to reach compiler settings in all sections
Updated Guideline#2 (Avoid floating-point calculation) per the updated Arithmetic
Libraries Guide
Minor document updates based on feedback
*D 4429390 ASRI 07/03/2014 Removed Guideline #5: Initializing Global Variables. This requirement is already
taken care of by updated version of the compiler.
Added Guideline #6: Bit manipulation in PSoC 1
Added Guideline #7: Calculating flash usage and execution time of C code
Added Figure 31. Address and Memory Details in .mp File
Added Figure 32. Flash Calculation Using .mp

*E 4476944 MSUR 08/18/2014 No technical updates.

Completing Sunset Review.

www.cypress.com Document No. 001-60486 Rev. *E 16

 ®
PSoC 1 M8C ImageCraft C Code Optimization nt

Worldwide Sales and Design Support

Cypress maintains a worldwide network of offices, solution centers, manufacturer’s representatives, and distributors. To find
the office closest to you, visit us at Cypress Locations.

Products PSoC® Solutions

Automotive cypress.com/go/automotive psoc.cypress.com/solutions
Clocks & Buffers cypress.com/go/clocks PSoC 1 | PSoC 3 | PSoC 4 | PSoC 5LP
Interface cypress.com/go/interface
Cypress Developer Community
Lighting & Power Control cypress.com/go/powerpsoc
cypress.com/go/plc Community | Forums | Blogs | Video | Training
Memory cypress.com/go/memory
PSoC cypress.com/go/psoc Technical Support
Touch Sensing cypress.com/go/touch cypress.com/go/support

USB Controllers cypress.com/go/usb

Wireless/RF cypress.com/go/wireless

PSoC is a registered trademark of Cypress Semiconductor Corp. PSoC Creator and PSoC Designer are trademarks of Cypress Semiconductor Corp.
All other trademarks or registered trademarks referenced herein are the property of their respective owners.

Cypress Semiconductor Phone : 408-943-2600

198 Champion Court Fax : 408-943-4730
San Jose, CA 95134-1709 Website : www.cypress.com

© Cypress Semiconductor Corporation, 2010-2014. The information contained herein is subject to change without notice. Cypress Semiconductor
Corporation assumes no responsibility for the use of any circuitry other than circuitry embodied in a Cypress product. Nor does it convey or imply any
license under patent or other rights. Cypress products are not warranted nor intended to be used for medical, life support, life saving, critical control or
safety applications, unless pursuant to an express written agreement with Cypress. Furthermore, Cypress does not authorize its products for use as
critical components in life-support systems where a malfunction or failure may reasonably be expected to result in significant injury to the user. The
inclusion of Cypress products in life-support systems application implies that the manufacturer assumes all risk of such use and in doing so indemnifies
Cypress against all charges.
This Source Code (software and/or firmware) is owned by Cypress Semiconductor Corporation (Cypress) and is protected by and subject to worldwide
patent protection (United States and foreign), United States copyright laws and international treaty provisions. Cypress hereby grants to licensee a
personal, non-exclusive, non-transferable license to copy, use, modify, create derivative works of, and compile the Cypress Source Code and derivative
works for the sole purpose of creating custom software and or firmware in support of licensee product to be used only in conjunction with a Cypress
integrated circuit as specified in the applicable agreement. Any reproduction, modification, translation, compilation, or representation of this Source
Code except as specified above is prohibited without the express written permission of Cypress.
Disclaimer: CYPRESS MAKES NO WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, WITH REGARD TO THIS MATERIAL, INCLUDING, BUT
NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. Cypress reserves the
right to make changes without further notice to the materials described herein. Cypress does not assume any liability arising out of the application or
use of any product or circuit described herein. Cypress does not authorize its products for use as critical components in life-support systems where a
malfunction or failure may reasonably be expected to result in significant injury to the user. The inclusion of Cypress’ product in a life-support systems
application implies that the manufacturer assumes all risk of such use and in doing so indemnifies Cypress against all charges.
Use may be limited by and subject to the applicable Cypress software license agreement.

www.cypress.com Document No. 001-60486 Rev. *E 17