• State Resolved
  • Locked Locked
  • Replies 7 replies
  • Subscribers 100 subscribers
  • Views 4237 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

McASP vs McBSP on AM1808

steve foster79764
Prodigy 230 points
Other Parts Discussed in Thread: PCM3168A

What is the difference between the McASP and McBSP in a few words? When should one be used over the other? Is the McBSP a subset of the McASP? Our application is to talk to a single I2S bus. No TDM, no parallelization.

Thanks

  • 0
    TI__Guru** 116170 points

    Please refer to Randy and Fawad`s responses here on this topic. It is on a different device but the discussion is on the same 2 peripherals.

    http://e2e.ti.com/support/dsp/tms320c6000_high_performance_dsps/f/115/t/171412.aspx

    Regards,

    Rahul

  • 0 in reply to Rahul Prabhu
    Prodigy 230 points

    I read that article before submitting this question, there is still not enough information to make a decision. They both do TDM and I2S by my reading. The article writes  “the A is for audio” but the B also does audio so what is the difference? Again is the McBSP a subset of the McASP? Please write down the differences and when one would be used instead of the other. Is there someone I can talk with instead of waiting a day later for an answer that may require another day to follow up?

  • 0
    TI__Guru*** 125430 points

    For a single I2S bus it doesn't really matter which you use.  Both peripherals can easily handle this use case.

    The McASP features many serializers, e.g. you could hook up multiple audio codecs to a single McASP.  In that scenario the clock and frame sync from the McASP would fan out to all the codecs.  Each codec would then connect to a unique data line/serializer.

    The McBSP is very similar to the McASP, but you have only a single data input and output.

    In the end, I think software is probably what I would use to make the decision.  In other words, if you have a driver (or previous experience) with one peripheral but not the other, then I would use that one.

  • 0 in reply to Brad Griffis
    Prodigy 230 points

    With the McASP many simple TDM incapable CODECs could be connected in parallel where as the McBSP could not do this. Since both interfaces can do TDM multiple TDM CODECs could be connected by both. Is the differentiator here is the support of many simple CODECs is possible by only the McASP?

    Thanks

    Steve

  • 0 in reply to steve foster79764
    TI__Guru*** 125430 points

    steve foster79764 said:
    Is the differentiator here is the support of many simple CODECs is possible by only the McASP?

    Yes.

  • 0 in reply to Brad Griffis
    TI__Guru 68920 points

    Probably a better example of the kind of CODEC that McASP is designed to interface with is:  http://www.ti.com/lit/ds/symlink/pcm3168a.pdf

    Other differences:

       - While you can increase the number of channels in a system through TDM on a single Tx/Rx pair, this also drives clock rates up.   That's not always good. The common alternative is to add data pins instead of increasing the clock rate, which is what McASP supports.

       - McBSP has integrated companding support which is generally a telecom feature.  The McASP doesn't include this block.

       - McASP has a mode where it transmits in S/PDIF format and includes an memory from which the information bits are pulled (an optional feature, so usually only 1 of the McASPs on each device implements this.)

       - McBSP doesn't have the same flexibility in clocking that McASP does.   For audio systems, you may want to upsample i.e. receive data at 48KHz but send it to the DAC at 192KHz.   It's a lot easier if the transmit and receive are synchronized if you do this, because then you don't have an asynchronous sample rate conversion problem.   The McASP allows for this case very easily, because it has separate dividers for the transmit and receive sections.   A single common master clock can be divided down to create 48KHz bit and lr clocks for receive but 192KHz bit and lr clocks for transmit.   Yet because of the single common clock source, the two will always stay in sync.

      - The McASP is a little more rigid in my experience with respect to data overrun and under-run conditions than McBSP.  I expect some people like this and some don't - the McASP will tend to enter an error state immediately on data underrun and transmit zeros (a hard mute), and also it has a MUTE output pin which can be used to drive an analog mute circuit.    I believe McBSP generally attempts to keep transmitting by repeating the last data word.   Additionally, the error status bits in McASP are 'sticky' so it's in my experience easier to find out that there was an error on McASP.   McBSP you have to catch in the act.

    Hope this helps further differentiate the two.

    Best Regards,

    Anthony

  • 0 in reply to Anthony F. Seely
    Prodigy 230 points

    Thanks Anthony and Brad, I now have enough info to make a choice