Forums » Software Development »
Audioexample with DSP-ARM-Communication
Added by Benedikt K. over 10 years ago
Hej,
I'm new to the TI OMAP and previously worked with AD Sharc-Processors.
For a new product I switched to the MityDSP L138F. Basic system requirements are audio input (TDM, 16 or 32 channels) using the McBSP, audio processing on the DSP and audio output via the McBSP (TDM16). Additionally the ARM should have a small linux running which can communicate to the outer world using ethernet / UART. The DSP must process the audio data blockwise in real time and should always have higher priority compared to the ARM to avoid gliches in the audio data.
The communication between DSP and ARM can be quite simple as there are only a few filter coefficients transferred. Later it should be possible to store and read audio data from sata / sd-card / usb instead of the McBSP. Either directly from DSP to the storage device or via the ARM/Linux.
Right now I'm at a point where I have to decide which OS I should use on the DSP:
- SysBios with SysLink (newer Version of DSPBios)
- DSPBios with DSPLink
- No OS
One important question is: How much overhead does the OS introduce to the DSP? As the audio processing task will consume most of the processing time of the DSP it may be more efficient to avoid a OS which introduce background tasks.
Second question: If I don't use a OS, can I boot the DSP from the ARM/Linux?
Does Critical Link have a audio talkthrough example which I can use as start point for my development?
Replies (2)
RE: Audioexample with DSP-ARM-Communication - Added by Michael Williamson over 10 years ago
DSPBIOS (or SYSBIOS) does not introduce much overhead, it should be fine for you application. If you need to, you could do your DSP processing in an interrupt handler to avoid context switching, but I suspect that a simple task based system will be more than adequate for what you need.
We currently support DSPBios with SysLink, as well as TI's DVSDK.
Syslink/SysBios is certainly an option, but we have not ported support for it with our board support packages. However, you should be able to build against our kernel with the syslink libraries from TI without an issue.
Any reason McBSP instead of McASP?
-Mike
RE: Audioexample with DSP-ARM-Communication - Added by Benedikt K. over 10 years ago
Hej Mike,
if your support is for DSPBios and DSPLink and there is no much overhead, then I will stick to that.
The main reason for using a McBSP is that I plan two options for the system. One using the MityDSP-FPGA to route the audio streams from several sources and sinks to the DSP (and later maybe several DSPs on several MityDSP modules). Then I only need one TDM audio stream in and out with 16 channels each. McBSP or McASP does not matter here as long as I can transfer 16 (maybe 32) channels to and from the FPGA.
The low cost option should be able to handle two I2S sources streaming at 192 kHz and a TDM16 / two TDM8 (or 8 I2S) sink running at 48 kHz without any FPGA. The format for the sink is not determined yet as this will depend on the DAC selected to output 16 analog channels. Therefore I decided to use the two McBSP for the I2S sources running at 192 kHz and the McASP for the sink running at 48 kHz.
I will start with the first option and therefore can also use the McASP. Nevertheless I need the McBSP later.
Instead of the MII-Phy of the MityDSP-Devboard I will use a RMII-Phy on our baseboard. Therefore I can use all McASP and McBSP-pins.
Are there any reasons why I should not use the McBSP?
Benedikt
