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.'"
Will it run, um, er, Windows?
A house divided against itself cannot stand.
DaVinci and MontaVista (Mona Lisa)? More than a coincidence in the naming there?
I think we need to get Dan Brown to write a book about this obvious conspiracy - "The DaVinci Source Code".
As a veteran of digital signal processing I believe this is a major step forward. The roots of DSP are different from traditional Von Neumann computing and yet there is some overlap. For 50 years we have basically had two streams of thinking, two paradigms to cope with. Algorithms for filters, impulse systems, convolution, table mapping, oscilators
and so forth have a mathematical basis that generally incorporates time implicitly although at the most basic level they are matrix computations. Expressing these in orthodox code can be frustrating, counterintuitive and inefficient. For example compare side by side the solutions to an audio filter written in Nyquist (scheme), vanilla C code, 56 series DSP
assembly or as a process flow in Max/PureData. They are barely recognisable as the same equation and converting between one paradigm and another (say functional to procedural) is so difficult one may as well start from scratch with the original equation. The idea of microcode/silicon instruction sets combined with the abstraction of a familiar kernel and realtime operating system as the starting point is going to be immensely empowering for the next generation of DSP programmers. Indeed I expect that in 10 years time we will no longer consider the two as distinct disciplines at all.
The next step in microprocessor evolution is, in accordance with the 'great wheel', for these entire architectures and their instruction sets to be incorporated back into the mainstream CPU core along with language constructs for dealing with them, such that one day it will be no more unusual express a closed form cosine sum than it is to write a for loop today.
"..is an upper class neighborhood..." http://en.wikipedia.org/wiki/Monta_Vista
Purple, because ice cream has no bones.
Gee, maybe you should go to the manufacturer's site for that kind of detail, instead of whining that a news article didn't publish tech specs.
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
MontaVista isn't going to get anywhere if they continue to insist on charging $18,000 USD a seat for 'gcc'. An embedded project I'm on comes with a Montavista runtime license. When I asked for the kernel source, the hardware vendor said they were legally bound by MontaVista not to give out the kernel source and to talk to MV. When I asked MV for the source, the salesperson tried to tell me that required a special source license that I had to pay for. I think someone in 'sales' doesn't understand the concept of a license. We've since chosen to just dump MV. I think TI would probably be better off just coming up with their own distro.
It's going to be great -- it'll do square roots, cube roots, nth roots, and root.
I too have felt the cold finger of injustice.
Analog Devices makes a family of DSP called the Blackfin that runs uClinux. We've been using a development board for well over a year. If this is TI's first linux offering, I'd say they're late to the party. Maybe it was hard to port Linux because sizeof(char) was 2. (If you've ever used a 16-bit TI DSP... :)
Please help find my missing daughter: FindSabrina.org
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!