• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 98 subscribers
  • Views 139 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.

Is Linux a necessity on the OMAP3530 when using the CODEC?

Tom Smith
Expert 2930 points
Other Parts Discussed in Thread: OMAP3530, DM3730

Not being Linux expert, in using the OMAP3530 we would like to simplify the design by NOT using Linux. The design is really straightforward. The ARM processor has to handle the user interface and control the receiver functions. The DSP has to do the CODEC and also allow for future operational enhancements. We don't need Linux to run the ARM code, and I'm not sure we need it for any of the DSP stuff beside the CODEC (MPEG4 encode).

Could you provide suggestions / guidance on our options for this design? Would C6EZACCEL software be a good tool for this design? Is the MPEG4 encode part of the OpenCV + VLIB's, see attachment.

6014.OpenCV_on_TIs_DSP+ARM_spry175.pdf

-Tom-

  • 0
    TI__Guru*** 125430 points

    Tom Smith said:
    Not being Linux expert, in using the OMAP3530 we would like to simplify the design by NOT using Linux.

    First off, you should use the DM3730 rather than the OMAP3530.  It's basically a die shrink (cheaper, faster, lower power).  Keep in mind that Linux provides a lot of underlying critical code.  Personally I recommend that you use Linux but use a commercial Linux provider.

    Tom Smith said:
    The ARM processor has to handle the user interface and control the receiver functions.

    • Who will write display subsystem drivers?
    • What kind of "receiver"?  If there's any peripherals involved (UART, ethernet, etc.) you will have to write those drivers too.
    • What about the interface?  There's a lot of value in using something like Qt for building and running a GUI.  We provide examples in our SDK too.

    Tom Smith said:
    The DSP has to do the CODEC and also allow for future operational enhancements.

    • Surrounding the codec is a lot of work in terms of understanding how to instantiate XDAIS algorithms, share scratch memory, share DMA resources, etc.
    • There's also a lot more "smarts" than just the codec.  The codecs supplied by TI can encode/decode elementary bitstreams.  You need higher level software to do things like understand container formats (i.e. for reading/writing standard files like *.mp4).  The higher level software would also be responsible for things like A/V sync.  This is where Linux projects like gstreamer enter the picture.

    Tom Smith said:
    Could you provide suggestions / guidance on our options for this design? Would C6EZACCEL software be a good tool for this design? Is the MPEG4 encode part of the OpenCV + VLIB's, see attachment

    MPEG4 codec is not part of C6EZACCEL.  In any case, C6EZACCEL is intended to plug into our Linux SDK.

    While on the surface this project might not seem all that complex, there are a lot of complexities in the codecs and the underlying SoC that will justify Linux many times over.  Customers that are not experts should get some training and subscribe to a commercial provider for support.