Flying start to OMAP3530 DSP software development?

GoogleGroups
1

Dear BeagleBoard Folks,

Please advice me for the best start-up for the OMAP3530 DSP software development.
What is the best source for the DSP architecture and instruction set?
What is the best cross development tool for a Windows (sorry) PC?
How does the Linux ARM processor and the DSP communicate?
Does the DSP have full access to the DMAs, McBSPs, and timers while ARM runs Linux?
What should I keep in mind to avoid conflicts between the ARM and DSP?
What other resources do you recommend for a beginner?

Thanks in advance, Happy New Year 2011, and best regards,
siñ

2

What is the best source for the DSP architecture and instruction set?

What is the best cross development tool for a Windows (sorry) PC?

TI Code Composer Studio 4 (it's free with XDS100v2 JTAG).

How does the Linux ARM processor and the DSP communicate?

Using any shared memory. See DSPLink/DSPBridge/DSP Gateway for
details.

Does the DSP have full access to the DMAs, McBSPs, and timers while ARM runs
Linux?

Yes.

What should I keep in mind to avoid conflicts between the ARM and DSP?

Synchronization.

What other resources do you recommend for a beginner?

3

Thank you VERY much Max,
siñ

4

Again, thank you very much for your advice Max!

A few things still:

  1. I cannot find the “free Composer Studio” offer with XDS100v2. Do you have the good link?
  2. Can you still recommend a tutorial on OMAP3530 DSP programming, with examples…
  3. All DSPLink/DSPBridge/DSP Gateway seem to be slightly immature and closed.
    Do you have a preference between them. My ARM-DSP connection will be very primitive.

Have a Great New Year 2010,
siñ

5

1. I cannot find the "free Composer Studio" offer with XDS100v2. Do you have
the good link?

Sure: http://focus.ti.com/docs/toolsw/folders/print/ccstudio.html?DCMP=dsp_ccs_v4&HQS=Other+OT+ccs

See "License Options" section: "Free: Use a full version of CCS which
limited to an XDS100 hardware emulator connection."

During the installation process you'll be asked about license options.
Just select the one with XDS100 support.

2. Can you still recommend a tutorial on OMAP3530 DSP programming, with
examples...

I'm afraid there is no good step-by-step tutorial for programming C64+
DSP for beginners (I didn't find any) just tutorials for using DSPLink
and so one. :frowning: It's not a very popular field of programming so you
have to search for information in books, forums, sources etc.

3. All DSPLink/DSPBridge/DSP Gateway seem to be slightly immature and
closed.
Do you have a preference between them. My ARM-DSP connection will be
very primitive.

If your connection will be very primitive you don't need DSPLink,
DSPBridge or DSP Gateway (it's a good news). You can write your own
linux driver for communication between ARM and DSP (it's a "bad" news
but I chose this way). :slight_smile: It's not a very difficult task, you have to
implement ioctl (for setting shared memory regions, starting/stopping/
reseting DSP) and mmap (for mapping shared memory) functions, add new
chrdev, map some DSP's registers, initialise DSP's mmu, set DSP's
entry point etc. After that you'll be able to load and run DSP binary
from your linux. A good starting point for you is DSPLink sources.

Have a Great New Year too! :slight_smile:

Cheers,
Max.

6

A quick google search found http://focus.ti.com/docs/toolsw/folders/print/xds100.html as a link to purchase the XDS100 units… The hardware is not free, but not outrageously expensive either.

2010/12/30 Seppo Nikkilä <seppo.nikkila@innovativeideas.fi>

7

Seppo Nikkilä,

For your driver you'll also need the next documents as references
(http://bunnitude.com/misc/files/omap/pdf/):

SPRUFA5 - "OMAP35xx Applications Processor: Power, Reset, and Clock
Management"
SPRUFA8 - "OMAP35xx Applications Processor: Interrupt Controller
(INTC)"
SPRUFF2 - "OMAP35xx Applications Processor: Memory Mapping"
SPRUFF5 - "OMAP35xx Applications Processor: Memory Management Units
(MMUs)"

Cheers,
Max.

8

Hi Max & William,

With your nice advice, I am now ready to start.
Thank you very much for getting me going.
And Happy New Year,

siñ

9

I’ve developed for a TMS320C6713 DSP platform in the past using CCS 3.31. I would love to be able to take advantage of the DSP in the Omap3530, but my current application does a lot of floating point stuff, and I don’t believe the DSP does floating point. Just as importantly, I don’t really have a firm grip on knowing how I’d partition my processes so that the appropriate parts ran on the DSP, and interacting with the portions running in the MPU.

If you get around to writing a tutorial after you’ve figured things out, I’d love to read it. On the other hand, if you find any reference books or sites that are helpful, sharing with the group is always appreciated…

Wim.

2010/12/30 Seppo Nikkilä <seppo.nikkila@innovativeideas.fi>

10

How does the Linux ARM processor and the DSP communicate?

Afaik it is limited to shared memory, a interrupt line and a hardware
mailbox.

Does the DSP have full access to the DMAs, McBSPs, and timers while
ARM runs Linux?

Yes and no.

There is no synchronization between the DSP and the Linux kernel. If a
linux driver is working with a piece of hardware (the McBsp2 for
example) you can technically access it from the DSP, but the chances are
high that you will not work. Programming the McBsp from the DSP and
having the linux kernel handling the interrupts is a receipt for a
disaster :slight_smile:

You can however just disable the driver support for the peripherals you
want to use in the linux kernel. Afterwards the DSP is free to do
whatever it wants to do.

Also , as far as I remember not all peripherals are usable from the DSP.
Most are, but for some peripherals you get register access but you there
exist no way to get the interrupts to the DSP. I could be wrong, but I
think the I�C block has this restriction. If you run into this problem
you can of course do the work on the ARM using a minimal driver that
communicates with the DSP. It raises the latency, but it is doable.

What should I keep in mind to avoid conflicts between the ARM and DSP?

The ARM and DSP have separate memory caches. If you write to memory
using the DSP and later access the memory from the ARM you may not see
the latest data because it may not have been written back to memory.

The same applies if the ARM has caches enabled.

In a nutshell if you use caches (you should!) the core that reads shared
memory should invalidate the memory region before doing the read, and
the core that writes to shared memory should write-back the cache-content.

On the DSP, DspBios offers the functionality to do this, on the ARM
DspLink offers functionality to do the same.

Btw, just wondering what you want to do with the DSP... I have quite a
bit of DSP code on my harddisk that I'm willing to share if I can help
out a beginner.

Cheers,
    Nils Pipenbrinck

11
  1. Can you still recommend a tutorial on OMAP3530 DSP programming, with
    > examples…

    Depends on what you are trying to do
    The C64xx support page has drivers etc for McBSP and Actually the C64xx was used as
    a microntroller one one project I worked and while another it was used for video codec

    I suggest you start with a tutorial on tc64xx. Granted there is a process you need to follow on the OMAP to hold the A8 in reset. There is a short TI wikki that covers c64x on Beagle it takes a bit of searching

    http://processors.wiki.ti.com

    — On Thu, 12/30/10, Max Galemin maksim.galemin@gmail.com wrote:


    > From: Max Galemin maksim.galemin@gmail.com
    > Subject: [beagleboard] Re: Flying start to OMAP3530 DSP software development?
    > To: “Beagle Board” beagleboard@googlegroups.com
    > Date: Thursday, December 30, 2010, 10:16 PM
    >
    > > 1. I cannot find the “free Composer Studio” offer with XDS100v2. Do you have
    > > the good link?
    >
    > Sure: http://focus.ti.com/docs/toolsw/folders/print/ccstudio.html?DCMP=dsp_ccs_v4&HQS=Other+OT+ccs
    >
    > See “License Options” section: “Free: Use a full version of CCS which
    > limited to an XDS100 hardware emulator connection.”
    >
    > During the installation process you’ll be asked about license options.
    > Just select the one with XDS100 support.
    >
    > > 2. Can you still recommend a tutorial on OMAP3530 DSP programming, with
    > > examples…
    >
    > I’m afraid there is no good step-by-step tutorial for programming C64+
    > DSP for beginners (I didn’t find any) just tutorials for using DSPLink
    > and so one. :frowning: It’s not a very popular field of programming so you
    > have to search for information in books, forums, sources etc.
    >
    > > 3. All DSPLink/DSPBridge/DSP Gateway seem to be slightly immature and
    > > closed.
    > > Do you have a preference between them. My ARM-DSP connection will be
    > > very primitive.
    >
    > If your connection will be very primitive you don’t need DSPLink,
    > DSPBridge or DSP Gateway (it’s a good news). You can write your own
    > linux driver for communication between ARM and DSP (it’s a “bad” news
    > but I chose this way). :slight_smile: It’s not a very difficult task, you have to
    > implement ioctl (for setting shared memory regions, starting/stopping/
    > reseting DSP) and mmap (for mapping shared memory) functions, add new
    > chrdev, map some DSP’s registers, initialise DSP’s mmu, set DSP’s
    > entry point etc. After that you’ll be able to load and run DSP binary
    > from your linux. A good starting point for you is DSPLink sources.
    >
    > Have a Great New Year too! :slight_smile:
    >
    > Cheers,
    > Max.
    >
    > –
    > You received this message because you are subscribed to the Google Groups “Beagle Board” group.
    > To post to this group, send email to beagleboard@googlegroups.com.
    > To unsubscribe from this group, send email to beagleboard+unsubscribe@googlegroups.com.
    > For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

    |
12

Sorry if this was mentioned
http://processors.wiki.ti.com/index.php/Download_CCS

Release notes explain how to get permanent free license

CCSV5 has a linux install and supports XDS100V2 also for ARM9
but I think future releases wont be perm free

— On Wed, 12/29/10, Seppo Nikkilä seppo.nikkila@innovativeideas.fi wrote:


> From: Seppo Nikkilä seppo.nikkila@innovativeideas.fi
> Subject: Re: [beagleboard] Re: Flying start to OMAP3530 DSP software development?
> To: beagleboard@googlegroups.com
> Date: Wednesday, December 29, 2010, 4:20 PM
>
> Thank you VERY much Max,
> siñ
>
> On Wed, Dec 29, 2010 at 11:44 PM, Max Galemin maksim.galemin@gmail.com wrote:
>
> > > What is the best source for the DSP architecture and instruction set?
> >
> > http://www.ti.com/litv/pdf/spru732j
> >
> > > What is the best cross development tool for a Windows (sorry) PC?
> >
> > TI Code Composer Studio 4 (it’s free with XDS100v2 JTAG).
> >
> > > How does the Linux ARM processor and the DSP communicate?
> >
> > Using any shared memory. See DSPLink/DSPBridge/DSP Gateway for
> > details.
> >
> > > Does the DSP have full access to the DMAs, McBSPs, and timers while ARM runs
> > > Linux?
> >
> > Yes.
> >
> > > What should I keep in mind to avoid conflicts between the ARM and DSP?
> >
> > Synchronization.
> >
> > > What other resources do you recommend for a beginner?
> >
> > http://www.dsprelated.com/
> >
> > –
> > You received this message because you are subscribed to the Google Groups “Beagle Board” group.
> > To post to this group, send email to beagleboard@googlegroups.com.
> > To unsubscribe from this group, send email to beagleboard+unsubscribe@googlegroups.com.
> > For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.
>
> –
> Developing next generation wireless audio
>
> –
> You received this message because you are subscribed to the Google Groups “Beagle Board” group.
> To post to this group, send email to beagleboard@googlegroups.com.
> To unsubscribe from this group, send email to beagleboard+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/beagleboard?hl=en.

|

13

Hi Fellows,

And, again, thank you for valuable advice.

I think I should really tell you what I am trying to do.

I am trying to use ARM, DSP, four DMA channels and three timers with 12
linear buffers linked to a circular one to:

  1. Receive a 49.152 Mbit/s realtime 8- channel, 24-bit, 192 kS/s audio stream via McBSP3.
    This stream goes to the 12 buffers by two alternating DMA channels managed by ARM
    and clocked by the McBSP3 I2S LRCK clock signal. The active DMA will interrupt
    when the buffer is full and ARM (or maybe DSP) will flip the control to the other DMA.
  2. Once a buffer is filled, the DSP is started to do the FEC coding on the buffer.
    The DSP must also fill the header and trailer fields to form a valid 802.11 frame.
  3. Once about 6 KB of audio data is in the buffers, the transmission to the USB port
    can start.
  4. ARM will start a 640 microsecond timer and get ready to send a WLAN beacon frame
    as soon as the on-going WLAN frame ends. A 3 TU contention free period is requested.
  5. When the 640 microsecond timer goes off the WLAN frame transmission is triggered
    by the timer using the third DMA channel. The HS USB 2.0 is (mis)used as a 480 Mbit/s
    point-to-point link to the WLAN radio.
  6. When the transmission of the current buffer is done, the third DMA is switched to the fourth
    one and the outward transmission continues.
  7. Steps 1 - 6 are repeated in an infinite loop until ARM terminates them.

As you can see I want to use two alternating pairs of DMA to move data in and out, the DSP to do the error correcting encoding and frame header/trailer handling and the ARM to coordinate the whole process. Communication between these actors is by memory buffers, descriptors, and interrupts back and forth. The aim is to maximize the parallism for speed.
For the same reason the McBSP is tuned by increasing its domain voltage to reach 49.152 Mbit/s speed and USP is used in the point-to-point serial link. The two remaining timers are used to time the CF-End frame transmission and the timing of the inter-frame period.

So this is my very preliminary sketch of what I want to do. I haven’t checked the plan against the OMAP3530 and BeagleBoard documentation yet, so many important details are still obscure, sorry.

Hope you got an idea of what I am after and why I want to use the HW resources fully.

The above described process is in my transmitter. The reverse process with channel filteration and FEC processing happens in each of my eight receivers. The HW is C3 Beagleboards with my own expansion boards.

siñ

14

Sounds like you plan using a simple superloop no LInux on A8?

probally good for what you are doing and avoid the recipe for disaster mentioned earlier

Of Course this shift the burden to you to “lift all drivers” from elsewhere and get them working as well as devise the sharing mechanisms between DSP and A8

So you plan on using LEDS (-: or printf’s? to debug

I know you mentioned the XDS100V2

May I ask if this is personal project ?

Best wishes

15

Well, I am hoping to use the A8 Linux to do all the preparations - and maybe also
to tell me what is going on on the big scale. Then I will fire the DMAs and DSP with it
and let the interrupts and timers take care of the rest.

My project is half-personal, a proof-of-concept to my recent patents.

And yes, I will be using lots of RGB LED signaling on my expansion boards
(hopefully with yet another DMA) and printfs().
Later the RGB LED will be the “latest error indicator”.
And in this kind of work the XDS100V2 is a MUST.

Currently we have 4 audio channels working solely with A8 Linux, so we are not too far from our goal any more.

siñ