Arm & DSP test on Mistral EVM

Hi Kevin,

Are you running Linux on the ARM?  My recommendation would be first to start with the DVSDK for DM3730:

http://www.ti.com/tool/linuxdvsdk-dm37x

Besides the Linux board support package for the ARM, this comes with video codecs and "c6accel" that run on the DSP.  The purpose of c6accel was to take our DSPLIB for the 64x+ DSP core and make it callable directly from the ARM.  I recommend looking at some of the c6accel documentation to better understand how to use it:

http://processors.wiki.ti.com/index.php/Category:C6Accel

Learning to make your own DSP images is another level of difficulty, so if your end goal is to have efficient FFTs then I think C6accel is the best choice.

Brad

Thank you Brad,

No, I'm not running Linux, my plan is to run the TI DSP Bios (TI-RTOS).  I have read about the C6Accel.  Can I call that directly from ARM without running Linux?  The simple clock_OMAP3530_CortexA project is the proper level of simplicity for what I require for the main application.  I just need to effectively address the UARTs to report answers and use the DSP.

Thank you,

Kevin

Kevin Judge said:

No, I'm not running Linux, my plan is to run the TI DSP Bios (TI-RTOS).

When you say your plan is to use DSP/BIOS, are you referring to the DSP?  You can use DSP/BIOS on the DSP, but there is no ARM support in DSP/BIOS.  What OS will you use on the ARM?

Kevin Judge said:

I have read about the C6Accel.  Can I call that directly from ARM without running Linux? 

You would need to do a lot of work in order to call that from the ARM without Linux.  My goal was to try to enable that without doing all of that work.  To be up front, most of this software is not actively supported any more.  If you can leverage work that was already done then I can probably help you get things working.  If you decide to do your own implementation from scratch, then that's more than we're going to be able to support.  In that scenario we may want to suggest a contractor with expertise in this area to help you get it done.

Kevin Judge said:

The simple clock_OMAP3530_CortexA project is the proper level of simplicity for what I require for the main application.  I just need to effectively address the UARTs to report answers and use the DSP.

I don't recognize that project.  Where did it come from?  So is a UART driver and interaction with the DSP the main things you need to do on the ARM?

Thank you Brad,

Ok, the picture is getting clearer.  I was under the impression that TI-RTOS that was developed from SYS/BIOS or  DSP/BIOS was designed as an ARM  and/or DSP RTOS.  Is SYS/BIOSdifferent from DSP/BIOS?  I came down this path initially after watching a tutorial on TI RTOS that seemed prepared to address the SoC packages.

Yes, I am all for taking advantage of existing tools and avoiding a lot of the drudgery of starting from scratch.  I thought TI RTOS was such a vehicle, if not and Linux is the path, then I may have to consider that option, though Linux is much more than I need for this project.

I think the clock_OMAP3530_CortexA project installed as one of the examples in the CCS V6.  And yes, it looks like a good HAL layer has been implemented and as such the print strings should be directed to the UART(s) but it hasn't woked.  Can you help explain why?

Yes, the goal is to do a litte in the ARM and a lot in the DSP.  My goal was to use the ARM to drive some DSP FFTs and use the UART to display some answers.  But so far I am not able to address the DSP, and I'm surprised by the failure to get data out the UART.

Am I on the wrong track trying to use TI RTOS or Sys Bios.  Can you tell me how DSP Bios / Sys Bios / Ti RTOS relate?

Thank you,

DSP/BIOS (aka DSP/BIOS 5.x) is only for DSPs

SYS/BIOS (aka SYS/BIOS 6.x, aka "TI-RTOS kernel") is for ARM and DSP

TI-RTOS = kernel (i.e. SYS/BIOS) + file system + drivers

There's not full TI-RTOS support for OMAP3, i.e. you may get some basic Cortex A8 support, but I wouldn't expect it to understand chip-level details and interprocessor communication.  Those are the things that you'll get as "goodies" with the Linux DVSDK.  You'll have DSP Link for the interprocessor communication, Linux for chip level support (UART driver, etc.), and other niceties like c6accel for your processing.

Although the Linux DVSDK is perhaps overkill on the ARM, it will save you an immeasurable amount of time and effort with regard to all the nitty gritty details surrounding the ARM+DSP frameworks.  I highly recommend taking that path.

Brad

Thanks again Brad,

I need to operate as a very fast highpriority task (32 KHz).  Will this require that I write Linux Kernel drivers or will the Linux DVSDK provide all of the support I need to run at that rate?

So it sounds like TI-RTOS or SYS/BIOS would be the right tool if it supported the chip-level details and interprocessor communication.  And it does seem like TI is heading in that direction but today is the state of the art Linux + c6accel for applications that require ARM + DSP ?

Thank you,

Kevin

Kevin Judge said:

I need to operate as a very fast highpriority task (32 KHz).  Will this require that I write Linux Kernel drivers or will the Linux DVSDK provide all of the support I need to run at that rate?

Given the speed and capability of the Cortex A8 on DM3730, I don't think a 32 kHz rate should be an issue (given your earlier comments of the ARM not having to do all that much stuff).  I would expect a normal user space app should be able to keep up with things just fine.  So besides interacting with UARTs and FFTs, what else is it doing?

Kevin Judge said:

So it sounds like TI-RTOS or SYS/BIOS would be the right tool if it supported the chip-level details and interprocessor communication

Correct.

Kevin Judge said:

And it does seem like TI is heading in that direction but today is the state of the art Linux + c6accel for applications that require ARM + DSP ?

TI-RTOS is targeted mostly at MCUs.  For high performing processors (i.e. Cortex A* class) we are investing most of our development resources into Linux.

Thank you,

Besides the UART and FFT interaction it is dumping the output of the FFT to an off Chip device via parallel I/O that I expect to hand to a DMA so I think your assertion still holds. 

Any help on why that OMAP_Clock project isn't getting data out to the UART(s) ?

Thanks again,

Kevin

Kevin Judge said:

Besides the UART and FFT interaction it is dumping the output of the FFT to an off Chip device via parallel I/O that I expect to hand to a DMA so I think your assertion still holds. 

By "parallel I/O" are you referring to the GPMC interface?  Yes, this sounds like a relatively simple Linux application.  I don't think it should be an issue to get it done in real-time on the Cortex A8.

Kevin Judge said:

Any help on why that OMAP_Clock project isn't getting data out to the UART(s) ?

I tried to create a new project in CCS 6 to see what you're talking about, but I don't have that project.  I'm not sure exactly where it came from, i.e. must be something you installed on top of CCS?  My list of "usual suspects" for the issue you describe would include pin muxing and clock gating.  Unfortunately that's about as much help as I'll be able to give on that subject.  Bare metal programming is very support intensive and I don't want to go down that path...  Please stick to Linux and it will be much easier for me and others to help you.

Hi Brad,

I'm stepping in to see about using Linux.  The TI instructions for installing Ubuntu recommends V10.04 LTS.  Naturally the Ubuntu site recommends the 64 bit version of Version 14.10.  Is this standard desktop version ok as the host platform for the development tools or do I need to use 10.04 LTS?

Thank you,

Kevin