TI’s DSP/BIOS real-time SYSTEM considerations 6 November 2015 Dr. Veton Këpuska Objectives • Define the topology of a common DSP system • List factors involved in.
Download ReportTranscript TI’s DSP/BIOS real-time SYSTEM considerations 6 November 2015 Dr. Veton Këpuska Objectives • Define the topology of a common DSP system • List factors involved in.
TI’s DSP/BIOS
real-time SYSTEM
considerations
6 November 2015
Dr. Veton Këpuska
1
Objectives
1
• Define the topology of a common DSP system
2
• List factors involved in design of a real-time
system
3
• Compare and contrast tradeoffs in R/T system
design
4
• Describe the basics of DSP/BIOS coding
conventions
5
• Demonstrate CCS skills to create, download
and debug a DSP project
6 November 2015
Dr. Veton Këpuska
2
2
Real-Time System Design
Considerations
1
2
3
4
6 November 2015
• Real-Time System Concepts
• DSP/BIOS
• Development Cycle with DSP/BIOS
• Lab
Dr. Veton Këpuska
3
3
Real-Time System
Design Concepts
6 November 2015
Dr. Veton Këpuska
4
Definitions / Vocabulary
Real-Time Systems:
DSP/BIOS:
Function:
•where processing must keep up with rate of I/O
•a scalable, real-time kernel, used in thousands of systems today.
Part of CCS, requires no license fees when used on TI DSPs
•Sequence of program instructions that produce a given result
Thread:
•Independent sequence of program instructions (functions) that
execute within a specific context (registers, stack, priority).
Object:
•a software bundle of variables and related methods
Instance:
Reentrant:
API:
Events:
Synchronous Events:
Asynchronous Events:
Stream:
Message:
6 November 2015
•a copy (or “channel”) of an object; implies reentrancy
•able to run multiple instances concurrently
•Application Programming Interface – methods for interacting with
routines
•cause a non-sequential change in the software flow of control
•occur at predictable times (eg: if/else, polling)
•occur at unpredictable times (interrupts)
•large and frequent continuous block of data
•typically smaller and infrequent packets of data; sporadic
Dr. Veton Këpuska
5
4
Acronyms
CSL:
• Chip Support Library – interface to peripherals via
predefined structures and API
HWI:
• Hardware Interrupt
DEV:
SIO:
• DEVice driver – original device driver standard in
DSP/BIOS
• Input Output Mini-driver – newest device driver
standard in DSP/BIOS
• Platform Support Package – Collection of IOMs for
a particular processor/board
• Streaming Input Output – BIOS standard for
interface between a driver and a TSK or SWI
SWI:
• Software Interrupt
TSK:
• Task
IOM:
PSP:
6 November 2015
Dr. Veton Këpuska
6
Input – Process – Output
Input
•CSL,
•HWI,
•DEV,
•IOM,
•PSP
Process
ptr
SIO
•SWIXDAIS
- launch on I/O
•TSK -algo
post on I/O
Output
ptr
SIO
•CSL,
•HWI
•DEV,
•IOM,
•PSP
XDAIS is a standard for algorithm development by
Texas Instruments for the TMS320 DSP family.
6 November 2015
Dr. Veton Këpuska
7
5
Polling vs Interrupt (Event)
Driven
Polling
Interrupts
Overhead of repeated
checking (-):
Wastes MIPS (and Watts)
(-)
Does not allow other
threads to run in the
mean time. (-)
No checking: (+)
Launch on event (+)
No wasted time or power
(+)
Allows other threads to
run independently (+)
Represents response to
priority events (+)
Small number of
interrupts sources to post
ISR. (-)
6 November 2015
Dr. Veton Këpuska
8
7
Software Interrupts &
Semaphore Posting
Allows interrupt/events launch of
threads beyond ISRs (+)
BIOS HWI & SWI are both posted to
run, like an ISR (+)
BIOS tasks (TSK) can be
synchronized via SEMaphores (+)
Improved Modularity (+)
6 November 2015
Dr. Veton Këpuska
9
Hardware and Software
Interrupt System
INT !
Hard R/T Process
SWI
Post SWI
SWI Ready
HWI
Cleanup, RETURN
Continue Soft R/T Processing ...
{
*buf++ = *SPRR;
Fast response to
count--;
interrupts
if (count == 0) {
SWI_post(&swiFir);
Minimal context switching count = COUNT;
buf = &buf2;
High priority for CPU
}
}
Limited number of HWI
possible
6 November 2015
Dr. Veton Këpuska
HWI
SWI
Latency in response time
Context switch performed
Selectable priority levels
Execution managed by
scheduler
10
BIOS & HWI + SWI
DSP/BIOS provides for HWI and SWI management
DSP/BIOS allows the HWI to post an SWI to the ready
queue
6 November 2015
Dr. Veton Këpuska
11
Thread Type Comparison
HWI
Int X ... I ...
P ...
O ...
Lab 3
usually sample oriented
post SWI : Process post
HWI
:
Input
HWI : Output Lab 4
SWI
BB
BB
U
UU
usually block oriented U
FF
FF
TSK
IOM (HWI)
post TSK : Process post
SB
IU
usually block oriented OF
6 November 2015
SB
IU
OF
Dr. Veton Këpuska
IOM (HWI)
Lab 5
Lab 6
12
Thread Type Comparison
Memory
Size
Response
Time
Reuse /
Modularity
Buffering
Model
Scheduler
Dimensions
6 November 2015
HWI – RF1
SWI – RF3
Tiny
Small
TSK – RF5
MediumLarge
ISR Rate
Quick
Slower
Minimal
Good
Excellent
n/a
Ptr pass / SIO SIO / ptr pass
1 (HWI only)
2 (HWI,SWI)
Dr. Veton Këpuska
3 (HWI,SWI,TSK)
13
Data Collection:
Samples vs. Buffers
Single sample – low latency, simple, easy.
Usually best implemented in HWIs – less context
switching overhead.
Buffered data – less frequent context switch overhead
better suited to multi-threaded systems.
Multiple buffers (2 or more) required for sustained
R/T performance:
1 to collect new data
while another is being processed)
Usually best if processing is in SWI or TSK to allow
new blocks to be built via HWI
Single context switch for entire block keeps overhead
to low/insignificant levels
6 November 2015
Dr. Veton Këpuska
14
Data Collection:
Samples vs. Buffers
Data Processing
Single Sample
Multiple Buffer
Latency
< 1 sample time
Up to total buffer
depths
Context switch
overhead
Data rate
Data rate / buffer
size
Best for
Small systems
Larger systems
Control systems
Non-recursive
systems
6 November 2015
Dr. Veton Këpuska
15
Single vs. Double Buffer
Systems
Single buffer system: collect data or process data – not both!
HWI
BUF
SWI/TSK
HWI
or
SWI/TSK
BUF
Nowhere to store new data when prior data is being processed
Double buffer system: process and collect data – real-time
compliant!
HWI
SWI/TSK
HWI
SWI/TSK
BUF
BUF
BUF
or
y
x
x BUF
y
One buffer can be processed while another is being collected
6 November 2015
Dr. Veton Këpuska
16
Double Buffer Systems
Considerations
When SWI/TSK finishes processing the buffer, it is
returned to HWI
TSK is now ‘caught up’ and meeting real-time
requirements
HWI must have priority over SWI/TSK to get new
data while prior data is being processed – standard
in DSP/BIOS
6 November 2015
Dr. Veton Këpuska
17
Single Threaded Systems
A/D
MP3
D/A
Simple systems can be easily coded under BIOS, allowing:
Maximum throughput
Ease of design
6 November 2015
Minimum code size
Low cost
Dr. Veton Këpuska
18
Multi Threaded Systems
Int
:
Dev.Dvr
A/D
IOM
while
(1)
xDAIS
MP3
TSK
Int
:
Dev.Dvr
D/A
IOM
DSP/BIOS
Scheduler
Streams
Mem.Mgmt
Complex systems benefit from the availability of more sophisticated support, including:
Multitasking scheduling allows lower priority threads to be preempted by higher ones
TSKs encapsulate and abstract processing code. Each is assigned a desired priority
Streams abstract the flow of data between drivers and processing threads (TSK, SWI)
XDAIS and IOM standards:
Define known standards across all algos and drivers, respectively
Assure non-interference between components in complex systems
Offers system integrator a uniform interface to all code components
6 November 2015
Dr. Veton Këpuska
19
Modularity & Reuse
Modularity
Don’t need to know everything
Divide project by skills required
Each segment is more manageable than the whole
Easier to modify
Easier to test
More maintainable
More adaptable for reuse
Reuse
Maximize return on cost of SW development
Product revisions
Product range (standard/minimalist/deluxe versions)
Standardized Interfaces
6 November 2015
Dr. Veton Këpuska
20
System Design Options &
Tradeoffs
Dynamic vs. Static Model
create
initialize
run
I
P
shutdown
O
Static Systems:
Smaller and faster code solutions, (+)
Simpler to create and manage, (+)
Not flexible. (-)
Dynamic Systems:
allow blocks of RAM to be
‘borrowed’ from heap when needed, (+)
and
returned afterward for reuse by
subsequent requestors; (+)
add the create & delete phases (-)
delete
6 November 2015
Dr. Veton Këpuska
21
System Design Options &
Tradeoffs
Speed vs. Memory:
MIPS vs. Mbytes
• System designers can often trade one for the other to
optimize performance and cost
Speed: Latency vs.
Flexibility
• Number of Buffers have effect on the
• Latency (input to output time) vs.
• Flexibility (improved ability to tolerate preemption)
Time: MIPS vs.
Time to Market
Cost: Device vs.
Time to Market
6 November 2015
• Faster DSP processing rates offer performance that
exceeds minimum requirements of many systems.
• More sophisticated features can be employed to simplify
coding effort, improve speed of coding and time to market .
• Price of DSP HW and development should be weighed
against the value of time to market.
Dr. Veton Këpuska
22
Real-Time System Design
Considerations
1
2
3
4
6 November 2015
• Real-Time System Concepts
• DSP/BIOS
• Development Cycle with DSP/BIOS
• Lab
Dr. Veton Këpuska
23
3
DSP/BIOS
6 November 2015
Dr. Veton Këpuska
24
DSP/BIOS
1
2
3
4
6 November 2015
• DSP/BIOS Components
• DSP/BIOS API
• DSP/BIOS Configuration
• DSP/BIOS Analysis Tools
Dr. Veton Këpuska
25
3
DSP/BIOS Components
Source
Files :
Code Composer Project
DSP/BIOS API
cfg.cmd
cfg.s54
cfg.h54
cfg_c.c
cfg.h
.cdb
DSP/BIOS
Configuration
6 November 2015
Code Generation
Tools
Compiler,
Assembler, Linker
Config Script
.tcf
Executable
DSP/BIOS
Application Tools
OLE Application
using RTDX
3rd Party
plug-ins
Host Emulation Support
Code Composer Editor
.c .h .asm
Code Composer Debugger
Workstation
Code Composer Studio
DSP/BIOS
Target
Hardware
DSP
Application
Program
RTDX
plug-ins
Dr. Veton Këpuska
26
DSP/BIOS Components
DSP/BIOS API. On the host PC, you write programs (in
C, C++, or assembly) that call DSP/BIOS API functions.
DSP/BIOS Configuration. You create a configuration that
defines static objects to be used in your program. The
configuration generates files that you compile and link with the
program.
DSP/BIOS Analysis Tools. These tools in Code Composer
Studio let you test the program on the target device while
monitoring:
CPU load, timing, logs, thread execution, and more.
Thread refers to any thread of execution:
hardware interrupt,
software interrupt,
task, or
idle function.
6 November 2015
Dr. Veton Këpuska
27
DSP/BIOS
1
2
3
4
6 November 2015
• DSP/BIOS Components
• DSP/BIOS API
• DSP/BIOS Configuration
• DSP/BIOS Analysis Tools
Dr. Veton Këpuska
28
3
DSP/BIOS Real-Time
Kernel & API
DSP/BIOS is a scalable real-time kernel, designed for
applications that require
real-time scheduling and synchronization,
host-to-target communication, or
real-time instrumentation.
DSP/BIOS provides
preemptive multi-threading,
hardware abstraction,
real-time analysis, and
configuration tools.
6 November 2015
Dr. Veton Këpuska
29
DSP/BIOS API Modules
The DSP/BIOS API is divided into modules. Depending on
what modules are configured and used by the application, the
size of DSP/BIOS can range from about 500 to 6500 words of
code. All the operations within a module begin with the letter
codes shown in the Table (next slides).
Application programs use DSP/BIOS by making calls to
the API. All DSP/BIOS modules provide C-callable interfaces.
Most C-callable interfaces can also be called from assembly
language, provided that C calling conventions are followed.
Some of the C interfaces are actually C macros and therefore,
cannot be used when called from assembly language. Refer to
the TMS320 DSP/BIOS API Reference Guide for your platform
for details.
6 November 2015
Dr. Veton Këpuska
30
DSP/BIOS Modules
Module
Description
Module
Description
ATM
Atomic functions written in assembly language
MEM
Memory segment manager
BUF
Fixed-length buffer pool manager
MSGQ
Message queue manager
C28,C54,C55
,C62,C64
Target-specific functions, platform dependent
PIP
Buffered pipe manager
POOL
Allocator pool manager
CLK
Clock manager
PRD
Periodic function manager
DEV
Device driver interface
PWRM
Power manager (C55x only)
GBL
Global setting manager
QUE
Atomic queue manager
GIO
General I/O manager
RTDX
Real-time data exchange settings
HOOK
Hook function manager
SEM
Semaphore manager
HST
Host channel manager
SIO
Stream I/O manager
HWI
Hardware interrupt manager
STS
Statistics object manager
IDL
Idle function manager
SWI
Software interrupt manager
LCK
Resource lock manager
SYS
System services manager
MBX
Mailbox manager
TRC
Trace manager
TSK
Multitasking manager
6 November 2015
Dr. Veton Këpuska
31
DSP/BIOS
1
2
3
4
6 November 2015
• DSP/BIOS Components
• DSP/BIOS API
• DSP/BIOS Configuration
• DSP/BIOS Analysis Tools
Dr. Veton Këpuska
32
3
DSP/BIOS Configuration
A DSP/BIOS configuration allows you to optimize your
application by creating objects and setting their properties
statically, rather than at run-time. This both improves runtime performance and reduces the application footprint.
The source file for a configuration is a DSP/BIOS Tconf
script, which has a file extension of .tcf.
There are two ways to access a DSP/BIOS
configuration:
1. Textually.
2. Graphically
6 November 2015
Dr. Veton Këpuska
33
DSP/BIOS Configuration
Textual DSP/BIOS configuration:
One can edit the text of the script using Code Composer Studio
(or a separate text editor).
Code in the configuration file uses JavaScript syntax. See the
DSP/BIOS Textual Configuration (Tconf) User’s Guide (SPRU007)
for details.
prog.module(“SWI”).create.(“encoder”)
prog.module(“SWI”).create.(“decoder”)
Graphical DSP/BIOS configuration:
Configurations are in read-only mode and can be viewed with the
DSP/BIOS Configuration Tool. The interface is similar to that
of the Windows Explorer.
6 November 2015
Dr. Veton Këpuska
34
DSP/BIOS Configuration
A wide range of parameters used by DSP/BIOS can be set at
run time. The created objects are used by the application's
DSP/BIOS API calls. These objects include
software interrupts,
tasks,
I/O streams, and
event logs.
When a configuration is saved, Tconf generates files to be
included in the project. Using static configuration, DSP/BIOS
objects can be pre-configured and bound into an executable
program image.
Alternately, a DSP/BIOS program can create and delete
certain objects at run time.
In addition to minimizing the target memory footprint by
eliminating run-time code and optimizing internal data
structures, creating static objects detects errors earlier by
validating object properties before program compilation.
6 November 2015
Dr. Veton Këpuska
35
DSP/BIOS Configuration Tool
Module Tree
6 November 2015
Dr. Veton Këpuska
36
DSP/BIOS
1
2
3
4
6 November 2015
• DSP/BIOS Components
• DSP/BIOS API
• DSP/BIOS Configuration
• DSP/BIOS Analysis Tools
Dr. Veton Këpuska
37
3
DSP/BIOS Analysis Tools
The DSP/BIOS analysis tools complement the Code
Composer Studio environment by enabling real-time
program analysis of a DSP/BIOS application.
One can visually monitor a DSP application as it runs with
minimal impact on the application's real-time performance.
The DSP/BIOS analysis tools are found in the DSP/BIOS menu,
as shown in the Figure below:
6 November 2015
Dr. Veton Këpuska
38
DSP/BIOS Analysis Tools
Unlike traditional debugging, which is external to the
executing program, program analysis requires the target
program contain real-time instrumentation services. By using
DSP/BIOS APIs and objects, developers automatically
instrument the target for capturing and uploading real-time
information to the host through the Code Composer Studio
DSP/BIOS analysis tools.
Several broad real-time program analysis capabilities are
provided:
Program tracing. Displaying events written to target
logs, reflecting dynamic control flow during program
execution
Performance monitoring. Tracking summary statistics
that reflect use of target resources, such as processor load
and timing
File streaming. Binding target-resident I/O objects to
host files
6 November 2015
Dr. Veton Këpuska
39
DSP/BIOS Analysis Tools
When used in tandem with other debugging capabilities of
Code Composer Studio, the DSP/BIOS real-time analysis
tools provide critical views into target program behavior
during program execution—
where traditional debugging
techniques that stop the target offer little insight.
Even after the debugger halts the program, information
already captured by the host with the DSP/BIOS analysis tools
can provide insight into the sequence of events that led up to
the current point of execution.
Later in the software development cycle, when regular
debugging techniques become ineffective for attacking
problems arising from time-dependent interactions, the
DSP/BIOS analysis tools have an expanded role as the
software counterpart of the hardware logic analyzer.
6 November 2015
Dr. Veton Këpuska
40
Code Composer Studio
Analysis Tool Panels
DSP/BIOS Analysis
Tools Toolbar
6 November 2015
Dr. Veton Këpuska
41
Naming Conventions
6 November 2015
Dr. Veton Këpuska
42
Naming Conventions
Each DSP/BIOS module has a unique name that is used
as a prefix for
operations (functions),
header files, and
objects for the module.
This name is comprised of 3 or more uppercase alpha-numeric
characters.
Two consecutive digits, e.g., 64 represents the two-digit
numeric appropriate to a specific DSP platform. Our DSP
platform is C6400 based, hence substitute 64 each time you
see other designation, e.g., 54.
For example, DSP/BIOS assembly language API header files for
the C6000 platform will have a suffix of .h64.
For a C5000 DSP platform, substitute either 54 or 55 for each
occurrence of 54.
6 November 2015
Dr. Veton Këpuska
43
Naming Conventions
All identifiers beginning with upper-case letters
followed by an underscore (XXX_*) should be
treated as reserved words.
6 November 2015
Dr. Veton Këpuska
44
Module Header Names
Each DSP/BIOS module has two header files containing
declarations of all constants, types, and functions made
available through that module's interface.
xxx.h. DSP/BIOS API header files for C programs. Your C
source files should include std.h and the header files for
any modules the C functions use.
xxx.h64. DSP/BIOS API header files for assembly
programs. Assembly source files should include the
xxx.h64 header file for any module the assembly source
uses. This file contains macro definitions specific to this
device.
6 November 2015
Dr. Veton Këpuska
45
Module Header Names
Any program must include the corresponding header for each
module used in a particular program source file. In addition, C
source files must include std.h before any module header files.
The std.h file contains definitions for standard types and
constants. After including std.h, you can include the other
header files in any sequence. For example:
#include <std.h>
// This include must be first
#include <tsk.h>
#include <sem.h>
#include <prd.h>
#include <swi.h>
6 November 2015
Dr. Veton Këpuska
46
Object Names
System objects included in the configuration by default
typically have names beginning with a 3- or 4-letter code for
the module that defines or uses the object.
For example, the default configuration includes a LOG object
called LOG_system.
Note:
Objects you create statically should use a common naming
convention of your choosing. You might want to use the module
name as a suffix in object names. For example, a TSK object
that encodes data might be called encoderTsk.
6 November 2015
Dr. Veton Këpuska
47
Operation Names
The format for a DSP/BIOS API operation name is
MOD_action where MOD is the letter code for the module
that contains the operation, and action is the action performed
by the operation.
For example, the SWI_post function is defined by the SWI
module; it posts a software interrupt.
This implementation of the DSP/BIOS API also includes
several built-in functions that are run by various built-in
objects. Here are some examples:
CLK_F_isr. Run by an HWI object to provide the lowresolution CLK tick.
PRD_F_tick. Run by the PRD_clock CLK object to
manage PRD_SWI and system tick.
PRD_F_swi. Triggered by PRD_tick to run the PRD
functions.
6 November 2015
Dr. Veton Këpuska
48
Operation Names
_KNL_run. Run by the lowest priority SWI object, KNL_swi,
to run the task scheduler if it is enabled. This is a C function
called KNL_run. An underscore is used as a prefix
because the function is called from assembly code.
_IDL_loop. Run by the lowest priority TSK object, TSK_idle,
to run the IDL functions.
IDL_F_busy. Run by the IDL_cpuLoad IDL object to
compute the current CPU load.
RTA_F_dispatch. Run by the RTA_dispatcher IDL object to
gather real-time analysis data.
LNK_F_dataPump. Run by the LNK_dataPump IDL object
to manage the transfer of real-time analysis and HST channel
data to the host.
HWI_unused. Not actually a function name. This string is
used in the configuration to mark unused HWI objects.
6 November 2015
Dr. Veton Këpuska
49
Operation Names
Symbol names beginning with MOD_ and MOD_F_ (where MOD
is any letter code for a DSP/BIOS module) are reserved for
internal use.
Note:
Your program code should not call any built-in functions
whose names begin with MOD_F_. These functions are
intended to be called only as function parameters specified in
the configuration.
6 November 2015
Dr. Veton Këpuska
50
Data Type Names
The DSP/BIOS API does not explicitly use the fundamental
types of C such as int or char. Instead, to ensure portability to
other processors that support the DSP/BIOS API, DSP/BIOS
defines its own standard data types. In most cases, the
standard DSP/BIOS types are uppercase versions of the
corresponding C types.
Table in the next slide lists all data types defined and used by
DSP/BIOS
Additional data types are defined in std.h but those are not
used by DSP/BIOS
6 November 2015
Dr. Veton Këpuska
51
DSP/BIOS Data Types
Type
Description
Arg
Type capable of holding both Ptr and Int arguments
Int
arguments
Bool
Boolean value
Char
Character value
Fxn
Pointer to a function
Int
Signed integer value
LgInt
Large signed integer value
LgUns
Large unsigned integer value
Ptr
Generic pointer value
String
Zero-terminated (\0) sequence (array) of characters
Uns
Unsigned integer value
Void
Empty type
6 November 2015
Dr. Veton Këpuska
52
DSP/BIOS Data Types
In addition, the standard constant NULL (0) is used by
DSP/BIOS to signify an empty pointer value. The constants
TRUE (1) and FALSE (0) are used for values of type Bool.
Object structures used by the DSP/BIOS API modules use
a naming convention of MOD_Obj, where MOD is the
letter code for the object’s module. If your program code
uses any such objects created in the configuration, it
should make an extern declaration for the object. For
example:
extern LOG_Obj trace;
6 November 2015
Dr. Veton Këpuska
53
DSP/BIOS Data Types
Running the configuration script automatically generates a C
header file that contains the appropriate declarations for all
DSP/BIOS objects created by the configuration
(<program>.cfg.h). This file should be included by the
application's source files to declare DSP/BIOS objects.
6 November 2015
Dr. Veton Këpuska
54
Memory Segment Names
C6000 EVM Platform
Segment
• Description
IPRAM
• Internal (on-device) program memory
IDRAM
• Internal (on-device) data memory
SBSRAM
• External SBSRAM on CE0
SDRAM0
• External SDRAM on CE2
SDRAM1
• External SDRAM on CE3
SBSRAM: Synchronous Burst Static Random Access Memory
6 November 2015
Dr. Veton Këpuska
55
Standard Memory Sections
The configuration defines standard memory sections and their
default allocations as shown in Table below. You can change
these default allocations using the MEM Manager. For more
detail, see MEM Module in the TMS320 DSP/BIOS API Reference
Guide for your platform.
C6000 Platform
Segment
• Sections
IDRAM
• System stack memory (.stack)
IDRAM
• Application constants memory (.const)
IDRAM
• Program memory (.text)
IDRAM
• Data memory (.data)
IDRAM
• Startup code memory (.sysinit)
IDRAM
• C initialization records memory (.cinit)
IDRAM
• Uninitialized variables memory (.bss)
6 November 2015
Dr. Veton Këpuska
56
DSP/BIOS Environment
6 November 2015
Dr. Veton Këpuska
57
DSP/BIOS Environment
DSP/BIOS is a library that contains a collection of modules with a
particular:
Interface and calling conventions
Set of data structures defined in the module’s header file
Application Program interfaces (API) define the interactions with a
module
Relates a set of constants, types, variables and functions visible to
user programs
Object based: global parameters that control operation of each
instance
Objects - are structures that define the state of a component
Pointers to objects are called handles
References to the object are via the handle
Object based programming offers:
Better encapsulation and abstraction
Multiple instance ability
6 November 2015
Dr. Veton Këpuska
58
DSP/BIOS Environment
User Code
#include <log.h>
#include <sem.h>
func1
{
LOG_printf(...);
}
func2
{
SEM_post(…);
}
DSP/BIOS Library
HWI
SWI
TSK
IDL
PIP
SEM
MSGQ
MSG
QUE
HST
CLK
LOG
STS
TRC
PRD
SIO
6 November 2015
Dr. Veton Këpuska
API
59
Data Access:
Handles & Pointers
pointer
structure….
handle
element1
element2
…
object
6 November 2015
Dr. Veton Këpuska
60
DSP/BIOS Naming
Conventions
Three or four letter module prefix naming convention:
Used as a prefix for API, header files, and objects for modules
Capitalization convention distinguishes:
functions,
types,
constants
Table of Conventions:
Category
Convention
Example
Function Calls
MOD_lowercase
LOG_printf
Data Types
MOD_Titlecase
LOG_Obj
Constants
MOD_UPPERCASE
TRC_USER0
Internal Calls
MOD_F_lowercase
FXN_F_nop
6 November 2015
Dr. Veton Këpuska
61
DSP/BIOS Data Types
Arg
•generic argument type
Bits
•unsigned bit string
Bool
•boolean value (TRUE or FALSE)
Byte
•minimal addressable unit
Char
•signed character value
Int
•signed integer value
Long
•signed long integer value
Uns
•unsigned integer value
Ptr
•generic pointer value
Short
•signed short integer value
String
•pointer to character
Void
•empty type
6 November 2015
Dr. Veton Këpuska
62
General Purpose vs. RealTime Operating Systems
General Purpose
OS
Real-Time OS
Scope
General
Specific
Size
Large: 10k-20M
Small: 1k-20k
Event Response
(0.1- 1) ms
(10-100) ns
File Management
FAT, etc.
Not supported
Dynamic Memory
Yes
Yes
Threads
Tasks, Interrupts
TSK, SWI, HWI
Scheduler
Preemption time
slicing
Preemption only
Host Processor
ARM, x86, Power PC
DSP: C2000, ‘5000,
‘6000
6 November 2015
Dr. Veton Këpuska
63
Real-Time System Design
Considerations
1
2
3
4
6 November 2015
• Real-Time System Concepts
• DSP/BIOS
• Development Cycle with DSP/BIOS
• Lab
Dr. Veton Këpuska
64
3
Development Cycle
With DSP/BIOS
6 November 2015
Dr. Veton Këpuska
65
Development Cycle With
DSP/BIOS
A sample DSP/BIOS development cycle includes the following
steps, though iteration can occur for any step or group of steps:
1. Configure static objects for your program to use. This can
be done using the Tconf scripting language.
2. Run the configuration script. This generates files to be
included when you compile and link your program.
3. Write a framework for your program. You can use C, C++,
assembly, or a combination of the languages.
4. Add files to your project and compile and link the program
using Code Composer Studio.
5. Test program behavior using a simulator or initial hardware
and the DSP/BIOS analysis tools. You can monitor logs and
traces, statistics objects, timing, software interrupts, and
more.
6 November 2015
Dr. Veton Këpuska
66
Development Cycle With
DSP/BIOS
6.
7.
Repeat steps 1-5 until the program runs correctly. You can add
functionality and make changes to the basic program structure.
When production hardware is ready, modify the configuration
to support the production board and test your program on the
board.
6 November 2015
Dr. Veton Këpuska
67
Summary: Development
Cycle with DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
• Using DSP/BIOS with Run-Time Support Library
• DSP/BIOS Startup Sequence
• Using C++ with DSP/BIOS
• User Functions Called by DSP/BIOS
• Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
68
1. Configuring
DSP/BIOS
Applications
Statically
6 November 2015
Dr. Veton Këpuska
69
Configuring DSP/BIOS
Applications Statically
DSP/BIOS configurations allow you create objects and set their
properties statically, rather than at run-time.
Create a configuration
graphically,
textually, or
using a combination of these methods
The DSP/BIOS Textual Configuration (Tconf) User’s Guide
(SPRU007) contains details on the syntax used in configuration
scripts.
6 November 2015
Dr. Veton Këpuska
70
Configuring DSP/BIOS
Applications Statically
1.
2.
3.
DSP/BIOS configurations should not be confused with other
items used for configuration within Code Composer Studio.
These other items include:
The Project Configuration (typically Debug or Release),
The RTDX Configuration Control window, and
The System Configuration Setup in the CCS Setup tool.
6 November 2015
Dr. Veton Këpuska
71
Referencing Statically
Created DSP/BIOS Objects
Statically-created objects that you reference in a program need
to be declared as extern variables outside all function bodies.
Example:
The following declarations make the PIP_Obj object visible in all
functions that follow its definition in the program.
extern far PIP_Obj inputObj;
or
extern PIP_Obj inputObj;
/* C6000 devices */
/* C5000 and C2800 devices */
The configuration tool generates a file that contains these
declarations. The file has a name of the form *cfg.h, where *
is the name of your program. This file can be #included in C
files that reference DSP/BIOS objects.
6 November 2015
Dr. Veton Këpuska
72
Small and Large Model
Issues with C6000
Although DSP/BIOS itself is compiled using the small model,
you can compile DSP/BIOS applications using either the C6000
compiler’s small model or any variation of the large model.
(See the TMS320C6000 Optimizing Compiler User.s Guide .)
Mixed compilation models possible with some restrictions.
.bss: DSP/BIOS uses .bss memory section to store
global data.
Objects configured statically are not placed in the .bss
section.
Maximizes flexibility for development in the placement of
application data.
Frequently accessed .bss can be placed in on-device memory
Less frequently accessed objects can be stored in external memory.
6 November 2015
Dr. Veton Këpuska
73
Small and Large Model
Issues with C6000
The small model makes assumptions about the placement of
global data in order to reduce the number of instruction cycles.
When using the small model (the default compilation mode) to optimize
global data access, the code can be modified (i.e., by compiler) to make
sure that it references statically-created objects correctly.
There are four methods for dealing with this issue. These
methods are described in the following slide providing the pros
and cons of each.
6 November 2015
Dr. Veton Këpuska
74
Small and Large Model
Issues with C6000
Declare
objects
with far
Method
Use global
object
pointers
Objects
adjacent
to .bss
Compile
with
large
model
Code works independent of compilation
model
Yes
Yes
Yes
Yes
Code works independent of object
placement
Yes
Yes
No
Yes
C code is portable to other compilers
No
Yes
Yes
Yes
Statically-created object size not
limited to 32K bytes
Yes
Yes
No
Yes
Minimizes size of .bss
Yes
Yes
No
Yes
Minimizes instruction cycles.
No
(3 cycles)
No
(2-6 cycles)
Yes
(1 cycle)
No
(3 cycles)
Minimizes storage per object
No
No
Yes
No
Easy to program & easy to debug
6 November 2015
(12 bytes)
(12 bytes)
(4 bytes)
(12 bytes)
Somewhat
Error Prone
Somewhat
Yes
Dr. Veton Këpuska
75
Referencing Static DSP/BIOS
Objects in the Small Model
In the small model, all compiled code accesses global data
relative to a data page pointer register. The register B14 is
treated as a read-only register by the compiler and is initialized
with the starting address of the .bss section during program
startup.
Global data is assumed to be at a constant offset from the
beginning of the .bss section and this section is assumed to
be at most 32K bytes in length. Global data, therefore, can
be accessed with a single instruction like the following:
LDW *+DP(_x), A0 ; load _x into A0 (DP = B14)
Since objects created statically are not placed in the .bss
section, you must ensure that application code compiled with
the small model references them correctly. There are three
ways to do this as explained in the next slide(s).
6 November 2015
Dr. Veton Këpuska
76
Referencing Static DSP/BIOS
Objects in the Small Model
1. Declare static objects with the far keyword.
The DSP/BIOS compiler supports this common extension to the C
language. The far keyword in a data declaration indicates that
the data is not in the .bss section.
For example, to reference a PIP object called inputObj that was
created statically, declare the object as follows:
extern far PIP_Obj inputObj;
if (PIP_getReaderNumFrames(&inputObj)) {
. . .
}
6 November 2015
Dr. Veton Këpuska
77
Referencing Static DSP/BIOS
Objects in the Small Model
2. Create and initialize a global object pointer.
One can create a global variable that is initialized to the address
of the object you want to reference. All references to the object
must be made using this pointer, to avoid the need for the far
keyword.
For example:
extern PIP_Obj inputObj;
/* input MUST be a global variable */
PIP_Obj *input = &inputObj;
if (PIP_getReaderNumFrames(input)) {
. . .
}
6 November 2015
Dr. Veton Këpuska
78
Referencing Static DSP/BIOS
Objects in the Small Model
Declaring and initializing the global pointer consumes an
additional word of data (to hold the 32-bit address of the object).
Also, if the pointer is a static or automatic variable this
technique fails. The following code does not operate as
expected when compiled using the small model:
extern PIP_Obj inputObj;
static PIP_Obj *input = &inputObj; /* ERROR!!!! */
if (PIP_getReaderNumFrames(input)) {
. . .
}
6 November 2015
Dr. Veton Këpuska
79
Referencing Static DSP/BIOS
Objects in the Small Model
3. Place all objects adjacent to .bss
If all objects are placed at the end of the .bss section, and the
combined length of the objects and the .bss data is less than 32K
bytes, you can reference these objects as if they were allocated
within the .bss section:
extern PIP_Obj inputObj;
if (PIP_getReaderNumFrames(&inputObj)) {
. . .
}
6 November 2015
Dr. Veton Këpuska
80
Referencing Static DSP/BIOS
Objects in the Small Model
You can guarantee this placement of objects by using the
configuration as follows:
i.
Declare a new memory segment by creating a MEM object and
setting its properties (i.e., the base and length); or use one of
the preexisting data memory MEM objects.
ii. Place all objects that are referenced by small model code in
this memory segment.
iii. Place Uninitialized Variables Memory (.bss) in this same
segment.
6 November 2015
Dr. Veton Këpuska
81
Referencing Static DSP/BIOS
Objects in the Large Model
In the large model, all compiled code accesses data by first loading the
entire 32-bit address into an address register and then using the
indirect addressing capabilities of the LDW instruction to load the data.
For example:
MVKL _x, A0; move low 16-bits of _x’s address into A0
MVKH _x, A0; move high 16-bits of _x’s address into A0
LDW *A0, A0; load _x into A0
Application code compiled with any of the large model variants is not
affected by the location of static objects. If all code that directly
references statically created objects is compiled with any large model
option, code can reference the objects as ordinary data:
extern PIP_Obj inputObj;
if (PIP_getReaderNumFrames(&inputObj)) {
. . .
}
6 November 2015
Dr. Veton Këpuska
82
Referencing Static DSP/BIOS
Objects in the Large Model
The -ml0 large model option is identical to small model except
that all aggregate data is assumed to be far.
This option causes all static objects to be assumed to be far
objects but allows scalar types (such as int, char, long) to be
accessed as near data. As a result, the performance
degradation for many applications is quite modest.
6 November 2015
Dr. Veton Këpuska
83
Static Model of DSP/BIOS
Objects
Creating objects statically provides the following benefits:
Improved access with DSP/BIOS analysis tools.
Reduced code size.
The Execution Graph shows the names of objects created statically. In addition, you
can view statistics only for objects created statically.
For a typical module, the XXX_create() and XXX_delete() functions contain 50%
of the code required to implement the module. If you avoid using any calls to
TSK_create() and TSK_delete(), the underlying code for these functions is not
included in the application program. The same is true for other modules. By
creating objects statically, you can dramatically reduce the size of your application
program.
Improved run-time performance.
In addition to saving code space, avoiding dynamic creation of objects reduces the
time your program spends performing system setup.
6 November 2015
Dr. Veton Këpuska
84
Development Cycle with
DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
• Using DSP/BIOS with Run-Time Support Library
• DSP/BIOS Startup Sequence
• Using C++ with DSP/BIOS
• User Functions Called by DSP/BIOS
• Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
85
2. Configuring
DSP/BIOS Objects
Dynamically
6 November 2015
Dr. Veton Këpuska
86
Creating DSP/BIOS Objects
Dynamically
For typical DSP applications, most objects should be created
statically because they are used throughout program
execution.
A number of default objects are automatically defined in the
configuration template.
Creating objects statically has the following limitations:
Static objects are created whether or not they are needed.
You may want to create objects dynamically if they will be used only as
a result of infrequent run-time events.
You cannot delete static objects at run-time using the XXX_delete
functions.
6 November 2015
Dr. Veton Këpuska
87
Creating DSP/BIOS Objects
Dynamically
Many, but not all, DSP/BIOS objects can be created by calling the
function XXX_create where XXX names a specific module.
Some objects can only be created statically.
Each XXX_create function allocates memory for storing the object’s
internal state information, and returns a handle used to reference the
newly-created object when calling other functions provided by the XXX
module.
Most XXX_create functions accept as their last parameter a pointer to
a structure of type XXX_Attrs which is used to assign attributes to the
newly created object.
By convention, the object is assigned a set of default values if this
parameter is NULL. These default values are contained in the constant
structure XXX_Attrs listed in the header files, enabling you to first
initialize a variable of type XXX_Attrs and then selectively update its
fields with application-dependent attribute values before calling
XXX_create. Sample code that creates a dynamic object using the
TSK_create is shown in the example in the next slide.
6 November 2015
Dr. Veton Këpuska
88
Creating DSP/BIOS Objects
Dynamically
Creating & Referencing
Dynamic Objects
Deleting a Dynamic Object
#include <tsk.h>
TSK_Attrs attrs;
TSK_Handle task;
attrs = TSK_ATTRS;
attrs.name = "reader";
attrs.priority = TSK_MINPRI;
task = TSK_create((Fxn)foo, &attrs);
TSK_delete (task);
The XXX_create function passes back a
Objects created with XXX_create
handle that is an address to the task’s
are deleted by calling the function
object. This handle is can then be passed
XXX_delete. This frees the
as an argument when referencing, for
object’s internal memory back to
example, deleting the object, as shown
the system for later use.
in next column.
6 November 2015
Dr. Veton Këpuska
89
Development Cycle with
DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
•Using DSP/BIOS with Run-Time Support Library
•DSP/BIOS Startup Sequence
•Using C++ with DSP/BIOS
•User Functions Called by DSP/BIOS
•Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
90
3. Files Used to Create
DSP/BIOS Programs
6 November 2015
Dr. Veton Këpuska
91
Files Used to Create
DSP/BIOS Programs
program.c
*.asm, *.c,
*.h and/or
*.cpp
*.cmd
(optional)
program.tcf
Generate
include
module.h
module.h64
Compile or
Assemble
program.obj
*.obj
programcfg.
h64
Programcfg_
c.c
programcfg.
s64
Assemble
programcfg.
obj
Programcfg.
cmd
programcfg.
h
Compile
programcfg_
c.obj
program.out
6 November 2015
Dr. Veton Këpuska
92
Files Used to Create
DSP/BIOS Programs
Program Files
program.c
Program source file containing the main function. You can also have
additional .c source files and program .h files.
program.tcf
The Tconf script that generates the configuration files when run. This is
the source file for the configuration. This is the file you add to a Code
Composer Studio project to make the configuration part of the
application.
*.asm
Optional assembly source file(s). One of these files can contain an
assembly language function called _main as an alternative to using a C
or C++ function called main.
module.h
DSP/BIOS API header files for C or C++ programs. Your source files
should include std.h and the header files for any modules the program
uses.
6 November 2015
Dr. Veton Këpuska
93
Files Used to Create
DSP/BIOS Programs
Program Files (cont.)
module.h64
DSP/BIOS API header files for assembly programs. Assembly source files
should include the *.h64 header file for any module the assembly source
uses.
program.obj
Object file(s) compiled or assembled from your source file(s)
*.obj
Object files for optional assembly source file(s)
*.cmd
Optional linker command file(s) that contains additional sections for your
program not defined by the DSP/BIOS configuration.
program.out
An executable program for the target (fully compiled, assembled, and
linked). You can load and run this program with Code Composer Studio
commands.
6 November 2015
Dr. Veton Këpuska
94
Static Configuration Files
When a Tconf script is run that contains the prog.gen()
method, the following files are created (where "program" is the
configuration file name and 54 below is replaced by 28, 55, or
64 as appropriate for the platform used):
programcfg.cmd
Linker command file for DSP/BIOS objects. This file defines
DSP/BIOS-specific link options and object names, and generic
data sections for DSP programs (such as .text, .bss, .data,
etc.). When you add a *.tcf file to a Code Composer Studio
project, this file is automatically added in the Generated Files
folder of the Project View.
programcfg.h
Includes DSP/BIOS module header files and declares external
variables for objects created in the configuration.
6 November 2015
Dr. Veton Këpuska
95
Static Configuration Files
programcfg_c.c
Defines DSP/BIOS related objects. (No longer defines CSL objects.)
programcfg.s64
Assembly language source file for DSP/BIOS settings. When you add a
*.tcf file to a Code Composer Studio project, this file is automatically
added in the Generated Files folder of the Project View.
programcfg.h64
Assembly language header file included by programcfg.s54.
program.cdb
Stores configuration settings for use by run-time analysis tools. In
previous versions, this was the configuration source file. It is now
generated by running the *.tcf file. This file is used by the DSP/BIOS
analysis tools.
programcfg.obj
Object file created from the source file generated by the configuration.
6 November 2015
Dr. Veton Këpuska
96
Development Cycle with
DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
• Using DSP/BIOS with Run-Time Support Library
• DSP/BIOS Startup Sequence
• Using C++ with DSP/BIOS
• User Functions Called by DSP/BIOS
• Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
97
4. Compiling And
Linking Programs
6 November 2015
Dr. Veton Këpuska
98
Compiling and Linking
Programs
Building the DSP/BIOS executable:
Code Composer Studio (Build)
Makefile (GNU make)
6 November 2015
Dr. Veton Këpuska
99
Development Cycle with
DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
• Using DSP/BIOS with Run-Time Support Library
• DSP/BIOS Startup Sequence
• Using C++ with DSP/BIOS
• User Functions Called by DSP/BIOS
• Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
100
5. Using DSP/BIOS with
Run-Time Support
Library
6 November 2015
Dr. Veton Këpuska
101
Using DSP/BIOS with RunTime Support Library
The linker command file generated by the configuration
automatically includes directives to search the necessary
libraries including a DSP/BIOS, Real-Time Data Exchange
(RTDXTM), and a run-time support library.
The run-time support library is created from rts.src,
which contains the source code for the run-time support
functions.
These are standard ANSI functions that are not part of the C
language (such as functions for memory allocation, string
conversion, and string searches).
A number of memory management functions that are defined
within rts.src are also defined within the DSP/BIOS library. These
are:
malloc
calloc
free
realloc
memalign
6 November 2015
Dr. Veton Këpuska
102
Using DSP/BIOS with RunTime Support Library
The libraries support different implementations. For example,
the DSP/BIOS versions are implemented with the MEM module
and therefore make use of the DSP/BIOS API calls
MEM_alloc and
MEM_free.
Because the DSP/BIOS library provides some of the same
functionality found in the run-time support library, the
DSP/BIOS linker command file includes a special version of the
run-time support library called rtsbios that does not include the
files shown in the Table in the next slide.
6 November 2015
Dr. Veton Këpuska
103
Files Not Included in rtsbios
C6000 Platform
memory.c
sysmem.c
autoinit.c
boot.c
6 November 2015
Dr. Veton Këpuska
104
Linker –x Switch
In many DSP/BIOS projects, it is necessary to use the -x linker
switch in order to force the rereading of libraries.
For example, if printf references malloc and malloc has not
already been linked in from the DSP/BIOS library, it forces the
DSP/BIOS library to be searched again in order to resolve the
reference to malloc.
The run-time support library implements printf with
breakpoints. Depending on how often your application uses
printf and the frequency of the calls, printf() can interfere with
RTDX, thus affecting real-time analysis tools such as the
Message Log and Statistics View, and preventing these tools
from updating. This is because the printf breakpoint processing
has higher priority processing than RTDX. It is therefore
recommended to use LOG_printf in place of calls to printf
wherever possible within DSP/BIOS applications.
6 November 2015
Dr. Veton Këpuska
105
Note
It is recommended to use the DSP/BIOS library version
of malloc, free, memalign, calloc and realloc within
DSP/BIOS applications.
When you are not referencing these functions directly in your
application but call another run-time support function which
references one or more of them, add ’-u _symbol’, (for
example, -u _malloc) to your linker options.
The -u linker option introduces a symbol, such as malloc,
as an unresolved symbol into the linker’s symbol table.
This causes the linker to resolve the symbol from the
DSP/BIOS library rather than the run-time support library.
If in doubt, you can examine your map file for information
on the library sources of your application.
6 November 2015
Dr. Veton Këpuska
106
Development Cycle with
DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
• Using DSP/BIOS with Run-Time Support Library
• DSP/BIOS Startup Sequence
• Using C++ with DSP/BIOS
• User Functions Called by DSP/BIOS
• Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
107
6. DSP/BIOS Startup
Sequence
6 November 2015
Dr. Veton Këpuska
108
DSP/BIOS Startup Sequence
When a DSP/BIOS application starts up, the calls or
instructions in the boot.s54 (C54x platform), or autoinit.c and
boot.snn (C6000 and C55x platforms) files determine the
startup sequence.
Compiled versions of these files are provided with the bios.ann
and biosi.ann libraries and the source code is available on the
distribution disks received with your product.
The DSP/BIOS startup sequence, as specified in the source
code of the boot files is shown below. You should not need to
alter the startup sequence.
6 November 2015
Dr. Veton Këpuska
109
DSP/BIOS Startup Sequence
1. Initialize the DSP.
A DSP/BIOS program starts at the C or C++ environment entry
point c_int00. The reset interrupt vector is set up to branch to
c_int00 after reset.
For the C6000 platform, at the beginning of c_int00, the
system stack pointer (B15) and the global page pointer
(B14) are set up to point to the end of the stack section
and the beginning of .bss, respectively.
Control registers such as AMR, IER, and CSR are also
initialized.
2. Initialize the .bss from the .cinit records.
Once the stacks are set up, the initialization routine is called to
initialize the variables from the .cinit records.
6 November 2015
Dr. Veton Këpuska
110
DSP/BIOS Startup Sequence
3. Call BIOS_init to initialize the modules used by the
application.
BIOS_init performs basic module initialization. BIOS_init
invokes the MOD_init macro for each DSP/BIOS module used
by the application. BIOS_init is generated by the configuration
and is located in the programcfg.snn file.
HWI_init sets up the ISTP and the interrupt selector registers, sets the NMIE
bit in the IER on the C6000 platform, and clears the IFR on all platforms.
See the HWI Module Section in the TMS320 DSP/BIOS API Reference Guide
for your platform for more information.
Note:
When configuring an interrupt, DSP/BIOS plugs in the corresponding
ISR (interrupt service routine) into the appropriate location of the
interrupt service table. However, DSP/BIOS does not enable the
interrupt bit in IER. It is your responsibility to do this at startup or
whenever appropriate during the application execution.
6 November 2015
Dr. Veton Këpuska
111
DSP/BIOS Startup Sequence
HST_init initializes the host I/O channel interface.
The specifics of this routine depend on the particular
implementation used for the host to target link. For
example, in the C6000 platform, if RTDX is used, HST_init
enables the bit in IER that corresponds to the hardware
interrupt reserved for RTDX.
IDL_init calculates the idle loop instruction count. If
the Auto calculate idle loop instruction count property was
set to true in the Idle Function Manager configuration,
IDL_init calculates the idle loop instruction count at this
point in the startup sequence. The idle loop instruction
count is used to calibrate the CPU load displayed by the
CPU Load Graph.
6 November 2015
Dr. Veton Këpuska
112
DSP/BIOS Startup Sequence
4. Process the .pinit table. The .pinit table consists of pointers
to initialization functions. For C++ programs, class
constructors of global objects execute during .pinit processing.
5. Call your program’s main routine. After all DSP/BIOS
modules have completed their initialization procedures, your
main routine is called. This routine can be written in assembly,
C, C++ or a combination. Because the C compiler adds an
underscore prefix to function names, this can be a C or C++
function called main or an assembly function called _main.
Since neither hardware nor software interrupts are enabled
yet, you can take care of initialization procedures for your
own application (such as calling your own hardware
initialization routines) from the main routine. Your main
function can enable individual interrupt mask bits, but it
should not call HWI_enable to globally enable interrupts.
6 November 2015
Dr. Veton Këpuska
113
DSP/BIOS Startup Sequence
6. Call BIOS_start to start DSP/BIOS. Like BIOS_init,
BIOS_start is also generated by the configuration and is
located in the programcfg.snn file.
BIOS_start is called after the return from your main routine:
BIOS_start is responsible for enabling the DSP/BIOS modules and
invoking the MOD_startup macro for each DSP/BIOS module.
If the TSK Manager is enabled in the configuration, the call to
BIOS_start does not return.
6 November 2015
Dr. Veton Këpuska
114
DSP/BIOS Startup Sequence
CLK_startup sets up the PRD register, enables the bit in the IER
(C6000 platform) or the IMR (C5400 platform) for the timer
chosen in the CLK Manager, and finally starts the timer. (This
macro is only expanded if you enable the CLK Manager in the
configuration.)
PIP_startup calls the notifyWriter function for each created pipe
object.
SWI_startup enables software interrupts.
HWI_startup enables hardware interrupts by setting the GIE bit
in the CSR on the C6000 platform or clearing the INTM bit in the
ST1 register on the C5400 platform.
TSK_startup enables the task scheduler and launches the highest
priority task that is ready to run. If the application has no tasks
that are currently ready, the TSK_idle executes and calls
IDL_loop. Once TSK_startup is called, the application begins
and thus execution does not return from TSK_startup or from
BIOS_start. TSK_startup runs only if the Task Manager is
enabled in the configuration.
6 November 2015
Dr. Veton Këpuska
115
DSP/BIOS Startup Sequence
7. Execute the idle loop.
You can enter the idle loop in one of two ways.
i. In the first way, the Task Manager is enabled. The
Task scheduler runs TSK_idle which calls IDL_loop.
ii. In the second way, the Task Manager is disabled and thus
the call to BIOS_start returns and a call to IDL_loop
follows.
By calling IDL_loop, the boot routine falls into the
DSP/BIOS idle loop forever. At this point, hardware and
software interrupts can occur and preempt idle
execution. Since the idle loop manages communication
with the host, data transfer between the host and the
target can now take place.
6 November 2015
Dr. Veton Këpuska
116
Development Cycle with
DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
• Using DSP/BIOS with Run-Time Support Library
• DSP/BIOS Startup Sequence
• Using C++ with DSP/BIOS
• User Functions Called by DSP/BIOS
• Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
117
7. Using C++ with
DSP/BIOS
6 November 2015
Dr. Veton Këpuska
118
Using C++ with DSP/BIOS
Since the use C++ as development
language is not encouraged you are
referred to spru423f.pdf document
under “TI Documentation” folder in
ece3552 directory.
6 November 2015
Dr. Veton Këpuska
119
Development Cycle with
DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
• Using DSP/BIOS with Run-Time Support Library
• DSP/BIOS Startup Sequence
• Using C++ with DSP/BIOS
• User Functions Called by DSP/BIOS
• Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
120
8. User Functions
Called by DSP/BIOS
6 November 2015
Dr. Veton Këpuska
121
User Functions Called by
DSP/BIOS
User functions called by DSP/BIOS objects (IDL, TSK, SWI,
PIP, PRD, and CLK objects) need to follow specific
conventions in order to ensure that registers are used
properly and that values are preserved across function calls.
On the C6x and C55x platforms, all user functions called
by DSP/BIOS objects need to conform to C compiler
register conventions for their respective platforms. This
applies to functions written both in C and assembly languages.
6 November 2015
Dr. Veton Këpuska
122
Development Cycle with
DSP/BIOS
1
2
3
4
5
6
7
8
9
• Configuring DSP/BIOS Applications Statically
• Creating DSP/BIOS Objects Dynamically
• Files Used to Create DSP/BIOS Programs
• Compiling and Linking Programs
• Using DSP/BIOS with Run-Time Support Library
• DSP/BIOS Startup Sequence
• Using C++ with DSP/BIOS
• User Functions Called by DSP/BIOS
• Calling DSP/BIOS API’s from Main
6 November 2015
Dr. Veton Këpuska
123
9. Calling DSP/BIOS
API’s from mAIn
6 November 2015
Dr. Veton Këpuska
124
Calling DSP/BIOS API’s from
Main
The main routine in a DSP/BIOS application is for user
initialization purposes such as configuring a peripheral, or
enabling individual hardware interrupts.
It is important to recognize that main does not fall into any of
the DSP/BIOS threads types (HWI, SWI, TSK, or IDL), and that
when program execution reaches main, not all of the
DSP/BIOS initialization is complete. This is because
DSP/BIOS initialization takes place in two phases:
1.
2.
during BIOS_init which runs before main, and
during BIOS_start which runs after your program returns from
main.
Certain DSP/BIOS API calls should not be made from the
main routine, because the BIOS_start initialization has
not yet run. BIOS_start is responsible for enabling global
interrupts, configuring and starting the timer, and enabling the
schedulers so that DSP/BIOS threads can start executing.
6 November 2015
Dr. Veton Këpuska
125
Calling DSP/BIOS API’s from
Main
Therefore, DSP/BIOS calls that are not appropriate from main
are
APIs which assume hardware interrupts and the timer
are enabled, or
APIs that make scheduling calls that could block
execution.
6 November 2015
Dr. Veton Këpuska
126
Calling DSP/BIOS API’s from
Main
For example, functions should not be called from main
because:
CLK_gethtime and CLK_getltime; the timer is not
running.
HWI_disable and HWI_enable; hardware interrupts are
not globally enabled.
Potentially blocking calls, such as SEM_pend or
MBX_pend; the scheduler is not initialized.
Scheduling calls such as TSK_disable, TSK_enable,
SWI_disable, or SWI_enable; are not appropriate
within main.
6 November 2015
Dr. Veton Këpuska
127
Calling DSP/BIOS API’s from
Main
BIOS_init, which runs before main, is responsible for
initialization of the MEM module.
Therefore, it is okay to call dynamic memory
allocation functions from main. Not only are the MEM
module functions allowed (MEM_alloc, MEM_free, etc.),
but APIs for dynamic creation and deletion of DSP/BIOS
objects, such as TSK_create and TSK_delete, are also
allowed.
While blocking calls are not permitted from main,
scheduling calls that make a DSP/BIOS thread ready to run
are permitted.
These are calls such as SEM_post or SWI_post. If
such a call is made from main, the readied thread is
scheduled to run after the program returns from main
and BIOS_start finishes executing.
6 November 2015
Dr. Veton Këpuska
128
Calling DSP/BIOS API’s from
Main
See the TMS320 DSP/BIOS API Reference Guide for your
platform for more information on a particular DSP/BIOS
function call. The Constraints and Calling Context sections
indicates if the API cannot be called from main.
6 November 2015
Dr. Veton Këpuska
129
Real-Time System Design
Considerations
1
2
3
4
6 November 2015
• Real-Time System Concepts
• DSP/BIOS
• Development Cycle with DSP/BIOS
• Lab
Dr. Veton Këpuska
130
3
LAB-2 Exercise
6 November 2015
Dr. Veton Këpuska
131
LAB 2: CCS Project Creation
Objectives:
Learn to setup Code Composer Studio project
environment
Steps:
Create a CCS project from given files
Build and run the code
Explore some of CCS debugging tools
Post Lab Review
6 November 2015
Dr. Veton Këpuska
132
LAB 2: Example System
Audio
In
(48 KHz)
Audio
Out
(48 KHz)
ADC
McBSP
AIC33
DRR
udevCodec
DAC
McBSP
AIC33
DXR
FIR.c
FIR Code
coeffs.c
Coefficients
HWI 4
isrAudio
pInBuf[bkCnt]=MCBSP_read
MCBSP_write(pOutBuf[bkCnt])
if(bkCnt=2*BUF) {
QUE_put(&fromDevQ, bufs)
SEM_post(&mySem)
bkCnt=0;
}
6 November 2015
Dr. Veton Këpuska
C:\ BIOS\Labs\Algos
CLK – 100mS
PRD SWI
Function:
Arg0:
tskProcBuf
procBuf
while()
{
SEM_pend(&mySem)
for (i =0, i<HIST; i ++)
pIn[i]=pPriorIn[2*BUF-HIST];
if( sw0 == 1 )
FIR(in[pIn-HIST],out[pOut])
else
pOut[i]=pIn[i];
}
00
10
01
11
C:\BIOS\Labs\HW
C:\ BIOS\Labs\Work
_SEM_post
_mySem
TSK
tskLoad()
SEM_pend(mySem)
call fxnLoad
fxnLoad()
read DIP sw’s
call asm fn: load
(load amt spec’d
by sw values)
very low
low
DIP Sw’s:
hi
>100%
3 2
133
LAB Description
6 November 2015
A
•Project Management
B
•Debugging Techniques
C
•Authoring Skills
D
•BIOS Instrumentation
Dr. Veton Këpuska
134
Supporting Information
C:\Users\vkepuska\Documents\Courses\TI Material\BIOS_WORKSHOP\Integration
Workshop\music files OR
http://my.fit.edu/~vkepuska/Music/
Open the MUSIC folder
Select all ( ctrl-A )
Enter
Music will play for next 40+ minutes…
Music courtesy of Chris August: chrismegert.com
6 November 2015
Dr. Veton Këpuska
135
22
Project Management
6 November 2015
A
•Project Management
B
•Debugging Techniques
C
•Authoring Skills
D
•BIOS Instrumentation
Dr. Veton Këpuska
136
Project Management
1. Launch CCS (double click the CCS icon
on the PC
desktop).
2. Open a starter project : On the CCS Menu bar, select:
Project | New and fill out the dialog box as per the
graphic below. Click on the Finish box when completed.
Note:
•A CCS project defines all the files in a program, the build options, and
all other details necessary to author a system to run on a TI DSP.
6 November 2015
Dr. Veton Këpuska
137
Getting the Source Code
Copy
From:
http://my.fit.edu/~xbeharry/, or
http://my.fit.edu/~vkepuska/ece3552/TI%20D
SP-BIOS/Labs/Lab%202/
To:
your projects Work directory
6 November 2015
Dr. Veton Këpuska
138
Project Management
3. Add files to the project - There are three techniques for
adding files to projects:
Method
1:
• Open Window Explorer; navigate to the directory where the source files
reside; select any or all the source files to add the project, drag and drop these
files on top of the project folder on the left pane in the CCS window.
Method
2:
• From the CCS menu bar, select: Project | Add Files to Project ...;
• Navigate to the directory with the desired files; double-click on a file you want to
add, or
• Select all the files you want to add the project, then click the open button.
Method
3:
• Right click on the project in the Project Window and select Add Files to Project…
This will call up a similar dialogue window to method 2.
Note: CCS automatically adds referenced header files
6 November 2015
Dr. Veton Këpuska
139
Project Management
Files to add to the project
From directory C:\BIOS\Labs\Work\
audio.c - The main code for an audio filter application
From directory C:\BIOS\Labs\Algos\ add:
fir.c
- An FIR filter that does DSP filtering on the audio data
coeffs.c - Tables of filter coefficients used by fir.c
nop_loop.asm - An assembly program that implements a simple
CPU load
load-2.c - A ‘dummy load’ program, generic example of a 2nd
thread
From directory C:\BIOS\Labs\HW\ add:
codec.c - Program to setup and interact with serial ports and AIC33
6 November 2015
Dr. Veton Këpuska
140
Project Management
4. Add to the project a configuration (.tcf) file:
BIOS based projects employ a ‘textual configuration” file that
defines the environment of a project:
a listing of memory available in target hardware,
how to route software elements to available memory,
definitions of all the BIOS objects in use, interrupt routing,
– all of which will be examined in subsequent chapters.
and so forth
To specify a BIOS configuration for the project, two files need
to be added:
From directory C:\BIOS\Labs\Work\
system.tcf
systemcfg.cmd
6 November 2015
The textual configuration file
(can also be edited using GUI tool)
Derived from the TCF file; specifies the linker procedure
Dr. Veton Këpuska
141
Project Management
5. Specify the target DSP:
From the CCS pull-down menus:
click on Project | Build Options ...
select the Compiler tab and the Basic category.
In the Target Version box, select C64x+ (-mv6400+).
This is the CPU type of the 6437.
To specify a BIOS configuration for the project, two files need
to be added:
From directory C:\BIOS\Labs\Work\
system.tcf
systemcfg.cmd
6 November 2015
The textual configuration file
(can also be edited using GUI tool)
Derived from the TCF file; specifies the linker procedure
Dr. Veton Këpuska
142
Project Management
6. Specify search paths:
In the Preprocessor category, type
“..\HW;..\Algos;C:\CCStudio_v3.3\boards\evmdm6437_v2\inclu
de;$(BSL)”
into the Include Search Path box and close the dialog box by clicking
on OK
7. Add library files to the project:
This project requires the Board Support Library (BSL), which are
provided by Spectrum Digital with the EVM6437. There are two
ways to add library files to the project:
Method
1
•Drag and drop:
•Navigate to the library file’s directory using windows explorer and drag the library file into
the CCS project’s library folder. (recommended)
Method
2
•Specify the include paths and add library files via linker tab:
•Click on Project | Build Options ...
•select the Linker tab and place search paths in Library Search Path box, and library names in
the Include Libraries box.
6 November 2015
Dr. Veton Këpuska
143
Project Management
8. Add the following library: evmdm6437bsl.lib
evmdm6437bsl.lib from
C:\CCStudio_v3.3\ boards\evmdm6437_v2\lib\
Expand the demo.pjt and Source
folders
Click on the “+” to the left of the folder
icons in the CCS Project view window.
Verify that the project now has the files as
shown to the right.
Note that you can right click on a file to view its
directory source (under the properties option),
double click on the file to open it onto the CCS
workspace for viewing and editing, or delete it from the
project (right click, delete).
6 November 2015
Dr. Veton Këpuska
144
Project Management
9. Verify Active Configuration
Verify that the Active Configuration window
displays Debug (and not Release).
Debug mode provides full symbolic visibility
for easy code review.
Release mode, used later, invokes selected
optimization, which often limits debug visibility.
Since each has its own benefits, both are
supported in any given project.
6 November 2015
Dr. Veton Këpuska
145
Project Management
11. Save the project:
Project | Save
12. Build the project:
Project | Build or
by clicking the
icon.
Note the progress of the build in the Output window at the bottom of
CCS. When done, the results should automatically be loaded to the
EVM target, as indicated by the Loading Program popup window
that should briefly appear during the download.
If errors are reported, recheck the steps above and try again. If there
are still errors, ask the instructor for assistance.
6 November 2015
Dr. Veton Këpuska
146
Debugging Techniques
6 November 2015
A
•Project Management
B
•Debugging Techniques
C
•Authoring Skills
D
•BIOS Instrumentation
Dr. Veton Këpuska
147
Debugging Techniques
Logical Debug – correct output verified
Breakpoints
Memory view
Watch windows
Graphing of Data
Temporal Debug – meet timing constraints
Profiling – determine where time is being spent
Deadline verification – proof of response time
for the thread itself and
within a complex multi-threaded total system
CPU Load graph – demonstrate available MIPS
Statistics on event to response time – verify deadlines
Execution graph – show where preemption is occurring
6 November 2015
Dr. Veton Këpuska
148
Debugging Techniques
1.
2.
3.
4.
5.
If audio.c is open with a yellow arrow at main(), the program is
ready to run.
On the PC, begin playing music as the input to the EVM via the audio
patch cable. Turn on the output speaker, or prepare to listen to the
headphones.
Start the program running via Debug | Run, function key F5, or the
run icon:
Verify that the selected music is now playing from the output device.
To enable/disable the FIR filter via CCS, open a watch window on the
filter control:
i.
Open audio.c (double click on it in the Project View
window);
ii. find and double-click on the variable sw0 to select it.
iii. Right click on the now highlighted variable and select Add
to Watch Window.
iv. Change the value shown in the watch window from 1 to 0 to
bypass the Filter (and back to 1 to re-apply the filter function).
6 November 2015
Dr. Veton Këpuska
149
Debugging Techniques
6.
7.
As an alternate way to add watch items: Drag and drop the variable sw1 onto
the watch pane. Changing its value from 0 through 2 will allow differing filter
functions to be applied. Optional: to peruse the coefficients, scan the file
coeffs.c
(Optional) Add a GEL file to the project:
A GEL (general extension language) file is a CCS macro script that can automate
keystrokes, add menu items, and visual controls – all of which are conveniences
when debugging.
To add the GEL, go to File | Load GEL . . . and navigate to
C:\BIOS\Labs\Gels\ and select the file Control.gel.
Go to the GEL menu and under Filter Controls experiment with the new
functions now found there.
On and Tone open slider controls that allow variables to be controlled by
the dragging of the slider to a new setting. When trying this, observe the
change in the sound as well as the corresponding changes in the variable
values in the watch window.
6 November 2015
Dr. Veton Këpuska
150
Debugging Techniques
8. Halt the program execution:
To halt the running program type Debug | Halt, or
function key Shift+F5, or the halt icon:
After
testing the halt function, resume the program by
asserting run again.
9. Finding text in code:
Locate the while loop in the procBuf code by typing
<ctl>F or Edit | Find, then type in while. Pressing OK
brings the display to the correct area and highlights the
while(1) sought.
6 November 2015
Dr. Veton Këpuska
151
Debugging Techniques
10. Set a breakpoint:
Multiple breakpoints can be defined in the code listing, and the
system will halt whenever a breakpoint is encountered.
This is a very common and helpful debugging tool.
Setting a breakpoint is very simple – click on any desired line
(try the SEM_pend just under the while statement) and
press F9.
Note the confirmation of the breakpoint by the addition of
the red dot on the left margin at the selected line.
Run the code and observe the system halts at the selected
breakpoint, as indicated by the yellow arrow on the red dot.
Set another breakpoint or two in the while loop and run a few
times more.
6 November 2015
Dr. Veton Këpuska
152
Debugging Techniques
11. Run to cursor:
When the code is halted, click on another line within the
while(1) loop and select Debug | Run to Cursor or <ctl>
F10 (or right-click and select Run to Cursor).
This will cause the program to run until it encounters the line
the cursor is currently at.
If you like, try again at another location within the while
loop. This ability is sometimes a convenient debugging
control option.
6 November 2015
Dr. Veton Këpuska
153
Debugging Techniques
12. Stepping through code:
For even finer debug observation, the ability to run one
line of code at a time is often required. This ability is
provided by the Debug | Step Over, or – more
conveniently – via the F10 key.
Press F10 multiple times and observe the progress
of the program as indicated by the yellow arrow in
the left margin.
Note: try to wait for the debugger to show
HALTED: s/w breakpoint in the lower left corner of
CCS before issuing additional run commands.
6 November 2015
Dr. Veton Këpuska
154
Debugging Techniques
13. Running free of breakpoints:
A handy option when many breakpoints are set is the
‘run free’ mode, where breakpoints are bypassed without
having to be cleared first.
Try Debug | Run Free or <ctl>F5 to use run free
mode.
14. Clearing breakpoints:
To clear a breakpoint, simply click again on a line where
a breakpoint is set and press F9 again. Notice the
red dot disappears, indicating the clearing of the
breakpoint.
To clear all breakpoints, click
or Debug |
Breakpoints
(remove all).
6 November 2015
Dr. Veton Këpuska
155
Debugging Techniques
15. View memory: It, it is often handy to be able to observe
arrays in memory. CCS provides this ability via View |
Memory.
Specify &in (the label for the input buffer array) as
the address, and for in the Format box at the
bottom of the window, select Hex 16-Bit – TI Style.
Make the window large enough to see 100 or more data
values.
Run to breakpoint a few more times and notice the
values within the memory window updating at various
times.
Note: arrays can also be displayed in the watch window.
6 November 2015
Dr. Veton Këpuska
156
Debugging Techniques
16. Load a workspace file:
By now, the CCS workspace has probably become rather
crowded.
Time was expended making room for each new pane added. At
this point, to start over, more time would be spent to reopen
and rearrange the panes. To minimize this time CCS provides
“workspaces”, which record all the project and display
settings to a file which can be reloaded at any later point.
This is a great convenience in the iterative world of debug, and
their use is highly recommended.
Use File | Workspace | Load Workspace and select Lab2.wks from C:\BIOS\Labs\Wks. After a moment, the screen
should be loaded with the windows described above arranged
in a particular layout.
6 November 2015
Dr. Veton Këpuska
157
Debugging Techniques
Note that the Memory view window changed
appearance when the workspace was loaded.
Originally, it was bound to the right edge of the CCS
window, but now is floating in the main window.
Most CCS panes can float in the main window, ‘dock’ to
an edge, or be independent of the CCS main window.
These options are set by right clicking on a given
pane and manipulating the “Float in Main Window”
and “Allow Docking” options. Experiment with a few
such options as desired.
6 November 2015
Dr. Veton Këpuska
158
Debugging Techniques
17. Save a workspace:
Once the layout is to your liking, save the workspace as
Lab02b.wks via File Workspace | Save Workspace
As.
18. Reloading a program:
If a file becomes corrupted during test, CCS offers
the ability to reload the program via File | Reload
Program.
6 November 2015
Dr. Veton Këpuska
159
Debugging Techniques
19.Save the project.
The C:\BIOS\Labs\Work directory will be the base path
for all succeeding labs.
So, if you want to keep a copy of your work for future
study, it is recommended that you save the contents of
the work directory after each lab. To facilitate this
process, the directory C:\BIOS\mySols was created with
an empty subdirectory to hold a copy of each of your lab
results.
Copy the contents of C:\BIOS\Labs\Work to
C:\BIOS\mySols\02.
6 November 2015
Dr. Veton Këpuska
160
Authoring Skills
6 November 2015
A
•Project Management
B
•Debugging Techniques
C
•Authoring Skills
D
•BIOS Instrumentation
Dr. Veton Këpuska
161
Authoring Skills
In this lab, completed code was provided as a
starting point. In subsequent labs, this will not
be the case – the work required to implement
a given solution will be a major point of all
future labs.
As such, knowledge of how to author C and
other files in CCS will be required. In this
section, key CCS authoring skills will be
reviewed. The bulleted items below are for
review and passive test only.
6 November 2015
Dr. Veton Këpuska
162
Basic Editor Commands
The editor in CCS shares some commands with most other text
editors, such as Windows Notepad.
The File commands to Open, Close, Save, and Save As, are already
familiar to you.
A slight difference is found with the File | New command –
instead of opening a new C source file directly, there are options
offered.
The first option is for a New | Source File, also possible with
the shortcut <ctl>N.
The other important option is for a DSP/BIOS
Configuration file. The ‘config’ file is a key component of BIOSbased projects. Via the config file, all system settings, such as
the memory map,
how to link software to memory,
setup and assignment of interrupts, and
static creation of all BIOS software objects is performed.
6 November 2015
Dr. Veton Këpuska
163
Basic Editor Commands
The creation of a new BIOS configuration will be considered in the next
chapter, and increasing use of configuration options will be a
component of all future labs. For now, just note that this is the route to
follow when a new config file is to be created.
Also notice one extra command in the File menu – Save All: handy
when locking in changes made to several files in a given project.
Also similar to Notepad and other text editors are several Edit
menu options and their shortcut keys:
Cut (ctl-X),
Copy (ctl-C),
Paste (ctl-V),
Select All (ctl-A),
Delete (delete),
Find/Replace (clt-F),
Undo (ctl-Z),
Redo (ctl-Y).
6 November 2015
Dr. Veton Këpuska
164
Editing Exercises
1.
While the code seen here does currently run, a few changes
can now be made to try out some of the skills covered in
previously, and to observe a few additional editing support
features.
Verify the current system:
Rebuild <alt>P,B and
verify that music will play as before by running the
application: <alt>D, R. If there are problems, you
can retrieve a working copy of the lab from
C:\BIOS\Sols\02.
Once original performance has been verified, halt the code
<alt>D, H.
6 November 2015
Dr. Veton Këpuska
165
Editing Exercises
2.
Introduce an intentional error:
In audio.c, locate the line reading: if( sw0 == 1 ).
Delete the “0” from the variable name. What do you predict
will happen when attempting to rebuild?
Save the file, close the audio.c file window and rebuild the
project.
Note in the message window at the lower left the progress
of the build. As expected, an error was encountered, so the
build was not completed nor downloaded.
Look above the final report indicating there was an error for the
line (in red) indicating the specific error found.
Note the report identifying what problem the compiler found.
Now – double-click on the reported error and observe the
file with the flaw is opened, and the cursor is set to the
line in question. This technique should be used routinely to
clean up flaws in newly authored or modified code, so keep it
in mind as a valuable time saving trick.
6 November 2015
Dr. Veton Këpuska
166
Editing Exercises
3.
Repair the typo in the variable name. While at this line,
make another change:
instead of testing for “1” instead test for “0”.
Rebuild and retest.
With the change in the code, how does switch 0
behave now?
6 November 2015
Dr. Veton Këpuska
167
BIOS Instrumentation
6 November 2015
A
•Project Management
B
•Debugging Techniques
C
•Authoring Skills
D
•BIOS Instrumentation
Dr. Veton Këpuska
168
BIOS Instrumentation
One of the most powerful features of DSP/BIOS is the
additional ability to perform temporal debugging. Once
logical debug is completed, the ability to observe the load on
the system and how events are progressing in real-time is
a valuable system tuning aid.
Later chapters in this course will provide all the details of the
tools shown here, so for now it is not expected that you would
have any ability to create their underlying components.
Instead, the goals here are to observe some key BIOS
instrumentation and consider how these can be helpful in
system design.
In addition, it is hoped that this preview will build enthusiasm
for later chapters which will teach all aspects in the design,
authoring, and use of these advanced temporal tools.
6 November 2015
Dr. Veton Këpuska
169
BIOS Instrumentation
Access to the CPU Load Graph, Message Logs, Statistical Data,
and an Execution Graph are all via CCS’s DSP/BIOS menu
selection, as shown in the diagram below:
6 November 2015
Dr. Veton Këpuska
170
BIOS Instrumentation
1. Observe CPU Load:
The DSP/BIOS | CPU Load Graph window should already
be in the bottom right corner of the CCS window (opened
via Lab02.wks).
A green trace in a black field represents the measured
load on the CPU over time, with graduations noted on the
left side.
In the cells below, the current and peak loads are specified.
Verify that switches 2 and 3 are in the ‘up’ position,
and run the program again and note the CPU load,
with the filter running and bypassed.
Is the load what you’d expected?
6 November 2015
Dr. Veton Këpuska
171
BIOS Instrumentation
2. Rebuild in release mode:
Switch to release in the Active Configuration cell and respecify the Project Build Options as per steps A-5 and
A-6, described previously.
What is the load now?
3. Dummy Load:
Another influence on load is the 2nd thread present in this
project (the ‘dummy’ load).
The amount of load is set by EVM DIP switches 2
and 3, as indicated in the diagram at the beginning of
this lab.
Note the loads imposed by various settings of these DIP
switches Also note that loads > 100% inhibit real-time
instrumentation, and CPU load update ceases)
6 November 2015
Dr. Veton Këpuska
172
BIOS Instrumentation
4. Message Logs:
Open the message log window via DSP/BIOS | Message
Log.
Float this window in the CCS workspace. Verify the
Log Name specified is logDipSw.
As before, toggle the switches that control the sw0 and
sw1 values, noting the status of the DIP switch
modifications in the Message Log window.
The commands that are driving the messages are
real-time versions of the common printf function. As
a real-time function, note that no interruption to the
performance (‘clicking sounds’) of the real-time system
occurs when the host is sent data for display.
6 November 2015
Dr. Veton Këpuska
173
BIOS Instrumentation
5. View Execution Graph and Statistical Data:
Finally, to observe the execution graph and statistical
data, load the workspace: Lab02d.wks.
This workspace opened the two new panes and
positioned the panes in the CCS window for a good layout.
6. Execution Graph Management:
In the Execution Graph window, note the tskProcBuf and
TSK0 threads. These represent the audio and dummy load
functions, respectively.
To make these easier to watch:
right click on the Execution Graph,
select Property Page, and
uncheck all but tskProcBuf , tskLoadAndSwitch and Other
Threads.
6 November 2015
Dr. Veton Këpuska
174
BIOS Instrumentation
7. Execution Graph Observations:
Change the load to setting 3, as indicated in the Message
Log display. With a low load setting, tskLoadAndSwitch
is seldom seen, but note now the increase in the running
state (thick blue line) of the dummy load.
Note also that TSK0’s process time was made so long
that it exceeds several audio thread events. The
execution graph is displaying an important BIOS feature –
the ability of the BIOS scheduler to prioritize threads. Since
the audio thread was made higher priority than the load,
the load is preempted every time the audio thread needs to
run.
What do you think would happen if their priorities were
reversed? In a later lab, this case will be tested, and you
can determine if your answer was correct.
6 November 2015
Dr. Veton Këpuska
175
BIOS Instrumentation
8. Statistics Display Observations:
Observe the Statistics View window.
A number of variables are displaying a range of
statistical information:
how many times they’ve been encountered in code,
the total number of cycles they’ve consumed thus
far,
the maximum value of that item thus far, and
the average value of all the times the value has been
observed.
Note again that all this data is being provided in real-time,
without intrusion on the real-time threads the DSP is
running.
6 November 2015
Dr. Veton Këpuska
176
BIOS Instrumentation
9. Statistics Display Management:
Right click on the Statistics View window and select
clear to reset the counters.
10. Statistics Display Setup:
Right-click on the Statistics View window and select
Property Page…
In the Units tab, click on STS Object
tskProcBuf and select Units: Microseconds.
Observe the change in the Statistics View window
display, and note the average and maximum values of
the execution time for this real-time thread.
Since this TSK has priority over the load TSK, its execution
time is relatively consistent.
6 November 2015
Dr. Veton Këpuska
177
BIOS Instrumentation
Note that all the tools previewed here will be fully covered in
subsequent chapters and labs. Feel free to experiment further
with this lab and the tools and techniques seen here.
Finally, review the CCS Reference Sheet that follows to determine
if you are now familiar with all the items noted there.
6 November 2015
Dr. Veton Këpuska
178
CCS Reference Sheet
CCS Reference Sheet
6 November 2015
Dr. Veton Këpuska
179
CCS Reference Sheet
Help:
6 November 2015
Contents, User manuals, Tutorial
Dr. Veton Këpuska
180
Project Management
Project:
New, Open, Save, Close, Add Files to Project, Build, Rebuild
All,
Build Options:
Compiler | Preprocessor:
Include search path,
Define Symbols
Compiler | Basic:
Target Version,
Generate Debug Info,
Speed vs Size,
Optimization Levels
Linker | Basic:
6 November 2015
Output Filename,
Map filename
Library Search Path,
Include Libraries
Dr. Veton Këpuska
181
Project Management
File:
Workspace:
Load Workspace,
Save Workspace,
Save Workspace As
Options | Customize:
Debug Properties – Perform Go Main automatically
Editor Properties – File Reloading Option: Automatically
reload
Program Load Options –
Perform verification during Program Load,
Load Program After Build,
Clear All Breakpoints when Loading New Programs
6 November 2015
Dr. Veton Këpuska
182
Project Management
Control Window Display – Board name, Current loaded
program, Current Project, Product Name
Source file Names: Display full path
Project close: Close all windows on Project Close
Close projects: Close projects on exit Control Window
6 November 2015
Dr. Veton Këpuska
183
Debugging Techniques
File:
Debug:
Load Program,
Reload Program
Run (F5),
Halt (shift-F5),
Step Over (F10),
Run to Cursor (ctl-F10)
Breakpoints:
Enable All
Add (F9)
Run Free
Go Main
Disable All,
Delete (F9)
Reset
Reset Emulator
Delete All
Animate (F12) Restart
6 November 2015
Dr. Veton Këpuska
184
Debugging Techniques
View:
Memory,
Watch Window,
Edit:
Memory,
Register,
Variable
6 November 2015
Dr. Veton Këpuska
185
Authoring Skills
File:
New,
Open,
Close,
Save,
Save As,
Save All,
New:
Source File (Ctl-N),
DSP/BIOS Configuration
6 November 2015
Dr. Veton Këpuska
186
Authoring Skills
Edit:
BIOS API Help:
Cut (shift-delete),
Copy (ctl-C),
Paste (ctl-V),
Select All (ctl-A)
Delete (delete),
Find/Replace (clt-F),
Undo (ctl-Z),
Redo (ctl-Y)
highlight any BIOS API and press F1 for users guide reference
Options | Customize:
Editor Properties – Tab stops, Auto-save Project and Files before build
6 November 2015
Dr. Veton Këpuska
187
Real-Time System
Considerations
END
6 November 2015
Dr. Veton Këpuska
188