Slashdot Mirror
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.'"
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
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
Program Intellivision!
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
Program Intellivision!