Texas Instruments Embedding Linux

darthcamaro writes "Looks like pretty soon Linux will truly become ubiquitous thanks to Texas Instruments new DaVinci System on a chip DSP. The new consumer electronics chip aimed at capturing the Digital Video market is powered by MontaVista Linux. 'TI understands that there is a larger number of Linux programmers than there are DSP programmers,' Huy Pham, DSP System-on-Chip product marketing manager at TI, told internetnews.com. 'What [DaVinci] does in partnership with MontaVista is enables the Linux developer to use the DSP without needing to understand the complexity of programming the DSP.'"

Comments

TI really need a QA dept

[phozz bare]

I do realize that this is slightly off topic, but remember that even the finest embedded system is worthless without a proper development environment. And TI's environment, named Code Composer Studio, has gone nothing but from bad to worse in the past few years.

TI really need to kick out their QA team, hire a new one, and get off their asses. I work with CCS 10 hours a day. After 2 weeks of working with the latest version (3.1) I had about 20 different things to complain about, and those are only the new bugs (the old ones tend to stay). I'm not talking about anything advanced - I just use the IDE for editing, compiling and debugging (breakpoints, etc) - I'm talking about usability annoyances, inexplicable slowdowns, crashes, Ctrl-F3 suddenly not working, things like that.

It is also not uncommon for basic Chip Support Library functions like DAT_copy (which initiates an EDMA memory transfer) to stop functioning with a new CSL release. QA, people, QA.

phozz

Re:TI really need a QA dept

[alexsh]

Not to mention that their RTS is buggy and doesn't handle C++ exceptions well. Debugging their RTS macaroni is no fun...

News?

[Tune]

This is great and all, I just don't see why this is front page news. I would consider ARM-DSP hardware with Linux support mainstream rather than a bold step taken by TI. A random grab from sponsored adds on google:
http://www.sandorlabs.com/
http://www.compulab.co.il/
http://www.plexxa.com/
http://www.atmel.com/products/AT91/
http://www.xbow.com/
http://www.lynuxworks.com/

All products seem to support Linux on ARM/XScale and (at least) some in combination with a DSP.
Sure, Texas instruments is a heavyweight in the embedded world, but is this just another clueless ScuttleMonkey post or did I miss something?

Not much help, but I come bearing a link!

[Mr Z]

Can't tell you much about the ARM side, though I will say the TI compiler tends to get high marks on code density and speed on the ARM. I'm sure you could write your ARM code with GCC. I don't know how the heterogeneous linking process works. Only other thing I know off-hand is that there is no flash. Silicon processes that support flash tend to not support high clock rate, and DaVinci can go real fast. :-) More at DaVinci's website.

Disclaimer: I work for TI and had a hand in the C64+ DSP that it includes, but I'm not a member of the DaVinci product team.

Too many companies...

[Mr Z]

Our compiler supports exceptions now? I've only ever used our C compiler and the linear assembly optimizer. I haven't really touched our C++ support.

All I can say is when you find bugs, send them in and get a bug number. The compiler team does track bugs, and they can't fix bugs they don't know about.

The IDE (Code Composer Studio) is not handled by the compiler team and I don't know if anyone on the compiler team uses it much, if at all. CCS is maintained in TI Toronto, last I knew. They too track bug reports. Unfortunately, though, they're under greater feature pressure than bug fix pressure. That makes it even more important to file bugs. Otherwise they'll never get the message. I'm probably not the only person who finds it a tad ironic that our integrated development environment is actually built out of parts by a handful of groups, at least a couple of which (TI Toronto, formerly Go DSP and TI Santa Barbara, formerly Spectron) used to be 3rd party companies. :-)

FWIW, I don't really use CCS myself either. These days I barely even use the compiler, though. The last time I used CCS seriously, I filed plenty of bugs against it. Our software tools team continues to evolve and I've seen some changes recently that I think will point CCS in a better direction. Here's hoping! (Since I am a TIer, I'm not sure how much I'm allowed to say, so sorry I haven't given more juicy details.)

--Joe

Re:DSP code can be easy to write ...

[Mr Z]

As long as you understand fixed-point arithmetic, it's not too bad to code from C either. I do recommend that you restrict-qualify pointers whenever possible and use some of the #pragma directives to let the compiler know about things like "I know this pointer is aligned to an 8-byte boundary" or "I know this loop goes around eleventy-billion times." Other compilers also benefit from this information, but given the extreme amounts of explicit parallelism and SIMD a DSP like the C64+ offers (up to 8 instructions per cycle, but more like 26 or more actual "operations"), you have much more to gain in DSP-space by giving the compiler this info. DSPs can't spend the transistors desktop CPUs do on dynamically scheduling all those operations at run-time.

Coding for the DSP is actually a lot like coding for MMX or SSE in some ways. (More like MMX when coding for C64x, since the DSPs are fixed point.) Just keep your data types sized appropriately, and in the case of TI DSPs, listen to the feedback from the compiler.

--Joe

Re:DSP is worthless IMHO

[Mechanik]

They are special purpose CPUs which do one thing well, implementing a fast filter. The trouble is, they really suck at branching and I/O servicing like protocol stack handling, decoding messages and state-machines.

You are entirely missing the point because that IS the point of the DSP. It is a lean, mean, number crunching machine, that crunches those numbers extremely fast and with low power consumption. If you need to control pretty GUIs on the device's LCD screen, use an ARM or somesuch. Better yet, use OMAP and get both.

You're not going to run a cellphone for days without charging if you try to use MIPS or powerpc. You will if you use an OMAP.

Re:At last

[jesup]

You're right - but this doesn't address that. DaVinci is a dual-core solution ala OMAP; you have an ARM running Linux and a DSP running DSP/BIOS on the same chip. Admittedly, with well-defined communication channels and "standard" TI XDIAS modules on the DSP you can mostly avoid doing real "DSP programming" - but then you're limited to using canned DSP algorithms or at most playing "building blocks" with them.

Not to say this isn't a nice setup - it is. Just don't assume it will remove the need to do traditional signal-processing coding.