Schedulers

Like many things this is a "horses for courses" issue. Cooperative scheduling is certainly the simplest form of multi-tasking but may not be suitable for every situation you are dealing with. You can mix interrupt handling with cooperative scheduling very easily (I do quite often). Pre-emptive scheduling can be used when you have very complex task handling requirements that would be very difficult under coooperative scheduling.

When using interrupts with cooperative scheduling you must make the ISR very short and quick. This means keeping the ISR to a simple series of steps to just grab single items of data, perhaps increment the data space pointer and then return. [%X]

That sounds like a system where appropriate scheduling strategy might be most needed. There are always tasks that can wait until there is more time to do something (assuming you have enough processing power in the first place - if not then consider a better processor if one is available).

Probably, in which case he is not in the real world. There are a wide range of considerations in selecting appropriate processors for a particular project. Amongst these will also be considerations of overall system architecture, whether or not to use multiple processors inside the same box or distributed widely across the system.

I hardly consider that the basics are useless but I agree that sometimes they do seem like bland copies for that portion of some books. However, authors must ensure that there is a reasonable starting point for the rest of the concepts covered by the book. So, I expect that the initial chapter or two might be providing this basis. I can live with this easily enough as technical books in my own collection cover quite a wide range of topics so I am not so bothered by this aspect so much.

--
********************************************************************
Paul E. Bennett ....................
Forth based HIDECS Consultancy .....
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..
********************************************************************

"Martin" wrote

No.

When someone claims there is only one way it is sure proof there are many.

That there is a book claiming cooperative schedulers are the one true way -- well there are all sorts of books with all sorts of claims: healing with crystals, the universe was created 9:00 am, Monday October 12, 4015 BC ... [I guess it would have to be on a Sunday if you were Jewish].

The same assumption that leads to 9:00 am, October 12?: imagination == reality and no further investigation is necessary.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

"Martin" wrote

1) Is the author paid by the word?

2) The surest way to know something is to teach it. The first 1/3 of the book is the author sending _himself_ to a refresher course.

The review section often introduces the author's notation system, and this can be useful. Research papers often go along fine and then up pops a Chi-bar-sub-h without any explanation of what it is and from whence it came.

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/

not

books I

because the

serious

over and

It's simple economics. There are more newbies than "serious practitioners". To achieve reasonable sells figures - you need to target the largest possible audience.

Pre-Julian Calender dating then ;>

--

******************************************************************** Paul E. Bennett .................... Forth based HIDECS Consultancy ..... Mob: +44 (0)7811-639972 .........NOW AVAILABLE:- HIDECS COURSE...... Tel: +44 (0)1235-811095 .... see for details. Going Forth Safely ..... EBA. ********************************************************************

I suppose my point is that a book like this is unlikely to be the only book in someone's embedded programming library. And so, devoting a few chapters with the basics seems kind of pointless. The reader is very likely to either know the basics or have several books that cover the subject well (including, perhaps, the darn data sheet and programming manual from the chip maker).

This sort of thing is very common in a lot of the Windows programming books. I've actually caught books from different authors (but same publisher) that have EXACTLY the same content in the introductory section!

-Martin

Which may not be a bad thing - provided they are accurate. In the Windoze world this is extremely unlikely. Then there is also contending with the ever shifting sands of Billware. Never saw a standard he couldn't corrupt.

--
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

means

that

from

data-crunching

at

not

task

the

and

First I would say that this is a very good book, if a little odd in the mix of hardware/software. I would recommend it to beginners as a reference. Having said that, there are several sections that I disagree with. Generalisations or assumptions that are too limited.

The book does use 8051 as the target for each 'pattern' and the 8051 architecture does not lend itself to preemptive scheduling - tiny stack, separate XRAM, etc, maybe the author is biased by this.

Pont does not say that preemptive should never be used - but he does imply that it is often used when unnecessary - which I would definitely agree with.

I think good engineering is making the best compromises (cost/performance/resource/etc.), and to do this you need the experience or resource to be able to consider the widest variety of options. Options include both cooperative and preemptive and which is best is totally dependent on the application.

I often get support requests from people using FreeRTOS on very small systems in an inappropriate way, and have recently added a few pages to the documentation on this subject

The example is not necessarily the best as it was difficult to come up with something that could be covered from both extremes of solution.

Regards, Richard.

I wouldn't interpret his statements as going *that* far. He does make a point that preemptive schedulers get a lot more attention than they deserve among RTOS designs, particularly among commercial ones. And I think he's right on that count. OTOH, going commercial with a pre-emptive RTOS would tend to be considerably more feasible (because of fewer restrictions on application coding strategies) than with a cooperative one.

No. It essentially just means that interrupts don't get to induce instantaneous task switches.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Turning around this argument, it's a strong point of this particular book that it *can* usefully be the only book in someone's library.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.