Is there a register-layer CSL for OMAP3530 to program McBSP?

OMAP DVSDK includes an audio ALSA driver that talks to TWL4030 part via McBSP.  This should point you in the right direction....

To clarify what Juan is getting at, essentially the only software support we have for peripherals like the McBSP comes in the form of Linux drivers that run on the ARM. This being said, there is no CSL for the DSP side of the OMAP3530.

From the Linux side the audio (ALSA) driver has support in it for the audio codec on the TWL4030/TPS65950 or a AIC23, if your particular ADC needs timings and such that differ from what the standard audio codecs are using than you will likely have to make some driver modifications in the kernel level. If you want to do more of this from user space than you may want to look into adding a proc that can just access the registers from user space, though that somewhat defeats the purpose of having the protected kernel vs user space.

Thanks Bernie and Juan for the advice.  I copied the CSL register abstraction from another board and modified values for OMAP 3530.  I'm using omap2-mcbsp-def.h from the Linux kernel to check my work.  Today I was able to get all the McBSP5 lines active, so I'm good to go for now.

Conceptually, I like the idea of keeping the register access in protected kernel space, but hardware engineers here don't know about that stuff.  :)  In our application, the C64xp is processing data from the peripherals, so it's just easier debugging everything on the DSP side with CCS and the emulator.  The ARM side will never care about the peripherals themselves, only the DSP results.

Thanks, many more E2E questions coming soon on other topics.  :)

I am glad to hear you were able to get things going from the DSP, this should help encourage other customers who decide to go this route. This is actually a common issue we have had since we started providing ARM parts with the DM6446, almost every developer who had used our DSPs before goes looking for the CSL, which for better or worse has not existed for a few generations. Moving to the Linux driver model can be a big step, but for most customers who use the peripherals in a typical context (in this case as an audio interface) it means they can do it out of the box and treat the device like it was a PC, of course for customizers like you it means a bit of extra work.

I look forward to seeing your questions, hopefully we can answer them all. :)

Dear Chris,

    Now we are a OMAP3530 project. Our new PCBA will released soon.

    Could you please share the mcbsp test program to us. We will also debug the mcbsp peripheral.

THX & BR

Jevon

Chris Norris said:

Thanks Bernie and Juan for the advice.  I copied the CSL register abstraction from another board and modified values for OMAP 3530.  I'm using omap2-mcbsp-def.h from the Linux kernel to check my work.  Today I was able to get all the McBSP5 lines active, so I'm good to go for now.

Conceptually, I like the idea of keeping the register access in protected kernel space, but hardware engineers here don't know about that stuff.  :)  In our application, the C64xp is processing data from the peripherals, so it's just easier debugging everything on the DSP side with CCS and the emulator.  The ARM side will never care about the peripherals themselves, only the DSP results.

Thanks, many more E2E questions coming soon on other topics.  :)

 

HI Chris,

I am using the beagle board 3530 using ccsv5 along with XDS100v2 emulator fine.

Now i want to read data from DDR/SD card ..whatever to the dsp side and the i will process it to give output to the mcbsp. Basically like you said i am new to ARM+DSp plateforms. Earlier i had used only DSP's. So can you  please guide me over this about few lines. ?

Nitin mewada

Hi Nitin,

What aspect of your design are you needing advice on?  Reading from SD or transmitting data with the McBSP?

Are you running Linux on the ARM side?

I suggest writing two applications:
(1) Linux program that reads from SD and sends data to the DSP using DSPLink.
(2) DSP program that receives data using DSPLink and sends to McBSP.

DSPLink can be downloaded from:
http://software-dl.ti.com/dsps/dsps_public_sw/DSPLink/index.html

When you unzip DSPLink, there will be a doc folder with a User Guide and Programming Guide.  The way I approach ARM+DSP programming is to start with the sample application that most closely matches my system requirements.

In the User Guide, take a look at "Figure 11 Data Flow in the sample application - RING_IO".  You could modify the ARM RingIO writer client to send data from the SD to the DSP through the RingIO 1 instance.  On the DSP side, instead of copying from RingIO1 to RingIO2, copy from RingIO1 to McBSP Tx FIFO.

I haven't done any DSP-side DMA with McBSP yet, but that would make the process more efficient.

Chris Norris

Hi Chris,

Thanks for your reply,

Actually i am using the window 7/window xp and ccsv5. Over here what  i had accomplished is , i had almost debugged successfully mp3 decoder code, plus some basic program on Buffer Rx/Tx using mcbsp.

So, now what i am thinking that, there will be file say  *.mp3, then i will decode using my decoder and play it through the audio out using McBSP2 (i guess).

Right now i am reading from the Input folder itself, then i will try to read the file from MMC card.

Note that i am not using any linux based application. Using Linux and its application its seems easy and i knew about it, but my task  is to independently develop the code that will be user friendly to all application level. 

The thing is that, plug in the mmc card, power up the beagle board, .out file is already there loaded by ccs. now when press user switch on board, an interrupt generates and it will play the mp3 file. that's it. Nothing required anymore.

If you have any idea or suggestions about it, then let me know. Hope that we will enjoy this one.

With Regards,

Nitin Mewada 

Hi Nitin,

To access the MMC card from the DSP-side, you will need software in the DSP to recognize the file system.  To support FAT on a different OMAP, I noticed that TI offers the DSP/BIOS File System:
http://software-dl.ti.com/dsps/dsps_registered_sw/sdo_sb/targetcontent/bios_file_system/index.html

The archive contains an example at rtfs_1_10_02_32\packages\ti\rtfs\examples\mmcsd for MMC access.

The RTFS package depends on peripheral drivers from the PSP.  For OMAP-L1x, the driver appears to be at pspdrivers_01_30_00_05\packages\ti\pspiom\mmcsd

Unfortunately for OMAP3530, a PSP driver for mmcsd doesn't exist.  I'm not sure if the MMC controllers are similar enough to port the drivers, so that may be challenging.

An alternative to the full SD interface is to interact with the SD in SPI mode.  This is a more common interfacing for simple microcontrollers.  For TI's Stellaris, I've seen an example at StellarisWare\boards\dk-lm3s9b96\sd_card.  This is a totally different processor, but through code inspection maybe you could learn the SPI technique.  If you Google, you can find several examples of microcontroller access to an SD card using SPI (Stellaris, MSP430, etc.)

Regarding system startup, I'm not sure if you will always boot the DSP using CCS and the emulator, or do you want your DSP program to start automatically after the board powers on?  I think the OMAP boot ROM code runs on ARM, so you would at minimum need some ARM software to power on the DSP and load the DSP code.

You could design your own DSP program loader, but I think the Linux DSP/BIOS Link processor loader is a much easier way to load programs on the DSP.  A shell script could launch the DSP program during the Linux boot sequence.

I hope this helps you with some ideas!

Regards,
~Chris

Hi Chris,

thnax for reply man.....................

Since i posted earlier, i was trying to learn these things. Now i got clear ideas of what i want to do. I know i need to go step by step in my project so  i am doing it.

Basically after McBSP, i am now focusing on writing again mp3 decoder code using xdc packages and SYSBIOS(using new CCSV5 and BIOS6 , RTSC plateform), then i will probably move to the system booting, reading from MMC card like just you explained me. Things are much broader than i thought for this project.

Let me know if you want to know something about my stuff.

With Regards,

Nitin Mewada