Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Linux Business Software Linux Hardware

Linux To Gain Another Chip Family 141

Posted by timothy from the assimilation-nation dept.
An anonymous reader submits "Freescale will unveil the first ColdFire processors ever to include a memory management unit (MMU), and therefore able to run full-scale Linux, this week at the Embedded Processor Forum in San Jose, Calif. The chips cost $17 - $25, and are used mostly in industrial control and factory automation. Simultaneously, Freescale tools subsidiary Metrowerks announced plans to offer Linux development tools for Coldfire chips, which previously had been restricted to running uClinux due to the lack of an MMU."
This discussion has been archived. No new comments can be posted.

Linux To Gain Another Chip Family More

Linux To Gain Another Chip Family

Comments Filter:

  • New Amigas (Score:5, Informative)

    by Amiga Lover ( 708890 ) on Monday May 17, 2004 @08:00PM (#9179189)
    These chips, distantly related to the 68k motorolas, were once touted as a possible upgrade path for new Amigas in the mid 1990s. Hopefully with these new ones, the more modern AmigaOS4 can be ported to them, and continue the heritage. At the moment the only stock available is AmigaOne G3, G4 and mini-itx PPC boards, which are artificially inflated in price by the apple/ibm/motorola consortium.

    • Re:New Amigas (Score:1, Insightful)

      by Anonymous Coward
      > Hopefully with these new ones, the more modern AmigaOS4
      > can be ported to them

      You can't "port" something that hasn't been written yet!

      6 years now and all promises :(
    • which are artificially inflated in price

      What? Niche products costing more? Yeah, that sounds pretty artificial.
      • Freescale's ColdFire line comprises 8-, 16-, and 32-bit processors. Significantly, the MCF547x and MCF548x ColdFire chips announced today are the first in the ColdFire architecture to be based on Freescale's new V4e core, which includes an on-chip MMU. The new ColdFire processors are capable of delivering up to 410 MIPS (million instructions per second) at 266 MHz, according to Freescale.

        haha. yes, please DO run your amigaOS @ 410MIPS.

        • Re:New Amigas (Score:1, Interesting)

          by Anonymous Coward
          AmigaOS 4 could run rings around any other OS even at 266MHz. Its core is still based in the idea of efficiency. Remember the days when a 25mhz machine was fast? Those days are still there. Now the OS that ran well on 25mhz can run at 266, or 500, or 1GHz, and enjoy the same multiples in speed.

          XP on a 3.4GHz P4? Still a slug
          • SunOS 4.1.2 ran pretty well at 25 MHz. I remember the days when an 8 MHz machine was fast. You had to press this button marked TURBO, as if you're sitting there thinking, Gosh, this machine is just dog slow! What can I do to make it go faster? Wait, I know! I'll press the TURBO button!

            I remember days from before those days, too. I remember many different days. But I don't remember the Amiga except for some stuff about video toaster special effects I saw at a science fiction convention one time. Wh

            • Gosh, this machine is just dog slow! What can I do to make it go faster? Wait, I know! I'll press the TURBO button!

              Though most of the time that would make the machine run *slower* because most people would enable turbo out of the box...

              /nova20

            • Wasn't that to make old software and hardware work that couldn't run right on the new machines?

    • PowerPC is as cheap as ColdFire (Score:5, Insightful)

      by Wesley Felter ( 138342 ) <wesley@felter.org> on Monday May 17, 2004 @08:34PM (#9179379) Homepage
      First, let's compare apples to apples. These new ColdFire processors run at 266 MHz and cost $20-27. The 266MHz PowerPC MPC5200 (also from Motorola) costs $27.

      Even the desktop-class PPC 750s and 74xxs aren't expensive if you buy them in volume. The AmigaOne is expensive because it is a niche-of-a-niche product, not because Moto is ripping people off.
    • There is actually an Atari Cold Fire Project based on these processors: http://acp.atari.org/
    • Well how about open motherboard designs? Is anyone working on this sort of thing? I know about the Open Core projects, but it's be neat to make a little computer from scratch.
    • These chips, distantly related to the 68k motorolas

      Can you elaborate. I thought ColdFire was basically a 68060 w/out an MMU. Does it have new instructions -- or strip out a few -- compared to 68k, (like the Power->PowerPC transition)? What else is different?

      • If I remember correctly, they junked the binary compatibility with the 68K series of chips. This allowed them to redesign the binary level instruction formats and instruction decoder circuits. They kept compatibility at the assembly language level, just reassemble your 68K source code with a new ColdFire assembler.

    • Re:New Amigas (Score:5, Informative)

      by Jeff DeMaagd ( 2015 ) on Monday May 17, 2004 @09:03PM (#9179537) Homepage Journal
      which are artificially inflated in price by the apple/ibm/motorola consortium.

      It appears that way when in reality, that probably is an exercise in comparing bananas and oranges.

      Development Evaluation / Reference Design boards are generally higher in price because of their volume, and the fact that they have different levels of support, often times, software, documents and engineering support is available to them for this type of product. Products intended for a slightly different market, the embedded market, are often slightly cheaper but don't always fit the "standard" form factors like ATX and ITX, but they weren't meant to be used as personal computers, so that point is moot, although it would probably help prices and cut development costs a lot.

      The idea is that a prospective manufacturer would buy the Devel board to test the capabilities of the overall system. When they want volume, they take the reference design as a basis for their own fabrication and and make it in volume, but often for proprietary form factors to fit a very specific task.

      One thing I noticed is that reference boards for Intel and AMD chips often cost a little more than those for RISC chips. If the ARM board costs $600, a similar embedded reference board for an x86 chip often costed $700 to $800. The difference here is that there are plenty of consumer boards available for x86 systems, but not RISC systems, so this is where the RISC boards look expensive.

  • Why is this so important? (Score:3, Informative)

    by raahul_da_man ( 469058 ) on Monday May 17, 2004 @08:00PM (#9179191)
    I thought I knew which processors were important in the embedded world. What exactly is Coldfire, and why does it matter compare to ARM and Motorola's offerings?

    I realise that Yet Another Embedded Processor that can run all of linux is a good thing. I just don't see why that is important, since the difference between embedded and desktop processors has been diminishing sharply.
    • Just as Power begat PowerPC and x86 begat x86-64,
      so 680x0 begat ColdFire.

      In this case, the instruction set was recoded
      to save memory and reduce power consumption.
      Given some 680x0 assembly code, you pretty much
      have ColdFire assembly code. The mapping from
      opcode to binary is different. Most likely there
      are a few minor changes beyond that, but not much.

    • Huge Difference (Score:5, Interesting)

      by bsd4me ( 759597 ) on Monday May 17, 2004 @08:35PM (#9179391)

      There is a really big difference between embedded processors and mainstream CPUs.

      The biggest is that power consumption is really important in the embedded world. Sometimes you can only get so much current to a board, or you can't run fans.

      Typically, embedded processors can run without support chips. Many have built in memory controllers and I/O.

      Another thing is the MMU. A lot of embedded processors have MMUs (I think most of the PPC ones do), but OS support for them is a bit lacking (or it was until recently). But at times, the MMU can get in the way

      IMHO, I would never run linux in an embedded product, other than simple internet appliances or where realtime isn't required. Commerical RTOSs like VxWorks [windriver.com] really are worth it for most embedded applications.

      • VxWorks is crummy (Score:3, Informative)

        by r00t ( 33219 )
        Their shell is an abomination. Their filesystem
        is plain old DOS FAT, optionally with an
        incompatible long-filename feature. The "mount"
        command (function? all the same...) is totally
        defective, doing some kind of dumb text substitution
        instead of real mount points. Memory support is
        terribly limited -- is 32 MB enough for you?

        For the cost of VxWorks, you can get a bit of
        extra memory for running Linux. You'll also save
        on development costs that way.

        If you'd really prefer a tiny OS designed for
        strict real-time fr

        • Re:VxWorks is crummy (Score:3, Interesting)

          by bsd4me ( 759597 )

          I have never needed a filesystem on an embedded product, and I don't think I have worked on a deployed system with more that 32 M. I think the biggest had 8M.

          I would also be hesitant to deploy an RTOS without a proven track record and without good support. I have found kernel bugs before, and I have had to fly out tech support to help out with problems at customer sites. Most commercial vendors will also support old versions for a long time if needed.

          • I would also be hesitant to deploy an RTOS without a proven track record and without good support. I have found kernel bugs before, and I have had to fly out tech support to help out with problems at customer sites. Most commercial vendors will also support old versions for a long time if needed.

            Well, ignoring that your login tells it all, I find it funny that you would knock Linux for support. You know that Linux (and to a large degree all OSS including BSD) has won the major awards for support for about

            • Well, ignoring that your login tells it all, I find it funny that you would knock Linux for support.

              I am not knocking Linux or BSD support. I am just saying that I have had situations where support from commercial vendors is really worth it, especially when you need the same level of support for old versions where upgrading is not an option.

              In addition, the Linux/OSS world gives you the source code...

              Yes, the Linux and BSD kernel and userland source is available for free. That is a huge bonus.

          • Consider the disk array controllers EMC makes.
            Last I heard, a year or two ago, they were
            using about 32 GB of RAM.

            Consider the airborne radar systems and cell
            phone base station software-defined radio based
            on Mercury Computer Systems hardware. It's common
            to have dozens of gigabytes of memory, sometimes
            even hundreds of gigabytes. Each node of the
            multi-CPU system might have 2 gigabytes or so.
            Linux is often used.

            Consider the telephone switchs NexTel produces.
            That's a few gigabytes, running Linux of course.

            • I can't comment on the drive controllers, since I don't know much about that area, but I know some about the other two.

              As for the radar and comm hardware, I suspect that these started out on workstation hardware, and Linux made the transition to actual hardware much easier. I used to do a ton of comm simulation work, and would have loved this luxary. This would be a good fit for Linux in the embedded world, but it wouldn't surprise me if a traditional RTOS was used for the control functions.

              Regarding

              • For the switch hardware, PowerPC Linux is used to emulate some proprietary hardware that is no longer manufactured. Within the emulator, there is another OS. I'm told you don't just rewrite this sort of software. I gather it's a pile of decades-old spaghetti-code in a screwball language, and it has to speak oddball protocols for Iran, etc.

                I'm more familiar with the radar and software-defined radio and such. Mercury, CSPI, and Sky are producing this. They put 300 PowerPC processors in a 9U space, or 80 pro

              • How about medical? Linux is used for various kinds of body scanners. Often, especially with the 3-D stuff, many gigabytes of memory are required. Examples:

                helical-scan CAT (a 3-D X-ray)

                ultrasound with live 3-D video

                digital X-ray, again with live video

                PET scan (radioactive sugar emits positrons)

                virtual bowel exam, with the doctor having a game-like 3-D view of your butt -- except that he doesn't get a BFG9000 to hit the cancers (the data comes from one of the above of course, the digital X-ray I th

      • ... Perl.

        We looked at VxWorks for our first-ever embedded project. When we found out there was no Perl for VxWorks, nor any chance of ever, ever having Perl on VxWorks, we quickly abandonded VxWorks in favor of Linux.

        We've have no problems whatsoever using Linux as an embedded OS. Plus, we get to write much of our code in Perl as well. This is as it should be.

      • Re:Huge Difference (Score:3, Informative)

        by bhima ( 46039 )
        I have *never* found a project where VxWorks was worth the cost! In fact if you look they are loosing market share to Linux. Also the two most commonly used systems are either in-house home rolled things like I use or Linux. Of I'm not writing code for space missions, just medical devices.
        • Of I'm not writing code for space missions, just medical devices.

          Yup. And you don't want to be naked in the wind in a product liability suit. Say what you will about commercial software, every one of them washes their hands of product liability.

          Much better to go with something that can be repeatably tested and eternally supported. A stack of real-live tests trumps any gaurantee from the manufacturer.

          • Exactly!

            In some cases it makes sense to go with an externally maintained OS and in some cases it does not. But liability isn't really a deciding factor because *no* OS vendor is going to provide liability indemnity of any sort.

            Really the factors that have the most weight are: Bootstrapping time, support and unit cost. The testing doesn't usually get factored in.

      • IMHO, I would never run linux in an embedded product, other than simple internet appliances or where realtime isn't required. Commerical RTOSs like VxWorks [windriver.com] really are worth it for most embedded applications.

        ACK you are missing a HUGE part of the usefulness of embedded linux.

        Yes RT stuff and other things that are running the hardware near it's limits and life is at risk when the device is running? rtOS is important.

        for a Network enabled device that needs lots of functionality... for exam
    • I believe Coldfire IS one of Motorola's offerings. The digital cable equipment company I worked at was using those for a variety of applications.
    • I think ColdFire [motorola.com] compares quite well with some of Motorola's offerings.

      Also I think that the PowerPC compares quite well with some chips from IBM, the Athlon compares well to certain chips from AMD, and the micro-n-SP is equivalent in power to several chips from SunPlus. :-)

    • Well er um it isn't!

      I fail to see the real point in a Coldfire. What can it do that an ARM or whatever can't? A lot of the justification for Coldfire was for the Motorola zealots to move to something other than 68k (you'd be suprised how many engineering companies will only use Motorola). A lot moved to PPC. It is exceedingly hard for Motorola to justify an extra architecture in between 68k and PPC - more so still since Motorola has also started making ARM-based parts.

      • I fail to see the real point in a Coldfire


        IIRC, the coldfire has been around for about 8 or 9 years (possibly longer). I don't think it was ever really popular. I think it was really marketed the same way that ARM markets the ARM cpu, as an IP core around which chip designers can design embedded controllers.

        • I don't think this is quite true, though I bet Motorola wishes it was :-).

          As far as I can tell the only places you'll see Coldfire is in Motorola parts or ASICs made for people by Motorola (probably very few of those).

          In the 90's the 8051 core was used by just about everyone for various embedded micros. ARM is set to be the "new 8051".

    • The ColdFire is a 680x0 with the instruction set constrained in some ways (the number of instruction extensions is limited so that not all the combinations of addressing modes one is used to on the 680x0 are available for all instructions, arithmetic operations are all 32-bit rather than having 8-bit and 16-bit flavors as well) and extended in others (to compensate for the restrictions on arithmetic operations, there are load with sign extend and load with zero extend). Also, the ColdFire will trap on unali

  • Metrowerks (Score:2, Informative)

    by lakeland ( 218447 )
    Freescale tools subsidiary Metrowerks


    Huh? Metrowerks produces apple development tools, and they dabble in linux/embedded development tools. I'm pretty sure that Metrowerks is not a freescale subsidary. See for example this [metrowerks.com] PR.

    • Re:Metrowerks (Score:3, Informative)

      by Jeremy Erwin ( 2054 )

      Founded in 1985, Metrowerks is today an independently operating subsidiary of Freescale Semiconductor. Metrowerks corporate headquarters are in Austin, Texas; Metrowerks Europe is headquartered in Munich; Metrowerks Asia is headquartered in Singapore; and Metrowerks Japan is headquartered in Tokyo.


      In turn, freescale is a subsidiary of motorola. Source (27 April 2004)
      • In turn, freescale is a subsidiary of motorola. Source (27 April 2004) Freescale is the new name of Motorola SPS, hence the reason Freescale itself is a subsidiary of Motorola.

      • Re:Metrowerks (Score:3, Interesting)

        by Megane ( 129182 )
        In turn, freescale is a subsidiary of motorola.

        Yeah, it was weird going down Parmer Road last week and noticing the Circle-M wasn't there any more. It took me a moment before I realized what those "Freescale" signs meant.

      • Actually, Freescale isn't a subsidiary. Motorola SPS is being spun off as a separate company (thus they're filing SEC filings for an IPO). They're only being held as a subsidiary for the time being while papers are being filed. And since when was Metrowerks a subsidiary of Freescale? Founded in 1985 in Montreal, Canada, Metrowerks moved its corporate headquarters to Austin, Texas ten years later. Other Metrowerks offices are located in Silicon Valley, Europe, India and Tokyo. Metrowerks became an inde

    • Re:Metrowerks (Score:5, Informative)

      by Rosco P. Coltrane ( 209368 ) on Monday May 17, 2004 @08:13PM (#9179271)
      Huh? Metrowerks produces apple development tools, and they dabble in linux/embedded development tools. I'm pretty sure that Metrowerks is not a freescale subsidary. See for example this PR.

      1 - Metrowerks is a Freescale "early tester", i.e. they get Freescale stuff first

      2 - Metrowerks acquired Lineo [lineo.com] and their Embedix Linux offering a while ago, and offer it as one of their core products. Therefore, they more than "dabble" in Linux.
      • Metrowerks also wrote many many development tools for linux/embedded. Take for example: Embedded linux for Motorola phones? Also, the development kit for PS2 and many gaming consoles. They've been around ever since I can remember for great development tools (remember Codewarrior?)

        And the only reason they get Freescale things first is because they're all Motorolan to some degree.

  • motorola (Score:5, Informative)

    by Coneasfast ( 690509 ) on Monday May 17, 2004 @08:05PM (#9179222)
    freescale is a subsidiary of motorola, here is homepage for coldfire [motorola.com].

  • Great, I can use them (Score:4, Interesting)

    by Orion Blastar ( 457579 ) <orionblastar@@@gmail...com> on Monday May 17, 2004 @08:07PM (#9179233) Homepage Journal
    I want to build a low cost Computer Automated Dispatch system with just the basics for low income firehouses, police stations, and hospitals. This chip might just fit the bill. I was going to go with Transmeta or a low end X86 processor.

    • Re:Great, I can use them (Score:5, Insightful)

      by DAldredge ( 2353 ) <SlashdotEmail@GMail.Com> on Monday May 17, 2004 @08:16PM (#9179287) Journal
      Mission critical systems and first generation chips are not a good match.
    • Cool idea. I, on the other hand, am entertaining grandiose dreams of alarm clocks, coffee makers, stereos, and microwave ovens. The limits are endless. Yes, it CAN run Linux ;)
    • I think you will find low end X86 to work quite well.

      Unfortunatly I still find the tranmetta offerings a bit to pricey (but then again I don't have real issues with battery life with my projects!)

      • That was my original idea to use a low end X86 processor. Embedded Linux already exists for it, and if SCO gets their way we can always change to BSD Unix.

        Anyway an original socket 7 X86 chip should work fine for low end 911 Computer Automated Dispatch. That is if they still sell them. ;)
        • I don't think SCO's case has much merit! I know I shouldn't say this here, I'm a big fan of *BSD. I just finished a project using NetBSD & AMD Elan that worked out very well. I also like Busybox!

          Mini-ITX and Nano-ITX products might also be a good choice. (coupled with CF cards)

          • it might help to lower the cost if we use standard off the shelf parts instead of fabercating our own.

            Just need a double-throw relay interface for the box to access the various devices it will set off. Like in a firehouse it needs to flicker the lights in the shower, etc. Everyone in the firehouse should know that there is a real emergancy going on, so a device is needed for every room. Figure about 12 to 15 double-throw relay interfaces. It will be a matrix that can be controlled, and one or more of those
        • The only x86 chip you would want to think about in an alarm box would be imbedded _3_86 flavors.

          That said, they'll still consume _way_ too much power. Yer alarm system has to run on batteries during power outages, or when intruders are smart enough to shut off the power before entering.

          You _definately_ want to look at 8-bit CMOS microcontrollers, or something else in that range. I'm rather fond of 80C31/51 types myself. No, these won't run Linux, but plenty of F/OSS tools are available. Do you want to
          • and can be programmed for things like voice over IP, image displays, real streaming audio, and perhaps have a small build in web server that can be used to configure or interface with another system. Security is a must, everything must be encrypted and password protected. I thought about using GPG for encryption for data packets the dispatch system sends to each 911 CAD box. We don't wany any false alarms or crackers tampering with the boxes.

            Windows and DOS simply won't do, not stable enough for a 24/7 rea
  • I wonder when MSFT Embedded Visual C++ will support this?
  • Yeah but do they run... oh... wait... nevermind.
    • Yeah but do they run... oh... wait... nevermind.

      You forgot "Just imagine a Beowulf cluster of these"... ;-)

      (Actually, for the price/performance ratio, I'd rather have a cluster of Athlon XP 2600's. But that would require thinking outside-the-joke).

  • on chip stuff (Score:5, Funny)

    by baryon351 ( 626717 ) on Monday May 17, 2004 @08:11PM (#9179256)
    Other key features of the new MCF547x and MCF548x ColdFire processors include on-chip FPU and eMAC

    Dammit apple, I just bought a brand new eMac only months ago, and now they're putting them on-chip for under $30!

  • ColdFire is *already* supported in Linux (Score:5, Informative)

    by gergoid ( 19247 ) on Monday May 17, 2004 @08:11PM (#9179258)
    I added support for ColdFire processors to Linux years ago. This won't be new. It was added to Linus kernels in the 2.5 series, and is fully supported in the 2.6 kernels for all the older ColdFire parts (5206, 5249, 5272, 5282, 5307, 5407). Ofcourse the older parts did not have an MMU.

    Look under the arch/m68knommu branch for all the architecture support...

  • Yay! (Score:2, Interesting)

    by ejaw5 ( 570071 )
    Finally! A day will come where I can get a processor with MM and NX bit on a mobile motherboard featuring MXM interface.

    • Re:Yay! (Score:3, Funny)

      by NanoGator ( 522640 )
      "Finally! A day will come where I can get a processor with MM and NX bit on a mobile motherboard featuring MXM interface. "

      Rats, my universal translator is broken.

  • FYI Freescale is the old Motorola SPS group (Score:5, Interesting)

    by cacheMan ( 150533 ) on Monday May 17, 2004 @08:25PM (#9179335)
    This isn't some fly-by-night chip maker.

  • Wow (Score:1, Funny)

    by iminplaya ( 723125 )
    Cold fusion processors... Is it real or is...oh, nevermind...

  • Another chip *family*? No. (Score:5, Interesting)

    by DdJ ( 10790 ) on Monday May 17, 2004 @09:06PM (#9179547) Homepage Journal
    Another chip family? No, unless you think Intel XScale and TI OMAP are in different chip families. The ColdFire chips are just another example of the m68k family, like the DragonBall chips are.

    • ColdFire are not MC68Ks (Score:2, Informative)

      by Anonymous Coward
      They try to fool you into thinking they are. But they aren't. They are an entirely different architecture that uses similar nmeumonics and addressing modes.

      Even the hexidecimal encodings of those instructions (i.e. the machine language) is dissimilar from 68K machine language.

      ColdFire is a strange product, I moto has been pushing it for some time now. I'm not sure why it is still around.

  • cheapest embedded linux board? (Score:2, Interesting)

    by Anonymous Coward
    What's the cheapest embedded linux board (inluding cost of flash ram .. oh yeah must have ethernet)?

    Anyone have ideas?

    I am checking on google .. seems like the minimum amount to spend would be over 200.
    • I am thinking about buying something similar (for ARM based, decent amount of flash, with ethernet). The best deal I can get is about $250 + complusive DHL option (another $40-50 to Australia/New Zeland). At the same time, I know I can get it for half the price if I can secure an order of 25+... Cannot find enough like minded geeks from my class to make a bulk order.

      I feel that we can take advantage of some consumer electronics product... A lot of them are slightly modification of the reference design..
      • How small does your embedded device have to be?
        You can get mini-itx systems including a via processor and motherboard for approximately A$210 (with the current exchange rate about US$150) with negligable shipping.
        They are not true embedded boards, and Via doesn't seem to have a handy total power draw figure on their website, but for many situations they might work just as well.
    • After you hack it up, will a Linksys Wrt54g do the trick for you?

      Linksys Wrt54g [seattlewireless.net]

  • Innovation like this underscores the need for relying on free software [gnu.org] (or, put differently, the problem with relying or recommending non-free software). It's an easy trap to get into when you use an i386 GNU/Linux distribution (as most GNU/Linux users do, I suspect) because there are so many opportunities to get hardware that only fully work with non-free software (like nVidia video cards that require non-free kernel driver software to operate fully). When you become dependent on non-free software you lose portability which prevents easily moving to interesting hardware like this one. Non-free video and audio codecs are similar; if you base your work on some Microsoft library for decoding audio or video you won't easily be able to read those files on a non-i386 platform.

    Software proprietors won't supply the wide range of support the free software community does. Software proprietors won't give you the power to provide your own support or buy it from programmers and sysadmins in the free marketplace.

  • mmmm.. that kind of sounds like an STD of some kind. A mix of crabs and clymedia. Can't wait to catch that one.

  • Anyone else find uClinux to be a funny word?

  • Rush fans everywhere rejoice!

  • Damn (Score:1, Funny)

    by Anonymous Coward
    That $30 chip is almost twice as fast as my combination (web/ftp/print/useless crap)server. If it has above 32M of memory, it has more RAM also.

    I've got to admit that the thing is finally going to die at some point.

  • What's so "u" about uCLinux? (Score:4, Interesting)

    by Doc Ruby ( 173196 ) on Tuesday May 18, 2004 @01:32AM (#9180789) Homepage Journal
    uCLinux is a port of Linux to CPUs without an MMU. Without an MMU, the chips don't support the convincingly simulated parallelism of fork(), rather just the nominally similar (blocking) vfork(). What other compromises must an application concede when running under uCLinux, rather than a "full" Linux kernel?
    • Considering most embedded apps are one-trick ponies, not a whole lot. Vending machines, security cameras, most robotics projects, they are even driven tasks. You are running an app that quietly waits for an interrupt event (a keystroke, a signal on one of it's inputs to change) and then respond as quickly as possible.

      I wouldn't run any kind of graphical application. Assuming you could outfit the things with a video card. They would also make crummy real-time processing units. (Real-time OS's ration proces

      • Aren't embedded CPUs mostly required to respond in realtime? Doesn't that mean uCLinux can't serve their primary market?
        • Depends on what you mean by "Realtime".

          "Realtime" to a human operator is half a second. That's eternity to even the slowest modern processor. The fastest someone can double click a button is about 0.17 seconds.

          "Realtime" to an HVAC system is 5 minutes. (Furnaces and AC units can't safely handle changes in smaller increments.)

          "Realtime" to a weather station is 15 minutes. (Weather doesn't change much faster than that.)

          • "Realtime" in embedded systems means at least deterministic execution time for any CPU task - not just arbitrarily fast. Simulated task switching, without even switchable HW context banks, don't cut it. That's why, for example, Java (a software VM simulating a CPU) isn't certified for aircraft navigation systems, and features unnervingly prominent warnings to that effect.
            • Very true.

              But if you have the budget to be building something that requires precise timing, you have the budget to use a processor with a real-live MMU.

              uCLinux is designed for the hobbiest for whom the concept of "realtime" is a little more fluid, or for low-cost appliances where price trumps performance.

              As far as aircraft navigation systems go, it's right up there with Nuclear reactor control on the "Don't Go There" list for just about every consumer device manufactured. The Windows operating system

              • The MMU is also a power and size liability. Spending money on engineering a resource-light product can be worth it, especially when confronting the rising ubiquity of mobile client devices, in a PAN.

                Right now I'm tracking a uCLinux port to the MicroBlaze "soft processor" [uq.edu.au], which runs on the Xilinx FPGAs. There's no MMU because gates are precious in the reconfigurable HW. They're having timing problems, where the simulated clock drifts, often wildly and hugely, in a feedback with certain performance scenario
    • Memory protection and the ability to multiprocess are two different concepts. All you need is a timer interrupt to implement concurrency. Without an MMU, the processes could corrupt each other, but there's no reason you can't multiprocess without an MMU.

      Consider the TSRs from the days of DOS. You could easily latch onto the timer interrupt and have some background task run 18.2 times per second. Your only restriction was that you couldn't call DOS if the "in-DOS" flag was set, because DOS wasn't reentrant

Slashdot Top Deals

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Close