Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Papers On Real-Time And Embedded Linux 102

Posted by Zonk from the embedded-where dept.
An anonymous reader writes "LinuxDevices has once again published the proceedings of the annual Real-Time Linux Workshop. This one, the seventh, was held in France earlier this month, at the University for Science and Technology of Lille (USTL). The papers span a range of topics, from fundamental real-time technologies to applications, hardware, and tools. Enjoy!"
This discussion has been archived. No new comments can be posted.

Papers On Real-Time And Embedded Linux More

Papers On Real-Time And Embedded Linux

Comments Filter:

  • Amazing Field of Work (Score:5, Interesting)

    by JoeShmoe950 ( 605274 ) <CrazyNorman@gmail.com> on Sunday November 20, 2005 @08:54PM (#14078525) Homepage
    I've always found the field of embedded operating system's somewhat intruiging. From the automatic welders, to the VCRs, etc. Anything involving robots, or extremely low power systems is somewhat interesting, and even if linux eventually fails on the desktop market (stops growing), it may be around us in our daily lives much longer.

    • Re:Amazing Field of Work (Score:4, Interesting)

      by ClosedSource ( 238333 ) on Sunday November 20, 2005 @09:24PM (#14078638)
      I think as long as you're talking about the "new" embedded systems (i.e. no or easy real-time or a general purpose computer in a smaller form-factor) then OS's like Windows CE or Linux will be OK.

      For traditional embedded systems (i.e extremely limited resources or true real-time software) these OS's will come up short. They are too bloated for low resources systems and their timing is to variable for serious real-time work.

      Of course, most of today's microprocessors aren't appropriate for hard real-time software either. Once you add complicated prefetch schemes and caches to the mix, you can't really do anything that requires fine timing precision.

      Fortunately for traditional OS's, real-time software is a dying art and most real-time work is done in specialized hardware rather than software these days. In addition, the resource issue is not really much of a problem these days.

      • Re:Amazing Field of Work (Score:3, Informative)

        by Quirk ( 36086 )
        Not my bailiwick, but isn't ITRON [sakamura-lab.org] meant to be the best embedded systems OS?

      • You are wrong (Score:3, Insightful)

        by Mindjiver ( 71 )
        When you say that real-time software is a dying art you are totally wrong. The move is from specialized hardware and/or mechanics to software-based solutions where the time-to-market for adding a new feature is smaller than for specialized hardware. If real-time software was a dying thing why does a modern car contain so many micro-processors running real-time software?
        • My point was that less hard real-time software is being written today relative to non-real-time software than 10 or 20 years ago. I don't know the details of the software running in cars but I doubt that it's hard real-time. The fact that you used the word micro-processor rather than microcontroller suggests to me that you may not be all that knowledgeable about it either. If you are, then maybe you could expand on the details a bit.
          • Doubt you will read this though but..

            Fair enough, it might be more microcontrollers than microprocessors. I was a bit unprecise when I wrote the comment.

            Software in cars? What do you call airbags, anti-lock brakes, traction control, which are all controlled by software, if not hard real-time! The move towards drive-by-wire would not be easy without hard real-time software as well. Fly-by-wire as implemented in Airbus airplanes are all hard real-time. Then we have GSM/3G communication networks, all using rea
            • Saying that real-time software was completely dead was perhaps overstating the case, but I think the use of dedicated microcontrollers implementing a single function and specialized hardware has made the programming effort less complex than in the past. That's as it should be.

              A single microcontroller in car probably represents less than .1% of the overall cost. Why not have more than one and improve the safety and lower the cost of developing the software?

  • Linux. (Score:3, Funny)

    by Anonymous Coward on Sunday November 20, 2005 @08:56PM (#14078531)
    This is Linux: ooooh look at ME! I can guarantee multiple-microsecond interrupt times! La dee da!

  • not really key area for linux (Score:5, Informative)

    by Keruo ( 771880 ) on Sunday November 20, 2005 @09:36PM (#14078685)
    Embedded devices aren't really focus market for linux. Even with being stripped to bare minimum, the kernel will take over 500kb to operate.
    Embedded systems usually don't have need to carry that much memory. Task specific operating systems like TRON and its variations take only few kilobytes, and are extremely efficient and reliable in what they do.
    What linux provides, is interesting approach, but it also rises the price tag with hardware specs higher than the cheapest alternatives.
    • uclinux is great for embeded. Also you probably have linux in your home router if you have one. Linux on handheld.org is very neat too.
      • "Also you probably have linux in your home router if you have one." I'd like you to substantiate that. It isn't true whatsoever. While linux is in some home routers (most notably early versions of the famous linksys WRT54G), it certainly isn't in most.
    • And that's part of what some people forget. Linux is great. It can be used for just about anything you can think of, given some tweaking. But for some things, while it is CABAPLE of doing everything, it's not necessarily GOOD at it. In general terms, what's better for the gamer? Most games are only available on windows. Some notably excellent ones are available elsewhere, but most aren't. Yet. For an older/smaller/cheaper mobile phone, desktop-intended OS's aren't ideal. Symbian was designed to be fast a
      • For an older/smaller/cheaper mobile phone, desktop-intended OS's aren't ideal.

        I wouldn't say that Linux is a desktop-intended kernel. It certainly didn't start out that way, and wasn't intended to.

        Many of the distributions are intended for the desktop. And many are intended to be run as servers. And a fair few are intended to be run in embedded systems.

        The Linux kernel has a lot of developers working on making it suit their specific needs. In this way, it can be all things to most people and most things

    • For the umpteenth time: embedded != small

      Sure, a digital camera is an embedded device, but so is an MRI scanner.

    • i'd still like to see a cutdown linux which can operate on a handheld like the hp/compaq ipaq. i know something exists right now but it reminds me more of like playing with fire than getting a solid linux machine in my pocket. currently the devices run with windows-ce and i don't like the idea having this thing in my pocket at all.

      ofcourse really tiny devices that have less memory than pocketpc's should choose probably something else to operate on. linux is getting more complicated each day to support new h
      • If the device has an MMU, you might have more luck getting NetBSD onto it - there's even an eBook floating around telling you exactly which bits of a BSD OS need modifying to support a new platform. NetBSD still runs quite happily on 68K hardware (so does OpenBSD, for that matter), so it should work okay.

        If you want a cheap Linux handheld, I can thoroughy recommend the Nokia 770 (rubbish name, great product). The developer environment is available for download, and it runs a fully open stack (Linux, X1

    • Yes, therefore no more research should be done in this area. :-)

      And from wikipedia:

      TRON itself does not specify the source code for the kernel, but instead is a "set of interfaces and design guidelines" for creating the kernel. This allows different companies to create their own versions of TRON, based on the specifications, which can be suited for different microprocessors. The specification of TRON is open, but the code generators are not required to make their source free unlike with the GNU General Publ

    • The term embedded covers a large area from small devices to devices with more power than desk top machines.

      However in the latest ESP survey it was found 24% said they were using linux 17% said they were likely to use it soon and 33% said it was likiely they would use it. That shows that Nearly 75% with an interest in linux. Not bad fo a non focussed market.

      ALso the biggest embedded OS provider(vxworks 22%) are pushing linux hard as a complementry solution to there flagship product.

      So I would say linux has a
  • I know this isn't Ask Slashdot, but does anyone have recommendations for good books on the subject of embedded systems? I was actually at Barnes & Nobles today and found two books: "Embedded C" & "Programming Embedded Systems in C and C++". I will be finishing UCSD in December with a BS in EE, and I have an opportunity to join a UC funded research team in a position which will require a lot of work with embedded devices (of which I have very limited experience), and I could use any advice on getti
      • Not only did you not recommend any books you didn't even spell embedded right.

        For the most part I think you'll learn the most just reading through the databooks and application notes that come with the particular embedded platform that you are working on. Stay FAR away from any hobby-type embedded systems books that focus on PIC processors if you are doing anything serious. I've found a lot of the code in those types of books to be poorly written and counter productive. Since most embedded systems are progr
    • A respected Dutch lecturer in Real-time systems I know recommends Alan Shaw "Real-time systems and software" ISBN: 0-471-35490-2. Personally I found it a bit heavy on the maths (he suggested I start out on Doing Hard Time ISBN: 0201498375), but if you're going on to do University research then you'd probably better get used to it! ;-)

  • Wow, I'm Impressed? (Score:2, Interesting)

    by zappepcs ( 820751 )
    It doesn't look like there are many RT programmers on /.?
    RT applications are said to be so because of the requirement for them to react in *real time* even though that is not the actual case. It just needs to seem that they do.

    Microprocessors and full fledged desktops or servers have different tasks, different design criteria. You may want to know as soon as an email arrives, but you damn sure want to know when your cars brakes are about to fail. There are differences in the meaning of 'real time' in these

    • Re:Wow, I'm Impressed? (Score:5, Interesting)

      by Animats ( 122034 ) on Sunday November 20, 2005 @11:20PM (#14079049) Homepage
      RT Linux does exist (QNX as example)

      QNX [qnx.com] isn't a Linux derivative. It's not even a UNIX derivative. It's a POSIX-compliant microkernel, with a totally different underlying architecture than Linux. Latency is much better than Linux, because the kernel just handles message passing, CPU dispatching, and timing - everything else, like file systems, drivers, and networking, is in user space and preemptable. Overall performance is slightly worse than Linux.

      The newer real-time Linux variants based on the 2.6 kernel are getting to be decent. 2.6 finally got most of the long interrupt lockouts out of the kernel, and allowed preemption of some kernel tasks. Look at the MonteVista or BlueCat variants. You still have to be careful not to load any drivers that contain long interrupt lockouts, or real-time latency will go way up.

      The original "RT Linux" was a hack which basically allowed running your real-time application as a loadable kernel module, like a driver. That's basically a dead end at this point in time.

      QNX, unfortunately, was acquired by a larger company, which has changed the business strategy from opening up QNX to raising prices and cutting functionality of the base package. The main architect of QNX died a few years ago, and things really haven't been the same since. It's sad.

    • Re:Wow, I'm Impressed? (Score:5, Insightful)

      by Jerry Coffin ( 824726 ) on Monday November 21, 2005 @12:36AM (#14079293)
      It doesn't look like there are many RT programmers on /.? RT applications are said to be so because of the requirement for them to react in *real time* even though that is not the actual case. It just needs to seem that they do.

      I suppose I'll get modded as troll (again) for saying so, but from what you've said, I'd guess you're one of the people who's not an RT programmer.

      Real-time programs do need to react in real time. A typical example is that the program needs to react within X microseconds of an interrupt happening. A hard real-time requirement is exactly that -- no "seem that they do" about it. For example, a navigation system for an aircraft must react within the right amount of time to input from the pilot, radars, etc. A late reaction carries the possibility of killing hundreds of people (conceivably even thousands with particularly bad luck about where it lands).

      ABS systems are not allowed to have delay, mail servers are.

      Every system has some delay -- the questions are 1) how much?, and 2) how much does it matter if it misses its window by some small amount? A hard real-time system is one where you have an absolute maximum delay, and you must never miss it. A soft real-time system is one where you may be able to get away with slightly greater delays on rare occasion -- the "softness" of the real time being determined largely by how large the delay can be, and how often it can happen. The situations above with brakes or aircraft navigation are about as hard of real-time as you can get -- excessive delay is likely to cause deaths. A router or mail server has substantially softer requirements. If it misses receiving part of a packet very often, it won't work well -- but as long as it's not very often, it's probably not a problem, and endangering lives is pretty far-fetched even at worst.

      Also note that real-time does not necessarily mean much about being fast. Years ago, I worked on some software to control some of the operations in a sewage plant. In most cases, the computers' requirements on the reaction times were measured in entire seconds and sometimes even minutes -- but if it missed a deadline, millions of dollars in damage could be expected, and endangering lives was possible as well. Ridiculously slow by most standards, but hard real-time nonetheless.

      So -- the essence of real-time is not about "high speed" it's about "dependable and predictable speed". Real-time requirements are specified not only in terms of "How fast?", but "How serious is too slow a reaction?" -- and the latter is often what really dominates.

      --
      The universe is a figment of its own imagination.

    • Re:Wow, I'm Impressed? (Score:2, Insightful)

      by Mindjiver ( 71 )
      "RT applications are said to be so because of the requirement for them to react in *real time* even though that is not the actual case. It just needs to seem that they do."

      I though the traditional definition of a real-time was a system that had temporal requirements as well as functional requirements. That is, it should perform the operation as specified and at the right time.

      Also, real-time system does not need to be small. There are real-time systems that run Pentium processors with several GHz, it's all
    • I've been a real-time embedded programmer for years. You seem to have a misunderstanding what "real-time" means. It does not mean really fast. It means you have hard dead-lines that must not be missed. The amount of time can be any required. You can have a hard dead-line of several minutes to hours. That is why having a good RTOS is so important. It is not, necessarily, important to have really, really fast context switches (though faster is always better). It is important that they are always deter

Slashdot Top Deals

The rule on staying alive as a program manager is to give 'em a number or give 'em a date, but never give 'em both at once.

Close