On Sat, 15 Jan 2005 15:22:26 -0500, "Michael N. Moran" <mnmoran@bellsouth.net> wrote:>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.A long time ago my group was developing multitasking applications on PDP-11 under RSX-11. Most people had good experience in designing and writing batch and interactive time share applications. After teaching them about multiple tasks and some of the most important OS mechanisms, it took several months until they independently could split the applications into tasks and design the synchronisation and communication between them. Even after that, you had to check their code for stupid things, such as busy loops (as a heritage of their batch and timesharing days). Paul
I don't use an RTOS because...
Started by ●January 12, 2005
Reply by ●January 16, 20052005-01-16
Reply by ●January 16, 20052005-01-16
CBarn24050 wrote:>>Subject: Re: So... What are the alternatives? Was: I don't use an RTOS >>because... >>From: Guy Macon http://www.guymaco > > >>I wonder how one could handle more >> >>>complex systems with no RTOS (or at least a multithread >>>cooperative scheduler) without getting into a big messy >>>buggy code. > > > Untill you can define what you want in something more specific terms than "more > complex" you'll just have to keep wondering.I guess you quoted the wrong guy. :-) Strictly speaking you are right, though IMNSHO the definition of either "complex" or "more complex" varies from case to case and from designer to designer. However, from the posts I have seen so far my question despite lacking a clear definition was clear enough to generate excelent posts. :-) Regards. Elder.
Reply by ●January 16, 20052005-01-16
Paul Keinanen wrote:> On Sat, 15 Jan 2005 15:22:26 -0500, "Michael N. Moran" > <mnmoran@bellsouth.net> wrote: >>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. > > A long time ago my group was developing multitasking applications on > PDP-11 under RSX-11. Most people had good experience in designing and > writing batch and interactive time share applications. After teaching > them about multiple tasks and some of the most important OS > mechanisms, it took several months until they independently could > split the applications into tasks and design the synchronisation and > communication between them. Even after that, you had to check their > code for stupid things, such as busy loops (as a heritage of their > batch and timesharing days).This sub-thread is contrasting rolling your own code scheduler and writing your own libc versus using an existing RTOS, and whether or not the RTOS is to be trusted. My experience is that at the core RTOS API's are the same and that the structure of a pre-emptive RTOS kernel is simple enough to be as reliable (perhaps more so) than most large libraries such as libc. As for having a team of inexperienced software engineers working on a project for which they are not qualified ... that's another issue ;-) -- 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 16, 20052005-01-16
Elder Costa wrote:> I have seen this multiprocessor approach proposal more often lately. I > am not sure if that is because I am paying more attention to the subject > or just because of a paradigm change though.I was trying to remember one of these articles just before I posted. Now I found it: http://www-128.ibm.com/developerworks/library/pa-migrate/ Regards.
Reply by ●January 16, 20052005-01-16
>> I have seen this multiprocessor approach proposal more often lately.I>> am not sure if that is because I am paying more attention to thesubject>I was trying to remember one of these articles just before I posted. >http://www-128.ibm.com/developerworks/library/pa-migrate/Hey, people read it! I'm flattered :)
Reply by ●January 16, 20052005-01-16
>Subject: Re: So... What are the alternatives? Was: I don't use an RTOS >because... >From: Elder Costa elder.costa@terra.com.br >Date: 16/01/2005 12:36 GMT Standard Time >Message-id: <34v5biF493l82U1@individual.net> > >CBarn24050 wrote: > >>>Subject: Re: So... What are the alternatives? Was: I don't use an RTOS >>>because... >>>From: Guy Macon http://www.guymaco >> >> >>>I wonder how one could handle more>>>>complex systems with no RTOS (or at least a multithread >>>>cooperative scheduler) without getting into a big messy >>>>buggy code. >> >> >> Untill you can define what you want in something more specific terms than >"more >> complex" you'll just have to keep wondering.>I guess you quoted the wrong guy. :-) Strictly speaking you are right, >though IMNSHO the definition of either "complex" or "more complex" >varies from case to case and from designer to designer. However, from >the posts I have seen so far my question despite lacking a clear >definition was clear enough to generate excelent posts. :-)Great posts maybe, but did they answer your question?
Reply by ●January 16, 20052005-01-16
Elder Costa wrote:> Paul E. Bennett wrote: >> Overall system resilience can be achieved much easier despite the number >> of physical connections. I also indicated that the system would have been >> (at minimum) a dual processor system in anycase. One system for control, >> the other system running a permit to operate. Even so, with the >> calculations performed on the system integrity, I favoured the many >> processors design because it was easier to prove that it met the >> integrity requirements. This was due to a lack of common mode issues >> between the various tasks that would have plagued the development within >> a single (or just two) processor(s). > > I think the right (if one can state there is a "right" anyway) solution > is highly system dependent. I used to favour one processor designs > because of (hardware) simplicity. It was a "let the software guys > solve" attitude even though I also did software.I guess that was the attitude back in the early 80's as almost everyone was trying to cram computing abilities into almost everything. Even today I am quite happy to do things in relay logic when that is the simplest solution. One can only discover the right approach by taking the time to explore the various ways of providing a solution and selecting the best in terms of apparent simplicity, time, costs and quality. Usually, when you get to systems that require one to deal with more than 20 I/O you should really start looking for the natural architecture of the problem. You can still look for the architecture of the problem below that level but it is usually very apparent . As I have indicated, I usually find that this is closely allied to the actuator distribution and groupings.> ..... After some (several :-) > ) years undergoing the pains of such an approach and after attending > some of Jack Ganssle's lectures I was struck by the perception of how > fool I was by chosing it (because it's quite obvious when one gives it > some thought). Just to cite an example I have a design in which a rotary > encoder is handled by the main processor. Putting a small > microcontroller there would make things much easier and reliable. The > main processor handles (proprietary) serial communication with some > acquisition modules. Another low end microcontroller would do the magic > and release the main processor for more apropriate duties, not to > mention would make the software design much easier. These are simple > examples.It is a quite scalable approach too.> I have seen this multiprocessor approach proposal more often lately. I > am not sure if that is because I am paying more attention to the subject > or just because of a paradigm change though.As the low end processing silicon gets less and less expensive to develop for and communication capabilities between them improve, it becomes easier and easier to support the strategy. I have been advocating the processor per drive strategy for 20+ years now. Especially when you realise that for almost any process or machine control actuator based solution there are only 28 types of control block. This is not a great many to have to develop strategies for.> I am in the process of designing a new architecture for new products and > that is the reason why I posted this questions. The posts so far have > been very interesting and enlightening. One thing at least is clear to > me right now: there is not a "one fits all" solution for the problem.As already stated, problem space needs analysis in order to determine what the structure of the problems architecture is, what tasks are necessary to accomplish the system goals and what risks are posed by achieving the solutions activities. Once you have looked at and thought about all of that you should start forming the simples and most appropriate strategy for achieving your solution. It is quite often easy to see where one of the 28 control blocks would likely fit in without expending too much brain power on it. -- ******************************************************************** Paul E. Bennett ....................<email://peb@a...> Forth based HIDECS Consultancy .....<http://www.amleth.demon.co.uk/> Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see http://www.feabhas.com for details. Going Forth Safely ..... EBA. www.electric-boat-association.org.uk.. ********************************************************************
Reply by ●January 16, 20052005-01-16
larwe@larwe.com wrote:>>>I have seen this multiprocessor approach proposal more often lately. > > I > >>>am not sure if that is because I am paying more attention to the > > subject > > >>I was trying to remember one of these articles just before I posted. >>http://www-128.ibm.com/developerworks/library/pa-migrate/ > > Hey, people read it! I'm flattered :) >I hadn't paid attention to the author's name until now. :-) My fault though - a matter of bad habit not looking at article's authors names. I look forward to reading the sequel. Brought PPC to my attention as a possible candidate for the main processor (thogh not necessarily for realtime tasks) in a new architecture. It's a pitty it lacks a built in LCD controller. Regards. Elder.
Reply by ●January 16, 20052005-01-16
CBarn24050 wrote:>>I guess you quoted the wrong guy. :-) Strictly speaking you are right, >>though IMNSHO the definition of either "complex" or "more complex" >>varies from case to case and from designer to designer. However, from >>the posts I have seen so far my question despite lacking a clear >>definition was clear enough to generate excelent posts. :-) > > > Great posts maybe, but did they answer your question?To some extent, yes. I will play with the idea of using a state machine based cooperative executive as pointed by some (I deployed the concept long ago but didn't design it apropriately and the implementation was awful). The thread also provided a lot of food for thought. Regards. Elder.
Reply by ●January 16, 20052005-01-16
>I hadn't paid attention to the author's name until now. :-) My fault >though - a matter of bad habit not looking at article's authors names.I>look forward to reading the sequel.The article series was tentatively set to be ten pieces long. To give you a sneak preview: The next article coming up (early Feb release date) talks about differences between x86 and PPC Linux startup. It also suggests a few different layouts for both the software bundle and the flash. Article #3 goes into details about the Linux distro shipped with the Kuro Box, and also how to upgrade it (some). Article #4 talks about building a web-administerable backend from a beginner's perspective (it sounds like a digression from the primary theme, but really it's not). Looks like they will be publishing them once a month, or thereabouts. I'm trying to keep at least two ahead.
