Code Composer Studio & DSP/BIOS

Code Composer Studio & DSP/BIOS
It's Real! It's Time! Time To Market Performance Reliability Integrated Develop Environment Real Time Scheduling, Debug & Analysis

Programming With DSP/BIOS
C- and ASM-callable functions HOST DEVELOPMENT COMPUTER Code Composer Studio  BUILD .c .asm .h program sources kernel headers interactive configuration tool CONFIGURATION kernel-aware debug support on-the-fly program analysis kernel modules .lib .exe executable image So what’s involved in developing a target application program that utilizes the DSP/BIOS kernel as part of its execution (or run-time) environment.... DSP/BIOS is essentially a library of functions callable from C (or assembly-language) prepare your source files in CCS; include BIOS headers; embed function calls programs are built (compiled/assembled) in the usual fashion interactive tool enables configuration of BIOS modules, tailored to your application select only the modules you need set module-specific parameters that control run-time behavior pre-create kernel data objects (in static systems only) to save memory output a library of kernel code/data that is linked into program in usual manner resulting executable file contains BIOS code/data within its image load, execute, and test programs using JTAG-based emulation and CCS debugger additional features for displaying status of kernel modules at breakpoints (task-aware debugging will be supported in future CCS 2.0 release) perform “on-the-fly” (real-time) analysis of target program, without halting execution DSP/BIOS contains functions for capturing information about running program captured information uploaded to host using RTDX protocol over physical JTAG >100 kbps RTDX bandwidth (single voice channel); roadmap to 10s of Mbytes/s CCS contains visual tools for displaying program info; SW “logical analyzer” unique feature of CCS/BIOS; important for finding “nasty glitches” “if you can’t see the problem, you can’t fix it” Now that we’ve seen how DSP/BIOS is integrated within Code Composer Studio, let’s focus on the specific run-time target functions implemented in its kernel modules.... target application program VISUALIZATION   DEBUG DSP/BIOS Kernel Interface RTDX real-time capture JTAG EMULATION SERVER TARGET TMS320 DSP HARDWARE

Software Modules DSP/BIOS™ contains a collection of modules
Each module is a coherent software package Module viewed from two perspectives interface — related set of constants, types, and functions visible to client programs body — algorithms and data structures chosen to implement functionality of the interface

Mix-and-Match Modules
DSP/BIOS Kernel Interface REAL-TIME CAPTURE software event logs statistics accumulators host cmd/data channels SUM COUNT MAX XXXX XXXX put() get() post() pend() HARDWARE ABSTRACTION real-time clock services device-independent I/O logical memory segments 0000 FFFF RAM data port streams messages periodic functions wall-clock time fast slow allocation static dynamic timer The palette of DSP/BIOS kernel modules — which can be included in a “mix-and-match” fashion within your application program — fall into three broad categories.... (#1) real-time capture + real-time link; drives host visualization of “time” dimension logs; configurable areas of memory for recording software events (4 words each) individual enabled; “one-shot”, “circular”; support for a 40-cycle printf() stat accums; primarily to measure avg / worse case fxn execution; deadlines also used as an inexpensive, general-purpose software event counter host channels; xmit/recv bulk data and/or small cmd messages through “pipe” development and deployment; “test what you fly, fly what you test” (#2) hardware abstraction; presenting physical HW through logical interfaces clock; (16-bit) timer; schedule periodic fxn calls; real-time (32-bit) clock I/O; uniform functions (get, put) for interfacing with I/O ports; (e.g., PIPes) serial ports, parallel ports, host ports, DMAs, shared memory, etc memory; LOGICAL segments hide differences in memory maps static (link-time) placement of objects or (NEW!) dynamic (run-time) allocation enables application portability among all present and future TMS320 DSPs (#3) multiple threads; schedule more than activity at once SW ints; like HW ints, up to 15 priority levels; unlimited number; HWI enabled very efficient way to structure most DSP apps; 8 words per; < 2µs switch time “standard” RTOS tasks; can block (on semaphores); require a stack per task circular list of background routines; run when no “real-time” threads ready BIOS automatically logs/measures threads; presents execution graph in CCS more structured, robust, flexible alternative to main() program loop; future growth <take questions here; refer them to Technical Overview for more detail> If you have no more questions at this time, we’d like to show you a short demo of DSP/BIOS “in action”.... MULTIPLE THREADS HW+SW interrupts synchronized tasks background routines real-time host link TARGET TMS320 DSP HARDWARE

LOG - Event Log Manager Logs reside in target memory
LOG (Message Log Manager). Log objects capture information about events in realtime. System events are captured in the system log. You can create additional logs using the Configuration Tool. Your program can add messages to any log. Logs are stored in target memory. Sent to host in idle loop. Used in execution graph, or write your own using statements such as log_printf Formatted on host - low overhead. Printf = thousands of cycles, log_printf is only a few cycles. Fixed: Stops receiving when buffer is full Circular: Records last events to occur Each log uses 4 words on target User can control how often host polls target logs Target logs cleared after sent to host, to save target memory Logs reside in target memory Fixed or circular buffer Logs passed to host during idle Set up with Config tool

Standard C function I/O
printf Function - data collection - I/O - data format & display 5,100+ cycles (200 cycles per char) 10,400 words

DSP/BIOS I/O LOGprintf Function 28 cycles (C54x) 16 words
THREAD - data collection 28 cycles (C54x) 16 words BIOS IDLE - I/O approx 100 cycles HOST - data format & display >1,000 cycles

STS - Statistics Manager
Capture Count, Maximum, and Total values for any variables in Real Time HWI, SWI, PRD, and PIP captured automatically STS statistics APIs for explicit statistics objects in your target program o STS (Statistics Manager). Statistics objects capture count, maximum, and total values for any variables in real time. Statistics about SWI (software interrupt), PRD (period), HWI (hardware interrupt), and PIP (pipe) objects can be captured automatically. In addition, your program can create statistics objects to capture other statistics. LOG and STS provide an efficient way to capture subsets of a real-time sequence of events that occur at high frequencies or a statistical summary of data values that vary rapidly. The rate at which these events occur or values change may be so high that it is either not possible to transfer the entire sequence to the host (due to bandwidth limitations) or the overhead of transferring this sequence to the host would interfere with program operation. Therefore, DSP/BIOS also provides an API module for controlling the data gathering mechanisms provided by the other modules:

Trace Manager Real-time analysis:
Turns on/off traces Use only what you need Target can start/stop acquiring data when anomaly discovered with fixed log: Store 1st n events since enabled Store last n events until disabled The TRC module manages a set of trace control bits which control the real-time capture of program information through event logs and statistics accumulators. For greater efficiency, the target does not store log or statistics information unless tracing is enabled. All trace constants except TRC_GBLTARG are switched off initially. To enable tracing you can use calls to TRC_enable or the Tools®DSP/BIOS®RTA Control Panel, which uses the TRC module internally. You do not need to enable tracing for messages written with LOG_printf or LOG_event and statistics added with STS_add or STS_delta. Your program can call the TRC_enable and TRC_disable operations to explicitly start and stop event logging or statistics accumulation in response to conditions encountered during real-time execution. This enables you to preserve the specific log or statistics information you need to see.

HST - Host Channel Manager
Real-time file I/O Audio SWI frame 1 frame 2 Host Channels PIPE buffers frame 2 frame 1 Host Computer Here, we have replaced the pipe connections to the codec with host channels, which can perform real-time file I/O. Host channels stream data between target and host Transmitted during idle loop with LNK_datapump. Idle loop must get some CPU time to pass data to the host. Each host channel is internally implemented within the target application by using a pipe function. Used to test data before final changes made, like file I/O in debugger, but real-time. Can count # frames transferred in the statistics window Bind to a host file such as a .dat file

CLK Manager /4 CPU Timer Timer Clock Register Interrupt ex: 200 MHz
PRD = 49999 CPU Clock Timer Register Timer Interrupt ex: 200 MHz User sets us/interrupt Tool sets PRD register Calls PRD_Tick Calls any CLK HWI functions CLK uses one of the available on-chip timers (2 available on C6201) Provides one of two timer functions: High and Low resolution Set up with Config tool Above: 200 MHz CPU clock, timer counter runs at 50 MHz, or 1/4 CPU rate Once PRD register is = 49999, it resets the timer counter, and sends a timer interrupt Timer interrupt does two things: Low-resolution time is incremented by 1 by calling PRD_tick Performs all other CLK functions as a hardware interrupt

PRD - Periodic Function Manager
Use CLK Manager to drive PRD Timer Interrupt Call PRD_Tick Posts PRD_SWI Executes all ready PRDs Low Resolution ‘tick rate’ ex: 1 ms ex: loadPRD every 16 ms (16 ticks) In the Config tool, if you check Use CLK Manager to drive PRD, the clock interrupt (ie once / 1000 us) will automatically call the PRD_tick function with each timer interrupt. You can also call PRD_tick yourself instead, based upon some event like I/O being available for example. PRD_tick advances the ‘tick rate’ by 1, ie 1ms, 2 ms, etc Every time PRD_tick is called, it posts a PRD_SWI that can be assigned a priority against other SWIs. However, all PRD functions have the same priority and use the same PRD_SWI. The PRD_SWI, when posted, executes all configure PRD functions. In the case of the audio demo, it executes the loadPRD (no-op loop) every 16 ticks, or 16 ms. or Call PRD_tick yourself

PIP - Buffered Pipe Manager
Example: audio demo Writer Reader Audio SWI frame 1 frame 2 Audio in/out Codec ISR PIPE buffers frame 2 frame 1 PIPES set up in internal data memory Pipes can be configured for frame size and number of words per frame. Single writer and a single reader An input pipe notifys its reader function when it is full and ready to be read. An output pipe notifys its writer fucntion when it is empty and ready to be written. Often, one end = ISR (like a codec) and the other end = SWI (like audio_swi) PIPEs can also pass data between SWIs, or to the host via host channels (next slide) Writer Reader

MEM - Memory Manager Examples:
Specify memory segments and locate code and data sections DSP/BIOS generates linker.cmd file Examples: MEM Manager Properties The DSP/BIOS memory section manager allows you to specify the memory segments required to locate the various code and data sections of a DSP/BIOS application. The following global parameters can be set for the MEM module: o Reuse startup code space. If this box is checked, the startup code section (.sysinit) can be reused after startup is complete o Stack Size (MAUs). The size of the software stack in MAUs. This value is shown in hex. The Configuration Tool status bar shows the estimated minimum stack size required for this application (as a decimal number). o Stack Section (.stack). The memory segment containing the software stack o Constant Section (.const). The memory segment containing the .const section generated by the C compiler to hold program constants such as string constants; if the C compiler is not used, this parameter is unused. o Text Section (.text). The memory segment containing the application code o BIOS Code Section (.bios). The memory segment containing the DSP/BIOS code o Data Sections (.data, .switch, .cio, .sysmem). These data sections contain program data, C switch statements, C standard I/O buffers, and the memory heap used by malloc and free. o Startup Code Section (.sysinit). The memory segment containing DSP/BIOS startup initialization code; this memory may be reused after main() starts executing o C Initialization Section (.cinit). The memory segment containing the .cinit section, to hold initialization records for C run-time autoinitialization o Uninitialized Sections (.bss, .far). The memory segment containing the .bss, .far, and .sysdata sections

Principal Software Requirements
Real Time System attributes... Event Driven synchronous & asynchronous Time Constrained hard & soft real time Require Concurrency preemption multi-tasking JWL - TISB - 2/08/00

The Historical Problem
_IO_isr: ssbx intm stm #0, imr pshm st0 …. popm st0 rsbx intm rete Hardware Only Scheduling !! Interrupts Disabled Unmanaged Interrupt Context Switch C main background functions !! void main(void) { /* enable end–of–frame interrupt */ DMA0_SCNTL = SCNTL_ENABLE; while (*ping_rx_flag != 0) { /* ping_flag starts 1, toggles every int */ if(ping_rx_flag == 1) ping_rx_flag = 0; else ping_rx_flag = 1; } No Guarantee of Concurrency Non-deterministic timing No Software Preemption Ad Hoc Analysis

The Need for Preemption - Single Task
Task A: period 2 ms, compute 1 ms (50%) A running idle Time B 1 2 3 5 4 6 7 Task A Task B Max Headroom CPU Usage Actual 100% -- 50% DR - TISB - 1/24/00

Cyclic Scheduling - Two Tasks
Task A: period 2 ms, compute 1 ms (50%) Task B: period 30 ms, compute 2 ms (6.67%) A running idle Time B 1 2 3 5 4 6 7 Task A Task B Max Headroom CPU Usage Actual 0% 57% DR - TISB - 1/24/00

Preemptive Scheduling - Two Tasks
Task A: period 2 ms, compute 1 ms (50%) Task B: period 30 ms, compute 2 ms (6.67%) A running idle Time B 1 2 3 1 2 3 5 4 6 7 Task A Task B Max Headroom CPU Usage Actual 87% 650% 100% 57% DR - TISB - 1/24/00

The DSP/BIOS Solution Foreground Level Scheduling !!
_IO_isr: HWI_enter pshm st0 pshm st1 …. popm st1 popm st0 HWI_exit Foreground Level Scheduling !! HW Interrupt Scheduling SW Interrupt Scheduling predictable thread control Real Time Analysis low overhead logging and statistics void main(void) { /* enable end–of–frame interrupt */ DMA0_SCNTL = SCNTL_ENABLE; /* post SW interrupt swiProcessBuffer */ SWI_post(&swiProcessBuffer); /* ping_flag starts 1, toggles every int */ if(ping_rx_flag == 1) ping_rx_flag = 0; else ping_rx_flag = 1; LOG_printf (&message, “Buffer 1 Avail”); Managed Context Switch Preemptive SW Scheduling Time Determinism Very Low Overhead

Real-time Multi-threaded Systems
Fundamental mechanism needed for an application to control and react to multiple, discrete real world events to produce a correct result within a specified time Independent Control Traditional Super-loop (Cyclically Scheduled) Multi-thread Approach: shoulder() { for(;;) { wait for event; moveshoulder() } wrist() { movewrist() Single-thread Approach: arm() { for (;;) { if (shoulder needs moving) moveshoulder(); if (wrist needs moving) movewrist(); ..... Multi-threaded programming techniques were developed on mini-computers in the early 1980’s to modularize and simplify complex control system problems.

Cyclically Scheduled Systems Are Problematic
CPU Load? INTs INTs fxn 4 fxn 3 Time-Out? fxn 2 fxn 1 The diagram above challenges the observer with several questions. Is data being corrupted by the application code or the thread priority and timing? Should P1 actually be prioritized to the level of P4? How long can a thread be pre-empted before it loses data? Is the CPU being loaded efficiently, are can more functionality (more threads) be added? In many conventional hard real-time systems, tasks are assigned with fixed priorities to reflect ‘critical’ deadlines, and tasks are executed in an order determined by the priorities. During the testing, the priorities are (usually manually) adjusted until the system implementer is convinced that the system works. Such an approach can only work for relatively simple systems, because it is difficult to determine a good priority assignment for a system with a large number of tasks by such a ‘test-and-adjust’ method. [Stankovic] Experience has shown that in spite of the limitations of statically scheduled systems, most commercial real-time DSP based products are designed with this paradigm. The advantages are; overhead that is usually a few percent or less of total MIPs, and a function library that is usually a few kwords or less in size. The diagram above describes the difficulties in multi-threaded systems. The problems come from knowing whether or not the system is working to specification, and if there are anomalies, what is their cause? main() Time ... hence the need for preemptive Real Time Scheduling

Thread Scheduling - HWI & Idle/ Background
INT 5 INT 4 INT 3 INT 2 INT 1 The diagram above shows the most fundamental approach to scheduling real-time threads in a DSP. The implementer is simply handling all scheduling by hardware interrupt service routines. The processor remains in idle when not servicing an interrupt. This is an example of the hardware (CPU with prioritized interrupts) acting as a scheduler for the software. DSP/BIOS uses a ‘priority based’ preemptive [static] scheduling technique. It is also sometimes called a subroutine model, or software interrupt model scheduler. In DSP/BIOS, threads run to completion, much the same as does an Interrupt Service Routine. In fact, DSP/BIOS scheduled threads are Software Interrupt Service Routines. In a statically scheduled ‘priority based’ system, threads are in one of the three states; inactive, ready, or running. In a dynamically scheduled system, tasks have available the additional state of being ‘blocked’. In a dynamic system all tasks, once running, continue to run unless blocked. In a ‘priority based’ system, the processor idles, until a thread is called by an interrupt. A thread will run to completion and return to idle unless preempted by an interrupt, or by a higher priority thread. Any running thread can post another thread (ready). If the posted thread has a higher priority, the processor will change context and go to that thread. If it is a lower priority, the processor will continue running the current thread to completion. The scheduler will then check to see if threads are pending (ready to run), and go to the ready thread with the highest priority. main() idle JWL - TISB - 2/4/00 Time

HWI - Hardware ISR Manager
Respond to external asynchronous events HWIs run uninterrupted to completion If posted multiple times, runs only once Need to minimize time and code in Interrupt Service Routine Move large processing needs by posting a SWI HWI time is ‘Other Threads’ on Execution Graph Set up with Config Tool DSP/BIOS manages the hardware interrupt vector table and provides basic hardware interrupt control functions; e.g., enabling and disabling the execution of hardware interrupts. Only need to enter name of ISR function in Config tool BIOS sets up interrupt service table, and also allows memory selection of IS table. If large amount of processing is required, the HWI should post a SWI to do the work, so that the processor can return from the HWI and re-enable interrrupts. The following global parameters can be set for the HWI module: o Function Stub Memory. Select the memory segment where the dispatch code should be placed for interrupt service routines that are configured to be monitored o Interrupt Vector Memory. Select the memory segment where the interrupt vector should be placed.

Priority Based Scheduling - DSP/BIOS
Ready (post) HWIs Run Post Preempted SWI 4 Run SWI 3 SWI 2 SWI 1 “The thread with the highest priority, that is ready to run, controls the CPU” Time 1: C main() calls BIOS_start, and then returns. Processor then drops to BIOS IDLE, which is then interrupted by a HW Interrupt. Time 2: The HWI posts SWI 1 which then runs. SWI 1 then decides to post SWI 4. SWI 4 is a higher priority than SWI , and therfore runs. While running a second HWI occurs which posts SWI 3, which is a lower priority than SWI 4, and so it is queued to run later. Time 3: SWI 4 completes, allowing SWI 3 to start running Time 4: SWI 3 posts SWI 2, which is lower priority than SWI 3, so it is queued to run Time 5: SWI 3 completes, allowing SWI 2 to start running; SWI 2 posts SWI 4, which is higher priority than SWI 2, so it starts running immediately Time 6: SWI 4 completes, switching back to SWI 2 Time 7: SWI 2 completes, switching back to SWI 1 All threads run to completion. If none are ready, then the processor drops back to BIOS Idle, which is the lowest thread priority. main () idle JWL - TISB - 1/24/00 Time

DSP/BIOS - Round Robin & Periodic Examples
INT 1 Round robin Scheduling SWI 5 SWI 3 SWI 4 Priority based Scheduling SWI 2 SWI 1 Periodic Scheduling The priority based scheduling within DSP/BIOS utilizes processor Software Interrupts to provide an additional level of thread management This intermediate or foreground level of scheduling provides a very efficient and structured mechanism for maintaining thread priorities. Fifteen levels of priority are provided with the possibility of multiple threads per level. Interrupt and background processing are available as well yielding a highly robust and flexible system. A high value side benefit to this approach, is that once DSP/BIOS is controlling threads via SWI, intrinsic analysis and instrumentation becomes available. For example, at any point in time, the scheduler knows which thread is running, when it was posted, and how long it ran once complete. Status words and timing ticks are stored into a few words of target memory, and later passed back to the host through the JTAG interface during idle time. This process has an almost insignificant affect on target DSP overhead, but yields valuable information to the host for display. The host reads, computes, formats, and renders variable count, timing, and thread interaction of the system while it is running. In the example above, we see how two SWI threads have been assigned the same priority, and will operate round robin until they complete. main () idle Time

DSP/BIOS - SW Interrupt Scheduling
DSP/BIOS Software Interrupt threads use an ‘Interrupt Service’ scheduling model. DSP/BIOS SWI threads are preemptable, and run to completion. DSP/BIOS SWI threads cannot be suspended (blocked) and therefore must have required resources ready before they run. DSP/BIOS SWI threads are an excellent scheduling mechanism for very low overhead, deterministic, ‘Hard Real Time’ systems. The priority based scheduling within DSP/BIOS utilizes processor Software Interrupts to provide an additional level of thread management This intermediate or foreground level of scheduling provides a very efficient and structured mechanism for maintaining thread priorities. Fifteen levels of priority are provided with the possibility of multiple threads per level. Interrupt and background processing are available as well yielding a highly robust and flexible system. A high value side benefit to this approach, is that once DSP/BIOS is controlling threads via SWI, intrinsic analysis and instrumentation becomes available. For example, at any point in time, the scheduler knows which thread is running, when it was posted, and how long it ran once complete. Status words and timing ticks are stored into a few words of target memory, and later passed back to the host through the JTAG interface during idle time. This process has an almost insignificant affect on target DSP overhead, but yields valuable information to the host for display. The host reads, computes, formats, and renders variable count, timing, and thread interaction of the system while it is running. In the example above, we see how two SWI threads have been assigned the same priority, and will operate round robin until they complete. JWL - TISB - 2/08/00

DSP/BIOS II - Beyond SW Interrupts
_IO_isr: ssbx intm stm #0, imr pshm st0 …. popm st0 rsbx intm rete What if our new design requires concurrent real time operation? But there is... void main(void) { /* enable end–of–frame interrupt */ DMA0_SCNTL = SCNTL_ENABLE; /* post SW interrupt swiProcessBuffer */ SWI_post(&swiProcessBuffer); /* ping_flag starts 1, toggles every int */ if(ping_rx_flag == 1) ping_rx_flag = 0; else ping_rx_flag = 1; LOG_printf (&message, “Buffer 1 Avail”); A need for Dynamic Prioritization No Guarantee of Resource Availability JWL - TISB - 2/08/00

The DSP/BIOS II Solution
_IO_isr: HWI_enter pshm st0 pshm st1 …. popm st1 popm st0 HWI_exit Then we need Synchronized Task Scheduling !! (Multi-Tasking) (SPOX) HW Interrupt Scheduling SW Interrupt Scheduling TASK Scheduling blocking semaphores dynamic prioritization dynamic creation & termination Real Time Analysis low overhead log & statistics Void main() { TSK_create((ProcessBuffer)task,1); } /* ======== task ======== */ Void task(Int id) { SEM_pend(ping_rx_flag = 1); } LOG_printf(&trace, ”Buffer 1 Avail"); RTOS style Concurrency Dynamic Scheduling Dynamic Resource Sharing Low Overhead JWL - TISB - 2/08/00

DSP/BIOS II Task Scheduling
Ready (post) INT 1 Run Preempted SWI 1 Blocked blocked Terminated TSK 2 TSK 1 preempted idle DSP/BIOS II adds “Multi-Tasking” scheduling to the “Interrupt Service” scheduling model. DSP/BIOS Tasks are dynamic, preemptable, and can be suspended (blocked) to wait for data or other tasks. DSP/BIOS Tasks are an excellent scheduling mechanism for dynamic, shared resource, ‘Hard & Soft Real Time’ systems.

IDL - Idle Function Manager
Program Insert functions to execute within idle Lowest priority SWI thread Set up with Config Tool Continuous loop - round robin Real-time analysis plug-ins updated DSP BIOS API H/W Interrupts SWI Background Host data pump Idle CPU load Your function The IDL module manages the lowest-level task in the application. This task executes functions that communicate with the host. There are three kinds of threads that can be executed by DSP/BIOS programs: hardware interrupts (HWI module), foreground software interrupts (SWI module), and background threads (IDL module). Background threads have the lowest priority, and execute only if no hardware interrupts or software interrupts need to run. An application’s main function must return before any software interrupts can run. After the return, DSP/BIOS runs the idle loop. Once an application is in this loop, hardware ISRs, SWI software interrupts, PRD periodic functions, and IDL background threads are all enabled. The functions for IDL objects registered with the Configuration Tool are run in sequence each time the idle loop runs. IDL functions are called from the IDL context. IDL functions can be written in C or assembly and must follow the C calling conventions described in the compiler manual. C main ()

Real-Time Analysis Determine whether the system is:
Operating within its design specifications Meeting its performance targets Showing any subtle timing problems Analyze real-time operation: Software logic analyzer CPU load Thread timing and count statistics We enable Real-time Analysis capabilities by connecting DSP BIOS to a Software Logic Analyzer (Execution Graph). And this proves to be highly useful for determining how tasks are interacting. However, there is a cost. Many DSP developers will say, "I can't use this because I can't afford to spare any cycles or bytes." Recognizing that concern, the DSP BIOS kernel has been rigorously designed to minimize the overhead impact on the DSP system. When we talk about low overhead, we mean overhead both in memory space and in MIPS. Key elements of DSP/BIOS Real Time Analysis Embedded fundamental instrumentation in system Lead to less interference in execution Deterministic and optimized Flexible user controlled and defined instrumentation Conditional instrumentation Control mechanism (on/off) to the instrumentation User defined and embedded instrumentation Pass data to the host automatically as a background (idle) thread (non-intrusive) Use a real-time interface between the host and target RTDX via JTAG

How do I ‘BIOS-ize’ my Code?
Start a new project Set up objects with Configuration Tool Migrate interrupt vector table to the HWI module Migrate memory sections from linker.cmd file to MEM module Save and Add the .cdb file to your project Edit C source for #include headers and declare variables Change C functions within your program to DSP/BIOS APIs. Build the new project /* DSP/BIOS header files*/ #include <std.h> #include <log.h> /* Objects created by the Configuration Tool */ extern far LOG_Obj trace; /* * ======== main ======== */ Void main() { LOG_printf(&trace, "hello world!"); /* fall into DSP/BIOS idle loop */ return; } Also… try the CC Studio Tutorial examples …and study the DSP/BIOS by Degrees app note - SPRA591 … also Audio Example - DSP/BIOS app note - SPRA598

Starting New Projects C BIOS New Project (xxx.mak)
Add source files Add linker command file Add Run-Time library BIOS New Project (xxx.mak) Setup new configuration Add configuration file (xxx.cbd) Add source files Add linker command file Step A: Create a DSP/BIOS configuration file. The DSP/BIOS Configuration Tool is first used to configure objects to be used in the application. The unused DSP/BIOS modules do not impact code size; however, the RTDX data pump is automatically included because it transports scheduling and instrumentation data from target to host. Step B: Insert the required objects, such as LOG or CLK objects, into the configuration file. Step C: Migrate the interrupt vector table to the HWI module of the configuration file. Each handled interrupt needs to be migrated into the HWI section of the configuration tool. Step D: Migrate memory sections from Linker command file to configuration MEM module. Use the configuration tool to define common memory regions and migrate definitions from the application's original linker command file. Step E: Save the configuration file and update the project file. This generates the three files; myfilecfg.s62, myfilecfg.h62, and myfilecfg.cmd. The myfilecfg.s62 file contains the code necessary to configure DSP/BIOS objects as well as the RTDX data pump which transfers data between the target and the host. The myfilecfg.cmd file defines all the necessary memory segments and sections required by the rts6201.lib and DSP/BIOS libraries. Be aware that the configuration file has to reside in the same directory as the final executable file.

Set Up System Easily with Configuration tool
Easy to visually configure run-time objects Set global run-time parameters Statically configures objects Detect errors early by validating properties before execution Calculate estimated data and minimal stack size Minimize target memory footprint by eliminating run-time code Saves time by getting you started quickly Adds basic Run Time services Add interrupt vector definitions Add memory section definitions Optionally add thread scheduling Optionally add low overhead instrumentation objects Visually create run-time objects bound to the executable program Unlike systems that create objects at run-time with API calls that require extra target overhead (especially code space), all DSP/BIOS objects are statically configured and bound into an executable program image. In addition to minimizing the target memory footprint by eliminating run-time code and optimizing internal data structures, this static configuration strategy detects errors earlier by validating object properties before program execution. You can use a Configuration file in programs that use the DSP/BIOS API and in programs that do not. A Configuration file simplifies ISR vector and memory section addressing for all programs. Saving a Configuration file will generate several files that you must link with your application. DEMO Start->Program->Code Composer Studio->Configuration Tool Load Audio.cdb Step through the major blocks: Global Settings: Shows what kind of target DSP and possibly what kind of target board (such as an EVM) Clock Manager: This is where you set up your real-time clock. You can tie periodic functions to this clock, or ‘Tick’ rate. You don’t have to use it if you don’t need periodic functions HWI: Set up H/W interrupts such as reset vector IDL: Set up functions that are to be done only when the machine is in the idle stage. Examples of this are the real-time displays like the CPU Load graph Log: perform printf-type functions, that do not stop the processor, and only take a few cycles! MEM: Set up memory map PIP: Set up ‘pipes’ or buffers of memory, so that threads can pass information PRD: Configure any periodic functions that need to run off the tick rate SWI: Set up program threads and their priorities Note that the config tool will estimate data size as well as minimum stack size.

Summary - DSP/BIOS Modules
Where do these fit? RT Capture, H/W Abstraction, or Multiple Threads ATM - Atomic Functions CLK - Clock Manager DEV - Device Driver Interface GBL - Global Properties HST - Host Channel Manager HWI - HW Interrupt Manager IDL - Idle Manager LCK - Resource Lock Manager LOG - Log Event Manager MBX - Mailbox Manager MEM - Memory Manager PIP - Pipe Manager PRD - Periodic Function Manager QUE - Queue Function Manager RTDX - Real Time Data Exchange SEM - Semaphores SIO - Stream I/O STS - Statistics Accumulator SWI - SW Interrupt Manager SYS - System Services TRC - Trace State TSK - Multi-Tasking

Sales and Support http://www.ti.com/sc/docs/tools
Where will customers go for support on Code Composer Studio? TI Product Information Center Recommended literature & source info? Code Composer Studio demo, tutorial, & docs: Get your own copy! 30 Day free Software Trial Code Composer Studio 1.11 release CD Order through the TI Web or your local Distribution Representative

Code Composer Studio & DSP/BIOS

Similar presentations

Presentation on theme: "Code Composer Studio & DSP/BIOS"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Code Composer Studio & DSP/BIOS

Similar presentations

Presentation on theme: "Code Composer Studio & DSP/BIOS"— Presentation transcript:

Similar presentations

About project

Feedback