How to Get Started With DSP/BIOS II

Transcription

1 Application Report SPRA697 October 2000 Andy The David W. Dart How to Get Started With DSP/BIOS II Software Field Sales Software Development Systems ABSTRACT DSP/BIOS II is Texas Instruments real time embedded kernel for TMS320C5000 and TMS320C6000 Digital Signal Processors (DSP). Understanding how to build applications using DSP/BIOS II requires adopting a multi-threaded design paradigm that at first seems foreign for new users of DSPs and veteran DSP developers alike. However, once understood, designing DSP/BIOS II applications becomes straightforward and you will find developing applications easier to design, debug, maintain, and extend. A real-time kernel such as DSP/BIOS II helps to factor problem and facilitate a robust design that is easily maintainable. Traditionally, DSP applications were very simple, typically using a single program loop to manage required processing. Over time, DSP applications began to require concurrent processing, as applications demanded DSP to perform more functions. Applications now typically require DSP to do several things at once and at different rates. In addition, DSP applications typically change over time requiring support for additional or modified features. Building modern DSP applications using traditional program loop paradigms is very challenging, difficult to maintain, and even more difficult to extend. Using DSP/BIOS II real time kernel offers developers foundation to build modern applications from simple to complex multi-threaded and multi-rate applications. Building modern DSP applications requires adopting a design paradigm, which includes preemptive, event-driven multi-threaded. This requires understanding how to architect applications using one or more execution threads rar than processing loops. DSP/BIOS II provides three distinct classes of execution threads with different execution, preemption, and suspension characteristics to build applications on. In support of se threads are several additional kernel objects that provide device-independent I/O, interthread communication and synchronization, and or real time services. This paper addresses how to get started building DSP applications using DSP/BIOS II. The primary focus is to understand multi-threaded design approach using DSP/BIOS II components. This includes organizing and structuring an application around DSP/BIOS II execution threads. TMS320C5000 and TMS320C600 are trademarks of Texas Instruments. Contents 1 Introduction Why DSP/BIOS II? The Development Process Design With Multiple Threads in Mind...5 1

2 2.1.1 DSP/BIOS II Thread Types Identify Independent Execution Paths Motor Control Application Example Identify Real Time Deadlines and Critical Operations Motor Control Example Specify Thread Triggering and Synchronization Identify Thread Life-Times Identify Periodic or Multi-rate Operations Identify Data Paths and Buffer Requirements Throughout Design Identify Inter-thread Communication and Messaging Paths Identify DSP/BIOS II Objects You Will Use Use Configuration Tool to Pre-configure System and DSP/BIOS II Objects Call DSP/BIOS II APIs from Your Application CCStudio Audio Example Conclusion...21 Figures Figure 1. Embedded System Software Components... 3 Figure 2. Traditional Main-loop Processing (left) Restructured as a Multi-threaded Application (right)... 6 Figure 3. Simple Motor Control Application Separated into Independent Execution Paths... 8 Figure 4. DSP/BIOS Thread Latencies... 9 Figure 5. DSP/BIOS II Periodic Thread Executes all Periodic Functions Figure 6. Prioritizing Periodic Functions Figure 7. Generic Mapping of PIP to Block-Diagram Data Paths Figure 8. Generic Mapping of SIO to Block-Diagram Data Paths Figure 9. Using DSP/BIOS II Configuration Tool Figure 10. Audio Processing Requirement Functional Block Diagram Figure 11. Audio Example Block Diagram Figure 12. Mapping Block-Diagram to DSP/BIOS Threads Figure 13. Audio Processing Operation Using DSP/BIOS II Figure 14. Load Processing Operation Using DSP/BIOS II Introduction By now, you have reviewed DSP/BIOS II Technical Overview (SPRA646) and or DSP/BIOS II technical documentation, and you may be thinking about how you can use DSP/BIOS II in your application. For developers unfamiliar with real time multi-threaded kernels, architecting applications using DSP/BIOS II kernel services will enable you to build structured, yet flexible applications. Once you become familiar with DSP/BIOS II and its capabilities, you will find developing applications easier to design, debug, maintain, and extend. For experienced developers, DSP/BIOS II implements most of traditional kernel services found in embedded systems and you will find DSP/BIOS II kernel services efficient, scalable, and easy to implement. 2 How to Get Started With DSP/BIOS II

3 This document is to assist you in getting started using DSP/BIOS II in your application design. Part of this document will convey philosophy of DSP/BIOS II and balance will go into examples of using DSP/BIOS II to build applications. For complete and in-depth technical data on DSP/BIOS II APIs, please refer to following documents: SPRU403 DSP/BIOS Application Programming Interface (API) Reference Guide, and SPRU303 DSP/BIOS Users Guide. Application Software System Software Timers system clock DSP Memory system I/O peripherals Figure 1. Embedded System Software Components 1.1 Why DSP/BIOS II? DSP/BIOS II is a feature-rich, yet scalable collection of kernel services that developers use to manage system-level resources and to build infrastructure of DSP applications. These kernel services, tuned and optimized for size and performance, are available on TMS320 C5000 and C6000 DSPs. If you think of DSP as a processing resource, n scheduling of this resource requires management. Managing system-level resources, including DSP, is role of system software and of DSP/BIOS II. In addition, DSP/BIOS II makes it easier to transfer your application to anor TMS320 DSP by providing hardware abstraction. The software required in typical embedded DSP systems is comprised of two general components, application, and system software. See Figure 1. System software is responsible for managing system resources for applications. System resources include hardware devices on target platform and DSP. Above this layer is application itself. It is important to distinguish elements of a system design into se components. Your intellectual property is in application. The system software provides application with infrastructure. How to Get Started With DSP/BIOS II 3

4 All DSP applications require some system software to manage resources in ir system. Typical embedded DSP systems include DSP processor, memory, a system timer or clock, and I/O peripherals. System software is required to properly initialize and control se hardware components. In addition, system software typically manages access between system resources and application software. This is important when transferring applications to different hardware platforms, such as next generation device. The system software provides some isolation, or a layer between application and physical hardware. In simple systems, system software consists of basic hardware initialization, peripheral access functions, and hardware interrupt service routines (ISRs). Systems that are more complex require real-time scheduling of DSP to ensure correct operation. Furrmore, as applications require concurrent access to hardware resources such as DSP, memory, or I/O, need for an efficient resource manager and scheduler becomes paramount. Managing se resources is precisely benefit of using DSP/BIOS II. DSP/BIOS II provide system services to manage DSP system hardware components and to provide applications with services that manage DSP utilization. By using DSP/BIOS II, you Manage DSP MIPS efficiently using multithreading. Use standard interfaces for I/O and hardware interrupts. Define and configure system resources efficiently, such as system memory. Gain real time visibility into execution of your application using real-time analysis tools. Add structure to your application, organizing it around a collection of inter-related threads. Make it easier to migrate to new TMS320 DSPs since DSP/BIOS abstracts much of system hardware. 2 The Development Process Since DSP/BIOS II is a scalable set of componentized system services, you have complete control over which DSP/BIOS II components you use. When you develop applications or port pre-existing applications to DSP/BIOS II, you select only those components that your applications needs. Only those components you select are included in build of your application, this keeps memory usage by DSP/BIOS II to a minimum. Typical applications use DSP/BIOS II to configure system interrupt vector table, and system memory map. During development process, most developers take advantage of real time analysis features built into DSP/BIOS II to gain visibility into runtime behavior of ir application. In addition, most applications take advantage of DSP/BIOS II scheduler to prioritize and manage DSP processing. Every application can take advantage of features within DSP/BIOS II. Pre-existing applications can take advantage of DSP/BIOS II to make it easier to port to anor supported TMS320 DSP; and take advantage of real time analysis features to better understand runtime behavior and performance. 4 How to Get Started With DSP/BIOS II

5 Concluding with audio example that ships with Code Composer Studio, we will describe process of developing a DSP/BIOS II application that uses several DSP/BIOS II components. You will likely use one or more of se in your application. However, first we will describe overall design process. While this process assumes you are developing a new application, many of steps pertain to migrating your existing application to use DSP/BIOS II as well. To help illustrate process steps, we will use a simple motor-control application. 2.1 Design With Multiple Threads in Mind The overall process requires designing an application using a multi-threaded or concurrent system paradigm. While DSP/BIOS II accommodates traditional loop architectures, multithreaded designs are far more flexible and maintainable. Even if your application consists of ISRs and a background operation, designing with DSP/BIOS II threads will make it easier to accommodate new features or or changes over time including migrating to anor TMS320 DSP. For many developers migrating to DSP/BIOS II, paradigm shift away from traditional processing loops or super loops to using multiple execution threads is new and perhaps challenging. However, organizing an application around a collection on inter-related threads provides structure to application that makes it easier to maintain and extend over time. This structure allows developers to assign relative priorities to threads to ensure application executes correctly. Figure 2 illustrates a main processing loop restructured around threads. Historically, DSP applications performed all processing in an ISR. Over time, a background loop became necessary to perform some of processing to minimize amount of time spent in ISR. Deferring some of processing to background reduced interrupt latency and increased interrupt bandwidth. As DSP application complexity increased, developers began to massage background loops to perform rudimentary scheduling to implement state machines, or to ensure higher priority operations met ir real time deadlines. How to Get Started With DSP/BIOS II 5

6 Main() Main() /* /* sequential sequential processing processing example example beventflag_0 beventflag_0 FALSE; FALSE; beventflag_1 beventflag_1 FALSE; FALSE; StartSystem(); StartSystem(); /* /* enable enable interrupts interrupts while(1) while(1) /* /* sequential sequential processing processing loop loop if if beventflag_0 beventflag_0 beventflag_0 beventflag_0 FALSE; FALSE; ProcessEvent_0(); ProcessEvent_0(); if if beventflag_1 beventflag_1 beventflag_1 beventflag_1 FALSE; FALSE; ProcessEvent_1(); ProcessEvent_1(); Event_0_ISR Event_0_ISR beventflag_0 beventflag_0 TRUE; TRUE; Event_1_ISR Event_1_ISR beventflag_1 beventflag_1 TRUE; TRUE; Main() Main() /* /* Multi-threaded Multi-threaded example example Thread_Event_0() Thread_Event_0() /* /* Event Event 0 0 processing processing thread thread while(1) while(1) wait wait for for Event_0 Event_0 signal signal ProcessEvent_0 ProcessEvent_0 Thread_Event_1() Thread_Event_1() /* /* Event Event 1 1 processing processing thread thread while(1) while(1) wait wait for for Event_1 Event_1 signal signal ProcessEvent_1 ProcessEvent_1 Event_0_ISR Event_0_ISR signal signal Event_0 Event_0 Event_1_ISR Event_1_ISR signal signal Event_1 Event_1 Figure 2. Traditional Main-loop Processing (left) Restructured as a Multi-threaded Application (right) These designs however still consisted of ISRs and a background-processing loop. As you can imagine, se designs are tricky with respect to timing, and are not very accommodating to changing requirements like adding new features. In most cases, se designs readily decompose into multiple independent paths of execution. With DSP/BIOS II, you assign a thread for each of se independent execution paths. Since threads must execute on same processor, y are inter-related. Therefore, you will assign relative priorities to se threads to ensure system performs correctly. DSP Bios II uses a fixed priority preemptive scheduler that allows you to apply well defined real time scheduling techniques such as rate monotonic scheduling (RMS) to ensure your application runs correctly. Guideline In your design, you should minimize ISR processing to be as little as possible, and defer balance of processing to a DSP/BIOS II thread such as a software interrupt (SWI) or synchronous task (TSK). Doing this for all I/O allows you to prioritize each operation based on its importance or real time deadline DSP/BIOS II Thread Types DSP/BIOS II supports four basic thread models. Hardware interrupt (HWI) and software interrupt (SWI) threads support fast interrupt processing. With DSP/BIOS II, you need to rethink interrupt processing from single-level (hardware interrupts only) to a two-level model. The twolevel model means you perform minimal processing in hardware interrupt, and defer balance of processing to software interrupt. Both HWI and SWI threads share system stack, this makes ir context switching times shortest possible making m ideal in time-critical operations. 6 How to Get Started With DSP/BIOS II

7 DSP/BIOS II provides a special software interrupt thread (PRD) to perform periodic functions. This thread executes as a function of a clock source. The clock source is eir system clock, or a data clock. This thread is ideal for implementing periodic operations. The synchronous task thread (TSK) processing model is typical application execution thread. Tasks have unique property of suspension making m very flexible in operation. This flexibility makes tasks easy to use for a variety of applications. However, since tasks each have private stacks, ir context switching times are longer than that of software interrupts. This suggests that most time critical operations execute as software interrupts and less time critical operations use task threads. The forth model is background idle loop. This thread runs forever and loops continuously in absence of any or thread ready to run Identify Independent Execution Paths Therefore, first you need to architect your application using DSP/BIOS II threads. To do this you need to isolate independent paths of execution. Data flow diagrams, system level block diagrams, and state machines provide good insight into both independent and dependent paths. These paths will end up as DSP/BIOS II threads. Typical applications use multiple threads and thread types. Guideline When you map threads to execution paths, choose thread type that matches your runtime requirements. Which thread type to use is dependent on many factors, such as priority, latency, overhead, triggering, and dependencies on or threads Motor Control Application Example Figure 3 illustrates a simple motor-control application. A single DSP is required to perform multiple functions: control motor, respond to keypad, drive a display device, and send data out remote port. The user uses keypad to control system. For purposes of this example, motor control algorithm is a simple speed control. A timer interrupt fires every millisecond (1 khz rate), and triggers motor control algorithm to read current speed (TACH value), and adjust motor drive to attain desired motor speed. The user uses keypad to control system. Controlling system includes controlling motor, selecting what to display, and controlling what to send to remote port. When enabled by keypad selection, remote port transmits diagnostic data. Figure 3 also illustrates this application as independent execution paths. Each of major functions executes independently. Although keypad control algorithm modifies system parameters to control or functions, motor control operation for instance is not dependent on execution of any of or system functions. How to Get Started With DSP/BIOS II 7

8 Motor DRIVE MOTOR CONTROL MOTOR TACH ADC Control algorithm DAC MOTOR DRIVE > Speed 3000 RPM > start speed remote stop display ENTER Motor TACH RS-232 Data Out KEYPAD CONTROL KEYPAD interface System Control algorithm Modifies System Parameters Motor Controller Requirements Control motor speed -- 1 khz khz sampling rate rate (dv/dt) Accept keypad commands to to control motor, change display, or or send send data data out out remote RS-232 port port Drive a simple display -- refresh data data 2 times per per second Send data data out out RS-232 port port when nothing else else to to do. do. DISPLAY CONTROL REMOTE OUTPUT Display algorithm Remote algorithm MCBSP DISPLAY interface RS-232 PORT Figure 3. Simple Motor Control Application Separated into Independent Execution Paths Identify Real Time Deadlines and Critical Operations Real time systems have real time deadlines for operations to complete. The critical operations in your application will likely have real time deadlines and must execute at higher priority than your non-critical operations. You need to determine all real time deadlines in your system, and assign relative priorities to each. This information is necessary to map your operations to appropriate DSP/BIOS II execution threads. Your most critical threads will likely execute using high-priority SWI or TSK threads. In addition to priority, thread latency may impact meeting your real time deadlines too. Latency used in this context relates to context switching times in activating a thread and measures time it takes to activate thread once triggered. See Figure 4, which illustrates relative thread latencies. In DSP/BIOS II, hardware interrupt has shortest latency or restated fastest context switching time. Following closely are software interrupts. This is a result from both hardware and software interrupt using same stack as application. However, each DSP/BIOS II synchronous task has a private stack. Consequently, context switching time for tasks is longer than that for software interrupts. Guideline As a rule, for your most time critical threads, use eir a hardware interrupt or a software interrupt thread. For less critical requirements, task thread may be more convenient. 8 How to Get Started With DSP/BIOS II

9 DSP/BIOS II Thread Interrupt Latency DSP Instruction Cycles C6000 C HWI / CLK SWI PRD TSK DSP/BIOS II Thread Types Figure 4. DSP/BIOS Thread Latencies For more details and analysis on DSP/BIOS thread latencies and or DSP/BIOS II objects, please refer to SPRA662 Benchmarking DSP/BIOS II on C6000, and SPRA 663 Benchmarking DSP/BIOS II on TMS320C54x Motor Control Example Controlling motor is most critical function in our example so it becomes highest priority operation in system. Responding to keypad is also important since this is control input. However, response time is not as critical as smooth motor operation so it has a lower priority than motor control operation. The display provides information, and is not critical to operation, so it is a lower priority than keypad. Finally, sending data out remote port is a background operation in our example, so it has lowest priority Specify Thread Triggering and Synchronization Each independent path of execution requires an activation mechanism. Hardware devices trigger an interrupt service routine managed by HWI. Software triggers DSP/BIOS II SWI and TSK threads. The idle loop runs continuously in background. In addition to triggering, your application may need to synchronize multiple trigger sources. How to Get Started With DSP/BIOS II 9

10 Each DSP/BIOS II execution thread type uses unique activation and synchronization methods. The DSP/BIOS II software interrupts (SWI) execute in a similar fashion to ir hardware counterparts. Once triggered, y run to completion and terminate. These threads are retriggerable. Software interrupt threads execute at a very high priority, just below hardware interrupts, and above synchronized tasks. To synchronize multiple trigger sources, software interrupts use a special control interface called SWI mailbox. The software interrupt will begin executing based on contents of this mailbox. You would use this interface to perform conditional triggering on software interrupt. Software interrupt threads are reactive. That is, activation is under external control. The thread cannot affect its own execution; once started, it cannot wait for or events or stop before completing (suspend). As a rule, all input needed by a software interrupt s function must be ready (available) before an event triggers software interrupt. Synchronized task (TSK) threads operate quite differently from interrupts. Tasks are not directly re-triggerable. You can use a while loop within task function to act in a re-triggerable fashion. Task threads have unique property of suspension, which allows m to affect ir own execution. Tasks should suspend when y wait for resources, such as data from a peripheral or access to shared memory, rar than poll. Suspension also allows tasks to stop mselves by sleeping for some amount of time, or explicitly yielding processor. Tasks pend on semaphores (suspend execution until ready) to synchronize execution. This gives you flexibility in use of task threads. Using semaphores allows you synchronize task execution to or events or or threads, or arbitrate access to system resources. Typically, your normal execution paths, control functions, and non-critical I/O use tasks. The idle loop executes in a similar fashion to traditional main loops. Each function in loop executes in order, and runs to completion. You add your functions to list using Configuration Tool. The idle loop runs continuously in absence of any higher priority thread ready to run. The traditional ISR and background processing loop architectures can take advantage of DSP/BIOS II by moving traditional loop functions first into this idle loop. Then to improve performance or add functionality, you can move functionality to or threads. All DSP/BIOS II threads are fully preemptable by higher priority threads. In your design, you will need to identify triggering or activation method for each execution thread, and determine if you want to execute portions of you application in idle loop Identify Thread Life-Times DSP/BIOS II allows you to create threads that will exist for duration of application. These are static threads. You also have choice to instantiate SWI and TSK threads dynamically, such that y exist as long as application needs m, n to free resources, you may delete m. These are dynamic threads. You create static threads using Configuration Tool, and you create/delete dynamic threads using DSP/BIOS II APIs in you application. The primary advantage of static threads is reduced memory requirements. Dynamic DSP/BIOS II objects require more code to support dynamic creation and deletion, and creation process may block waiting for memory allocation to complete. However, you should know that once created, execution time (and MIPS) is identical. 10 How to Get Started With DSP/BIOS II

11 Static threads also support real time analysis tools better than dynamic threads. The execution graph does not have direct visibility into dynamically created threads, and cannot display as detailed information as it does with static threads. Dynamic threads however allow you greater flexibility in application designs. You need to identify which threads in your application need to be static, and which threads you will instantiate dynamically. Guideline To minimize code space use static threads Identify Periodic or Multi-rate Operations Many DSP applications process data periodically. For example, audio data sampled and packed into 20 ms sized buffers requires processing each buffer every 20 ms. Multi-rate systems imply that multiple periodic operations will occur at different rates. DSP/BIOS II provides a periodic function manager, PRD, that you will configure to execute your periodic functions. See figure 5, which illustrates periodic thread operation. Recall from DSP/BIOS II Technical Overview, that periodic functions execute as a special SWI called PRD_swi. Clock Source Periodic Thread Periodic Clock Periodic Functions DSP/BIOS DSP/BIOS II II Timer Timer tick J_ticks DSP DSP Selectable Source Periodic Periodic Manager Manager K_ticks DSP DSP User-Defined User-Defined Clocking Clocking tick L_ticks DSP DSP Data Data Clocks Clocks Frame Frame Rates Rates Figure 5. DSP/BIOS II Periodic Thread Executes all Periodic Functions How to Get Started With DSP/BIOS II 11

12 Guideline You need to identify all periodic operations in your application. For all periodic operations in your application, determine period operation needs to run, and time required completing operation once initiated. All of your periodic functions need to occur at integer multiples of PRD tick. Therefore, you need to make sure you set PRD tick period appropriately. To prioritize periodic functions, you should have PRD functions post software interrupts or synchronized tasks to perform operation, which you prioritize as required. See figure 6. Prioritizing Periodic Thread Functions Clock Source Periodic Clock Periodic Functions DSP/BIOS DSP/BIOS II II Timer Timer tick J_ticks Trigger Trigger SWI SWI Selectable Source Periodic Periodic Manager Manager K_ticks SEM_post() SEM_post() User-Defined User-Defined Clocking Clocking tick L_ticks Trigger Trigger SWI SWI Data Data Clocks Clocks Frame Frame Rates Rates Figure 6. Prioritizing Periodic Functions For example, an audio algorithm may require processing 20 ms size buffers and take 5 ms to execute. This algorithm operates on continuously streaming data. If a buffer is dropped (not ready for output), n output will contain distortion sounding like pops. The application must ensure algorithm completely executes (all 5 ms), within 20 ms window (buffer period), orwise we will drop a buffer. The period is 20 ms, and real-time deadline is 20 ms since we do not want to drop a buffer. Some applications perform periodic operations on data from sources that supply ir own clocking. For example, frames of data transferred by DMA, perhaps originating from a serial port (MCBSP). The frame rates drive clocking. If your application needs to perform periodic operations on this type of data, you will want to drive PRD clock from interrupt service routine that handles this data. In this way, you can perform periodic operations at tick or frame -rate of incoming data. In previous example, DMA interrupt would call PRD_tick() to advance PRD clock after each frame transfer. 12 How to Get Started With DSP/BIOS II

13 The default setup uses DSP/BIOS II system clock to drive PRD clock, and is set-up through CLK manager in Configuration Tool. This allows periodic functions to execute at integer multiples of system clock. For more information on DSP Bios II threads and thread scheduling, see SPRA714 Threading Models in DSP Bios II. Peripheral Processing Peripheral Device Device DSP DSP Device Device Peripheral DSP/BIOS DSP/BIOS II II HWI HWI thread thread Peripheral DSP/BIOS DSP/BIOS II II HWI HWI thread thread PIP PIP PIP PIP Processing DSP/BIOS DSP/BIOS II II SWI SWI thread thread or or TSK TSK thread thread or or IDL IDL thread thread Figure 7. Generic Mapping of PIP to Block-Diagram Data Paths 2.2 Identify Data Paths and Buffer Requirements Throughout Design In many DSP applications, data flow from input to output is often a continuous flow of data blocks or buffers. This continuous flow of data, referred to as data streaming, is typical of Audio, Video, and speech applications. Or data flows may be non-continuous, such as messaging and communication paths. The DSP/BIOS II data pipes (PIP) and data streams (SIO) are well suited to manage streaming data. In your application, you will use se objects to pass buffers between I/O devices and your application, or between DSP/BIOS II threads within your application. In your design, you need to isolate data paths that involve more than one thread. To send streaming data between threads you use eir PIP or SIO. Streaming data applications require management of flow of data buffers throughout application. Typically, DMA devices move data from peripherals to system memory, or opposite path, system memory to peripheral. The DMA transfer complete interrupt signals application that data is available (for data input), or memory is available to output data. However, once in application, managing buffer movement is not as straightforward. Application designers devise ir own non-standard methods to accomplish this. DSP/BIOS II data pipes and data streams are kernel objects optimally designed to perform se common tasks. How to Get Started With DSP/BIOS II 13

14 The PIP module provides a minimal architecture that is code-efficient, fast, and flexible. You can think of PIP as a software-dma that performs transfer of data between two DSP/BIOS II threads; and provides both event-driven and polling interfaces. Much as a DMA device issues an interrupt when a block transfer is complete, PIP can execute a callback function to alert target thread that a block is available. Figure 7 illustrates a typical mapping of data paths in a block-diagram and implementation using data pipes (PIP). Alternatively, you can use SIO module. The SIO module provides a high-level mechanism to perform streaming I/O between a synchronous task thread and a device. SIO provides a simple common interface independent of underlying device. This level of abstraction allows application designers to easily communicate with any device. SIO provides APIs to create and delete I/O channels, control data stream such as, start, stop, idle and flush; and to transfer data in channel, get, put, issue and reclaim. SIO supports static creation as well as dynamic creation and deletion. Peripheral Processing Peripheral Device Device DSP DSP Device Device Peripheral Processing DSP/BIOS DSP/BIOS II II HWI HWI thread thread DEV SIO SIO Peripheral DSP/BIOS DSP/BIOS II II HWI HWI thread thread DEV SIO SIO DSP/BIOS DSP/BIOS II II TSK TSK thread thread Figure 8. Generic Mapping of SIO to Block-Diagram Data Paths Figure 8 illustrates a typical mapping of data paths in a block-diagram and implementation using data streams (SIO). Note that SIO links device drivers to synchronous tasks. I say device drivers rar than devices since device drivers provide isolation from SIO to a device or anor thread. In fact using DPI device driver supplied with DSP/BIOS II allows you to stream data between two or more synchronous tasks. Both PIP and SIO are flexible in that content of buffers is user-defined. The buffers can contain data directly, addresses to data buffers, or anything else. It is important to note that both PIP and SIO pass pointers to buffers between threads; y do not copy contents. This makes size and contents of buffers independent of transfer. This allows transfer time to be constant, a must for real-time systems. 14 How to Get Started With DSP/BIOS II

15 To understand how to architect multi-channel applications using PIP and SIO, please refer to SPRA689 Using PIP and SIO in Multichannel Systems. To understand how to write device drivers that will interface with PIP and SIO, please refer to SPRA700 Writing Flexible Device Drivers for DSP Bios II Identify Inter-thread Communication and Messaging Paths It is common for threads to communicate with one anor. This is typical of control systems that send messages to tasks to command ir operations. DSP/BIOS II provides mailboxes to send messages (or anything else defined in message being sent) between threads. Mailboxes differ from PIP and SIO in that messages posted to mailbox are copied into mailbox. You would use se objects to communicate messages typically between threads. For example, you create a supervisor task that receives and transmits messages to or processing tasks in system. As with PIP and SIO, contents of messages are not restricted. You can pass anything in message such as commands, raw data, and pointers to memory buffers. Queues in DSP/BIOS II provide simplest mechanism to communicate between any two threads without copying. DSP/BIOS II queues are double-linked lists that threads insert and remove elements from. You can think of queues as software-fifos. Queues are not limited to communication between threads, however this is ir most common use. In fact, SIO uses two internal queues to pass buffers between task and device driver on same task thread. 2.3 Identify DSP/BIOS II Objects You Will Use Once you have a multi-threaded design, you need to identify DSP/BIOS II objects you will use in application. From design, you will map appropriate thread type to each execution path. If re are dependencies, you need to determine interaction and synchronization required. You also need to identify data paths and characteristics of each. This includes buffer sizes and formats. For I/O device communication, select eir data pipes (PIP) or data streams (SIO). For inter-thread communication, you can use data pipes or steams, data Queues (QUE), or Mailboxes (MBX). 2.4 Use Configuration Tool to Pre-configure System and DSP/BIOS II Objects DSP/BIOS II needs to be aware of several global system parameters. These include DSP device, CPU clock speed, endian mode, cache settings, and some ors. Use DSP/BIOS II Configuration Tool in CCStudio to pre-configure your target system settings. You use Configuration Tool to select and configure DSP/BIOS II runtime support objects needed for your application. Using se objects, you develop and validate logic of your application by building an application framework that represents execution threads, I/O, and ir interactions. How to Get Started With DSP/BIOS II 15

16 For DSP/BIOS II threads, you specify thread priority and function thread will call when activated. For software interrupts (SWI), you will also specify two function arguments that will pass with function when thread is activated; and you will specify initial SWI mailbox value. For synchronized tasks (TSK), you will specify function arguments that will pass with function when thread activates; and you will specify both task stack size and memory segment task stack will occupy. For idle functions, which execute in background idle loop, you will specify function to call. You use Configuration Tool to create system memory map. In non-dsp/bios II designs, you would specify this map in linker command file under MEMORY directive. You also use Configuration tool to specify sections DSP/BIOS II will occupy and use; and to specify system stack size and section. You may optionally specify C compiler sections here too. You use Configuration Tool to create interrupt vector table. In non-dsp/bios II designs, you would specify this table in a separate file, usually in Assembly. You use Configuration tool to program on-chip timer to operate as DSP/BIOS II system clock. This system clock is required for real time analysis features, and sources or DSP/BIOS II time functions. The visual interface allows you to specify timer interrupt rate in units of microseconds per interrupt, and Configuration Tool generates required register settings. Figure 9 summarizes what you will do using Configuration Tool to configure DSP settings and to pre-configure static DSP/BIOS II objects you will use in your application. Using Using configuration configuration tool... tool... DSP/BIOS DSP/BIOS II II Modules Modules Set Set and and verify verify DSP DSP global global settings settings Global Global Settings Settings Setup Setup system system memory memory map map MEM MEM Setup Setup on-chip on-chip timer timer for for system system clock clock CLK CLK Setup Setup hardware hardware interrupt interrupt vector vector table table HWI HWI Pre-configure Pre-configure DSP/BIOS DSP/BIOS II II objects objects application application uses uses statically statically Save Save configuration configuration file file HST, HST, IDL, IDL, LCK, LCK, LOG, LOG, MBX, MBX, PIP, PIP, PRD, PRD, QUE, QUE, RTDX, RTDX, SEM, SEM, SIO, SIO, STS, STS, SWI, SWI, SYS, SYS, TSK, TSK, and and devices devices Figure 9. Using DSP/BIOS II Configuration Tool 16 How to Get Started With DSP/BIOS II

17 2.5 Call DSP/BIOS II APIs from Your Application Once static configuration is complete, you will make DSP/BIOS API calls from within your program to access and manipulate DSP/BIOS II objects. DSP/BIOS II allows you to use application s main() function to perform application initialization. You can think of main() function as a create phase in which you allocate memory buffers and do or initializations that need to be set and available before your application actually starts. After main() is called, DSP/BIOS II globally enables interrupts and starts running. 3 CCStudio Audio Example The example we will describe is Audio example that ships with Code Composer Studio. This is a simple application that illustrates use of HWI, SWI and PRD threads. It also illustrates use of data pipes (PIP objects) to manage flow of data throughout application. The first step in this example is to create block diagram of intended application, see figure 10. Audio CODEC Audio Processing Audio CODEC Copy Algorithm Get Get Input Input Data Data Copy Copy input inputî output output Put Put Output Output Data Data Figure 10. Audio Processing Requirement Functional Block Diagram The application needs to acquire audio data from CODEC, perform some processing, and issue data out CODEC again. For simplicity, our example just copies audio input to output. Figure 11 illustrates this in section labeled Processing Threads. How to Get Started With DSP/BIOS II 17

18 I/O Thread Processing Threads Audio Thread I/O Thread MCBSP MCBSP // CODEC CODEC COPY 96 words COPY MCBSP 96 words MCBSP // CODEC CODEC Clock Source Periodic Thread Periodic Clock Periodic Functions DSP/BIOS DSP/BIOS II II Timer Timer 1 ms Periodic Periodic Manager Manager 8 ms Load Load ms Step Step Figure 11. Audio Example Block Diagram In addition to audio processing, we want to periodically load CPU to view impact on our audio processing. We would also like to incrementally increase and decrease this loading to stress application. Figure 11 illustrates this in section labeled Periodic Thread. Now that we have block diagram that isolates execution paths, we can assign DSP/BIOS II threads. Since audio-processing path is very simple, we only need to use one thread to do processing. We choose to simplify design by keeping sample rates at input and output to be identical, this allows us to use same ISR to handle input and output. We will use HWI to manage interrupt. We could use eir a SWI or a TSK thread to do audio processing, however, we choose to use SWI in this case just to illustrate use of SWI mailbox to synchronize multiple trigger sources. With an TSK thread using SIO module, this synchronization is not required. We want SWI to do audio processing only when re is a full buffer of input data, and we have an available empty buffer to store processed data. To manage flow of se buffers, we will use data pipes to illustrate callback operation that will trigger SWI audio processing. Figure 12 illustrates mapping of se DSP/BIOS II objects onto our audio processing threads. Thus, in our simple example, we have one HWI thread handling CODEC interrupts, and we use one SWI thread to handle audio processing. The interrupt processing is one execution path, and audio processing is a separate execution path. Connecting se execution paths, or threads, are data pipes, which manage buffer flow. 18 How to Get Started With DSP/BIOS II

19 Audio Example Processing Threads SWI Audio Processing Software Interrupt Audio CODEC MCBSP 1 HWI ISR (common) Input Pipe PIP Get Get Data Data X i i Audio processing function y i i x i i Put Put Data Data Y i i Output Pipe PIP Figure 12. Mapping Block-Diagram to DSP/BIOS Threads Independent of audio processing, our example has periodic functions to add CPU loading. We are using system clock to drive PRD clock with one-millisecond ticks. In this example, PRD functions execute directly in PRD_swi thread. The load function occurs every 8 milliseconds, and step function executes every 10,000 milliseconds, or 10 seconds. The step function modifies load function by increasing and decreasing load period (see Figure 11). For our example, we reference hardware implementations built on C6201 EVM, C6211 DSK, and C5402 DSK. See Figure 13. The multi-channel buffered serial port, MCBSP 1, connects to audio CODEC. This example uses an ISR (DSS_isr()) to interact with MCBSP to read and write audio data. This example uses DSP/BIOS II HWI module to manage hardware interrupts. The CODEC ISR fills empty blocks with input data; and outputs full blocks until y are empty. How to Get Started With DSP/BIOS II 19

20 Audio Example Processing Threads Audio CODEC MCBSP 1 HWI ISR (common) DSS_isr() synchronization SWI_andn() SWI Audio Processing Software Interrupt (audioswi thread) audioswi mailbox Input Pipe PIP DSS_rxPipe Get Get Data Data X i i audio() function y i i x i i SWI thread calls audio function Put Put Data Data Y i i Output Pipe PIP DSS_txPipe INPUT data path OUTPUT data path Figure 13. Audio Processing Operation Using DSP/BIOS II To transfer data between ISR and application, we use DSP/BIOS II data pipes managed by PIP module. One data pipe transfers data from ISR to application (DSS_rxPipe), or transfers full data to ISR for output (DSS_txPipe). The audio() function attached to DSP/BIOS II software interrupt thread (audioswi) performs audio processing. The audio processing thread activates only when both a full block of data and an empty block of data are available. To synchronize se events, we use audioswi s mailbox. The initial value of SWI mailbox is set to 3, which sets first 2 bits in SWI mailbox to 1 s. When both of se bits become 0 (value of mailbox is 0), SWI thread activates to perform processing. We will use data pipe notify functions to clear se bits individually. Both data pipes signal software interrupt using SWI_andn() calls to ir assigned bits in SWI mailbox to synchronize processing. The input data pipe will signal audioswi when ISR has filled a block and it is available for processing by calling SWI_andn(2) to clear bit 1 in SWI mailbox. Likewise, output data pipe will signal audioswi when an empty block of data is available for application to fill by calling SWI_andn(1) to clear bit 0 in SWI mailbox. Figure 14 illustrates periodic thread configuration. Note we use system clock to drive periodic clock, and tick period is one millisecond. The PRD manager will call load() every 8 milliseconds, and step() function every 10 seconds. All of DSP/BIOS II objects used in this example are static. The audio.cdb file contains ir configuration information. Within application, you can observe API s calls used to access buffers in data pipes; both in ISR and in audio(). 20 How to Get Started With DSP/BIOS II

21 Audio Example Periodic Thread Clock Source Periodic Clock Periodic Functions CLK CLK DSP/BIOS DSP/BIOS II II Timer Timer HWI HWI 1 ms Periodic Periodic Manager Manager PRD_swi PRD_swi 8 ms load() load() ms step() step() 4 Conclusion Figure 14. Load Processing Operation Using DSP/BIOS II Understanding how to build applications using DSP/BIOS II requires adopting a multi-threaded design paradigm. However, once understood, designing DSP/BIOS II applications becomes straightforward and you will find developing applications easier to design, debug, maintain, and extend. As we can see from motor control and audio examples, decomposing an application into independent execution paths is not as difficult as it first appears. Often, reviewing systemlevel block diagrams yields insight into separation. After you have divided application into independent threads, you need to assign appropriate DSP/BIOS II thread type. DSP/BIOS II provides four basic thread types that allow you to optimally apply based on execution requirements. You n choose appropriate data flow objects to pass data throughout your application. DSP/BIOS II offers device independent I/O objects to handle continuous block data transfers. For inter-thread communication and or transfers DSP/BIOS provides mailboxes and data queues. To build your application, DSP/BIOS II provides a system configuration tool to specify and configure system components such as system memory map and hardware interrupt vector table. You also use this tool to statically declare DSP/BIOS objects (threads and I/O) that you will use in your application. This provides foundation and infrastructure that your application will use. At this point, you build your application using se components and services. How to Get Started With DSP/BIOS II 21

22 IMPORTANT NOTICE Texas Instruments and its subsidiaries (TI) reserve right to make changes to ir products or to discontinue any product or service without notice, and advise customers to obtain latest version of relevant information to verify, before placing orders, that information being relied on is current and complete. All products are sold subject to terms and conditions of sale supplied at time of order acknowledgment, including those pertaining to warranty, patent infringement, and limitation of liability. TI warrants performance of its semiconductor products to specifications applicable at time of sale in accordance with TI s standard warranty. Testing and or quality control techniques are utilized to extent TI deems necessary to support this warranty. Specific testing of all parameters of each device is not necessarily performed, except those mandated by government requirements. Customers are responsible for ir applications using TI components. In order to minimize risks associated with customer s applications, adequate design and operating safeguards must be provided by customer to minimize inherent or procedural hazards. TI assumes no liability for applications assistance or customer product design. TI does not warrant or represent that any license, eir express or implied, is granted under any patent right, copyright, mask work right, or or intellectual property right of TI covering or relating to any combination, machine, or process in which such semiconductor products or services might be or are used. TI s publication of information regarding any third party s products or services does not constitute TI s approval, warranty or endorsement reof. Copyright 2000, Texas Instruments Incorporated