Testing the six-channel sample code

We will start with a sample application, which simply sends the inputs into the outputs--relaying both the audio inputs from the A/D converters to the D/A converters, and any data that comes in on the serial port back to the PC. To familiarize yourself with this sample application, locate a copy of thru6.asm and assemble it.

Once you have done that, start Code Composer. Since we are using the on-chip RAM on the TMS320C549 to hold program code, we need to map that RAM into program space before we can load our code. This can be done by opening the CPU Registers window (the same one you use to look at the ARx registers and the accumulators) and changing the PMST register to 0xFFE0. This sets the OVLY bit to 1, switching the internal RAM into the DSP's program memory space.

Finally, load the thru6.out file, use Code Composer's Reset DSP menu option to reset the DSP, and run the code. Probe at the connections with the function generator and the oscilloscope; inputs and outputs are shown in Figure 1. Note that output channels 1-3 come from input channel 1, and output channels 4-6 come from input channel 2. Figure 1 shows the six-channel board's connector configuration.

Figure 1: Six-Channel Board Analog Inputs and Outputs

Also test the serial communications portion of the thru6.asm application. This can be done by starting a provided terminal emulator package (such as Teraterm Pro or HyperTerminal), configuring it to communicate at 38400 bps, with no parity, eight data bits, and one stop bit, and attaching the correct serial port on the computer to the TI TMS320C54x EVM. A serial port is a 9-pin D-shell connector; it is located on the DSP EVM next to the power connector. Typically, there will be two matching D-shell connectors on your computer, often labeled COM1 and COM2; make sure you connect your serial cable to the right one!

Once you have started the terminal emulator, and the emulator has been correctly set to communicate with the DSP board, reload and rerun the thru6.asm application. Once it is running, you should be able to communicate with the DSP by typing text into the terminal emulator's window. Characters that you type should be echoed back; this indicates that the DSP has received and retransmitted the characters. If the DSP is not connected properly or not running, nothing will be displayed as you type. If this happens, check the connections and the terminal emulator configuration, and try again. Due to a terminal emulation quirk, the "Enter" key does not work properly.

After you have verified that the EVM is communicating with the PC, close the terminal window.

Using the D/A and A/D converters

Here we will discuss thru6a.asm, which is shown below. ser_echo.asm is discussed in Core File: Serial Port Communication Between MATLAB and TI TMS320C54x.

	  

	  1		.copy "core.asm"
	  2
	  3		.sect ".text"
	  4	main
	  5		; Your initialization goes here.
	  6	
	  7	loop
	  8		; Wait for a new block of 64 samples to come in
	  9		WAITDATA
	  10	
	  11		; BlockLen = the number of samples that come from WAITDATA (64)
	  12		stm #BlockLen-1, BRC	; Repeat BlockLen=64 times
	  13		rptb block-1		; ...from here to the "block" label
	  14
	  15		ld      *AR6,16, A		; Receive ch1
	  16		mar *+AR6(2)                ; Rcv data is in every other word
	  17		ld      *AR6,16, B		; Receive ch2
	  18		mar *+AR6(2)                ; Rcv data is in every other word
	  19
	  20		; Code to process samples goes here.
	  21
	  22		sth A, *AR7+		; Store into output buffer, ch1
	  23		sth A, *AR7+		; ch2
	  24		sth A, *AR7+		; ch3
	  25
	  26		sth B, *AR7+		; Store into output buffer, ch4
	  27		sth B, *AR7+		; ch5
	  28		sth B, *AR7+		; ch6
	  29		    
	  30	block
	  31		b loop

	  

	

Line 1 copies in the core code, which initializes the six-channel board and the serial interface, provides the interface macros, and then jumps to "main" in your code. Line 3 declares that what follows should be placed in the program-code area in internal memory.

On Line 4, we find the label "main". This is the entry point for your code; once the DSP has finished initializing the six-channel board and the serial port, the core file jumps to this label.

On Line 9, there is a call to WAITDATA. WAITDATA waits for the next block of 64 samples to arrive from the A/D. When it returns, a pointer to the samples captured by the A/D is returned in AR6 (which can also be referred to as pINBUF); a pointer to the start of the output buffer is returned in AR7 (also pOUTBUF). Note that WAITDATA simply calls the wait_fill subroutine in the core file, which uses the B register internally, along with the DP register and the TC flag; therefore, do not expect the value of B to be preserved across the WAITDATA call.

Lines 12 and 13 set up a block repeat. BlockLen is set by the core code as the length of a block; the repeat instruction therefore repeats for every sample time. Lines 15-18 retrieve one sample from each of the two channels; note that the received data is placed in every other memory location. Lines 22-24 place the first input channel into the first three output channels, and lines 26-28 place the second input channel into the last three output channels. Figure 1 shows the relationship between the channel numbers shown in the code and the inputs and outputs on the six-channel board.

Line 31 branches back to the top, where we wait for the next block to arrive and start over.

Using test vectors

A second version of the core file offers the same interface as the standard core file, but instead of reading input samples from the A/D converters on the six-channel board and sending output samples to the D/A converters, it reads and writes from test vectors generated in MATLAB.

Test vectors provide a method for testing your code with known input. Given this known input and the specifications of the system, we can use simulations to determine the expected output of the system. We can then compare the expected output with the measured output of the system. If the system is functioning properly, the expected output and measured output should match3.

Testing your system with test vectors may seem silly in some cases, because you can see if simple filters work by looking at the output on the oscilloscope as you change the input frequency. However, they become more useful as you write more complicated code. With more complicated DSP algorithms, testing becomes more difficult; when you correct an error that results in one case not working, you may introduce an error that causes another case to work improperly. This may not be immediately visible if you simply look at the oscilloscope and function generator; the oscilloscope does not display the signal continuously and transient errors may be hidden. In addition, it is easy to forget to check all possible input frequencies by sweeping the function generator after making a change.

More importantly, the test vectors also allow you to test signals that cannot be generated or displayed with the oscilloscope and function generator. One important signal that cannot be generated or tested with the function generator and oscilloscope is the impulse function; there is no way to view the impulse response of a filter directly without using test vectors. The unit impulse represents a particularly good test vector because it is easy to compare the actual impulse response of a digital filter against the expected impulse response. Testing using the impulse response also exposes the entire range of digital frequencies, unlike testing using periodic waveforms generated by the function generator.

Lastly, testing using test vectors allows us to isolate the DSP from the analog input and output section. This is useful because the analog sections have some limitations, including imperfect anti-aliasing and anti-imaging filters. Testing using test vectors allows us to ensure that what we see is due only to the digital signal processing system, and not imperfections in the analog signal or electronics.

After generating a test vector in MATLAB, save it to a file that can be brought into your code using the MATLAB command save_test_vector (available as save_test_vector.m):

	  
	  >> save_test_vector('testvect.asm',ch1_in,ch2_in);  % Save test vector
	  

	

(where ch1_in and ch2_in are the input test vectors for input channel 1 and input channel 2; ch2_in can be omitted, in which case both channels of the test-vector input will have the same data.)

Next, modify your code to include the test-vector support code and the test-vector file you have created. This can be done by replacing the first line of the file (which is a linker directive to copy in core.asm) with two lines. Instead of:

	  
	  .copy	"core.asm"
	  

	

use:

	  
	  .copy	"testvect.asm"
	  .copy	"vectcore.asm"
	  

	

Note that, as usual, the whitespace in front of the .copy directive is required. (Download vectcore.asm into your work directory if you do not already have a copy.)

The test vectors occupy the .etext section of program memory between 08000h and 0FEFFh. If you do not use this section, it will not interfere with your program code or data. This memory block is large enough to hold a test vector of up to 4,000 elements. Both channels of input, and all six channels of output, are stored in each test vector element.

Now assemble and load the file, and reset and run as usual. After a few seconds, halt the DSP (using the Halt command under the Debug window) and verify that the DSP has halted at a branch statement that branches to itself: spin b spin.

Next, the test vector should be saved and loaded back into MATLAB. This is done by saving 6k 6 k memory elements (where k k is the length of the test vector in samples, and the 6 corresponds to the six output channels) starting with location 08000h in program memory. Do this by choosing File->Data->Save... in Code Composer, then entering the filename output.dat and pressing Enter. Next, enter 0x8000 in the Address field of the dialog box that appears, 6k 6 k in the Length field, and choosing "Program" from the drop-down menu next to "Page." (Always ensure that you use the correct length - six times the length of the test vector - when you save your results.)

Last, use the read_vector function (available as read_vector.m) to read the saved test vector output into MATLAB. Do this using the following MATLAB command:

	  
	  >> [ch1, ch2, ch3, ch4, ch5, ch6] = read_vector('output.dat');
	  

	

The MATLAB vectors ch1 through ch6 now contain the output of your program code in response to the input from the test vector.