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.'"
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.
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
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?
I too work with CCS all day long, and yes it's a real pain. I just
use it as a C compiler, and don't hit all the complex features, nor
do I use their CSL library. I have also noticed that some of their
side tools, like the flash-ram utility, don't always work first time...
My big complaint is their silicon -- why wasn't EDMA designed so
that you could easily stream chunky (non-uniform block size) data
from the MCBSP into memory? I have a work-around, but it is seriously
ugly...
Also, would it have killed them to give me some GPIO pins? And
why the heck did they have to change the pinout between REV B
and C of the C6711, leaving me stuck with the older processor
until the powers that be approve doing a new board?
I'm also still annoyed that their entire DSP support department all
went to a convention at the same time, leaving me without support
during a critical week.
I can say that I've NEVER seen a compiler bug, which is impressive,
especially given the tricky parallel instruction execution that goes
on.
For my current project I've switched to Xilinx and Microblaze, and
I've been told they do a better job with their tools.
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!