Meindert Sprang wrote:> "Mike Harding" <mike_harding@nixspam.fastmail.fm> wrote in message > news:7begu0hs4og1ejke64f2s9r204riip0lrg@4ax.com... >> I very occasionally use sprintf if there is an LCD but >> otherwise can't think of anything. > > Well, the moment you do 32 bit arithmetic on an 8-bitter, most likely a > library function is called... > > MeindertWhich is precisely why you need to think very carefully before doing so. Ian -- Ian Bell
I don't use an RTOS because...
Started by ●January 12, 2005
Reply by ●January 15, 20052005-01-15
Reply by ●January 15, 20052005-01-15
Guy Macon wrote:> Ian Bell wrote: > > >>But it is worth noting that there is a significant lowering of >>reliability as soon as you move to a pre-emptive system. > > > I don't like them. They are great for systems where you will > be running code that someone else wrote (example: desktop PC), > but if you control all of the software a cooperative scheduler > is usually batter than a preemptive scheduler for real-time. > Then again, perhaps I just haven't run into the kind of problem > that they solve; we all have limited experience. > >I've used them extensively. They're great when you're working on projects that need more than one software engineer, and in an environment where you're using a lot of library code. It seems that the difficulty of managing a task-loop kind of cooperative scheduler goes up as an N^2 kind of thing, where a preemptive multitasker is more proportional to N (N being some measure of complexity that I will refuse to pin down). The preemptive multitasker is certainly harder to set up and will floor you with more really subtle bugs, but when you've got four different people all trying to create one code base at one time it's certainly an aid to progress. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●January 15, 20052005-01-15
Tim Wescott wrote:> Guy Macon wrote: > >> Ian Bell wrote: >> >> >>>But it is worth noting that there is a significant lowering of >>>reliability as soon as you move to a pre-emptive system. >>snip>> > I've used them extensively. They're great when you're working on > projects that need more than one software engineer, and in an > environment where you're using a lot of library code.That is an interesting comment. I have never heard an RTOS having properties that make multi-person development easier. It is mot clear from the post but did you mean an RTOS in general or a pre-mptive one in particular? Ian -- Ian Bell
Reply by ●January 15, 20052005-01-15
CBarn24050 wrote:>>Subject: Re: I don't use an RTOS because... >>From: "Meindert Sprang" > >>"Mike Harding" <mike_harding@nixspam.fastmail.fm> wrote in message >>news:7begu0hs4og1ejke64f2s9r204riip0lrg@4ax.com... >>> I very occasionally use sprintf if there is an LCD but >>> otherwise can't think of anything. > >>Well, the moment you do 32 bit arithmetic on an 8-bitter, most likely a >>library function is called... >> > > Yes the maths library is the most usefull part.No,no,no,no,no not unless you absolutely *have* to do floating point arithmetic. Ian -- Ian Bell
Reply by ●January 15, 20052005-01-15
Robert Scott wrote:> The difference between C libraries and an RTOS is that most C library > functions can be simply documented and understood. But giving > overall control to an RTOS requires a more thorough understanding of > the interface. It is usually more than are series of simple function > calls. It is more like completely understanding all the ins and > outs of the Overlapped IO operations in Win32 programming.If all we are talking about here is the RTOS, then the understanding of tasks/threads, semaphores, mutexes, and perhaps some other inter-thread communications mechanisms is all that is required. Yeah, it's a learning curve, but it's not *that* complex. A worthy grok for any software practitioner. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●January 15, 20052005-01-15
Ian Bell wrote:> 42Bastian Schick wrote: >>So, you do write you C libraries yourself too ? > > 99.999% of C library functions are irrelevant for small embedded systems so > what's to write?As usual, the arguments come down to the "embedded system" qualifiers. Here the qualifier is small. However, there are *many* of us who work with embedded systems that are moderate to quite large. If the complexity is large, then an RTOS helps to contain and manage that complexity, as does the careful selection of libraries. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●January 15, 20052005-01-15
Ian Bell wrote:> But it is worth noting that there is a significant lowering of reliability > as soon as you move to a pre-emptive system.What a bunch of FUD. I assure you that for an appropriate application I can write a more maintainable and highly reliable application with a pre-emptive scheduler. Do you have an facts to back-up that claim? -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●January 15, 20052005-01-15
Tim Wescott wrote:> The preemptive multitasker is certainly harder to set up and will floor > you with more really subtle bugs,Like so many things software, this depends entirely upon the team's familiarity with RTOS concepts. Saying that you *will* encounter subtle bugs just because you use an RTOS is quite misleading. -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●January 15, 20052005-01-15
joep wrote:> Distributing the problem over more processors simplifies each > controller, but you still have to make the total system work. It seems > your just moving the complexity somewhere else (interface > specification) and not really making the total system any less complex. >I have to agree with this sentiment. Yes, distributing over multiple processors forces the interface design issue. However, were the team to take the same care with interfaces between threads on the same processor, the same gain can be achieved with the benefit of not needing communications protocols and parsing (one addresss space.) -- Michael N. Moran (h) 770 516 7918 5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144 http://mnmoran.org "So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone" The Beatles were wrong: 1 & 1 & 1 is 1
Reply by ●January 15, 20052005-01-15
>> I've used them extensively. They're great when you're working on >> projects that need more than one software engineer, and in an >> environment where you're using a lot of library code. > >That is an interesting comment. I have never heard an RTOS having >properties that make multi-person development easier. It is mot clear from >the post but did you mean an RTOS in general or a pre-mptive one in >particular?>IanI agree with Tim - Any OS, not necessarily an RTOS. For the same reasons that another poster recommended using multiple processors: Divide and conquer. Splitting a large application into separate processes that communicate with each other using a limited and well specified set of functions, (I do not mean that it as in "C" functions) makes it simpler to develop them, to assign them to separate teams, to test and verify them in isolation, etc. Of course you can do the same without an OS. But having one generally provides most, (at least some) of the common layer as OS calls, IPC mechanism, etc. Many projects that need more functionality than what is provided by the bare OS would add it in a way that still looks as common OS functions. (Like a message passing library for IPC, etc) As others pointed out, there are embedded systems and there are embedded systems. I probably would not make any sense to use an RTOS in, let's say, a TV remote controller. But the kind of systems I am currently working on, (32bit processors, 128-256 Mbyte RAM - all used up - multiple hardware interfaces to the external world and other system components, support for multiple communication protocols, 20+ people development teams, etc.) would be much more difficult to develop without the foundations provided by an OS. Roberto Waltman. [ Please reply to the group, return address is invalid ]
