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".
From TFA:
"There have definitely been a few GPL legal issues and even TI had to work through some of these," Pham said. "TI does have a proprietary processor communication between the ARM and the DSP. We do need to keep that separate from the Linux side."
Pham noted that TI provides its customer with support and some legal advice to keep things separate.
"Yes it's a complication and yes some customers have some issues with it and some questions with it," Pham said. "But in general, it hasn't been so much as an issue as it has been questions."
A house divided against itself cannot stand.
"Pham noted that the response time of the latest MontaVista Linux is 'tremendous.'"
I wonder what they were using prior to MontaVista, just plain old Vista?
Join the Slashcott! Feb 10 thru Feb 17!
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.
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?
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.
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.
Program Intellivision!
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!
Now I can run Linux on my TI-99/4A!
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!
I am a systems engineering and have had the misfortune of working with DSP chips. 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. They don't seem to spend much time doing the filtering, but spend an inordinate amount of time in the less glamorous housekeeping section.
Give me a decent MIPS or powerpc. So what if it takes twice as long to run the filter; you don't spend most of your time in the filter. And now running linux, this will be even more accentuated. What a loser idea.
They get used around here because if it's a DSP, the hardware guys get to write the software instead of the software guys. It has nothing to do with price or what is the best technical solution. It is a turf war and reaction against software guys who might not understand what they are coding.
It is also a bit of domain crossing pain avoidance. The slowdown of writing specs (which look like code) and they having someone else type it, get it wrong, another rev of specs spelling it out in even more excruciating detail &c.
TI wants to push its crappy DSP because they are getting ousted by power and arm processors.
Yoghurt
It's all well and good for TI to benefit from the open source community. But TI still refuses to publish their WiFi information for open source driver developers.
In 2001, TI (Texas Instruments) decided to make a big push on the 802.11 market. ... From the start, TI has refused to give any help towards a Linux driver and have decided to totally ignore the Linux community.
Sure it's all great to see some more uptake of Linux, but beware that TI has not shown itself to be a great friend in the past.
Anybody want a peanut?
You are wrong.
Please read the ellided GPL pieces below (or read a copy of the GPL). We do not mention what constitutes a derived work here, but the rights and obligations are clear. You would be wrong -- source rights extend to any 3rd party, or include full source which is then again distributable.
Ratboy
" if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights."
" You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License."
" You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) "
Just another "Cubible(sic) Joe" 2 17 3061
Yeah, that does suck that DAT_copy got broken. I worked with the guys that defined it initially. I do remember there was an integer-wrapping problem that broke it for a little while years ago (C6211 days), but I didn't think that escaped the lab.
The ownership of that code's shifted around a few times. That's more reflective of our internal organizational structure than anything else. The DSP software applications teams have changed shape a couple times since I was last a member of that group. These days I'm on an architecture team, so I'm kinda out of touch with how they're shaped specifically today.
--Joe
Program Intellivision!
I'm sure it's just ignorance on the part of the salesidiot... In another matter, I asked a simple "yes/no" question which resulted in a 3 day scheduling negotiation to speak with one of their lead engineers. Once we got the conference call going, I was asked to pose my question. I posed it and the lead engineer said "err, Yes" with a barely detectable tone that said "I'm going to kill this salesperson". In the end; MV was far more expensive. $18k USD a seat for GCC plus $5k/year for business-hours support, maximum 5 'incidents'. 2 days of effort produced for me a fully functional cross-compile toolchain on which I was able to develop a prototype of our production product as proof of concept. So we punted on MV. We're not idiots. We can support our own toolchain. I suspect most embedded software shops have people who possess reasonable clue and don't need someone like MV to hoover money out of their wallets to answer gcc questions. Non-clueful people are probably not doing embedded software. So just who is MV's target audience? PHB's.