Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Linux Business Software

Texas Instruments Embedding Linux 128

Posted by ScuttleMonkey from the right-tool-for-the-job dept.
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.'"
This discussion has been archived. No new comments can be posted.

Texas Instruments Embedding Linux More

Texas Instruments Embedding Linux

Comments Filter:

  • But... (Score:4, Funny)

    by pedestrian crossing ( 802349 ) on Tuesday December 06, 2005 @07:31AM (#14192593) Homepage Journal
    Will it run, um, er, Windows?

    • Re:But... (Score:2, Informative)

      by andydread ( 758754 )
      If you get Xen up and running then it will run windows but veeery slooowly maybe vmware will do a better job. Then again if there is any virtualization support in the Ti DSP then Xen should fly on this device.

    • Re:But... (Score:1, Funny)

      by Anonymous Coward
      No, no, no. The proper cliche is "I'd like to see a beowulf cluster of these things."
    • Will it run, um, er, Windows?

      As soon as it is ported to TI's DSP chips.

      Do the world a favor and hold your breath until that happens. ;)
    • Of course, with embedded VMware!

  • Perfect partnership or conspiracy? (Score:5, Funny)

    by mrRay720 ( 874710 ) on Tuesday December 06, 2005 @07:35AM (#14192604)
    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".
    • Yes, the Knights of the Templar hatched a plot with Emperor Constantine and put the clues to their scheme in a microchip. They've been waiting a while for the technology to be available.
    • Bet you never knew that TI actually stood for The Illuminati
      • That explains all the hooded men with torches walking in and out of dimly lit meeting rooms at work. (I work there and actually had a hand in DaVinci's DSP.) Wait a minute, that means I have parts of DaVinci's code on my hard drive. *looks around suspiciously* Maybe I'll call in sick today.
    • 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".

      I always thought programming was an art... but lately (DaVinci, Picassa, et al.) it seems like they finally are marketting it that way.
      My logic for the fact that is an art is: A science is meant to understand a phenomom or a set of phenomena, where as an art is about creation of something. Programming thus falls
      • from tfa:

        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.

        they just turned art into crap. if you dont understand what you are doing, you will end up developing ms outlook or inter(pr0n)net explorer. full of new pronish features and exploits.
      • A science is meant to understand a phenomom or a set of phenomena, where as an art is about creation of something. Programming thus falls to the art class?

        Sure. But "art" is very broad. Creation of "art" happens irrespective of a functional purpose. The creation need not acccomplish a task. The purpose of the creation may simply be "to exist", where no such thing existed before.

        I think a more appropriate term for programming would be "engineering". Engineering is a process of creation (and so can proba
    • 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!!
    • Hang on, Monta Vista means Montain View in spanish.

  • In case you were wondering (Score:3, Informative)

    by pedestrian crossing ( 802349 ) on Tuesday December 06, 2005 @07:36AM (#14192609) Homepage Journal

    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."

  • tremendous response time (Score:3, Funny)

    by sl4shd0rk ( 755837 ) on Tuesday December 06, 2005 @07:37AM (#14192613)
    "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?

  • At last (Score:5, Insightful)

    by Anonymous Coward on Tuesday December 06, 2005 @07:48AM (#14192645)
    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.

    • Re:At last (Score:4, Informative)

      by jesup ( 8690 ) * <{randellslashdot} {at} {jesup.org}> on Tuesday December 06, 2005 @09:56AM (#14193296) Homepage
      You're right - but this doesn't address that. DaVinci is a dual-core solution ala OMAP; you have an ARM running Linux and a DSP running DSP/BIOS on the same chip. Admittedly, with well-defined communication channels and "standard" TI XDIAS modules on the DSP you can mostly avoid doing real "DSP programming" - but then you're limited to using canned DSP algorithms or at most playing "building blocks" with them.

      Not to say this isn't a nice setup - it is. Just don't assume it will remove the need to do traditional signal-processing coding.
      • 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.
    • it seems like a step in the right direction.

      I think all MCU and DSP manufacturers should do something like this. At work, I write firmware and it seems that I spend too much time reinventing the wheel and wasting time over timing etc instead of spending most of my time writing functionality.
      Right now its not practical for us to put any available embedded Linux OS into our MCU because of the huge space requirement, and there is a lot of functionality on embedded Linux OS's that we don't need. Yes 4MB is a lo

  • Monta Vista... (Score:5, Funny)

    by jollyroger1210 ( 933226 ) <jollyroger1210 AT gmail DOT com> on Tuesday December 06, 2005 @07:50AM (#14192652) Homepage Journal
    "..is an upper class neighborhood..." http://en.wikipedia.org/wiki/Monta_Vista [wikipedia.org]

  • TI really need a QA dept (Score:5, Informative)

    by phozz bare ( 720522 ) on Tuesday December 06, 2005 @08:02AM (#14192684)
    I do realize that this is slightly off topic, but remember that even the finest embedded system is worthless without a proper development environment. And TI's environment, named Code Composer Studio, has gone nothing but from bad to worse in the past few years.

    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

    • Not to mention that their RTS is buggy and doesn't handle C++ exceptions well. Debugging their RTS macaroni is no fun...

      • Too many companies... (Score:5, Informative)

        by Mr Z ( 6791 ) on Tuesday December 06, 2005 @08:37AM (#14192804) Homepage Journal
        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
        • The C++ compiler supports templates as well. How well and how efficiently - those are other questions I haven't answered, but as far as I've tested they work.

          Breaking DAT_copy() was a real "oops". How in the world did that ever escape...

          It's really annoying how looking at certain things (stats windows, CPU use, etc) slows down all future JTAG operations including loading code, dramatically, until you quit and restart.

          The IDE/JTAG losing communication with the CPU - this happens way too often if the DSP i

          • DAT_copy (Score:2, Interesting)

            by Mr Z ( 6791 )
            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 d
    • 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
    • Code Composer was known "affectionately" as Code DeComposer by our developers when we were using it a while back (several years ago). Hopefully it's improved since then!
    • Seriously, Code Composer Studio is truly one of the worst pieces of software I've ever used. When using a JTAG debugger on the parallel port, does it have to continually poll the paraport while I'm not debugging or transferring code (that is, 99% of the time), and in the process slowing my high end workstation down to a painful crawl? Is it still the case that you need two separate versions of CCS running at the same time if you're using both cores on an OMAP? I hope they fixed that one. And heaven forb
      • When using a JTAG debugger on the parallel port, does it have to continually poll the paraport while I'm not debugging or transferring code (that is, 99% of the time), and in the process slowing my high end workstation down to a painful crawl?

        From what I've heard that's an intentional "feature". The Development Starter Kit (DSK) version of CCStudio is locked to the hardware you purchased along with it. It's sold at a reduced price, and you can't run the app without the hardware connected. It keeps ch
      • As a TI support engineer, I can assure you that we do track issues that are submitted and work to research and resolve all issues that our customers submit to us, provided that we have the required information, files and details to do so. We take our customers and their concerns very seriously and we continuously strive to make our products and processes better. Our QA and development teams work very hard to make Code Composer Studio the best in the industry that meets the needs of all our customers.

        Regardi
        • Did you make this account especially for me? I'm touched.

          Honestly, the CCS issues are not my primary concerns with TI. All other things being on par with other firms, I could live with it (though I'd be cursing TI daily), and I imagine it's improved somewhat since we started with it. But I've seen too many projects burned by poor Texas Instruments support to ever think of trying it again.

          I remember going to a DSC124(?) training class some years back (back when the chip was new). The instructor could not
    • i'm curious, how many qa personell do you think would be required to test a complex product, especially if there are combinations of supported devices and OSs?

  • free software is expensive. (Score:5, Interesting)

    by nblender ( 741424 ) on Tuesday December 06, 2005 @08:04AM (#14192691)
    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.
    • 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.

      Um. That sucks. If Montavista is a Linux distribution... someone here's breaking the law. Violating thousands of people's copyrights. They've sold you the binaries,

      • I would assume that when he says "kernel" he is not referring to the Linux Kernel but rather Monta Vista's and perhaps one of their board support packages. So I doubt any copyright has been violated... just a few people miss understanding each other. On the otherhand Monta Vista can be a little pricy...

        • Re:free software is expensive. (Score:1, Informative)

          by Anonymous Coward
          MontaVista's kernel is the Linux kernel, with their modifications (and others' modifications) on top of it - which is GPL-ed. So if a customer requests the source, they must jump and provide it ...
          • With my limited understanding of the GPL (IANAL), I believe that a vendor can charge what he/she wants for the binary version of the software, and is then obligated to provide the source (to that same person) at a nominal additional cost. The GPL only requires providing the source to those parties that receive the binaries. The customer, however, has no obligation (under the GPL) to keep the source code secret, and can redistribute the code at any cost (including none) to other parties. If MV adds an add
            • With my limited understanding of the GPL (IANAL), I believe that a vendor can charge what he/she wants for the binary version of the software, and is then obligated to provide the source (to that same person) at a nominal additional cost. The GPL only requires providing the source to those parties that receive the binaries.

              Very well. The OP was developing an embedded system based on this Linux-derived kernel. He needed the source code. Montevista tried to charge him a great deal of money for a 'source lic

            • So Much Bullshit! (Score:3, Informative)

              by ratboy666 ( 104074 )
              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. A
              • And how does this explain the parent wrong? It appears to me that the parent loosely described pretty much the same thing.
              • Well, I certainly won't claim that I am absolutely right. However, from the GPL FAQ [gnu.org]:

                If I distribute GPL'd software for a fee, am I required to also make it available to the public without a charge?

                No. However, if someone pays your fee and gets a copy, the GPL gives them the freedom to release it to the public, with or without a fee. For example, someone could pay your fee, and then put her copy on a web site for the general public.

                That seems pretty clear, but I couldn't have told you that from reading the a

            • With my limited understanding of the GPL (IANAL), I believe that a vendor can charge what he/she wants for the binary version of the software, and is then obligated to provide the source (to that same person) at a nominal additional cost. The GPL only requires providing the source to those parties that receive the binaries.

              This is now getting rather far-afield from the original, since all other evidence points to MV being a very good GPL-abiding corporation. (I suspect, as do others, that some wires got cr

      • Re:free software is expensive. (Score:2, Interesting)

        by Anonymous Coward
        Numerous companies do this sort of thing, sadly. Hauppauge, Liteon, Cadenux, Tritton Technologies, MacSense, Compex, Inventel and Sweex all either sell modified Linux sources at high prices or use modified Linux kernels in their products without releasing source.

        Probably the reason why SCO made their crazy argument that the GPL is somehow invalid is that these breaches of copyright law are not adequately followed up and prosecuted, presumably due to lack of time and money.

    • MontaVista in violation of the GPL? (Score:1, Informative)

      by Anonymous Coward
      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 c
      • 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 suppo
    • FYI: MontaVista is what NetGear uses in the WG302 Wireless Access Point

    • MontaVista isn't going to get anywhere if they continue to insist on charging $18,000 USD a seat for 'gcc'.

      To be fair, thats a little daft - they already have got somewhere charging 18k a seat.

      I think TI would probably be better off just coming up with their own distro.

      Well they have. There's a mailing list [omap.com] (but it's currently unused!) and a nod on TI's DaVinci webpage [slashdot.org] to the fact there's going to be an open source distro as there is for the OMAP boards. There's no real content there at the moment, but ther

  • News? (Score:3, Informative)

    by Tune ( 17738 ) on Tuesday December 06, 2005 @08:08AM (#14192701)
    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/ [sandorlabs.com]
    http://www.compulab.co.il/ [compulab.co.il]
    http://www.plexxa.com/ [plexxa.com]
    http://www.atmel.com/products/AT91/ [atmel.com]
    http://www.xbow.com/ [xbow.com]
    http://www.lynuxworks.com/ [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?
    • You don't consider a major player in the industry adopting Linux support for its DSP's to be newsworthy? Interesting. Its certainly more interesting than articles posted about this or that new Distribution Du Jour.
      • This is not even new to TI. They've had Linux support for their chips for years. I went to a TI OMAP event 4 years ago and they were pitching Linux on their OMAP chips. At the time they handed off Linux support to a third party called RidgeRun. RR went out of business as far as I know. The TI reps at one point were trying to get my company to be their Linux support provider. Nowadays it's MonteVista doing the TI Linux. The only thing that means is that their board support packages are going to be eve

    • Sure, Texas instruments is a heavyweight in the embedded world, but is this just another clueless ScuttleMonkey post or did I miss something?

      A few things, yes.

      First, that this resembles TI's OMAP chips ... found in quite a lot of cell phones. In some ways DaVinci is nicer to work with since it's cleaner internally (fewer busses, bridges, clock domains) and externally (pin muxing is a nightmare on OMAP). You might say that the reason the ARM/DSP/Linux combo is now mainstream has a lot to do with prec

  • Can't wait for the TI calculator. (Score:5, Funny)

    by Ph33r th3 g(O)at ( 592622 ) on Tuesday December 06, 2005 @08:14AM (#14192710)
    It's going to be great -- it'll do square roots, cube roots, nth roots, and root.

  • Blackfin? (Score:5, Interesting)

    by GregAllen ( 178208 ) on Tuesday December 06, 2005 @08:31AM (#14192781) Homepage
    Analog Devices makes a family of DSP called the Blackfin [analog.com] that runs uClinux [uclinux.org]. 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... :)
    • Was sizeof(char) really 2, or was it just that char was 16 bits? Either way, I'm pretty sure that was a C54x thing. That doesn't apply to the C64+ DSP on DaVinci, that much I can tell you.

      People have been running various forms of Linux on our DSPs and ARMs prior to this. I think the real news is that TI's embracing it this time rather than saying "Ok, do as you will" and otherwise ignoring them.

      --Joe
    • There are couple other Linux's available for the C6000 series of TI DSPs (SoftTier, etc), though not from TI.
    • Was sizeof(char) really 2, or was it just that char was 16 bits?
      C54x bytes and words are equivalent (16 bits)." So sizeof (char) on a 16 bit DSP is 1, not 2.

      I stand corrected -- sizeof(char) was 1, but a char was 16 bits. That's equally confounding, and exactly my point. :)
    • 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.

      No, they've been providing Linux on the OMAP (dual core ARM9+C55) for at least a couple of years in both Open Source and Montavista flavours.

      ~Pev

  • This is great! (Score:3, Funny)

    by British ( 51765 ) <british1500@gmail.com> on Tuesday December 06, 2005 @08:38AM (#14192809) Homepage Journal
    Now I can run Linux on my TI-99/4A!

    • 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.

      • Excuse me, but I assume from your comment that you think a TI 99/4A is a calculator... it is not, it is in fact one of the first (if not the first) 16-bit home computers. We are back in the Sinclair ZX Spectrum and Commodore 64 days and it is before Commodore Amiga and Atari ST.
        Some specs can be found here TI 99/4A [old-computers.com]
  • 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? :)

    • Nah... the DSP on there is a C64+. Maybe our next DSP will be the C68x-family... ;-)

      (And no, I wasn't the only one who chuckled when we brought out the C64 DSP family...)

      • I think the poster was referring to it being Amiga-like in terms of "GP CPU plus coprocessors for sound/video/etc". And in a way, it is. The coprocessor core (DSP) is more general-purpose, and it's all on a chip instead of as a system, but the general idea of specialization is there. It is a bit stretched, though.

        The C64 name is a bit amusing. Even C65 would be - the Commodore C65 actually existed, and after bankruptcy about the about 100-200 C65's escaped into the wild. 4?MHz 6502 (we had 10MHz 6502s
        • Oh, I realize the SoC architecture of DaVinci does evoke some of the same distributed compute concepts as Amiga's "three sisters." I was attempting to make a lame joke, as Commodore refused to kill the C64 and push the Amiga (here in the states, at least) and in the end the whole company became irrelevant...

  • DSP is worthless IMHO (Score:2, Interesting)

    by yoghurt ( 2090 )
    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 ru
    • Apparently you don't know much about OMAP. The processor with which this article is referring is a combination of an ARM and a DSP in a single package.

    • TI wants to push its crappy DSP because they are getting ousted by power and arm processors.

      But what I got from the article (reads like a press release, actually) is that it is designed to interface with arm, so they are using the DSP for what the DSP is good for (filter) and using a generic processor for the rest...

    • I big thing with this is that there are 2 CPU cores on the one die. There is an ARM9 processor and a TI C64x DSP core. Think AMP (Asymentric Multi Processing) with the DaVinci stuff for now.

      This allows the processor that is good at branching and control code to execute that and the DSP to execute the filters that it is good at.

    • Re:DSP is worthless IMHO (Score:4, Informative)

      by Mechanik ( 104328 ) on Tuesday December 06, 2005 @09:43AM (#14193200) Homepage
      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.

      You are entirely missing the point because that IS the point of the DSP. It is a lean, mean, number crunching machine, that crunches those numbers extremely fast and with low power consumption. If you need to control pretty GUIs on the device's LCD screen, use an ARM or somesuch. Better yet, use OMAP and get both.

      You're not going to run a cellphone for days without charging if you try to use MIPS or powerpc. You will if you use an OMAP.

    • It's my impression that DSPs are "special purpose" processors designed to be really good at real-time digital signal processing. Nothing more, nothing less. ARMs, MIPSs, and PowerPCs are more general microprocessors and should be used as such. I can only imagine the extent of your woes if you were using a DSP as your core processor (though some people do).

      I've had a pretty good experience with TI's DSP as we have prototyped a fiber-optic communication device a few years back. I wish TI had embedded L
    • actually this product sounds like it'd be perfect for your situation. the ARM can handle all of the "housekeeping" thats taking so long and you can have a real software guy write that code while the hardware guys can focus on the filtering on the DSP chip. if not, PPCs are being used to run DSP code nowadays using Altivec libraries. although, if your software guys have trouble coding DSP software, it won't matter if it runs on a DSP chip or a general purpose chip and you'll still have the hardware guys t
    • Oh wow, really! Try decoding a h.264 main profile stream on Mips or powerPC and then talk about how useless DSPs are. You seem to be doing mainly control software with little or no signal processing, so using a RISC core may seem like a good idea to you. Try some real signal processing to learn about why one needs special purpose engines like DSPs.

  • Hypocritical (Score:4, Interesting)

    by FrankDrebin ( 238464 ) on Tuesday December 06, 2005 @08:51AM (#14192874) Homepage

    It's all well and good for TI to benefit from the open source community. But TI still refuses to publish their WiFi information [hp.com] for open source driver developers [sourceforge.net].

    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.

    • Re:Hypocritical (Score:3, Interesting)

      by Kadin2048 ( 468275 )
      You make a good point; TI is no friend to open source or Free software.

      However, just because someone releases a Linux-based product doesn't even begin to suggest that they are, so I'm not sure if 'hypocrisy' is really the right thing to be calling them out for. I don't think they've ever claimed to support open source in any form, and it seems as if their inclusion of Linux is really more because they've finially realized that there are a lot more Linux programmers than DSP programmers, and they need to get
      • You make a good point; TI is no friend to open source or Free software.

        I wouldn't agree with such a blanket statement. TI is currently contributing actively to Eclipse [eclipse.org], for example.
    • Yeah, I was considering posting the same thing, because I have suffered from this when I bought a WLAN card with TI's ACX111 (a friend mistakenly told me it has full Linux support). If they just totally ingored Linux altogether, then that's one thing, but it's sad to see them using Linux like this without putting in the tiniest bit of effort to help the project out in return.

      Incidentally, the drivers on the site given by the parent poster have stopped working for me recently, but there are updated driver

    • 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.

      have you considered the fact that maybe their driver contains proprietary 3rd party IP that they're not at liberty to disclose? It happens quite often in my experience. Also with companies like TI often the will is there to help but you need to find the right person inside the company to talk to that is both willing to help and has the right contac

  • 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.

    • 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)

      Well I can explain this in better detail for you (See disclaimer at end of post) The model that TI have is that you have two business types : Wireless (people doing seriously high volumes) and Catalog (everyone else). They support the big boys directly, but for the smaller volumes they have 3rd parties as intermediaries to provide suppor

  • TI's last generation of ARM/DSP SOC's support Linux as well, from a company called Cadenux.

    Check out their list of TI platforms: http://www.cadenux.com/bsp/ [cadenux.com]

  • ...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
  • Is TI doing anything to work with the dspgateway project? It's already giving linux on OMAP access to the dsp.

    http://dspgateway.sourceforge.net/pub/index.php?Pa ge=What_Is [sourceforge.net]

    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/ [sigmadesigns.com]

    Thank you,
    Michael Uman
    Sr. Software Engineer, System tools
    Sigma Designs
  • Hi Folks, For those who are still interested, here is it in linuxdevices [linuxdevices.com]http://www.linuxdevices.com/news/NS9968931411.html [linuxdevices.com]

Slashdot Top Deals

Some people manage by the book, even though they don't know who wrote the book or even what book.

Close