1

Table of Contents
I. Context and Definition of Intended User/Customer...................................................................................1
Product Purpose......................................................................................................................................1
Potential Customers................................................................................................................................1
Customer/Market Requirements.............................................................................................................1
Unique Needs/Circumstances/User Environment...................................................................................2
II. Background Technology Review..............................................................................................................2
Alternative DSP Development Board Consideration..............................................................................4
TABLE..............................................................................................................................................I

DSP DEVELOPMENT BOARD COMPARISON MATRIX...........................................................5

III. Project Design Engineering
Requirements.............................................................................................. 7
TABLE II
FUNCTIONAL AND FEATURE REQUIREMENTS.....................................................................
7
TABLE III
PERFORMANCE SPECIFICATIONS.............................................................................................8
IV. System Design - Functional Decomposition (Level
1)............................................................................ 9
Fig. 1. Level 1 functional block diagram..........................................................................................
9
Module
Descriptions................................................................................................................................9
V. Subsystem
Descriptions........................................................................................................................... 11
Device
Initialization...............................................................................................................................11
Fig. 2. Board Initialization subsystem block diagram (Level 2).....................................................11
Memory
Management............................................................................................................................13
Fig. 3. Memory Management subsystem block diagram (Level 2)................................................
13
Input/Output Control.............................................................................................................................
14
VI. Physical Implementation and Integration..............................................................................................
15

2
VII. Integrated System Tests........................................................................................................................
15
VIII. Revised Schedule of Major Tasks and Milestones..............................................................................16
IX. Budget............................................................................................................................................. 21
Labour Cost Estimate..............................................................................................................................
21
Parts Cost Estimate................................................................................................................................21
TABLE III
PARTS COST
ESTIMATES..................................................................................................................21
Conclusion………………………………………………………………………………...…….………21
Appendices...................................................................................................................................................22
A. Design Analysis ………………………………………………………………………………… 22
B. Program Listing................................................................................................................................
25
C. Source
Code......................................................................................................................................25
D. Other Sources...................................................................................................................................
25

3
I. Context and Definition of Intended
User/Customer
DSP find applications in various fields,
including digital image processing,
telecommunications, and sonars.
Pursuing a career in digital signal
processing can be lucrative for students.
Cal Poly offers a digital signal
processing class for those interested in
specializing in this field. However, the
Digital Processing Laboratory at Cal
Poly currently uses an outdated and
slower DSP programmable board,
which may not adequately prepare
students for industry requirements.

Currently, Cal Poly's EE 459 lab relies

on MATLAB simulations for digital
filter implementation, lacking real-time
applications. The project aims to
provide a real-time digital filter
platform that allows students to apply
theoretical concepts learned in lectures
to practical scenarios. By bridging this
gap, students can gain hands-on
experience in digital signal processing.
 Fig. 2. Board Initialization subsystem block diagram (Level 2).
Design Requirements
The Device Initialization subsystem covers both the Code Composer Studio project
setup and the initialization code for other peripherals used for the digital filter
implementation project.

As part of the Code Composer Studio project setup, the Device Initialization
subsystem should include procedures for adding the libraries necessary to interface
with the C6748 power and clock control peripherals, as noted in the Level 2 block
of the Board Initialization subsystem above.

The initialization code should compile without error in Code Composer Studio and
debug on the DSP development board through the external emulator. The
initialization code should be able to run before other subsystems and should not
need to be called again by other subsystems.

6
Design Choices and Alternatives Considered
The Device Initialization subsystem includes the initial project setup within the
Code Composer Studio
IDE which involves installing software libraries. Since the initial release of the
TMS320C6748 DSP in 2009, multiple versions of the device's Software
Development Kit (SDK) have been released and documented. The SDK also
provides the option to use a Real-Time Operating System (RTOS) or implement
"bare metal" programming. This project aims to use bare metal programming
through libraries provided with the TI Processor SDK.

Based on the availability of documentation, the TI Processor SDK, last updated in

April 2020, was selected for this project. While older software development kits
for the C6748 are available for download and come bundled with offline
documentation, discussion on active user forums more often refer to the Processor
SDK. Additionally, the Processor SDK is confirmed to work with recent versions
of Code Composer Studio. The Processor SDK includes support for TI-RTOS and
also chip support libraries, drivers, and other board support utilities.

An alternative to the Processor SDK is the C6000 DSP StarterWare which provides
no-OS platform support for C6000 processors. The StarterWare files were last
updated around June 2013. StarterWare includes an example that interfaces with
the AIC3106 audio codec and provides audio loopback through the line-in and
line-out audio jacks onboard the TMS320C6748 DSP development kit. The
Processor SDK, on the other hand, does not have an audio loopback example
specific to the C6748 devices. The Processor SDK does include a Chip Support
Library (CSL) which mirrors that of the StarterWare drivers for backward
compatibility, though using the higher-level driver Application Programming
Interfaces (APIs) is generally recommended by the Processor SDK documentation.

Between using the TI-RTOS or bare metal implementation, which does not use an
operating system, bare metal programming appears better suited for the purpose of
this project. An RTOS enables the use of task schedulers and priority levels,
making this preferable for complex programs that contain multiple processes.

7
However, an RTOS generally uses more power and memory. Additionally, due to
the higher level of abstraction, issues with code may be harder to debug in an
RTOS application. Since the goal of implementing digital filters on the DSP
development board will consist primarily of arithmetic operations on a single
stream of samples after the initial setup, an RTOS does not seem necessary at this
time. Programming for a non-OS application will allow for more control over the
code, and the method of programming to register directly will be more familiar to
electrical engineering students having taken microcontroller-based system design
courses at Cal Poly.

Subsystem Verification Test Plan

The Device Initialization subsystem can be tested by running code that makes an
on-board LED blink. Successfully deploying code is a simple way to verify that the
correct libraries are added to the project and that IDE can communicate with the
DSP development board. Programming an LED to blink also ensures that project
members are familiar with working with the Processor SDK APIs.

Memory Management
The memory management subsystem works closely with the other subsystems to
enable access to instruction and data memory. Memory controllers also handle
interrupts. The Memory Management subsystem includes the following
peripherals:

- DDR2 Memory Controller

- EDMA3 Memory Controller
- DDR2 Memory Controller

8
 Fig. 3. Memory Management subsystem block diagram (Level 2).
Design Requirements
The Memory Management subsystem should ensure that memory is allocated
appropriately such the program does not run out of memory. The memory available
to the device is limited to 128 MB DDR2 SDRAM running at 150 MHz and 128
MB, 16-bit wide NAND FLASH.

The memory management peripheral should also implement circular buffering to

fulfil the overall project’s customer requirements.
Design Choices and Alternatives Considered
The Linker Command File (C6748.cmd) created with each Code Composer Studio
project can be edited to change the memory layout on the device. Using this
memory layout, the data and instruction memory on the TMS320C6748 DSP
development kit is assigned statically or automatically depending on what is
specified in the code. The default layout used in the example projects from the
C6000 DSP Starter Ware will be used unless it proves insufficient for future
applications.

9
Subsystem Verification Test Plan
If memory allocation issues are present, an error should display to the IDE console
during debugging. Additional debugging tools such as instruction stepping,
breakpoints, and memory allocation views can be used for troubleshooting.
Because memory management is heavily interconnected with other subsystems,
this subsystem must be tested as part of the whole system.

Input/Output Control
The Input/Output Control subsystem uses the Multichannel Audio Serial Port
(McASP) peripheral to interface with the AIC3106 stereo audio codec on the
TMS320C6748 DSP development kit.

Design Requirements
The Input/Output Control subsystem must intake and output signals through at
least one audio channel. Interfacing with the AIC3106 audio codec with minimal
distortion requires that the input signal falls within the nominal line-level voltage
value for consumer audio of -10 dBV, which is approximately 0.894 V peak-to-
peak around signal ground.

To complete the project goal of implementing digital filters on the DSP

development board, the audio samples taken in by the board must be stored in
memory such that the software can copy and apply arithmetic operations to the
samples for signal processing.

Design Choices and Alternatives

Using the on-board AIC3106 stereo audio codec is this project’s chosen method of
receiving and outputting a signal on the TMS320C6748 DSP development kit. It is
also possible to utilize another peripheral, for example, the Multichannel Buffered
Serial Port (McASP) or Serial Peripheral Interface (SPI), to communicate with an
external ADC/DAC or codec. However, since that would require additional
hardware, using the on-board audio codec is best suited for this project.

10
Verification Test Plan
An audio loopback program can be used to verify the functionality of the
Input/Output Control subsystem. An audio loopback involves passing a signal to
the board through the Line In phone jack and having the board output the same
signal to the Line Out phone jack.

A Line In signal can be provided to the DSP development board using a 3.5 mm
TRS cable connected to a computer’s speaker output. Headphones or speakers can
then be connected to the Line Out jack on the board to play the board’s output.
Hearing clear audio through the board should indicate that the board’s McASP
peripheral is successfully taking audio samples and outputting those samples from
memory.
Alternatively, phone plug adapter cables can be used to connect the Line In and
Line Out on the development board to test equipment to verify subsystem
performance.

VI. Physical Implementation and Integration

The hardware necessary for this project includes the following:
● DSP development board
● 5 V power supply
● External JTAG emulator and included cables
● 3.5 mm stereo phone adapters
● Computer (for compiling code)
● Test equipment (Vector network analyzer, or pulse/signal generator and
spectrum analyzer, and associated cables)

The DSP development board, external JTAG emulator, and 5 V power supply can
be purchased off-the-shelf and are contained in their own packaging. These
components are shared between team members and can be packaged together in
the project. The combined package would need cables to interface with a computer
for compiling code to the JTAG emulator. connectors to interface with test
equipment, and a connector or cable for the power supply.

11
The computer is supplied by the team member or student, while the test equipment
is supplied by the department.

VII. Integrated System Tests

Test methods for confirm the system performance specifications include:
1. Signal processing accuracy
a. Define the desired signal processing functionality and
requirements,such as noise reduction or type of filtering.
b. After implementing the algorithm in CCS, prepare a set of input
signals with known characteristic.
c. Process the input signal with the implemented processing algorithm,
capture a record the result using external test equipment like an
oscilloscope.
d. Compare the output result with expected result. Expected result can be
obtain through MATLAB simulation.
e. Validate it meet the accuracy requirement
2. Real Time Process with circular buffering
a. Implement the circular buffering algorithm
b. Prepare test input data such as audio samples that represent different
signals
c. Configure the buffer size.
d. Set up the testing environment, execute the test by providing the input
data to the buffer at varying rates.
e. Monitor and track the buffer behavior by tracking the read and write
position.
f. Measure the processing time and latency by configuring a GPIO port
to measure high at the processing task of the code and use the
oscilloscope to measure the time.
g. Identify the code where circular buffering process to measure the
buffering latency.
h. Compare measurement with expected timing and latency.

12
 Power Consumption Measurement:
3.
a. Use a power measurement tool or instrument, such as a power meter
or current probe, to measure the DSP board's power consumption.
b. Set up the DSP board in different operational modes or scenarios that
represent typical usage patterns.
c. Measure and record the power consumption during these scenarios,
noting any variations based on different tasks or input conditions.
d. Compare the measured power consumption against the specified
limits or efficiency targets to ensure compliance.
Demonstration result

Figure 4: Moving Average Filter, yellow waveform input, blue output

The moving average filter is applied to the a simple sinewave ofr 1kHz, the result
seems to work as intended. This is the result of a simple differential equation y[n]
= 0.3333x[n] + 0.3333x[n-1] + x[n-2] apply to the signal. Showing the the
algorithm to implement the differential equation to a signal works as intended.

Infinite Impulse Response

In order to test to see if the differential equation works, a more complicated
differential was added but this time to the output too, making it an IIR filter.

13
 Figure 5: Design using Pole-Zero Diagram

Which result in the equation: y[n]−1.8837y[n−1]+0.9025y[n−2]=x[n]

−1.9829x[n−1]+x[n−2].
Resulting in the coefficient b: 0.95061 -1.885 0.95061
a: 1 -1.8837 0.9025

Figure 6: Simulated result of the IIR filter at 1kHz

Figure 7: Actual result with input of 2kHz

14
The result for some reason seems to doesn’t work like it should, this signal lowest
attenuation is at 2kHz which is off from the 1kHz center frequency. It also doesn’t
fully attenuated like it is in the simulation, however the signal does return to
normal outsite the notch center frequency range.

IRR by Windowing

Figure 8: Designing an FIR by windowing using Hamming

coefficient

Figure 9: Pole Zero of the FIR

15
 Figure 10: Matlab simulation of the windowing at FC = 9.6 KHz
For the actually implementation the, the value was actually at half at 9.6kHz but
for some reason it doesn’t adjust with the frequency and stay the same moving
away from the center frequency.

Table IV: Summary of results from the implementation

Frequency Actual
Filters Simulated Vp Actual Vp
desired Frequency
Moving
1kHZ 1kHz 0.9 1.03
Average
IIR filter 1kHz 2kHz ~0 ~0.5
FIR by
9.6 kHz cutoff - 0.45 0.44
windowing

VIII. Revised Schedule of Major Tasks and Milestones

While the subsystem descriptions and functional requirements have been
completed, the design requirements are missing quantified performance
specifications that would require additional research. Integrated system tests and
project verification tests are missing specific procedures with quantifiable expected
results. Project hardware has been fully procured.

16
20
IX. Budget
Labor Cost Estimate
The estimated time to complete this project is based on Cal Poly’s quarter system
credit policy. EE 461 and EE 462 are 2-unit courses that call for 1 hour of faculty
instruction per unit and 2 hours of outside work per unit. The total of 6 hours per
week for 20 weeks yields 120 labor hours per team member to design, build, and
test digital filter implementation on a DSP development board.

Based on the average salary for a newly-graduated electrical engineer in California,

which amounts to about $42 per hour, the expected labor cost is $5,040 per person.
Since this project is designed for a two-person group, the total labor cost is
$10,080.

Parts Cost Estimate

Changes Noted
The original parts cost estimate did not account for the total cost of the components
which includes tax and shipping. Shipping can cost up to $12 depending on the
distributor, and sales tax for San Luis Obispo is 8.75%. This new total has been
added to Table III below.

X. Conclusion
The implementation aspect of this project was not met for the most part, all
the implementation of the filter did not meet the desire outcome. First suggestion
on how to improve these shortcoming is to considered using another board. The
TMS320C6748 is has been around since earl 2010, as of now is the only board
specializing in digital signal processing that TI is selling. It has discontinued all of
the upgrade and even the more expensive board. Leading to the belief that TI is
shifting its focus away from the DSP board market. The TMS320C6748 currently
sold out on TI website and known distributor like mouser and Digi key.
TI also basically stopped supporting the board, as help can’t be ask on their
own forum with this specific board. Most help and documentation that were
requested on the forum tend to lead to a broken link or were taken down. Which

19
can be frustrating for student not very adept at microcontrollers, but is doable with
someone with a strong foundation in it.
Another suggestion if this board were to be used is to incorporate TI dsp library
function, which is recommended for more complex algorithm like FFT. An attempt
was made to incorporate the DSP library, but after many attempt it wouldn’t work.
Many help online and on the forums with step on how to incorporate it seems to be
taken down.
Third suggestion is to understand the data flow and figure out how the built
in stereo codec work as the document wasn’t very clear. The AIC3601
documentation seems to show that it is broken into block and first half is the left
channel, last half of it is the right. However, most of the sample code on the forum,
it seems like channels were interleaved through. Both method were used but none
produced the desired outcome. Which is the most likely reason why the attempt
didn’t work like expected.
TABLE III
PARTS COST
ESTIMATES
Part Description Total Cost + Justification
Unit
Tax
Cost
& Shipping
DSP DSP board with $234 ~$266.48 The most important
Development C6748 part of the system,
Kit DSP Core, with the DSP board
both fixed and handled the power
floating point. distribution, input
Program filters control,
using C. 5 memory, DSP
V power supply algorithm, and the
included. DAC. Typical price
range for a low cost
development kit is
around

20
 $200-$300. This one
specifically cost
$234 from the
manufacturer’s
website.
USB JTAG $135 ~$156.79 Allows for
Emulator JTAG in-circuit simulation and
emulator with debugging. Price
debug function. range is
Includes 14-pin $135 for the
cable to board and recommended
USB cable to external emulator for
computer. TI embedded
processors

Appendices
- This project is supposed to be able apply what was learn in DSP classes and
implement it real time and to be able to observed the affect of the filter.
However, the overall capabilities of this project still need work as not all the
filters work like design.

• Primary Constraints
- Primary constrain is mostly due to lack of documentation and support from

- TI. There is standard reference manual every microcontroller has but when it
come to there starter ware and RTOS the documentation is hard to come by.
TI also stopped supporting this board so every references and documentation
seems to be removed. So most of the time was spent reading what is there in
hope that the require info is there but most of the time it isn’t there or just
playing around with it slowly and hope something work.

21
Economic
The economic impact result in human designing the filter and implementing it on
the board, while financially the cost and build of this can be costly due to limited
quantity.
When and where do costs and benefits accrue throughout the project’s lifecycle?

- The cost and benefits accrue at the end with the project completion, due to
being able to help teach a bunch of future generation of engineer to continue
to do this and help benefit society

- This project need a computer, DSP board, JTAG, Stereo pin, AD2 or
oscilloscope to analyze the waveform. The schools has to invest in order to
pay for all this, such as the school offering a oscilloscope for use. The
original cost was around $320 but the actuall cost is about 737$
-

The project doesn’t earn much as it supposed to help learn and teach students but if
more student take this class then the school will profit

- This product will probably exist until TI stop manufactured it, which maybe
soon, when the project ends, hopeful it will help future engineer with
learning.

Environmental

22
 - The board used a lot of metals and silicon which may impacted through
mining and processing, which can also impact energy consumption.
- This project can directly use such as energy consumption through laptop and
power and indirectly affect mining operations that requires metal and energy.
The natural resources this project help improved is not a lot directly but
integral to monitor energy consumption and process environmental data.
Electronic waste can harm other species if not disposed of properly.

Sustainability

- Maintenance Challenges: DSP systems may require regular software

updates, component replacements, or recalibrations, especially if operating
in harsh environments.

- Resource Use Impact: The project could contribute to sustainable resource

use by optimizing energy consumption in its applications or improving
efficiencies in systems it's integrated with.

- Design Upgrades: Future upgrades could focus on enhancing energy

efficiency, reducing physical size, or utilizing more sustainable materials in
construction.

- Upgrade Challenges: Implementing upgrades might face technical

limitations, compatibility issues with existing systems, or increased costs.
Transitioning to more advanced or sustainable materials might also present
sourcing or technical challenges.

Ethical
- Since this is a learning tool, there is not many ethical issue with this project.

Health and Safety

-No real health concerns.

Social and Political

23
Social and Political Issues: Manufacturing and use of DSPs involve considerations
like labor practices in production facilities, environmental impact of electronic
waste, and data privacy concerns in applications involving user data.

Stakeholder Impact: Direct stakeholders include users, manufacturers, and

developers. Indirectly, communities affected by environmental impacts or
benefiting from improved technologies (like healthcare or communication systems)
are stakeholders.

Benefits and Harms: Stakeholders benefit from technological advancements and

improved efficiencies. However, negative impacts could include job displacement
due to automation and environmental harm from production and disposal.

Equity Considerations: Stakeholders' benefits and burdens may not be evenly

distributed. Those with better access to technology, resources, and skills might
benefit more, while those in less developed regions or with fewer resources might
face greater environmental and social impacts.

B. Program Listing
The list below contains links to the program and software kits used for this project.

- Code Computer Studio: https://www.ti.com/tool/CCSTUDIO

- TI Processor SDK for OMAPL138: https://www.ti.com/tool/PROCESSOR-
SDK-OMAPL138
- C6000 DSP Starter Ware: https://www.ti.com/tool/STARTERWARE-C6DSP

C. Source Code
The code below only contains original or modified code. Example code is provided
with the TI software kits provided in the Program Listing section above.

Blinking LEDs Test Code - main.c

#include <stdio.h>
#include <time.h>

24
 #include <ti/board/board.h>

#include <ti/drv/gpio/GPIO.h>
#include <ti/drv/gpio/soc/GPIO_soc.h>
#include <ti/drv/gpio/src/v0/GPIO_v0.h>
#include <ti/osal/osal.h>

#define GPIO_LED0_PIN_NUM (9U)

#define GPIO_LED0_PORT_NUM(0U) /* GPIO port 0 */

/* ON Board LED pins which are connected to

GPIO pins. */ typedef enum GPIO_LED {
USER_LED0 = 0 }GPIO_LED;
#define GPIO_PIN_VAL_LOW (0U)
#define GPIO_PIN_VAL_HIGH(1U)

/* GPIO Driver board specific pin configuration structure */

GPIO_PinConfig gpioPinConfigs[] =
{
/* Output pin */
GPIO_DEVICE_CONFIG(GPIO_LED0_PORT_NUM,
GPIO_LED0_PIN_NUM) | GPIO_CFG_OUTPUT
};

/* GPIO Driver call back functions */

GPIO_CallbackFxn gpioCallbackFunctions[] =
{
NULL
};

GPIO_v0_Config GPIO_v0_config =
{ gpioPinConfigs, gpioCallbackFunctions,
sizeof(gpioPinConfigs) /
sizeof(GPIO_PinConfig),
sizeof(gpioCallbackFunctions) /
sizeof(GPIO_CallbackFxn), 12

25
 };

/**
* main.c
*/ int
main(void)
{
Board_initCfg boardCfg;

boardCfg = BOARD_INIT_PINMUX_CONFIG |
BOARD_INIT_MODULE_CLOCK |
BOARD_INIT_UART_STDIO;

/* Supports initialization of PLL, peripheral clocks, external DDR

memory, pinmux and IO Delay configurations */
Board_init(boardCfg);

GPIO_init();

while(1)
{
GPIO_write(USER_LED0, GPIO_PIN_VAL_HIGH);
Osal_delay(500U);
GPIO_write(USER_LED0, GPIO_PIN_VAL_LOW);
Osal_delay(500U);
}
}

Linker Command File - C6748.cmd

This file is automatically generated with each new Code Composer Studio project
for the C6746 DSP with an additional line added to designate a memory section
for .csl_vect.
MEMORY
{
DSPL2ROM o= l= /* 1MB L2 Internal ROM */

26
 0x00700000 0x00100000
DSPL2RAM o = l= /* 256kB L2 Internal RAM */
0x00800000 0x00040000
DSPL1PRAM o = l= /* 32kB L1 Internal Program
0x00E00000 0x00008000 RAM */
DSPL1DRAM o = l= /* 32kB L1 Internal Data RAM
0x00F00000 0x00008000 */
SHDSPL2ROM o = l= /* 1MB L2 Shared Internal
0x11700000 0x00100000 ROM */
SHDSPL2RAM o = l= /* 256kB L2 Shared Internal
0x11800000 0x00040000 RAM */
SHDSPL1PRAMo = l= /* 32kB L1 Shared Internal
0x11E00000 0x00008000 Program RAM */
SHDSPL1DRAMo = l= /* 32kB L1 Shared Internal
0x11F00000 0x00008000 Data RAM */
EMIFACS0 o= l= /* 512MB SDRAM Data (CS0)
0x40000000 0x20000000 */
EMIFACS2 o= l= /* 32MB Async Data (CS2) */
0x60000000 0x02000000
EMIFACS3 o= l= /* 32MB Async Data (CS3) */
0x62000000 0x02000000
EMIFACS4 o= l= /* 32MB Async Data (CS4) */
0x64000000 0x02000000
EMIFACS5 o= l= /* 32MB Async Data (CS5) */
0x66000000 0x02000000
SHRAM o= l= /* 128kB Shared RAM */
0x80000000 0x00020000
DDR2 o= l= /* 512MB DDR2 Data */
} 0xC0000000 0x20000000

SECTIONS
{
.text > SHRAM
.stack > SHRAM
.bss > SHRAM

27
 .cio > SHRAM
.const > SHRAM
.data > SHRAM
.switch > SHRAM
.sysmem > SHRAM
.far > SHRAM
.args > SHRAM
.ppinfo > SHRAM
.ppdata > SHRAM
.csl_vect > SHRAM
/* COFF sections */
.pinit > SHRAM
.cinit > SHRAM

/* EABI sections */
.binit > SHRAM
.init_array >
SHRAM .neardata >
SHRAM .fardata >
SHRAM .rodata >
SHRAM
.c6xabi.exidx > SHRAM
.c6xabi.extab >
SHRAM }

FIR BY WINDOWING
#define FILTER_LENGTH 9// Replace M with your odd value
#define CUTOFF_FREQ 9600 // Replace fc with your cutoff
frequency #define SCALE_FACTOR 1 // Replace sf with your
scale factor

28
float filterCoeffs[FILTER_LENGTH]; void
processAudioDifferential(short *x, short *y, int
samples) {
// Assuming samples is the total number of interleaved stereo
samples int n;

// Previous samples for left and right channels

static float L_n1 = 0, L_n2 = 0;// R_n1, R_n2;

// Coefficients for the differential equation

float a0 = 0.3333, a1 = 0.3333, a2 = 0.3333;

// Process each stereo pair

for (n = 0; n < samples; n +
+) {
// Extract left and right samples
float L_n = x[n]; // Left channel
// float R_n = x[n + 1]; // Right channel

// y[n] = (short)(a0 * L_n + a1 * L_n1 + a2 * L_n2);

L_n1 = L_n;
L_n2 = L_n1;

// Process left channel y[n] = (short)(a0 *

L_n + a1 * L_n1 + a2 * L_n2);
// L_n1 = L_n;
// L_n2 = L_n1;

// Process right channel

// y[n+ 1] = (short)(a0 * R_n + a1 * R_n1 + a2 * R_n2);
// R_n1 = R_n;
// R_n2 = R_n1;
}
}

void
ComputeFIRCoefficients()

29
 { int m =
(FILTER_LENGTH - 1) /
2; int i;
//float fc = CUTOFF_FREQ /
SAMPLING_RATE; float
hammingWindow; for (i = 0; i <
FILTER_LENGTH; i++) { if (i ==
m) {
filterCoeffs[i] = SCALE_FACTOR * (2 * 0.2);
} else { float idealFilter = sin(2 * M_PI * CUTOFF_FREQ * (i - m) /
SAMPLING_RATE) /
(M_PI * (i - m)); hammingWindow = 0.54 - 0.46 * cos(2 * M_PI * i /
(FILTER_LENGTH - 1));
filterCoeffs[i] = SCALE_FACTOR * (idealFilter *
hammingWindow); }
} } void applyFIRFilter(short *x, short *y, int
numSamples) {
// For each sample in the
input int i,j; for (i = 0; i <
numSamples; i++) { float
filteredSample = 0.0;

// Apply the FIR filter for (j = 0;

j < FILTER_LENGTH; j++) { if
(i - j >= 0) {
filteredSample += x[i - j] *
filterCoeffs[j]; }
}

// Store the filtered sample in the output buffer

y[i] = (short)filteredSample;
} } void processAudioDifferential(short *inBuf, short *outBuf, int
numFrames, int numChannels)
{ int frame, chan; int idx; static float y_n_1[2] = {0, 0}, y_n_2[2] = {0,
0}; // Static variables to maintain

30
state between calls
float y_n;

for(frame = 0; frame < numFrames; frame++)

{ for(chan = 0; chan < numChannels;
chan++)
{ idx = frame * numChannels +
chan;

// Apply the difference equation y_n = inBuf[idx] - 1.9829f *

inBuf[idx - numChannels] + inBuf[idx - 2 *
numChannels]
+ 1.8837f * y_n_1[chan] - 0.9025f * y_n_2[chan];

// Store output in the buffer

outBuf[idx] = (short)y_n;

// Update the previous output values for the next

iteration y_n_2[chan] = y_n_1[chan]; y_n_1[chan]
= y_n;
}
}
}

int main(void)
{
ComputeFIRCoefficients();
while(1) { if(lastFullRxBuf !=
lastSentTxBuf)
{
/*
** Start the transmission from the link paramset. The
param set ** 1 will be linked to param set at
PAR_TX_START. So do not ** update paRAM set1.
*/ parToSend = PAR_TX_START +
(parOffTxToSend % NUM_PAR);

31
 parOffTxToSend = (parOffTxToSend + 1) %
NUM_PAR; parToLink = PAR_TX_START +
parOffTxToSend;

lastSentTxBuf = (lastSentTxBuf + 1) % NUM_BUF; //updated by

cycling thru
available transmit buffers

short *inputBuffer = (short

*)rxBufPtr[lastFullRxBuf]; short *outputBuffer =
(short *)txBufPtr[lastSentTxBuf];

applyFIRFilter(inputBuffer, outputBuffer,
NUM_SAMPLES_PER_AUDIO_BUF);
//processAudioDifferential((short
*)rxBufPtr[lastFullRxBuf],
(short
*)txBufPtr[lastSentTxBuf],
NUM_SAMPLES_PER_AUDIO
_BUF*2);

/*
** Send the buffer by setting the DMA params
accordingly.
** Here the buffer to send and number of samples are
passed as ** parameters. This is important, if only
transmit section ** is to be used.
*/
BufferTxDMAActivate(lastSentTxBuf,
NUM_SAMPLES_PER_AUDIO_BUF,
(unsigned short)parToSend,
(unsigned short)parToLink);
//initiate the transfer data from the current transmit
buffer }
}
}

32
C. Other Sources
- TMS320C6748 DSP Technical Reference Manual (Rev. C)
- TMS320C6748 Fixed- and Floating-Point DSP Datasheet (Rev. G)
- L138/C6748 development kit (LCDK) (Rev. A)
- TLV320AIC3106 Audio Codec Datasheet (Rev. G)
- Processor SDK RTOS Software Developer’s Guide — Processor SDK
RTOS Documentation

33