This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
My partner and I are trying to use the ezdspC5535 as an audio effects processor intended for use by musical instruments for our senior project in electrical engineering at the University of Vermont. We want to use this device for real-time playback of effected audio signals. We would like to input the signals through the stereo input jack J3 and output them through the stereo output jack J4. Upon reviewing the documentation associated with the connected audio framework we have come to understand that for real-time playback of audio the signals go through the micro USB port J1. We want to know if it is possible to change the path from which we input signals for real-time playback. Ultimately we want to insert our own filter algorithms into the playback path, but we would like our input to be directly from the instrument itself via an 1/8th inch jack not the USB.
Any advice or help would be greatly appreciated.
Mike & Mike
Hi Mike and Mike,
Cool project - C5000 DSPs are well suited for real-time audio processing.
Check out the examples in the C5000 University Teaching ROM - 20 labs that use the audio input and output jacks for filtering, audio effects, etc. I have used these labs with the pickups of an electric guitar as the audio source - it worked well.
These labs are written for the C5505 and C5515 eZdsps, but are easily ported to the C5535 eZdsp. I have been meaning to write the wiki article on the porting - essentially replace I2S0 with I2S2 in all instances - I2S2 is connected to the AIC3204 codec on the C5535 eZdsp whereas I2S0 was connected to the codec on C5505 and C5515 eZdsps.
For your project, the connected audio framework might not be the best starting point unless you require USB streaming playback or record.
Let us know how we can help.
Regards,
Mark
Mark,
Thanks for the quick response, your help is appreciated. We attempted to begin the first lab in Chapter 1. We changed I2S0 to I2S2 in the files, and got the code to build without any errors or warnings. When attempting to debug the program we ran into issues. We think the code is set up to work with the C5505 processor and we are unsure how to get it to debug with our processor. We would be grateful for any help.
Thanks,
Mike & Mike
Mike and Mike,
Try replacing the original Teaching ROM files with these attached modified files.
I bet your problem was not making this change to the EBSR register (pin mux) to bring out I2S2...
SYS_EXBUSSEL = 0x1000; // Configure PPMODE 1 = I2S2
3542.C5000 Teaching ROM Port to C5535 eZdsp.zip
This is going on the wiki for sure.
Hope this helps,
Mark
Mike and Mike,
I have created this Porting C5000 Teaching ROM to C5535 eZdsp wiki page:
http://processors.wiki.ti.com/index.php/Porting_C5000_Teaching_ROM_to_C5535_eZdsp
Successfully verified this port on all 20 Teaching ROM labs!
Regards,
Mark
Hey Mark,
We are having issues still getting the first program to run. We followed the steps included in the wiki, but still can't hear any audio being output. We have observed that the demo code is still loaded onto our device, and can in fact still play audio from our PC through the micro-USB. Would this be an issue if this code is still on our device? Is there any specific way we should be loading code on our device in order to clear out old code? We appreciate your help so far, and we think we are very close to figuring this out.
Thanks,
Mike & Mike
Hi Mike and Mike,
Try to import this existing CCS4 project.
4174.Chapter 1 - C5535 eZdsp.zip
michael swanson said:We have observed that the demo code is still loaded onto our device, and can in fact still play audio from our PC through the micro-USB.
Once you connect to the eZdsp from within code composer, that demo program should stop running - the OLED will keep its display until power cycled or written to.
Make sure you are connecting to the J2 USB port when you connect to the eZdsp through CCS.
Isnt the demo code stored on the microSD card? Why not just remove the microSD card to stop the demo code from running?
After connecting to the eZdsp, and after building the CCS4 project, use the load program feature to load the .out file into the DSP internal memory.
Then using the debugger, run the program by clicking on the Green Run arrow button.
Let me know where you are getting stuck.
Hope this helps,
Mark
Mark,
Thank you very much! We weren't familiar with devices that required manual loading, and sure enough loading the .out file allowed us to play audio through our device. We appreciate all your help.
Best,
Mike and Mike
Mark,
Now that we have this process complete we have run into another small road block. It appears that in order for us to have a program run while the ezDSP is not connected to the computer via J2 we need to load a boot-image of the program onto the device. We found an article on this, but we had trouble understanding the full process. Could you give us some advice for how to perform this process correctly? Thanks again for all your help, you have been an invaluable resource to us.
-Mike & Mike
Hi Mike and Mike,
Not a problem.
Here's the flow of things:
SPI Flash has precedence over SD Boot if both have valid images - SPI Flash can be disconnected (boot avoided) by switching DIP SW3 Pin 4 to OFF
See http://www.ti.com/lit/an/sprabl7a/sprabl7a.pdf:
"Each device has a fixed order in which it checks for a valid boot image on each supported boot device. The device order is 16-bit SPI EEPROM, 24-bit SPI serial flash, I2C EEPROM, and SD/SDHC/eMMC/moviNAND"
Hex55 Reference: See http://www.ti.com/lit/ug/spru280i/spru280i.pdf - Chapter 13 - Hex Conversion Utility Description
Also try this attached bootimg of Teaching ROM Chapter 1 ported to C5535 eZdsp that I created with this procedure:
1731.bootimg_Chapter1-5535.bin
Hope this helps,
Mark
Dear Mark,
I would like to check the Teaching ROM examples, but it seems the link http://www.ti.com/ww/eu/university/cd-rom/c5000.zip from TI University Program is not active. The other ROMs (From MATLAB and SIMULINK to Real Time... and C6000 Teaching ROM) can be downloaded.
Is it possible to get still the C5000 Teaching ROM content?
BTW, I am starting with the eZDSP USB stick for C5515 and would like to make a SPL meter using A-weighting filtering and True-RMS measurement.
Did you see any similar project examples?
Thanks for help!
Cheers,
Krzysztof
Hi Krzysztof,
Here is the correct link to the EU University Teaching ROMs: http://www.ti.com/ww/eu/university/roms.html
The Teaching ROM has labs for FIR, IIR, multirate filters, FFTs, and MATLAB examples but it does not have coefficients or the algorithms for A-weighting or efficient RMS.
Neat project, for A-weighting do you plan to use IIR, biquads, or maybe FFT?
Also the DSPLIB has sum of squares of a vector (power) and square root of a vector functions.
Hope this helps,
Mark
Hello Mark,
thanks for your answer. I have downloaded the exaples. Looks very helpful, just starting play with.
I don't know yet what type of filtering I will use for A-weighting curve. I will try first with a FIR. If there will be not enough of memory/time will try IIR. I have to note, I'm just start the adventure with the DSP, so I'm greenhorn in this :-) Any help is welcome.
Greetings,
Krzysztof
Mark,
We have been making great progress with our audio effects processor project thanks to all your help. I was curious if you could help us out with our most recent issue. We are using a resistive touch pad to alter filter parameters on our DSP. We have been working with this touch pad controller for the past couple of weeks and we would like to communicate data from our touch pad controller to the C5535 using i2c communication. In order for us to verify whether or not our touch pad controller is working correctly, we would like to write data from it to our DSP using i2c and then read the data to confirm that it is in fact working. Are there any good pieces of demo code that spell out how to do this i2c writing and reading? Any help would be appreciated.
Thanks again,
Mike & Mike
Hi Mike & Mike,
I would reuse the usbstk5505_i2c.c and usbstk5505_i2c.h files included with the teaching ROM materials. USBSTK5505_I2C_read() and USBSTK5505_I2C_write() may need to be modified based on the data format of your I2C device.
Do you have a datasheet to check the I2C data format?
The AIC3204 codec and the OLED (Chapter 20) are configured with I2C commands, so you can study the code for these devices, and modify it to work with your device.
For I2C peripheral details, see Chapter 9 of the C5535 Technical Reference Manual.
Hope this helps,
Mark
Hi Mark,
We have been able to use the C5535 to communicate with our resistive touchpad using i2c communication. We are using the functions USBSTK5505_I2C_read() and USBSTK5505_I2C_write(). One issue that has come up is that using the USBSTK5505_I2C_read() to read coordinate data from our resistive touchpad has somehow been interfering with the use of the audio codec. Included below is our code. We are just simply trying to use the coordinate data from the resistive touchpad to attenuate the output signals, kind of like a volume control pad. Upon commenting out both the read and the write we were able to hear our sound signals pass through the system fine. After reintroducing the write commands we are still able to hear our sound signals pass through the system. Upon reintroducing the read command our sound signal does not pass through the system well. We essentially get a extremely incoherent noisy signal. Is there a certain way we should be using this read function in order to not interrupt the use of the audio codec?
Thank you,
Mike & Mike
void main( void )
{
/* Initialize BSL */
USBSTK5515_init( );
/* Initialize PLL */
pll_frequency_setup(60);
/* Initialise hardware interface and I2C for code */
aic3204_hardware_init();
/* Initialise the AIC3204 codec */
aic3204_init();
/* Turn off the 4 coloured LEDs */
USBSTK5515_ULED_init();
/* Initialise the OLED LCD display */
oled_init();
SAR_init();
oled_display_message(" ", " ");
printf("\n\nRunning Project Echo and Reverberation\n");
printf( "<-> Audio Loopback from Microphone In --> to Headphones/Lineout\n\n" );
/* Setup sampling frequency and 30dB gain for microphone */
set_sampling_frequency_and_gain(SAMPLES_PER_SECOND, GAIN_IN_dB);
oled_display_message("Application 3 ", "Echo and Reverb ");
/* New. Add descriptive text */
/* New. Default to XF LED off */
asm(" bclr XF");
/* i2c comm with mtouch device */
enableTouch[0] = 0x9A;
enableTouch[1] = 0x00;
enableTouch[2] = 0x55;
enableTouch[3] = 0x01;
enableTouch[4] = 0x12;
passFail2 = mTouch_multiSend( enableTouch, 5 );
printf("Passfail2 %d\n", passFail2);
xTemp = 0;
while(1)
{
passFail = USBSTK5505_I2C_read( 0x4D, cmd, 5);
// initialize at zero parameters
if(cmd[0] != 0x81 && cmd[0] != 0){
cmd[1] = 0;
cmd[2] = 0;
cmd[3] = 0;
cmd[4] = 0;
}
// printf("Address 1 %x\n", cmd[0]);
// printf("Address 2 %x\n", cmd[1]);
// printf("Address 3 %x\n", cmd[2]);
// printf("Address 4 %x\n", cmd[3]);
// printf("Address 5 %x\n", cmd[4]);
// printf("Passfail %d\n", passFail);
x1 = cmd[4];
x2 = cmd[3];
x3 = (x1 << 7) + x2;
printf("%x\n", x3);
aic3204_codec_read(&left_input, &right_input); // Configured for one interrupt per two channels.
left_output = left_input; // Straight trough. No processing.
right_output = right_input;
aic3204_codec_write(left_output, right_output);
Step = pushbuttons_read(1);
//if ( Step == 1 )
// {
//if ( Step != LastStep )
// {
// oled_display_message("STEP1 No Processing", " Set Levels ");
// LastStep = Step;
// }
/*if( (x3 - xTemp) < 4000 && (x3 - xTemp) > 3000){
left_output = left_input/100; // Straight trough. No processing.
right_output = right_input/100;
}
else if( (x3 - xTemp) < 2000 && (x3 - xTemp) > 1000){
left_output = left_input/50; // Straight trough. No processing.
right_output = right_input/50;
}
else if( (x3 - xTemp) < 1000 && (x3 - xTemp) > 0){
left_output = left_input/25; // Straight trough. No processing.
right_output = right_input/25;
}*/
// }
xTemp = x3;
bargraph_6dB(left_output, right_output);
}
/* Disable I2S and put codec into reset */
aic3204_disable();
printf( "\n***Program has Terminated***\n" );
oled_display_message("PROGRAM HAS ", "TERMINATED ");
SW_BREAKPOINT;
}
Hi Mike & Mike,
If I2C works for one but not both, you might be running out of clock cycles to complete all processing with enough headroom to read and write from the I2S registers at 48KHz.
Try to increase the PLL frequency.
/* Initialize PLL */
pll_frequency_setup(60); // can go up to 120 MHz
Measure the frequency of your foreground while loop to see that it matches the sampling frequency of the codec (48KHz probably)
You can probe XF pin with an O-scope, and use bset and bclr to toggle it. (see code below)
If the while loop frequency is below 48KHz, then you are dropping samples from I2S, which would cause audio distortion.
I have been able to reproduce audio distortion due to missed samples at various PLL frequencies with enough "processing delay" (for loop of NOPs)
while(1)
{
//insert "processing delay"
for(j=0;j<1000;j++)
{
asm(" nop");
}
//XF on at beginning of codec read
asm(" bset XF");
aic3204_codec_read(&left_input, &right_input); // Configured for one interrupt per two channels.
aic3204_codec_write(left_input, right_input);
//XF off at end of codec write
//Freq of XF should be 48KHz if enouch cycles are provided to complete "processing" delay and poll I2S in time to avoid missing samples
asm(" bclr XF");
}
Hope this helps,
Mark
We have attempted to change the PLL clock, but it appears we need it to be even faster than the maximum value. We also attempted to change the i2c clock to be faster aswell, and have heard some promising results but nothing near what the audio should sound like. Any help you can provide would be great. We have been working on this issue for awhile and are just stumped.
Thanks again,
Mike & Mike
Hi Mike & Mike,
michael swanson said:where is the xf pin?
You can probe the XF pin where it connects to the XF LED next to the mini-USB connector on the C5535 eZdsp.
With the software written to poll the I2S registers audio samples are ready, you should see that the loop executes with a frequency of 48KHz.
There are more efficient ways than polling to read audio samples - interrupt when I2S registers are filled, DMA to copy blocks of I2S samples at a time, even DSP/BIOS RTOS to switch between multiple tasks...
You might also study Chapter 18 - Assembly language - the PPT Slide 10 for this chapter (Sampling Rate 48000 Hz) has some good info and instructions for profiling your software.
Are you able to use an oscilloscope and toggle the XF pin to see where your software is spending all of its time?
Does your software read from the mTouch every loop iteration?
Regards,
Mark
Hello Mike,
I have been trying to get the ROM Port working but I'm still having issues. I have followed the wiki page to the t and have been searching all over the forums but haven't seen anything relating to the problem I'm experiencing.
When trying to compile FIR chapter 6 for example, the code compiles (using the adapted files for porting) however when I go to debug and run the program it is stuck at the pll_frequency_setup() function and it never reaches the rest of the lab. All I'm getting on the display is:
PLL frequency 100 MHz
REGISTER --- CONFIG VALUES
but nothing further. I've let it sit for minutes at a time but I'm pretty sure it is not supposed to take this long for initialization. Any help would be greatly appreciated!
Cheers,
Andrew
Hello Andrew,
I hope you have solved the problem by now. I experienced the same when SD card was inserted - I simply forgot to remove it.
Regards,
Victor