Post Go back to editing

ADSP-SC58x/218x Audio Talkthrough: Example code

Attached is the sample code for Audio Talk through on EVAL-SC589-EZLITE for I2S mode of operation.

Audio_passthrough_I2S.zip
  • Hi Sachin,

    What is the difference between the MultiCoreTalkThruSharc example code and this?


    Ksam

  • Hi Ksam,

    I think you are referring to example code that is offered along with the EE-377, please correct me if I am wrong.

    1. First important difference, It is a single core framework, ie.. only SHARC1 core configures the ADC/DAC receives data from ADC over sport and copies them to DAC buffers to be played by DAC. Here all the buffers are placed in SHARC 1 core.Code that comes along with EE-377 actually demonstrates inter-core communications. Here SHARC 1 core controls ADC and SHARC 2 core controls DAC. It demonstrates how inter-core communication need to be taken care in such scenarios.

    2. The code attached here doesn't use any drivers and services. It performs simple register read and write. The codes provided in EE-377 uses devices drivers and services. So this code is for people who prefer register level programming over device drivers and services.

    3. The EE-377 code performs input filtering but the code attached here is just a passthrough.

    4.The EE-377 code is for 4 Audio channels and configures serial ports in TDM 4 mode. the code attached here is only for 2 audio channels and configures serial port to I2S mode 

    There may many other subtle differences but most importantly I had this code lying around my machine just thought that I will share with the community.

    Thanks,

    Sachin

  • Hi Sachin,

    Thanks for feedback, and explaining it clearly. As I am new to this kind of development, can you suggest me about from where exactly we need to start, about the configuration of the DAC/ADC, SPORT I2S and other things.

    Some small doubts also I am having about EE377 note. Can we use this source code along with the uCOS. ? if we want to make it work using uCOS, what are the things we need to update? 

  • Hi Sachin,

    If you have audio talk through using the SPORT without using the  devices drivers and services, please share it?

    Can we use the uCOS III with device drivers and services?

    Awaiting for your response.

    Ksam

  • Hi Ksam,

    The code attached in the thread doesn't use Device Drivers and Services.

    You can first start with ADSP-SC58x Hardware reference manual and learn about SPORT, DAI,DMA and other peripherals and infrastructure. If you want to use Device Driver and Services based codes, please go through the CCES help menu and understand various Device Drivers APIs. It is absolutely essential to understand Device Driver's implementation

    Yes, It should be possible to use UCOS 3 with the Device Drivers and services. I am not an expert in UCOS related stuff  but I believe, you need to create a UCOS project. Then create few threads for various devices like ADC and DAC. Configure ADC, DAC and SC589's SPORT inside thread. Use few semaphores for consumer thread to wait till data is read from ADC by SPORT into ADC buffers (SC589's Memory) and perform the necessary filtering and write back to DAC buffers (SC589's Memory). Send these buffers to SPORT for playback through DAC.

    Thanks,

    Sachin

  • Hi Sachin,

    Is there a version of the talkthrough code that will run on EVAL-SC584-EZLITE?

    If not, could you provide some guidance on the changes that need to be made to target SC584?

    Is the sru config automatically generated or does it need editing by hand?

    Thanks,

    RV

  • Hi RV,

    Attached is the audio loopback code for SC584 processors. In this example code, SRU has been coded manually ( see DAI_init() function).

    Thanks,
    Sachin

  • Hi Sachin,

    Many thanks for providing the updated code, it is very helpful.

    One issue I have found is the code does not seem to always load/run properly (or at all).  About half the time I try to run, the code appears to fail and exits at __lib_prog_term.

    I repeat the procedure a second time and it then runs fine.  I’m not sure if it is something to do with the way I am using the de-bugger?  The procedure I use is as follows:

    1. Build code (target SC584)

    2. Click on Debug (target EZKit)

    3. The De-bugger loads all 3 cores (this takes over a minute to complete)

    4. Click on Multicore Run: code runs till Core 0 halts.

    5. Click on Core 1 in the Debug/Call trace window and then click on single core run (F5)

    6. Usually this fails the first time and exits as mentioned. I then click on Terminate followed by Remove All Terminated.

    7. Repeat the procedure starting from (2) above.  Typically it runs the 2nd time.

    This means every time I need to change the code or simply reset and restart it, it takes about 3 minutes.  That becomes painful when trying to debug various things.

    Is there a better sequence I could use to improve the success rate?  Is there a simpler way to restart the code for example after hitting a break point (rather than having to go through the whole Terminate/Re-launch procedure?

    If anyone else has any insights I’d be grateful to hear them

    Reverb

  • Hi Reverb,

    I haven't faced any of these issues before.

    Are you resetting the processor between different loads ? If you are not doing that already, please do that.

    Thanks,

    Sachin

  • Hi Sachin,

    In the debug configuration for the EZKit, all 3 processors have the "Reset before load" option selected.

    Are the steps I outlined earlier for loading & running correct or is there a way for example to get the main program in core 1 to run without having to perform both steps 4 & 5?

    Reverb