Attached is the sample code for Audio Talk through on EVAL-SC589-EZLITE for I2S mode of operation.
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?
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?
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
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?