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.
slow down there, switch to de-caff. :o)
Give it a chance to come out.
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!
Funny how fast something spreads through a market when it becomes the default choice?
Microsoft was able to get their OS into a position where it was the default choice for just about anything outside of mainframes or embedded devices.
Now Linux, or open source unix implementations to more accurate, have become the default choice for virtually all new computing devices. The only areas where companies are creating new Microsoft based devices are the result of Microsoft directly paying companies to use their products.
Things are just going to get worse for the "Microsoft is always teh winnah!" crowd. The old Microsoft dream of "Windows everywhere" from the late '90s is coming true - except they got the OS wrong.
The new world is Linux Everywhere(or open source unix implementation Everywhere if you want to be long winded and accurate).
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.
Is this just ignorance on the part of the salesperson, or is it MontaVista company policy?
If the latter then the folks at gpl-violations.org will probably be interested.
As a direct user of MontaVista software, you might like to inform them that you are currently assessing whether they are knowingly in violation of the GPL, or whether its an unfortunately and temporary mistake which can be corrected with remedial education of their salesforce.
Matlab will actually write the routines you need to implement filters. It doesn't just supply the coefficients, it actually gives you the code. Of course, you then have to supply the code to the IDE etc. etc.
Actually, DSPs can be byzantine. A DSP is capable of doing more than one instruction per clock cycle. Trying to optimize code by hand is almost impossible. (I'm thinking of an older Sharc which could do nine things at once. I'm sure it's gotten worse.) The IDE does a much better job of optimizing the code than even skilled programmers.
We could be going to a situation where nobody outside the manufacturer writes actual code for DSPs. Everyone else will program on a simplified layer like Matlab or the one mentioned by Pham.
YES!!!! I've always wanted to run linux.....on a calculator....er...whats the point? I mean, there's no drives, no wifi, no ports, nothing! TI, you can take your calculators with linux on them and go home!
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
FYI: MontaVista is what NetGear uses in the WG302 Wireless Access Point
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!
Am I the only one who, when reading the specs on the website, gets the feeling that the "Amiga-setup" might be coming back in style? :)
If he could ever write something that was historically accurate then maybe. But I'm sure that this whole business of Linux and TI teaming up on DaVinci no doubtedly has something to do with all this and I'm sure it will finally tie that Merovingian bloodline to Jesus once and for all!!
Greg Duffield
ACS Data Recovery
www.acsdata.com
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?
This is just for TI's DSP (Digital Signal Processor) chips (i.e. the kind you'd find in sound systems, and TVs). TI calculators, ironically enough, use Motorola CPUs, with some kind of proprietary assembly language.
Besides, I don't think there's enough RAM to run Linux. NetBSD maybe, but not Linux.
We all know what to do, but we don't know how to get re-elected once we have done it
It would be great to see TI calculators grow up into full featured palmtops.
With what we are seeing what can be done on Cell phones and laptops,
TI is overdue for boosting the abilities in it's products.
When I first saw the Samsung i730
I thought that T.I. could be doing products like that.
A full color screen, retractable QWERTY keyboard, ability to do calculations, email, music, and video.
Every iPod and Palm device in the world could have been a T.I. product!
If only Texas Instruments would wake up from behind the wheel and start driving their company into new market spaces.
unsubscribe
Infuriate left and right
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
You use a DSP for what it is good at. You use it because nothing else will do the job. There are many applications for DSPs. As the grandparent states or implies, you can do DSP tasks on any processor. I've even done simple filtering using a PIC. When you need a DSP to do a DSP's job is really obvious though. You'll know it when it hits you in the face and you can't do the job any other way.
I'd love it if we put more people on our tools teams. I know I raise that point whenever I can here at work. TI is a silicon company first, though, so that's where they tend to put their money first. Like I said, I've seen some internal organizational shifts that I hope also signal a change in attitude towards tools investment. That's about all I can say, though.
:-)
I'm not trying to be an apologist. When I speak here, it's for me, not the company. I can say generically, though, that internal customers can sometimes be as frustrated as external customers.
Program Intellivision!
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!
There's also the chance to write apps to a Linux API on an FPGA. I'd love to see one of those MicroBlaze/uCLinux chips interfaced directly with one of these TI DSP/MVLinux chips, running multiprocessors. You can even put multiple MB/uCL instances on a single FPGA, with gates to spare. Which are gates that can be used to solve multiproc problems in ways unavailable to fixed-config chips like x86, PPC, or even the TI DSP. How about a Beowulf cluster in gates of these...
--
make install -not war
The problem with OMAP and a lot of other TI stuff is that they either flat out say they won't support small developers (what, you only want 1000 units? don't waste my time) or they put really large prices on things like mpeg encoder libraries ($25K - just so we don't have to deal with the little guys who can't pony up). Other vendors do a much better job of supporting the little guys.
-- All that's left of me, is slight insanity, whats on the right, I don't know. -- Bob Mould
Check out their list of TI platforms: http://www.cadenux.com/bsp/
...would be putting linux on their calculators. I can't imagaine how nice it would be to be able to code in C, Perl, or Python, or even just use a shell on my Ti-84
I am Spartacus
Of course, with embedded VMware!
J
Is TI doing anything to work with the dspgateway project? It's already giving linux on OMAP access to the dsp.
a ge=What_Is
http://dspgateway.sourceforge.net/pub/index.php?P
This is how the Nokia 770 makes use of the dsp, so there may even start to be more mainstream interest. (The Nokia 770 is a linux platform running on a TI OMAP 1710)
Hello,
I don't think TI did anything which hasn't already been done. I work at Sigma Designs and we have developed several DSP chipsets which run Linux. We use ARM/MIPS as host and DSP for video/audio decoding. Our chips are used in Set-top boxes and Digital Media Players. We have been one of the leaders in this field for over five years.
Check out http://www.sigmadesigns.com/
Thank you,
Michael Uman
Sr. Software Engineer, System tools
Sigma Designs
Michael A. Uman
Sr Software Engineer
softwaremagic.net
The biggest obstactle to the adoption of DSP computing has been price to entry. A modern compiler for a TI series DSP is thousands of dollars. That buys a lot of commodity hardware to hack on.
If they're going to keep the development toolchain open, this could be a very potent package indeed. Part of me doubts that is going to happen, given the nature of the business.
..don't panic
Would you prefer TI taking another decade and half to fix the Bugs ??
Or will it not be better to outsource the job to Bangalore where Graduate
Engineer are working at rate of domestic workers so that TI can hire them by dozen and fix the bug in months ???
Now I have to retract my well thought out and logical conspiracy theory. My years of serious debate and research ruined by this fact that I overlooked!
Hi Folks, For those who are still interested, here is it in linuxdevices http://www.linuxdevices.com/news/NS9968931411.html