Attached is the sample code for Audio Talk through on EVAL-SC589-EZLITE for I2S mode of operation.
What is the difference between the MultiCoreTalkThruSharc example code and this?
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 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?
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.
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.
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?
Attached is the audio loopback code for SC584 processors. In this example code, SRU has been coded manually ( see DAI_init() function).
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
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.
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?
Sorry, I wasn't clear, I meant Power on Reset ( Power Cycle)
How to run this project? I just try it on my SC589 ezborad, but I cannot hear any voice like the ADC_DAC_Playback example.
From your previous replies i come to know you are very well expert in SHARC Board and audio concepts.
I am new to this domain,I want to learn about SPORT, DAC/ADC,Audio playback.Can you share the code and thing
I just ran the code in latest CCES 2.5.0 and found it to be functional. It's a 2 channel loopback code, refer to setup.jpg for input and output connection details. The original code was built for silicon revision of 0.1, you can change that in the project setting depending on your Ezkit.
ADSP-SC58x Hardware reference manual is good place to start for the detailed explanation of SPORT. If you haven't already, please install ADSP-SC5xx board support package, it has lot of Audio examples. There are application notes like EE-383 and EE-377 on SC58x based Audio frameworks.
Retrieving data ...