read.pudn.comread.pudn.com/downloads129/sourcecode/others/553272/altium des… · All rights...

LiveDesign Training Module

Document Version 1.1, May 2007 Software, documentation and related materials: Copyright © 2007 Altium Limited. All rights reserved. You are permitted to print this document provided that (1) the use of such is for personal use only and will not be copied or posted on any network computer or broadcast in any media, and (2) no modifications of the document is made. Unauthorized duplication, in whole or part, of this document by any means, mechanical or electronic, including translation into another language, except for brief excerpts in published reviews, is prohibited without the express written permission of Altium Limited. Unauthorized duplication of this work may also be prohibited by local statute. Violators may be subject to both criminal and civil penalties, including fines and/or imprisonment. Altium, Altium Designer, Board Insight, CAMtastic, CircuitStudio, Design Explorer, DXP, LiveDesign, NanoBoard, NanoTalk, Nexar, nVisage, P-CAD, Protel, SimCode, Situs, TASKING, and Topological Autorouting and their respective logos are trademarks or registered trademarks of Altium Limited or its subsidiaries. Microsoft, Microsoft Windows and Microsoft Access are registered trademarks of Microsoft Corporation. OrCAD, OrCAD Capture, OrCAD Layout and SPECCTRA are registered trademarks of Cadence Design Systems Inc. AutoCAD is a registered trademark of AutoDesk Inc. HP-GL is a registered trademark of Hewlett Packard Corporation. PostScript is a registered trademark of Adobe Systems, Inc. All other registered or unregistered trademarks referenced herein are the property of their respective owners and no trademark rights to the same are claimed. Module 6

Altium Designer Training LiveDesign

i

LiveDesign Training Module 1 LiveDesign..................................................................................................................6-1

1.1 Learning objectives.........................................................................................6-1 1.2 Topic outline ...................................................................................................6-1

2 Introduction to LiveDesign.......................................................................................6-2 3 Embedded application development.......................................................................6-3

3.1 Creating an embedded Project.......................................................................6-3 3.2 Editor basics ...................................................................................................6-4 3.3 Exercise 1 – Editor familiarization ..................................................................6-9

4 The TASKING tool chain ........................................................................................ 6-10 4.1 The build flow............................................................................................... 6-10 4.2 Targeting the project.................................................................................... 6-11 4.3 Project options ............................................................................................. 6-11 4.4 C compiler options ....................................................................................... 6-12 4.5 Assembler options ....................................................................................... 6-17 4.6 Linker options .............................................................................................. 6-19 4.7 Compiler output ........................................................................................... 6-22 4.8 Exercise 2 – First compile ........................................................................... 6-22

5 Utilizing microprocessor softcores ...................................................................... 6-23 5.1 How soft is a softcore? ................................................................................ 6-23 5.2 Using a softcore in an FPGA schematic...................................................... 6-24 5.3 On-chip debugging or not? .......................................................................... 6-24 5.4 Exercise 3 – Placing a softcore onto an FPGA schematic .......................... 6-25

6 Linking an embedded project to the hardware design....................................... 6-27 6.1 Project hierarchies ....................................................................................... 6-27 6.2 Attaching an embedded project to an FPGA project ................................... 6-28 6.3 Linking program memory to the processor core.......................................... 6-30 6.4 Exercise 4 – Linking projects....................................................................... 6-31

7 Putting wheels on LiveDesign............................................................................... 6-32 7.1 The printf dilemma.................................................................................. 6-32 7.2 Initializing the LCD....................................................................................... 6-32 7.3 Exercise 5 – Using LiveDesign to initialize an LCD..................................... 6-34

8 Debugging the design............................................................................................ 6-42 8.1 A word about simulation .............................................................................. 6-42 8.2 The Debug menu......................................................................................... 6-42 8.3 Embedded control panels............................................................................ 6-44 8.4 Exercise 6 – Code Debug............................................................................ 6-50

9 Advanced compiler features ................................................................................. 6-51 9.1 C language extensions ................................................................................ 6-51 9.2 Supported data types .................................................................................. 6-51 9.3 Memory type qualifiers................................................................................. 6-52 9.4 Accessing hardware from C: __sfr, __bsfr .................................................. 6-54 9.5 Placing an object at an absolute address: __at() ........................................ 6-56 9.6 Declaring interrupt functions........................................................................ 6-56 9.7 Incorporating assembly in C code ............................................................... 6-58 9.8 Real-Time Operating System (RTOS)......................................................... 6-62 9.9 Exercise 7 – PWM measurement ................................................................ 6-63

10 Review ..................................................................................................................... 6-65


6 - 1

1 LiveDesign The primary objective of Day 2 is to make participants proficient in the process of developing, downloading and running Embedded Software from the Altium Designer environment. We will highlight the software authoring and debugging features of Altium Designer as well as develop a small, embedded application that can be run on the NanoBoard.

1.1 Learning objectives • To be competent in developing embedded applications under the Altium Designer environment. • To understand how to include an embedded processor core into an FPGA design and link an

embedded project to that core. • To be competent in the debugging environment offered under Altium Designer. • To understand how to tune the compiler settings for a given application.

1.2 Topic outline

Core topics Advanced topics (time permitting)

Advanced compiler features

Using an FPGA

softcore

Linking code &

hardware

LiveDesign

The TASKING compiler tool chain

Working “Hello World”

project Code

debugging

Introduction to the text

editor

Figure 1. Topic outline for Day 2 – LiveDesign


2 Introduction to LiveDesign “Debugging is twice as hard as writing the code in the first place.

Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.“

Brian W. Kernighan Altium Designer supports a new approach to electronics development – called LiveDesign. LiveDesign is an integrated electronics system design methodology that is based on 'live' engineering inside a programmable physical hardware design space. LiveDesign-enabled tools provide real-time communication and ‘hands-on’ interaction between you and your design during the development process. LiveDesign allows you to run real software on real hardware in real time, right from the start of the design cycle! LiveDesign is supported in Altium’s design systems with the inclusion of ready-to-use FPGA-based components such as processor cores, generic logic blocks and FPGA-based virtual instruments. Full software development toolchains for the supplied processors are integrated with the hardware development environment and provide an interactive and scalable development environment for the design of both system hardware and software. In summary, LiveDesign allows you to: • Reduce development costs and time-to-market by working in a fully-integrated

design/implementation/test environment • Interact in ‘real-time’ with your design throughout the development process • Design hardware and software concurrently and in parallel • Probe, analyze and debug your design as you would a physical prototype using FPGA-based

virtual instruments • Delay commitment to final hardware until late in the design cycle • Update your design hardware at any time without time or cost penalties • Integrate complex digital circuits, including processor-based designs, into an FPGA without the

need for HDL coding or RTL-level simulation experience Today’s session will introduce you to the LiveDesign approach and how you can utilize it in your next embedded design. It is assumed that attendees to this session will have completed the previous session on FPGA design.

6 - 2


3 Embedded application development 3.1 Creating an embedded Project Source code that is to execute on a single processor should be contained within an embedded project (*.PrjEmb). Creating an embedded project is much the same as creating any project. From the menu select File » New » Project » Embedded Project. An empty embedded project will be created in the current workspace. We will then create a number of source files to contain your application. Altium Designer contains a C cross compiler and assembler for each of its supplied soft processors. The compiler determines how to treat a file (compile or assemble) based on its file extension. C code should reside in a file with the extension .C, assembly code should reside in files with the extension .ASM. To add an empty source file to the embedded project, right-click the embedded project in the Projects panel and select Add New to Project » Assembly File or C File.

Figure 2. Adding a new source file to an embedded Project.

6 - 3


3.2 Editor basics • The editor included with Altium Designer is a Language

Sensitive Editor and is capable of applying a number of visual enhancements to the source code to make it more readable and compliant with company coding practices.

• The primary point of interaction with the Editor features is from the Tools menu:

• Show Code Templates will allow the user to insert predefined code templates (Figure 4) at the current cursor location within the file. The user can add additional templates from within the Language Setup dialog box (Figure 5 & Figure 7).

• Indent will force the currently highlighted lines to be indented one level.

• Unindent will remove one level of indentation from the currently highlighted lines.

• Change Case will apply various case changing edits to the currently selected items in the editor.

• Word Wrap will simply wrap a line that extends beyond the page size to the next line.

Figure 3. Tools menu.

• Formatting Options… launches the main Preferences dialog box and displays settings relating to the Code Formatting (Figure 8 & Figure 9).

• Format Source Code immediately applies the current format settings to the currently opened file. • Import Editor Settings from enables previously saved editor preferences and settings to be

imported into the current project. • Editor Preferences launches the main Preferences dialog box and displays settings relating to

the Text Editor (Figure 10, Figure 11 & Figure 12). The Edit Syntax… button (Figure 12) is the controlling point for setting up all features specific to a given language such as syntax highlighting styles, reserved words, and comment handling etc. (Figure 13).

• Embedded Preferences launches the main Preferences dialog box and displays the embedded system settings (Figure 14).

Figure 4. Predefined code templates.

To use the editor’s autocomplete features, type the text as it appears in bold on the right hand side of Figure 4 and select Ctrl-J. Selecting Ctrl-J next to a block of text which is not known as an autocomplete statement will bring up the Code Templates list as shown in Figure 4.

Altium Designer uses two different mechanisms for determining how it handles different file types. The Associations setting in the Language Setup dialog simply defines how the editor will display the syntax of the file. The existence of a file association in the Language Setup dialog does not dictate how Altium Designer will treat the file. A system file called <Install Dir>\System\FileExtensions.Txt defines how the file is to be treated by the Altium Designer platform. Only specific file types are considered as ‘Source Documents’. Other file types not listed in FileExtensions.Txt are treated as ‘Documentation’. It

6 - 4


is therefore important how files are labeled otherwise they will not be properly included when the project is built.

Figure 5. Language setup dialog box.

Figure 6. Only specific files known to Altium Designer can be used as ‘Source Documents’.

Figure 7. Code templates editor.

6 - 5


3.2.1 Code formatting

Figure 8. Specifying general code formatting options.

Figure 9. Specifying general code formatting options to apply to how code is spaced.

6 - 6


3.2.2 Text editor settings

Figure 10. General text editor settings.

Figure 11. Text editor settings controlling overall visual appearance

6 - 7


Figure 12. Text editor settings controlling how specific items are highlighted/colored.

3.2.3 Syntax highlighting

Figure 13. Syntax editor/options.

6 - 8


3.2.4 General options

Figure 14. General embedded systems document options.

3.3 Exercise 1 – Editor familiarization 1. Open a new embedded project. Save it as HelloWorld.PrjEmb. 2. Open a new C File. Save it as HelloWorld.C 3. Insert the following lines of code from the Hello World application (Figure 15).

Figure 15. Hello World Source code.

4. If time permits, experiment with some of the editor settings to see their effect on the source code. Remember to select Tools » Format Source Code after making each change.

5. Save your work.

6 - 9


4 The TASKING tool chain Many long-time users of Protel are familiar with its advanced schematic and PCB capabilities and can understand how schematic-based FPGA development is a natural extension of Altium’s core technologies. Delving into the world of embedded systems programming however represents a significant departure from the hardware focus that Protel has previously had and some may question just how serious a player Altium intends to be in this market. The reality is that Altium, through their corporate acquisition of TASKING, are already a major player in the embedded systems marketplace. TASKING products are world-leading tools for embedded software development, bringing together the advanced software design technology needed to compete in the embedded communications era. The award-winning TASKING integrated development environment, compiler, debugger, embedded Internet and RTOS offerings support a wide range of DSPs and 8-, 16- and 32-bit microprocessors and microcontrollers for all areas of embedded development. With over 100,000 licensed users of TASKING products, including the world's leading telecom, datacom, wireless and peripheral manufacturers, the TASKING product range has a long history of technology leadership and innovation.

4.1 The build flow

Figure 16. The TASKING tool chain.

6 - 10


Building an application is the process of compiling all of the top-level source documents into a binary file that can be executed by a target processor. This is a multi-step process involving a number of tools. In many situations, the user will be shielded from the detail of the underlying compilation processes however in some circumstances it will be necessary to diagnose the source of build or compilation errors and for this it is important to understand the compilation flow. The C compiler, assembler and debugger are target dependent, whereas the linker and the librarian are target independent. The bold names in Figure 16 are the executable names of the tools. Substitute target with one of the supported target names, for example, c51 is the 8051 C compiler and cz80 is the Z80 C compiler.

4.2 Targeting the project Prior to compiling an embedded project, it is necessary to notify the compiler of which processor we intend to use and any special compilation features we may wish to include. This is done via the Project Options dialogue box that can be accessed by right-clicking the Embedded Project in the Projects panel and selecting Project Options panel or by selecting Project » Project Options from the main menu.

Figure 17. Specifying options for an embedded project.

4.3 Project options

4.3.1 Processor class Select from TASKING 165x, TASKING 8051 or TASKING Z80 processor families. These processors are instruction set compatible with the PIC16CX, Intel 8051 and Zilog Z80 industry standard processors respectively.

4.3.2 Processor definition The only processor class that currently contains an option at this point is the 165x. There is a TSK165A, TSK165B, and TSK165C variant. The following table summarizes their differences:

Feature TSK165A TSK165B TSK165C

Addressable program memory 512*12 2K*12

Data memory 16 + 9 bytes 64 + 9 bytes

Program Counter width 9 bits 11 bits

Stack width 9 bits 11 bits

Same features as TSK165B, plus three additional 8-bit ports.

6 - 11


4.3.3 Startup code The defaults are generally acceptable for the majority of projects. If you should ever choose not to include the default startup code produced by the compiler you will have to assume the responsibility of handling the reset interrupt, initializing memory variables, and passing control to the main function in the C source code.

4.4 C compiler options The Compiler is functionally responsible for parsing the high-level C source commands and reducing them to atomic operations that can be easily mapped onto the target processor’s instruction set. This process involves a number of phases including (but not limited to):

1. Preprocessing 2. High-level Optimization 3. Instruction selection 4. Peephole Optimization / Instruction Scheduling 5. Register Allocation 6. Low-level Optimization 7. Code formatting.

Due to the vast variation in requirements and optimization goals, it is not possible to have a “one setting suits all” compiler. Subsequently a number of compiler options are made visible to the user so that the compilation process can be tuned to the specific application. These options are discussed further below:

4.4.1 Memory model Only the 8051 has options for the memory model. By default, the small memory model is selected however the TASKING C compiler also supports a large and auxiliary page memory model:

Memory model Description Max. RAM size Default memory type

Small Direct addressable internal RAM 128 bytes __data

Auxiliary page One page of external RAM 256 bytes __pdata

Large External RAM 64 kB __xdata

The exact size of the different memory segments can be defined in the Linker – Memory section of the Project Options dialogue box. By default the 8051 compiler uses the small memory model. In the small memory model all data objects with the default memory type and the stack (used for function parameter passing) must fit in the internal RAM. Objects with an explicit memory type qualifier can exceed this limitation (for example an object qualified as __xdata or __pdata). Note that the stack length depends upon the nesting depth of the various functions. Accessing data in internal RAM is considerably faster than accessing data in external RAM. Therefore, it is useful to place often used variables in internal data memory and less often referenced data elements in external data memory. When the compiler uses the large memory model to access data, the produced code is larger and in some cases slower than the code for a similar operation in one of the other memory models. The auxiliary page memory model is especially interesting for derivatives with 256 bytes of 'external' RAM on chip. All data objects with the default memory type must fit in one 256 bytes page. Optionally you can choose to enable reentrancy. If you select reentrancy, a (less efficient) virtual dynamic stack is used which allows you to call functions recursively. With reentrancy, you can call functions at any time, even from interrupt functions.

6 - 12


C Compiler - Memory model (8051 only)

Memory model option Command line

Select a compiler memory model -M[a | l | s]

Allow reentrant functions --reentrant

4.4.2 Code generation The only item that may need to be altered in this panel would be the Strings option. Copy strings from ROM to RAM at startup may cause more RAM than would otherwise be absolutely necessary to be consumed when the project is built. On the other hand, accessing strings from RAM is generally quicker.

C Compiler - Code generation

Code generation options Command line

Copy strings from ROM to RAM at startup no option

Keep strings in ROM (8051 only) --romstrings

Do not generate code for interrupt vector --novector

Reset/interrupt vector offset --vector-offset=address

Do not generate frame for interrupt handler --noframe

Do not allow absolute registers (AR0-AR7) in generated code (8051 only)

--noregaddr

4.4.3 Preprocessing This section is helpful if it is necessary to define preprocessor macros that will direct conditional compilation in the source. For example you may wish to declare a macro called DEBUG_MODE and use conditional compilation in your source code depending on whether this macro was defined: #ifdef DEBUG_MODE do something... #else do normal processing... #endif

C Compiler - Preprocessing

Preprocessing options Command line

Define macro -Dmacro[=def]

Include this file before source -Hfile

Store the C Compiler preprocess output (file.pre)

-E

4.4.4 Optimization The TASKING C compilers offer four optimization levels and a custom level. At each level a specific set of optimizations is enabled. • Level 0: No optimizations are performed. The compiler tries to achieve a 1:1 resemblance

between source code and compiled code. Expressions are evaluated in the order written in the source code, associative and commutative properties are not used.

• Level 1: Enables optimizations that do not affect the debug-ability of the source code. Use this level when you are developing/debugging new source code.

6 - 13


• Level 2: Enables more aggressive optimizations to reduce the memory footprint and/or execution time. The debugger can handle this code but the relation between source code and generated instructions may be hard to understand. Use this level for those modules that are already debugged. This is the default optimization level.

• Level 3: Enables aggressive global optimization techniques. The relation between source code and generated instructions can be very hard to understand. The debugger does not crash, will not provide misleading information, but does not fully understand what is going on. Use this level when your program does not fit in the memory provided by your system anymore, or when your program/hardware has become too slow to meet your real-time requirements.

• Custom level: you can enable/disable specific optimizations.

Figure 18. Specifying code optimization options for an embedded project.

C Compiler - Optimization

Optimization options Command line

Optimization level Custom optimization

-O[0|1|2|3] -Oflag

Optimize for size / speed -t{0|4}

6 - 14


4.4.5 Language Defaults are usually adequate however on the odd occasion you may wish to build code that is pre ISO C 99 compatibility and you will need the options contained in this panel.

C Compiler - Language

Language options Command line

ISO C standard 90 or 99 (default: 99) -c{90|99}

Language extensions: Allow C++ style comments in C source Relaxed const check for string literals

-Ap -Ax

Treat 'char' variables as unsigned -u

Treat 'int' bitfields as signed --signed-bitfields

Always use 16-bit integers for enumerations --integer-enumeration

4.4.6 Debug information In general it is helpful to always generate debug information unless building for a final production release where debug information would be superfluous.

C Compiler – Debug information

Debug information options Command line

Generate symbolic debug information -g

4.4.7 Floating point In general the default setting (i.e. floating point trap/exception handling checked) is acceptable unless you have good reason to change it.

4.4.8 Diagnostics This section controls how compilation warnings are reported. In some cases it may be desirable to suppress specific warnings if they are creating too much ‘noise’ in the Messages Panel.

C Compiler - Diagnostics

Diagnostics options Command line

Report all warnings Suppress all warnings Suppress specific warnings

no option -w -w -wnum[,num]...

Treat warnings as errors --warnings-as-errors

4.4.9 MISRA C & MISRA C Rules The Motor Industry Software Reliability Association (MISRA) is in existence “To provide assistance to the automotive industry in the application and creation within vehicle systems of safe and reliable software.” Through extensive consultation within the automotive industry, MISRA has completed the development of guidelines specifically aimed at the use of the C language in safety related systems. These guidelines primarily identify those aspects of the C language that should be avoided in safety-related systems, along with other recommendations on how other features of the language should be used. It is anticipated that the guidelines will be adopted for embedded C programming throughout the automotive industry. Altium Designer includes a number of compilation options that can flag as a warning code that does not comply with MISRA recommendations.

6 - 15


C Compiler - MISRA C

MISRA C options Command line

MISRA C rules --misrac={all|nr[-nr] ,...}

4.4.10 Miscellaneous Use this section to pass any compiler flags or settings that have not been covered in the previous panels. The Options String at the base of the compiler settings panel provides an indication of the options that will be passed to the C compiler. Further information about each individual setting can be found in GU0105 Embedded Tools Users Guide.pdf or via the help system under Embedded Software Development » Embedded Tools Options Reference » Compiler Options.

C Compiler - Miscellaneous

Miscellaneous options Command line

Merge C source code with assembly in output file (.src) -s

Additional C Compiler options options

Command line only

Description Command line

Display invocation syntax -? / --help[=item,...]

Default register bank [0..3] (8051 only) -bn

Maximum size of a match with code compaction (default: 200)

--compact-max-size=value

Show description of diagnostic(s) --diag=[fmt:]{all|nr,...}

Redirect diagnostic messages to a file --error-file[=file]

Use single precision floating point only -F

Read options from file -ffile

Always inline function calls --inline

Maximum size increment inlining (in %) (default: 25) --inline-max-incr=value

Maximum size for function to always inline (default: 10) --inline-max-size=value

Keep output file after errors -k

Maximum call depth, default infinite (-1) --max-call-depth=value

Send output to standard output -n

Do not clear non-initialized global variables --noclear

Specify name of output file -ofile

Rename default section name -R[type]={name | -f | -m | -fm}

Treat external definitions as "static" --static

Remove preprocessor macro -Umacro

Display version header only -V

Max. nr. of bytes for automatic regs. (default: 4) (8051 only)

-xvalue

6 - 16


4.5 Assembler options The assembler converts hand-written or compiler-generated assembly language programs into machine language, using the IEEE-695 object format. These files serve as input for the linker. Phases of the assembly process

1. Preprocess directives 2. Check syntax of instructions 3. Instruction grouping and reordering 4. Optimization (instruction size and jumps to branches) 5. Generation of the relocatable object file and optionally a list file

Figure 19. Specifying assembler options for an embedded project.

The Project Options… dialogue box contains a number of assembler options. The subsections of the assembler options allow for additional control over the assembler in much the same way that the previously mentioned compiler options do. The default options are generally sufficient for most applications. However, should you find it necessary to tune the assembler, then further information can be found in GU0105 Embedded Tools Users Guide.pdf or via the help system under Embedded Software Development » Embedded Tools Options Reference » Assembler Options. A summary of the available assembler options are listed below:

Assembler - preprocessing

Preprocessing options Command line

Define macro -Dmacro[=def]

Include this file before source -Hfile

Assembler - optimization


Generic instructions -Og

Instruction size -Os

6 - 17


Assembler - debug information

Debug information options Command line

No debug information -gAHLS

Automatic HLL or assembly level debug information -gs

Custom debug information -gflags

Assembler - list file

List file options Command line

Generate list file -l

Display section information in list file -tl

Suboptions for the Generate list file option -Lflags

Assembler - diagnostics





Assembler - miscellaneous


Assemble case sensitive no option-c

Labels are by default: - local (default) - global

-il -ig

Additional assembler options options

Command line only


Display invocation syntax -? / --help


Emit local symbols --emit-locals

Redirect diagnostic messages to a file --error-file[=file]



Select TASKING preprocessor or no preprocessor -m{t|n}

Specify name of output file -ofile

Generate NOPs for ROM monitor support (8051 only) --rom-monitor-nops

Use strict assembly syntax (Z80 only) --strict

Enable expression type checking --type-checking

6 - 18


Verbose information -v


Use Zilog assembly syntax (Z80 only) --zilogsyntax

4.6 Linker options

Figure 20. Specifying linker options for an embedded project.

The linker combines and transforms relocatable object files (.obj) into a single absolute object file. This process consists of two phases: the linking phase and the locating phase. In the first phase the linker combines the supplied relocatable object files (.obj files, generated by the assembler) and libraries into a single relocatable object file. In the second phase, the linker assigns absolute addresses to the object file so it can actually be loaded into a target. The linker can simultaneously link and locate all programs for all cores available on a target board. The target board may be of arbitrary complexity. A simple target board may contain one standard processor with some external memory that executes one task. A complex target board may contain multiple standard processors and DSPs combined with configurable IP-cores loaded in an FPGA. Each core may execute a different program, and external memory may be shared by multiple cores. Most linker options can be controlled via the project options dialog but some options are only available as command line switches. The default options are generally sufficient for most applications however should you find it necessary to tune the linker then further information can be found in GU0105 Embedded Tools Users Guide.pdf or via the help system under Embedded Software Development » Embedded Tools Options Reference » Linker Options. A summary of the available linker options are listed below:

Linker - output format

Output format options Command line

Absolute file for debuggers -o[filename][:format[:addr_size][,space]]...

Intel Hex records or Motorola S-records for EPROM programmers

-c[basename]:format[:addr_size],...

6 - 19


Linker - libraries

Libraries options Command line

Link default C libraries -lx

(Do not) rescan libraries to solve unresolved externals

--no-rescan

Linker - optimization


Use a 'first fit decreasing' algorithm -Ol / -OL

Emit smart restrictions to reduce copy table size -Ot / -OT

Linker - map file

Map file options Command line

Generate a map file (.map) -M

Suboptions for the Generate a map file option -mflags

Linker - diagnostics





Linker - miscellaneous


(Do not) include symbolic debug information -S (strip debug)

Print the name of each file as it is processed -v

Link case sensitive (required for C language) no option --case-insensitive

Dump processor and memory info from LSL file --lsl-dump[=file]

Link incrementally --incremental

Use project specific linker script file -dfile

Additional linker options options

6 - 20


Command line only


Display invocation syntax -? / --help

Define preprocessor macro -Dmacro[=def]


Specify a symbol as unresolved external -esymbol

Redirect diagnostic messages to a file with extension .elk

--error-file[=file]


Scan libraries in given order --first-library-first

Search only in -L directories, not in default path --ignore-default-library-path


Link only, do not locate --link-only

Check LSL file(s) and exit --lsl-check

Do not generate ROM copy -N

Locate all ROM sections in RAM --non-romable


6 - 21


4.7 Compiler output Files generated as a result of the build process are, by default, stored in the same directory as the source files. To separate generated files from the source files, place an entry into the Output Directory (instead of project directory): text box under the Build Options tab of the Project Options… dialogue box.

Figure 21. Controlling the location of compiler output.

4.7.1 To compile a single source file: • Open the document in the main window and select Project » Compile Document {docname}. • Right-click on the document in the Projects panel and select Compile Document {docname}.

4.7.2 To compile an entire embedded project: Open any one of the project’s source documents and select Project » Compile Embedded Project project_name or select Project » Recompile Embedded Project project_name. Right-click on the project in the Projects panel and select Compile Embedded Project project_name or select Recompile Embedded Project project_name.

4.8 Exercise 2 – First compile This exercise follows on from the previous exercise. 1. Right click on the embedded project in the Projects panel and select the Project Options…

menu item. 2. Set the Configuration to TASKING TSK51x/TSK52x. 3. Under the Build Options section, ensure that the Output directory is set to ‘Generated’ (See

Figure 21). 4. Click OK to close the dialog box. 5. Compile the Project. If any errors result, fix those errors. 6. Observe the files generated by the compiler. Scan through these files to satisfy yourself of their

contents.

6 - 22


5 Utilizing microprocessor softcores An application is of no use without a target system for it to run on. In this section we will put the finishing touches to an FPGA project that will contain a microprocessor softcore and serve as the basis for our embedded platform.

5.1 How soft is a softcore? Altium Designer comes bundled with a number of pre-verified, pre-synthesized microprocessor softcores that can be incorporated into an FPGA project and execute application code. These processors are labeled as soft because they are implemented as a downloadable core that runs from an FPGA device rather than as a hard physical microprocessor in its own distinct package. By utilizing softcores, the designer can select the most appropriate core for a given application without needing to modify hardware.

Figure 22. Pictorial representation of a softcore loaded onto an FPGA device.

6 - 23


5.2 Using a softcore in an FPGA schematic Building an FPGA project that incorporates a softcore is no different from building any other FPGA project; you simply select components from a library and place them onto your schematic. The FPGA softcores can be accessed from the integrated library: <Altium>/Library/FPGA/FPGA Processors.IntLib

Figure 23. FPGA Processors.IntLib library contents with popup Help menu.

This library will grow as more and more processor cores become available.

5.2.1 Accessing softcore datasheets Detailed data sheets can be accessed for each device by highlighting the device and selecting the F1 key or by right-clicking the device and selecting Show Help for … (see Figure 23).

5.3 On-chip debugging or not? When looking through the list of processors, you will notice the existence of ‘OCD’ microcontrollers and non-OCD microcontrollers. The OCD microcontrollers contain additional On Chip Debugging resources which are necessary if you wish to make use of Altium Designer’s debugging features. One notable difference between the two microcontrollers is the existence of program memory write resources on the OCD version. This is necessary since the debugger requires write access to program memory so that it can place breakpoints in program memory when breaking or stepping through code. Thus when using the OCD version, program memory must be comprised of read/write memory. In general it is advisable to use the OCD version during development and switch back to the non-OCD version for production.

6 - 24


6 - 25

TSK51A Microprocessor

CLKRSTEA

SFRDATAO[7..0]SFRDATAI[7..0]

SFRADDR[6..0]SFRWRSFRRD

ROMDATAI[7..0]

ROMADDR[15..0]

ROMRD

INT0INT1

T0T1

RXDTXDRXDO

P0O[7..0]P0I[7..0]

P1O[7..0]P1I[7..0]

P2O[7..0]P2I[7..0]

P3O[7..0]P3I[7..0]

MEMDATAO[7..0]MEMDATAI[7..0]

MEMADDR[15..0]MEMWRMEMRD

PSRD

U1

TSK51ATSK51A OCD Microprocessor

CLKRSTEA



ROMDATAO[7..0]ROMDATAI[7..0]

ROMADDR[15..0]ROMWRROMRD

INT0INT1

T0T1

RXDTXDRXDO

P0O[7..0]P0I[7..0]

P1O[7..0]P1I[7..0]

P2O[7..0]P2I[7..0]

P3O[7..0]P3I[7..0]



PSWRPSRD

U1_OCD

TSK51A_D Figure 24. Comparing non-OCD and OCD microcontrollers.

5.4 Exercise 3 – Placing a softcore onto an FPGA schematic A semi-complete project has been created in preparation for this exercise. Your instructor will tell you where to find it on your local hard drive.

1. Open the FPGA_HelloWorld.PrjFpg FPGA project and open FPGA_HelloWorld.SchDoc. Observe that no softcore has currently been placed.

2. Select the TSK51A_D processor from the FPGA Processors.IntLib library and place it onto the schematic. Your schematic should appear the same as Figure 25.

3. Ensure that the pins of the softcore component are correctly connected. 4. Annotate the softcore component and save your work.

Altium Designer Training Module LiveDesign

6 - 26

TSK51A OCD Microprocessor

CLKRSTEA





INT0INT1

T0T1

RXDTXDRXDO

P0O[7..0]P0I[7..0]

P1O[7..0]P1I[7..0]

P2O[7..0]P2I[7..0]

P3O[7..0]P3I[7..0]



PSWRPSRD

U3

TSK51A_D

[7..0]

[7..0]

U2

IOBUF8B

LCD_E P89P89LCD_RW P166P166LCD_RS P164P164LCD_DB[7..0]

P88,P87,P86,P84,P83,P82,P81,P75P88,P87,P86,P84,P83,P82,P81,P75

LCD_LIGHT P94P94

2 x 16 Liquid Crystal Display

I[7..0] O0O1O2O3O4O5O6O7

U5

J8B_8S

GND

GND

[11..0][11..0]

CLK_BRDP182P182

CLK

DELAY[7..0]

INIT

U6

FPGA_STARTUP8

U4

OR2N1SVCC

TEST_BUTTONP3P3

JTAG_NEXUS_TMS P10P10JTAG_NEXUS_TCK P9P9JTAG_NEXUS_TDO P11P11JTAG_NEXUS_TDI P8P8

TCKTMS

TDITDO

TRST

JTAG

.

JTAG

JTAG

JTAG

JTAG

JTAG

..VCC

LEDS[7..0]


CLK_BRD

LEDS[7..0]

CLKDOUT[7..0]

ADDR[11..0]

DIN[7..0]

WE

U1

RAMS_8x4K

Reset

CLK_BRD should be set to 50MHz

Frequency Counter

FREQAFREQB

TIMEBASE

U7

FRQCNT2

CLK_BRD

O[15..0]IA[7..0]

IB[7..0]

U9

J8B2_16B

CLK_BRD

Logic Analyser

CLKCLK_CAPCHANNELS[15..0]

TRIGGER

STATUSU8

LAX_1K16

Figure 25. Schematic with the TSK51A_D softcore placed.


6 - 27

6 Linking an embedded project to the hardware design

Figure 26. LCD_Keypad structural view

Having created an FPGA schematic that incorporates a softcore, the next task is to link the application code to the softcore so that they get compiled together.

6.1 Project hierarchies

Figure 27. Possible project hierarchy for a design containing multiple projects.

The hierarchy of the LCD_Keypad project is given below.

Furthermore the LCD_Keypad FPGA project also makes use of a core component called KeyPadScanner which has been defined as a core project (extension .PRJCOR). A PCB Project may contain one or more FPGA projects but never the other way around. If you think about it you will recognize that it is quite intuitive; a PCB contains FPGAs whereas an FPGA can’t contain a PCB. Similarly, an FPGA could contain one or more custom FPGA cores or microprocessor softcores. A unique Core Project will define each FPGA core component and a unique Embedded Project will define the software that executes on each of the softcores.

Altium Designer supports a fully hierarchical design approach. As such it is possible for some projects to contain other projects within them. Figure 24 shows a structural view of the LCD_Keypad design that is distributed as an example in the Altium Designer installation. From this view we can observe the hierarchy of the different projects involved. The top-level project is an FPGA project called LCD_Keypad and has the filename extension PRJFPG. Within the FPGA design is an instance of the TSK51 embedded softcore. The program or software that this embedded softcore executes is contained within another project called LCD.PrjEmb.

PRJEMB

PRJFPG

PRJPCB PCB Pro

FPGA Pro

ject

Embedded Pro

ject

jectSource code for a program that will execute on a single Softcore

Output is a sin

Output is a sin

g

g

le FPGA

le PCB


6.2 Attaching an embedded project to an FPGA project Creating a link between the softcore and its associated embedded code ensures that correct code / processor coupling is made. It also ensures that subsequent project builds incorporate all hardware and software changes that have been made. The process of linking an FPGA Project to its associated embedded code first requires that both projects are open together. Figure 28 shows two projects open together prior to being linked. These two projects are not bound in any way – they are just two distinct projects that happen to be open at the same time. To link the Embedded Project to the FPGA Project we must utilize the Structure Editor.

6.2.1 The Structure Editor A project can be viewed in one of two ways in the Projects panel.

Figure 28. Unlinked projects

File View Structure Editor

Figure 29. Linked projects (File View).

In the File View, files are grouped primarily according to which project they are a part of and secondarily according to the file type – schematic, PCB, settings, etc.

Figure 30. Linked projects (Structure Editor).

In the Structure Editor, the hierarchical linkage between projects is shown – i.e. above we see that the HelloWorld embedded project has been linked to U3 (the TSK51 core) in the FPGA_HelloWorld FPGA project.

6 - 28


6.2.2 Linking the projects Linkage between projects is created and broken using drag-and-drop. By click-and-holding the left mouse button on a sub-project, all possible drop locations (valid linkage points) will highlight in blue and the sub-project can be drag-and-dropped onto the parent project to create the link. To break the linkage, drag the sub-project away from the parent project and drop it on a clear region of the Structure Editor. Alternatively you can right click on the processor and specify the embedded project using the Set Embedded Project menu option (Figure 32).

Figure 31. Linking an embedded project to its hardware

Figure 32. Linking an embedded project to a processor via the schematic interface.

6 - 29


6 - 30

6.3 Linking program memory to the processor core Having linked the embedded project to its hardware, the final task now is to formally notify the softcore of which schematic component contains its program memory. This is done via the Component Properties dialog which is accessible by double-clicking on the processor symbol in the schematic.


CLKRSTEA





INT0INT1

T0T1

RXDTXDRXDO

P0O[7..0]P0I[7..0]

P1O[7..0]P1I[7..0]

P2O[7..0]P2I[7..0]

P3O[7..0]P3I[7..0]



PSWRPSRD

U3

TSK51A_D

[11..0][11..0]

CLKDOUT[7..0]

ADDR[11..0]

DIN[7..0]

WE

U1

RAMS_8x4K

Figure 33. Softcore connected to its program memory.

Figure 34. Specifying which component contains the softcore’s program memory


Making this link in the schematic will ensure that both software and hardware is correctly loaded onto the target processor when we build and download the design to the NanoBoard.

6.4 Exercise 4 – Linking projects This exercise follows on from the previous exercise 1. With your design annotated, set the value of the TSK51’s ChildCore1 parameter to reference

the designator of the program memory. 2. While keeping the FPGA_HelloWorld.PrjFpg project open, also open the

HelloWorldPrj.PrjEmb project that you will find in the /Application directory under the main project directory.

3. Link the two projects as described in 6.2.2. 4. Once the projects have been correctly linked, they should appear as they do in Figure 29 &

Figure 30. Notice that HelloWorldPrj.PrjEmb is now listed as a sub-project of FPGA_HelloWorld.PrjFpg.

5. You can try unlinking the two projects again by dragging the linked embedded project off U3 in the structure editor.

6. Save your work.

6 - 31


7 Putting wheels on LiveDesign In this section we will demonstrate the true flexibility that the LiveDesign methodology offers as we develop the code necessary to drive an LCD.

7.1 The printf dilemma Our example “Hello World” application is a standard application used as an introduction to most development environments and languages. In our system, however, it is impossible for the compiler to know that we have an LCD connected to one of the ports and that it is capable of accepting ASCII data. Subsequently, the printf command that we use in our code is meaningless since the output has nowhere to go. It would be possible to delve into the heart of the compiler’s library code and modify the printf code to direct its output to the LCD but this would be an overly complex way of addressing our problem. A simpler solution would be to create a custom function that accepts a string as input and sends it to the LCD display.

7.2 Initializing the LCD Figure 35 shows a typical flow diagram for initializing an LCD module. You will note that a number of time delays are required between successive commands to the LCD.

Figure 35. LCD Initialization sequence.

6 - 32


7.2.1 Using the supplied LCD control module Contained within the Altium Designer FPGA Peripherals.IntLib library is the LCD16X2A component. This component automates much of the LCD initialization process and provides an easy method for writing to any segment of the display. Under normal production situations, we would make use of this component in our schematic however for today’s purposes we will not be using it. Instead we shall connect directly to the LCD peripheral and perform the initialization process ourselves in software.

CLKRST

DATA[7..0]ADDR[3..0]LINE

BUSYSTROBE

LCD_ELCD_RWLCD_RS

LCD_DATA_TRI

LCD_DATAO[7..0]

LCD_DATAI[7..0]

U?

LCD16X2A Figure 36. LCD Controller

Note: The LCD control module supplied with Altium Designer is very capable for standard character display however in our final application that we will develop to completion on Day 3, we need to be able to create our own characters in the LCD. The LCD control module does not allow this and so we must ‘roll our own’ LCD interface.

7.2.2 Developing a custom LCD software module Because we will not be using the supplied LCD module, we shall have to implement a timing routine as part of our application code. We could hand assemble a routine and calculate the number of loops required based on the processor clock speed and the instruction timing information however this is a time consuming activity. Utilizing the burn and learn strategy afforded by the Altium Designer environment, we can achieve our desired outcome far quicker.

6 - 33


6 - 34

7.3 Exercise 5 – Using LiveDesign to initialize an LCD In this exercise we will make use of an embedded frequency counter instrument to tune a software delay loop to a prescribed time and a Logic Analyzer instrument to verify the operation of our LCD read and write routines.

7.3.1 Tune software timing loop 1. Open the provided project and look at the schematic. You will notice a frequency counter

instrument (U7) connected to one of the microprocessor port pins.


CLKRSTEA





INT0INT1

T0T1

RXDTXDRXDO

P0O[7..0]P0I[7..0]

P1O[7..0]P1I[7..0]

P2O[7..0]P2I[7..0]

P3O[7..0]P3I[7..0]



PSWRPSRD

U3

TSK51A_D

[7..0]

[7..0]

U2

IOBUF8B

LCD_E P89P89LCD_RW P166P166LCD_RS P164P164LCD_DB[7..0]


LCD_LIGHT P94P94

2 x 16 Liquid Crystal Display

I[7..0] O0O1O2O3O4O5O6O7

U5

J8B_8S

LEDS[7..0]


LEDS[7..0]

Frequency Counter

FREQAFREQB

TIMEBASE

U7

FRQCNT2

CLK_BRD

O[15..0]IA[7..0]

IB[7..0]

U9

J8B2_16B

CLK_BRD

Logic Analyser

CLKCLK_CAPCHANNELS[15..0]

TRIGGER

STATUSU8

LAX_1K16

Figure 37. ‘Hello World’ application with Frequency counter and Logic Analyzer connected.

2. Open the HelloWorld.C file and observe the software delay loop that has been coded into the Wait_100us function. The controlling constant is defined as US_COUNT. Currently it is set to 1. Our task is to determine a better value for US_COUNT that will yield a delay of at least 100us.

3. Notice the use of a #ifdef CHK_TIMER statement in main(). This statement controls conditional compilation of the program. For instance, if the constant CHK_TIMER has been defined, the software code between the #ifdef and #endif will be compiled. If CHK_TIMER has not been defined, this code will be skipped. By inserting statements such as this around code that you may wish to use for debugging purposes greatly reduces development time. CHK_TIMER can be defined using a #define CHK_TIMER statement earlier in the program however we are going to pass it into the compilation as a project setting.


Figure 38. Using a #ifdef statement to conditional compile code

4. Open the Options for Embedded Project dialog box by right-clicking the embedded project in the Project panel.

Figure 39. Accessing the project options dialog

5. Under the Compiler Options tab, find the Preprocessing item under the C Compiler group. Ensure that a User Macro called CHK_TIMER is defined. This will ensure that CHK_TIMER is defined when we compile the project.

6 - 35


Figure 40. Specifying a user defined macro

6. From the Devices View, build and download the project to the NanoBoard. 7. Set the NanoBoard clock to 50Mhz.

Figure 41. Set the NanoBoard clock to 50Mhz

8. Open the frequency counter instrument panel and ensure that its clock reference is also 50Mhz. Observe the period recorded by the frequency counter module.

Figure 42. Observe the initial delay period

9. Try changing the value of US_COUNT to tune the software delay loop to be exactly 100us. Take note that the period displayed is equal to twice the software delay period since the software delay is used on both the high and low phases of the signal being fed to the frequency counter.

Note: It is not necessary to rebuild the entire project after each software update has been made. Locate the Compile and Download button in the toolbar. Pressing this after each software adjustment will cause only the embedded code to be recompiled and loaded into the FPGA for immediate execution.

ct after each software update has been made. Locate the Compile and Download button in the toolbar. Pressing this after each software adjustment will cause only the embedded code to be recompiled and loaded into the FPGA for immediate execution.

6 - 36


Figure 43. Adjust the value of US_COUNT to produce a period of 200us.

10. Modify the two wait statements in the main() routine from Wait_100us(1) to Wait_1ms(1). The constant that controls this loop is ONE_MS_COUNT. Tweak the value of this constant to achieve a 1ms delay.

Figure 44. Adjust the value of ONE_MS_COUNT to produce a 2ms period.

7.3.2 Verify LCD write operation Our next task is to verify the operation of our LCD read and write routines and to ensure they comply with the timing requirements of the LCD. For this we will use the logic analyser instrument.

1. In the Options For Embedded Project… dialog remove the CHK_TIMER macro and replace it with CHK_WRITE_LCD.

2. Rebuild the embedded project and download the code to the NanoBoard. 3. Open the Preferences dialog and view the options under Wave » General. Make sure that

the Sloped Wave Forms checkbox has been selected. 4. Open the logic analyser control panel.

Figure 46. Logic analyser control panel

5. Select the Options button on the logic analyser panel and check the Capture Every Clock Edge and Enable External Trigger checkboxes. Also ensure the Clock Capture Frequency is set to 50MHz. Click on OK to close the dialog box.

6. Select the Show Panel button on the logic analyser, and change the Triggering Mode to Split 8-Bit Channels.

7. Click on the Arm button on the logic analyser control panel.

8. Click the Show Waves button next to the DIGITAL label on the logic analyser control panel. The waveform viewer window will open in the main screen. Figure 45. Logic analyser options

6 - 37


9. Select the Continuous Capture icon in the main toolbar to see a continuous update of the waveform window.

Figure 47. Digital waveform view – write LCD.

10. If the labels next to each of the signals are not set, update them to appear as they do in Figure 47.

11. To zoom in or out of the digital waveform view, first ensure that the waveform viewer has the focus and then press the keyboard Page Up or Page Down keys as you would in any other Altium Designer document. Ensure that you can see at least one full pulse of the Enable signal.

12. Right-click in the digital waveform view area to reveal a pop-up menu. Select the Measure Time option. Left-click on two locations within the waveform viewer to measure the time between them.

Figure 48. Measure time between selected events

13. Verify that the LCD write timing waveform complies with the datasheet requirements of Figure 49 and Figure 50.

6 - 38


Figure 49. LCD write timing requirements

Figure 50. LCD Write Waveform

7.3.3 Verify LCD read operation 1. In the Options for Embedded Project… dialog, remove the CHK_WRITE_LCD macro and

replace it with CHK_READ_LCD. 2. Rebuild the embedded project and download the code to the NanoBoard. 3. Once again view the logic analyser and observe the output waves.

6 - 39


Figure 51. Digital waveform view - read LCD

4. Verify that the LCD read timing waveform complies with the datasheet requirements of Figure 52 and Figure 53.

Figure 52. LCD read timing requirements

Figure 53. LCD read waveform

5. Compile the code with no #defines and run it. Observe the output of the LCD. 6. Save your work once you have finished.

6 - 40


7.3.4 LCD instruction definitions

Figure 54. LCD instruction definitions

6 - 41


8 Debugging the design In this section we will review the debugging features that are a part of the Altium Designer development system.

8.1 A word about simulation In general, it is desirable to interact with real hardware when debugging rather than performing simulations only. The presence of the NanoBoard means that most designs can be debugged in real hardware, i.e. LiveDesign, however there may be the odd occasion when it is necessary to simulate a design. The Altium Designer development environment supports full simulation based debugging as well as LiveDesign using real hardware; the interface is identical. Switching between LiveDesign and Simulation is achieved by changing the debugger mode via the Debug » Current Debugger Mode menu option available when editing an embedded project source document. For our discussions we shall focus on the LiveDesign environment, as this is usually the most desirable mode of debugging however all that is mentioned here is applicable to the simulation environment also. The easiest way to initiate a debugging / simulation session is to right-click the embedded project in the Projects panel and selecting Debug or Simulate. Of course, the Debug option is only available if a NanoBoard or target platform is present and powered up.

8.2 The Debug menu Debug commands are available whenever an embedded source file is open in the main window. Debug commands can be accessed via the Debug toolbar:

Figure 55. Debug toolbar

Figure 56. Debug menu

Or from the Debug menu: Current Debugger Mode: Use this menu item to select between simulation mode or LiveDesign. If more than one processor is present on the target design then you will have to select which device is the target of debugging commands. Run (F9): Run the current embedded project in debug mode. After launching the command, execution of the code in the embedded software program will begin. If any enabled breakpoints have been setup, code execution will halt at these points, if encountered Run to Cursor (Ctrl+F9): Execute the embedded code up to the line containing the cursor. Toggle Breakpoint (F5): This command is used to toggle an enabled breakpoint for the current line. After launching the command, the current line will have an enabled breakpoint added to it or removed from it, depending on whether or not an enabled breakpoint currently exists for that line.

6 - 42


Enabled breakpoints are indicated in the code by a red highlight over the breakpoint line and a red circle with a cross in the margin. Disabled breakpoints are indicated in the code by a green highlight over the breakpoint line and a green circle with a cross in the margin. A disabled breakpoint remains defined but will not cause running code to halt when encountered. If a disabled breakpoint exists for the line and this command is used, the breakpoint will be removed. You can view a list of all breakpoints that have currently been defined in all open embedded project source code files, in the Breakpoints panel. Add Watch: This command enables you to define watch expressions for the current embedded source code document. A watch expression can be a single variable or an expression containing one or more variables and allows you to view the value of the expression as you step through the code. Basic mathematical operations are supported (e.g. a+b, a*b, c+(b-a)). Step Into (F7): Use this command to execute each line of the current embedded source code sequentially, including the individual lines of code contained within any procedures/functions that are called. The next executable line of code is highlighted in blue and is indicated by a blue circle with an arrow in the margin. Step Over (F8): The same as the Step Into command except procedure/function calls are treated as a single line of code and executed as a single step. Step Into Instruction (Shift+F7): This command is used to execute each individual instruction at the assembly code level, in turn, including the instructions contained within any functions that are called. When the source code document is an .asm file, the next executable instruction is highlighted in blue and is indicated by a blue circle with an arrow in the margin. This command and the Step Into Source command will behave in the same way. When the source code is a high level language (.c file), use of this command should ideally be made from within one of the two disassembly views for the code - either the extended mixed source-disassembly view (accessed by clicking the Show Disassembly button on the debug toolbar in the source code view), or the pure disassembly view (accessed by clicking the Toggle Source Code button on the disassembly standard toolbar, from within the mixed source-disassembly view). In both mixed and pure disassembly views, the next executable instruction is highlighted in dark blue and is indicated by a dark blue circle with an arrow in the margin. Step Over Instruction (Shift+F8): The same as the Step Into Instruction command except procedure/function calls are treated as a single line of code and executed as a single step. Step Out: This command is used to step out of the current function within the embedded source code. The remaining executable code within the current function will be executed and the execution will be passed onto the next sequential line of code after the function's calling statement. Show Disassembly: Open an intermixed source and disassembly view for the current embedded software project. A new view will open as the active view in the main design window. This view shows a mixture of disassembled instructions and source (C) code. The source for all source code files in the current embedded project will be displayed. In this intermixed disassembly and source view, the next executable source line is highlighted in blue and is indicated by a blue circle with an arrow in the margin. The next executable disassembled instruction is highlighted in dark blue and is indicated by a dark blue circle with an arrow in the margin. Resynchronize: Use this command to synchronize the debugger execution point with the external hardware. Show Execution Point: Position the text cursor at the start of the next line of code to be executed. If the next executable line of code is outside of the visible area of the main display window, the document will be panned to bring it into view. Break: Halt an executing processor at the next executable line of source code. Reset (Ctrl+F2): Reset the executing processor currently being debugged, at any stage when stepping through code or after a breakpoint has been encountered, and return the current execution point back to the first line of executable code. Stop Debugging (Ctrl+F3): Terminate the current debugging session.

6 - 43


8.3 Embedded control panels

Figure 57. Available embedded panels

Clicking on the Embedded button of the workspace panels will open the list of embedded control panels. Alternatively use the menu commands by selecting View » Workspace Panels » Embedded. Selecting F1 whilst an item within a panel has the focus will bring up extensive help on the panel’s operation.

8.3.1 Code Explorer The Code Explorer provides a convenient summary and navigation tool for accessing all of the functions and variables defined within the source code. Double-clicking on any of the items in the Code Explorer panel will immediately transfer the cursor in the main window to the location where the selected variable or function is declared.

Figure 58. Code explorer panel

8.3.2 Call Stack When an executing processor is paused, the Call Stack panel shows the function call sequence that has lead to the current line of execution. Beside each called function is the source code line that processing will return to after the subroutines are executed.

Figure 59. Call stack panel

6 - 44


8.3.3 Watches Use the Watches panel to see the value of selected variables. Watched variables will be updated automatically when a running processor is paused and as each line of source code is stepped through. For variables to be viewable in the Watches panel they must be within the scope of the current execution point within the source code. For example, variables local to a specific function will not be viewable whilst code outside of that function is being executed. Watched variables can be added, deleted, edited and enabled/disabled from the popup menu that appears upon a mouse right-click from within the Watches panel. Watches are extremely flexible in that they can be displayed in a number of different formats. Formatting options can be accessed by right clicking a watch variable and selecting Edit.

Figure 60. Watches panel

Figure 61. Edit watch dialog

Figure 62. Watch format dialog

Changing the display style of the watch to anything other than [Default] will place a format specifier in the watch declaration. This format specifier can be used in a number of other panels also.

Figure 63. Watches panel with format specifiers

6 - 45


8.3.4 RTOS

Figure 64. RTOS panel

The RTOS panel has a number of sub-panels which can be activated via the Debug » RTOS menu option. Note that this menu option only becomes available when an RTOS embedded project is paused during execution. The different sub-panels enable the user to track RTOS pertinent information such as System Status, Concurrent Tasks, Resources, Messages, and Alarms. For further information regarding RTOS and Altium Designer support for RTOS projects, read GU0102 8051 RTOS.pdf in the or access this document from the help contents under Embedded Software Development » 8051 RTOS Guide.

6 - 46


8.3.5 Registers

Figure 65. Registers panel

The Registers panel provides a central point for viewing and modifying processor registers. Useful when debugging lines of assembly source, the Registers panel provides a line-by-line update of the state of key processor resources. Variables in the Registers panel can be modified by clicking on one of the values in the Decimal, Hexadecimal or Binary columns and updating the value. This value shall remain and be used in subsequent lines of code.

8.3.6 Locals

Figure 66. Locals panel

When an executing processor is paused, the Locals panel will display a snapshot of the variables that are local to the currently executing function. Variables will be updated as each line of source code is executed. The Locals panel is complementary to the Watches panel as it does not get cluttered with information of variables outside of the scope of the currently executing function.

8.3.7 Evaluate

Figure 67. Evaluate Panel

The Evaluate panel provides a quick means for determining the value of a variable or expression. Expression syntax must follow C standards and variables contained within an expression must be within the scope of the currently executing function. Evaluated values or expressions are not updated whilst the code is stepped through however repeat evaluations can be made by selecting the Evaluate button. Alternatively, variables can be added to the Watches panel by selecting the Add Watch button. The Evaluate window is also useful for determining the address of a variable so that it can be located within one of the memory panels or, in the case of registers, in the registers panel.

6 - 47


8.3.8 Cross References The Cross references panel can be used to quickly find out all occurrences of a given symbol in the source files and optionally jump to each location. For example, one could be interested to check all the places where a specific variable is addressed, or a function is called. Left-clicking once on the variable in the top pane of the Cross References panel will cause the bottom pane to show the associated line of source code. Double-clicking the variable in the top pane will cause the main editor window to jump to the associated line of source code.

Figure 68. Using cross references to navigate around a document

8.3.9 Enabling cross references Before cross references can be used, the feature must first be enabled in the editor. With a C file open in the main window, select the Tools » Editor Preferences… from the menu.

Figure 69. Enabling cross reference libraries (code sources)

6 - 48


The Library Name is simply used as a meaningful identifier in the Library Databases – the system does not use this field in any way. The Library Root specifies the root folder where the source files are located. Full Source controls whether C files should be processed. If this option is left unchecked only header files (.H) will be scanned. Once the cross reference libraries have been set up, the Cross References panel can be used from the editor. Right click any identifier, and select Show Cross-References from the popup menu. The Cross References panel will be displayed revealing all occurrences of the selected identifier:

8.3.10 Debug Console

Figure 70. Debug console panel

The Debug Console provides a record of the debugging session and the debugging commands that have been executed. The Debug Console is based heavily on Tasking’s CrossView technology and so many of the CrossView commands are also valid here.

8.3.11 Breakpoints

Figure 71. Specifying breakpoints

Use breakpoints to halt the processor execution at a specified line of source code. The properties of a breakpoint accessed by right-clicking an item in the Filename/Address column of the Breakpoints panel and selecting Properties from the popup menu. The Count value identifies how many times the breakpoint will be hit and continue before stopping (it stops when the count gets to 0). Reset Count is a number that is reloaded into Count once Count gets to zero and stops. Condition can contain a test expression that will be evaluated at the point of the breakpoint. If the expression is true then the debugger will pause.

6 - 49


8.3.12 Memory Altium Designer contains a powerful memory display tool that is capable of viewing multiple memory spaces concurrently. Memory data is displayed using both hexadecimal and ASCII character notation.

Figure 72. Memory panels

For debugging purposes it is often necessary to modify the contents of memory to provoke a certain response from the processor. This is possible via the Memory panel. Click on one of the hexadecimal cells and type in the new hexadecimal value. The memory will automatically refresh with the new value. The Memory panel does not discern between read only and read-write memory. If the user attempts to alter memory that is not writeable, the request will be rejected and the memory location will remain unchanged. The Memory panels always number the memory spaces they represent from 0 regardless of where the memory space physically resides in the processor’s memory map. For instance, the Special Function Register (SFR) space of the 8051 architecture is located between 80h and FFh of the Internal RAM. The starting address of the SFR Memory panel is listed as 0000h (not 0080h). Blocks of memory can be highlighted by left-click and dragging across multiple cells. Pressing the Alt key whilst dragging will drag a rectangle. Once highlighted, memory cells can be used as the basis for read, write or read/write breakpoints however this feature is only available in simulation mode.

8.4 Exercise 6 – Code Debug This exercise is based on the work previously done in Exercise 5.

1. You will notice that the ’Hello World’ text scrolls across the screen but doesn’t go all the way to the left-most character position. Your task is to rectify the problem so that ’Hello World’ scrolls across the screen and stops in the left-most character position.

2. Using breakpoints, single stepping, and variable watching, attempt to track down and rectify the error(s) in the source code.

6 - 50


9 Advanced compiler features 9.1 C language extensions The TASKING compiler(s) fully support the ISO C standard and add extra possibilities to program the special functions of the individual targets. In addition to the standard C language, the compiler supports the following: • extra data types, like __fract and __accum for targets on which these data types can be

supported • intrinsic (built-in) functions that result in target specific assembly instructions • pragmas to control the compiler from within the C source • predefined macros • the possibility to use assembly instructions in the C source • keywords to specify memory types for data and functions • attributes to specify alignment and absolute addresses • keywords for inlining functions and programming interrupt routines • libraries All non-standard keywords have two leading underscores (__). In this section the target specific characteristics of the C language are described, including the above mentioned extensions.

Note: For the 165x no compiler is available.

9.2 Supported data types Support Type C Type Size

(bit) Align (bit)

Limits

c51 cz80

Bit __bit 1 1 0 or 1

Boolean _Bool 1 8 0 or 1

[signed] char 8 8 -27.. 27-1 Character

unsigned char 8 8 0 .. 28-1

[signed] short [signed] int

16 8 -215 .. 215-1

1 1 0 or 1

8 8 -27.. 27-1

Enum

16 8 -215 .. 215-1

unsigned short unsigned int

16 8 0 .. 216-1

[signed] long 32 8 -231 .. 231-1

unsigned long 32 8 0 .. 232-1

[signed] long long 32 8 -231 .. 231-1

Integral

unsigned long long 32 8 0 .. 232-1

6 - 51


pointer to __data, __idata, __pdat or __bit 8 8 0 .. 216-1

Pointer

pointer to function, __xdata or __rom 16 8 0 .. 216-1

float

32 8

-3.402e38 .. -1.175e-38 1.175e-38 .. 3.402e38

Floating Point

double long double 32 8

-3.402e38 .. -1.175e-38 1.175e-38 .. 3.402e38

Notes • The long long types are treated as long. • The double and long double types are always treated as float. • When you use the enum type, the compiler will use the smallest sufficient type (__bit, char or

int), unless you use compiler option --integer-enumeration (always use 16-bit integers for enumeration).

The following rules apply to __bit type variables: 1. A __bit type variable is always unsigned. 2. A __bit type variable can be exchanged with all other data type-variables. The compiler

generates the correct conversion. 3. __bit type variable is like a boolean. Therefore, if you convert an int type variable to a

__bit type variable, it becomes 1 (true) if the integer is not equal to 0, and 0 (false) if the integer is 0. The next two C source lines have the same effect: t_variable = int_variable; bit_variable = int_variable ? 1 : 0;

4. Pointer to __bit is allowed, but you cannot take the address of a bit on the stack. 5. The __bit type is allowed as a structure member. However, a bit structure can only contain

members of type __bit, and you cannot push a bit structure on the stack or return a bit structure via a function.

6. A union of a __bit structure and another type is not allowed. 7. A __bit type variable is allowed as a parameter of a function. 8. A __bit type variable is allowed as a return type of a function. 9. A __bit typed expression is allowed as switch expression. 10. The sizeof of a __bit type is 1. 11. A global or static __bit type variable can be initialized. 12. A __bit type variable can be declared volatile.

9.3 Memory type qualifiers

9.3.1 Memory type qualifiers for the 8051 In the C language you can specify that a variable must be located in a specific part of memory. You can do this with a memory type qualifier. For the 8051 you can specify the following memory types:

Qualifier Description

__data Direct addressable on-chip RAM

6 - 52


__sfr Defines a special function register. Special optimizations are performed on this type of variables.

__bsfr Bit-addressable special function register

__idata Indirect addressable on-chip RAM

__bdata Bit-addressable on-chip RAM

__xdata External RAM

__pdata One 256 bytes page within external RAM

__rom Data defined with this qualifier is placed in ROM. This section is excluded from automatic initialization by the startup code. __rom always implies the type qualifier const.

If you do not specify a memory type qualifier for the 8051, the memory type for the variable depends on the default of the selected 8051 memory model.

Examples using explicit memory types

__data char c; __rom char text[] = "No smoking"; __xdata int array[10][4]; __idata long l; The memory type qualifiers are treated like any other data type specifier (such as unsigned). This means the examples above can also be declared as: char __data c; char __rom text[] = "No smoking"; int __xdata array[10][4]; long __idata l;

Pointers Pointers for the 8051 can have two types: a 'logical' type and a memory type. For example, a function is residing in ROM (memory type), but the logical type is the return type of this function.

Example using memory types with pointers __rom char *__data p; /* pointer residing in data, pointing to ROM */

means p has memory type data (allocated in on-chip RAM), but has logical type 'character in target memory space ROM'. The memory type qualifier used left to the '*', specifies the target memory of the pointer, the memory type qualifier used right to the '*', specifies the storage memory of the pointer. The memory type qualifiers are treated like any other data type specifier (like unsigned). This means the pointer above can also be declared (exactly the same) using:

char __rom *__data p; /* pointer residing in data, pointing to ROM */

The 8051 C compiler is very efficient in allocating pointers, because it recognizes far (2 byte) and near (1 byte) pointers. Pointers to __data, __idata and __pdata have a size of 1 byte, whereas pointers to __rom, __xdata and functions (in ROM) have a size of 2 bytes.

Structure tags A tag declaration is intended to specify the layout of a structure or union. If a memory type is specified, it is considered to be part of the declarator. A tag name itself, nor its members can be bound to any storage area, although members having type "... pointer to" do require one. A tag may then be used to declare objects of that type, and may allocate them in different memories (if that declaration is in the same scope). The following example illustrates this constraint.

6 - 53


struct S { __xdat int i; /* referring to storage: not correct */ __idat char *p; /* used to specify target memory: correct */ };

In the example above the 8051 compiler ignores the erroneous __xdat memory type qualifier (without displaying a warning message).

Typedef Typedef declarations follow the same scope rules as any declared object. Typedef names may be (re-)declared in inner blocks but not at the parameter level. However, in typedef declarations, memory type qualifiers are allowed. A typedef declaration should at least contain one type qualifier.

Example using memory types with typedefs typedef __idat int IDATINT; /* memory type __idat: OK */ typedef int __data *DATAPTR; /* logical type __data memory type 'default' */

9.3.2 Memory type qualifiers for the Z80 In the C language you can specify that a variable must be located in a specific part of memory. You can do this with a memory type qualifier. For the Z80 you can specify the following memory types:

Qualifier Description

__sfr Defines a special function register. Special optimizations are performed on this type of variables.

__sfr8 Defines an 8-bit special function register

__rom Data defined with this qualifier is placed in ROM. This section is excluded from automatic initialization by the startup code. __rom always implies the type qualifier const.

Example using explicit memory types

__rom char text[] = "No smoking"; The memory type qualifiers are treated like any other data type specifier (such as unsigned). This means the example above can also be declared as: char __rom text[] = "No smoking";

9.4 Accessing hardware from C: __sfr, __bsfr Using special function registers It is easy to access Special Function Registers (SFRs) that relate to peripherals from C. The SFRs are defined in a special function register file (*.sfr) as symbol names for use with the compiler. An SFR file contains the names of the SFRs and the bits in the SFRs. Example use in C:

P0 = 0x88; // use port name P1_3 = 1; // use of bit name if (P1_4 == 1) { P1_3 = 0; } IE1 = 1; // use of bit name

6 - 54


The compiler generates (TSK51A):

mov 128,#136 setb 144.3 gjnb 144.4,_2 clr 144.3 _2: setb 136.3

You can easily find a list of defined SFRs and defined bits by inspecting the SFR file for a specific core. The files are named regcore.sfr, for example regtks51a.sfr in the Altium Designer 6\System\Tasking\c51\include directory.

Defining special function registers With the __sfr memory type qualifier you can define a symbol as an SFR. The compiler may assume that special SFR operations can be performed on such symbols. The 8051 compiler can decide to use bit instructions for those special function registers that are bit accessible, in this case use __bsfr instead of __sfr. For example, if bits are defined in the SFR definition, these bits can be accessed using bit instructions. For the 8051 only the SFRs at addresses 0x80, 0x88, 0x90, 0x98, 0xa0, 0xa8, 0xb0, 0xb8, 0xc0, 0xc8, 0xd0, 0xd8, 0xe0, 0xe8, 0xf0 and 0xf8 are bit addressable. A typical definition of a special function register looks as follows: typedef struct unsigned int __b0:1; unsigned int __b1:1; unsigned int __b2:1; unsigned int __b3:1; unsigned int __b4:1; unsigned int __b5:1; unsigned int __b6:1; unsigned int __b7:1; } __t_sfrbits;

#define P0 (*(__bsfr volatile unsigned char *)0x80) #define P0_0 ((*(__bsfr volatile __t_sfrbits *)0x80).__b0) #define P0_1 ((*(__bsfr volatile __t_sfrbits *)0x80).__b1) #define SP (*(__sfr volatile unsigned char *)0x81) #define TCON (*(__bsfr volatile unsigned char *)0x88) #define IT0 ((*(__bsfr volatile __t_sfrbits *)0x88).__b0) #define IE0 ((*(__bsfr volatile __t_sfrbits *)0x88).__b1) Example of access to the SFR: P0 = 0x56; P0_0 = IE0; This example only contains byte and single bit SFRs. Different sized SFRs are also supported with a specific struct definition. For example: typedef struct { unsigned int __b0s3:3; unsigned int __b3s2:2; unsigned int __b5s3:3; } __t_sfr_ctrl_bit; #define CTRL (*(__sfr volatile unsigned char *)0x95) #define CTRL_ST ((*(__sfr volatile __t_sfr_ctrl_bit *)0x95).__b0s3) #define CTRL_CL ((*(__sfr volatile __t_sfr_ctrl_bit *)0x95).__b3s2)

6 - 55


#define CTRL_IN ((*(__sfr volatile __t_sfr_ctrl_bit *)0x95).__b5s3)

Non-initialized global SFR variables are not cleared at startup. For example:

__sfr int i; // global SFR not cleared

It is not allowed to initialize global SFR variables. SFR variables are not initialized at startup. For example:

__sfr int j=10; // not allowed to initialize global SFR

9.5 Placing an object at an absolute address: __at() Just like you can declare a variable in a specific part of memory (using memory type qualifiers), you can also place an object at an absolute address in memory. This may be useful to interface with other programs using fixed memory schemes, or to access special function registers. With the attribute __at() you can specify an absolute address.

Examples unsigned char Display[80*24] __at( 0x2000 );

The array Display is placed at address 0x2000. In the generated assembly, an absolute section is created. On this position space is reserved for the variable Display.

int i __at( 0x1000 ) = 1;

The variable i is placed at address 0x1000 and is initialized at 1. void f( void ) __at( 0xf0ff + 1 ) {}

The function f is placed at address 0xf100.

Restrictions Take note of the following restrictions if you place a variable at an absolute address: • The argument of the __at() attribute must be a constant address expression. • You can place only global variables at absolute addresses. Parameters of functions, or automatic

variables within functions cannot be placed at absolute addresses. • When declared extern, the variable is not allocated by the compiler. When the same variable is

allocated within another module but on a different address, the compiler, assembler or linker will not notice, because an assembler external object cannot specify an absolute address.

• When the variable is declared static, no public symbol will be generated (normal C behavior). • You cannot place structure members at an absolute address. • Absolute variables cannot overlap each other. If you declare two absolute variables at the same

address, the assembler and / or linker issues an error. The compiler does not check this. • When you declare the same absolute variable within two modules, this produces conflicts during

link time (except when one of the modules declares the variable 'extern').

9.6 Declaring interrupt functions A function can be declared to serve as an interrupt service routine. You can use the function qualifier __interrupt() for this purpose. Interrupt functions cannot return anything and must have a void argument type list. For example, in:

void __interrupt(vector-address[, vector-address]...) isr(void) { ... }

The function qualifier __interrupt() takes one or more vector addresses as arguments. All supplied vectors will be initialized to point to the interrupt function.

If you want to use interrupt numbers instead of vector addresses for the TSK51A core, you can use the __INTNO macro which is defined in the delivered special function register file (regtsk51a.sfr) as:

#define __INTNO(nr) ((8*nr)+3)

6 - 56


Example 8051 #include <regtsk51a.sfr> void __interrupt( S0IR ) serial_receive( void ) { ... } void __interrupt( __INTNO(2) ) serial_transmit( void ) { ... }

Example Z80 Z80 mode 2 interrupt: void __interrupt( 0x10 ) IntHandler( void ) { Interrupt(); } This will reserve a word (.dw directive) on address 0x10, where the address of the interrupt function is placed. Z80 mode 1 interrupt or non-maskable interrupt: void __interrupt( -1 ) IntNmHandler( void ) __at(0x66) { InterruptNm(); } The vector address '-1' tells the compiler not to make a vector table entry. The __at() attribute places the interrupt service routine on the desired absolute address. The compiler generates the appropriate interrupt vector, consisting of a JMP instruction jumping to the interrupt function. You can suppress this with the compiler option --novector or the #pragma novector. The difference between a normal function and an interrupt function is that an interrupt function ends with an RETI instruction instead of a RET instruction, and that registers that might possibly be corrupted during the execution of the interrupt function are saved on function entry and restored on function exit. For certain ROM monitors it is necessary to specify an offset for all interrupt vectors. For this you can use the command --vector-offset=value. Suppose a ROM monitor has the interrupt table at offset 0x4000. When you compile with --vector-offset=0x4000 interrupt vector 1 (vector address 11) is being located at address 0x400B instead of 0xB.

6 - 57


9.7 Incorporating assembly in C code With the __asm keyword you can use assembly instructions in the C source and pass C variables as operands to the assembly code. Be aware that C modules that contain assembly are not portable and harder to compile in other environments. Furthermore, assembly blocks are not interpreted by the compiler: they are regarded as a black box. So, it is your responsibility to make sure that the assembly block is syntactically correct.

General syntax of the __asm keyword __asm( "instruction_template" [ : output_param_list [ : input_param_list [ : register_save_list]]] );

instruction_template Assembly instructions that may contain parameters from the input list or output list in the form: %parm_nr

%parm_nr[.regnum] Parameter number in the range 0 .. 31. With the optional .regnum you can access an individual register from a register pair. For example, with the word register R12, .0 selects register R1.

output_param_list [[ "=[&]constraint_char"(C_expression)],...]

input_param_list [[ "constraint_char"(C_expression)],...]

& Says that an output operand is written to before the inputs are read, so this output must not be the same register as any input.

constraint _char Constraint character: the type of register to be used for the C_expression.

C_expression Any C expression. For output parameters it must be an lvalue, that is, something that is legal to have on the left side of an assignment.

register_save_list [["register_name"],...]

register_name Name of the register you want to reserve.

Typical example: adding two C variables using assembly __data char a, b; __data int result; void add2( void ) { __asm( "MOV A, %1\n\t" "ADD A, %2\n\t" "MOV %0, A": "=m"(result): "r"(a), "r"(b) ); } generated code (8051): mov R0,_b mov R1,_a MOV A, R0 ADD A, R1 MOV _result, A %0 corresponds with the first C variable, %1 with the second and so on.

Specifying registers for C variables With a constraint character you specify the register type for a parameter. In the example above, the r is used to force the use of registers (Rn) for the parameters a and b.

6 - 58


You can reserve the registers that are already used in the assembly instructions, either in the parameter lists or in the reserved register list (register_save_list, also called "clobber list"). The compiler takes account of these lists, so no unnecessary register saves and restores are placed around the inline assembly instructions.

Available operand constraints 8051

Constraint character

Type Operand Remark

a accumulator A

b bit ACC.[0..7], B.[0..7], C, AC, F0, RS1, RS0, OV, F1, P, _bitvar

bit registers/variables

d direct register PSW, SP, B, ACC, DPH, DPL, AR[0..7]

direct address of registers

i immediate value #data, #data16

m memory direct, label, addr11, addr16, rel

memory variable or function address

p data page pointer

DPTR

r register R[0..7]

R registers R01, R12, R23, R34, R45, R56, R67

word registers

s register indirect @R0, @R1 register indirect addressing

number other operand same as %number used when in- and output operands must be the same

Available operand constraints Z80

Constraint character

Type Operand Remark

i immediate value #value

m memory address, label stack or memory operand, a fixed address or indexed addressing

r register A, B, C, D, E, H, L, I, R

8-bit register

IX, IY, SP, AF, BC, DE, HL

16-bit register

number other operand same as %number Used when in- and output operands must be the same

Loops and conditional jumps The compiler does not detect loops with multiple __asm statements or (conditional) jumps across __asm statements and will generate incorrect code for the registers involved.

6 - 59


If you want to create a loop with __asm, the whole loop must be contained in a single __asm statement. The same counts for (conditional) jumps. As a rule of thumb, all references to a label in an __asm statement must be contained in the same statement.

9.7.1 Example 1: No input or output A simple example without input or output parameters. You can use any instruction or label. __asm( "nop" ); Generated code: nop

9.7.2 Example 2: Using output parameters Assign the result of inline assembly to a variable. A register is chosen for the parameter because of the constraint r; the compiler decides which register is best to use. The %0 in the instruction template is replaced by the name of this register. Finally, the compiler generates code to assign the result to the output variable. int var1; void main(void) { __asm( "mov %0,#ff" : "=r"(var1)); } Generated assembly code (Z80 code): mov HL,#ff ld _var1,HL

9.7.3 Example 3: Using input and output parameters Add two C variables and assign the result to a third C variable. Registers are used for the input parameters (constraint r, %1 for a and %2 for b in the instruction template) and memory is used for the output parameter (constraint m, %0 for result in the instruction template). The compiler generates code to move the input expressions into the input registers and to assign the result to the output variable. __data char a, b; __data int result; void add2( void ) { __asm( "MOV A, %1\n\t" "ADD A, %2\n\t" "MOV %0, A": "=m"(result): "r"(a), "r"(b) ); } void main(void) { a = 3; b = 4; add2( ); } Generated assembly code (8051): _add2: mov R0,_b mov R1,_a MOV A, R0 ADD A, R1 MOV _result, A _main: mov _a,#3

6 - 60


movx _b,#4 gcall _add2

9.7.4 Example 4: Reserve registers Sometimes an instruction knocks out certain specific registers. The most common example of this is a function call, where the called function is allowed to do whatever it likes with some registers. If this is the case, you can list specific registers that get clobbered by an operation after the inputs. Same as Example 3, but now register R0 is a reserved register. You can do this by adding a reserved register list (: "R0"). As you can see in the generated assembly code, register R0 is not used (the first register used is R1). __data char a, b; __data int result; void add2( void ) { __asm( "MOV A, %1\n\t" "ADD A, %2\n\t" "MOV %0, A": "=m"(result): "r"(a), "r"(b) : "R0" ); } Generated assembly code (8051):

_add2: mov R1,_b mov R2,_a MOV A, R1 ADD A, R2 MOV _result, A Example 5: input and output are the same

If the input and output must be the same you can use a number constraint. The following example adds two values. Input variable a has to go in the same place as the output variable a, so %2 and %0 are the same thing. That is why the constraint of argument 2 is 0, that is, the same as argument 0. Note also that the .0 and .1 select a kid register from a register pair. Register A is reserved. int _ADDI( int a, int b ) { __asm("MOV A, %1.1\n\t" "ADD A, %0.1\n\t" "MOV %0.1, A\n\t" "MOV A, %1.0\n\t" "ADDC A, %0.0\n\t" "MOV %0.0, A" : "=R"(a) : "R"(b), "0"(a) : "A" ); return a; } void main(void) { int ovar; ovar = _ADDI(2,3); } Generated assembly code (8051): __ADDI: MOV A, R5 ADD A, R7 MOV R7, A MOV A, R4 ADDC A, R6 MOV R6, A ret

6 - 61


_main: mov R6,#0 mov R7,#2 mov R4,#0 mov R5,#3 gcall __ADDI ret

9.8 Real-Time Operating System (RTOS) The TDK51 includes a compact RTOS, compliant with the OSEK/VDX standard. The RTOS is a real-time, preemptive, multitasking kernel, designed for time-critical embedded applications. It offers: • A high degree of modularity and the ability to create flexible configurations • Time critical support, through the use of system object creation during the system generation

phase • Well defined interfaces between application software and the operating system • Superior application software portability, via the use of the OSEK Implementation Language, or

OIL The RTOS panel is a runtime status panel, which can display information such as System Status, Alarms, Tasks and Resources. Open the RTOS panel via the Embedded button at the bottom right of the workspace, then enable the required RTOS information by clicking the RTOS button on the Debug toolbar. More information can be found in document GU0102 8051 RTOS.pdf or from the help contents under Embedded Software Development » 8051 RTOS Guide.

6 - 62


9.9 Exercise 7 – PWM measurement In this exercise we will implement an Interrupt Service Routine that will be responsible for measuring the pulse width modulated output of a digital accelerometer. A fragment of the accelerometer’s datasheet is shown in Figure 74: A semi-complete project has been prepared and your instructor will tell you where to find it on your local hard drive. The purpose of this program is to use and interrupt service routine to measure the duration of the accelerometer high (T1) pulse and the period (T2) of the accelerometer output. The main() routine will take values updated in the Interrupt Service Routine and display them on the LCD display. The basic framework of the application code has already been developed. Your task is to fill in the missing lines of code in the Interrupt Service Routine.

1. Open the provided project and download the design to the NanoBoard. 2. Ensure that the NanoBoard Clock is set to 10MHz and the Frequency Generator is set to

1KHz. 3. Observe the contents of main(). Take note of the two variables that are to be displayed. 4. Look at TimeTSK51_Shell.C. You will notice a number of comment lines but the source

code is missing. Fill in these lines with the code in Figure 73. 5. Compile your completed code and run it on the NanoBoard. 6. Adjust the frequency of the Frequency Generator and observe the change in the LCD output. 7. Save your work.

Figure 73. Solution code for interrupt service routine

6 - 63


Note: For this exercise you may wish to refer to CR0115 TSK51x MCU.pdf for reference information about the TSK51 processor. This document can be accessed from the help contents under FPGA Design » Core References » Processors » TSK51x MCU.

Figure 74. Extract from accelerometer datasheet. RSET has been set to 1.25M.

6 - 64


6 - 65

10 Review

Date post:	27-May-2020
Category:	Documents
Upload:	others
View:	4 times
Download:	0 times