Kолко трябва да бъде Clock-а за превключване на тасковете в зависимост от МИПСовете и броя на тасковете?

Правило няма, зависи колко можеш да си позволиш.
Смисленото от практическа гледна точка е да си загубиш не повече от 10-15% от производителността на процесора за операционната система ...

би трябвало да има някаква приблизителна/относителна сметка
Гледам за 10 Мипса е около 10 мили сек
за 40 мипса 1 мили

Сметката е, че ти трябват 2х(машинни цикли за пуш-ване на текущия таск във стека=машинни цикли за поп-ване на следващия) + колкото машинни цикли можеш да си позволиш за реална обработка на следващ таск. Като , както каза Балкана, съотношението между двете трябва (въпрос на вкус) да е 1:6 до 1:10. Колкото по-малко съотношението, толкова повече губиш в непроизводителни машинни цикли (служебни, за превключване на тасковете), колкото по-рядко сменяш тасковете, толковапо-голям стек ти трябва, толкова по-бавно ти вървят отделните таскове. Поне при "Салво" е така.

@evc: Някъде по дебелите книги пишеше че real-time e относително понятие и с него се означава дефинираният краен период от време на реакция на системата на външно въздействие; Практическите съображения от моя гледна точка са следните:
1. Осигуряване на минималното време за реакция на системата за съответното приложение;
2. Минимален загубен ресурс на производителност на операционната система ...

Както винаги, решението е въпрос на компромис. Сигурно има някакъв теоретичен оптимум в който получаваш най-добрия вариант и от двете, но нямам идея дали за това пита TheWizard ...

Аз лично подхождам по чисто практически съображения и после проверявам дали получените резултати ме удовлетворяват.

Прощавай колега Балкана, наистина си мисля, че аз казвам същото. Т.е. точно това искам да кажа и аз. Наистина малко по-профанизиран стил използвах, но това е точно моята мисъл също. /Какво става днеска ве?/
Точка първа от твоите, зависи от времетраенето на самия таск, т.е. колко полезни машинни цикъла се отделят за реална обработка на данните и/или извършвани операции в изпълнението на всеки таск(задача, многозадачна среда - мултитаск, нали?). Значи тука се двете тенденции, от една страна минимално време за изпълнение на задача, от друга страна споделеност на ресурси - многозадачност.
Точка втора (по твоята таблица) - се дефинира със съотношението между "служебните" машинни цикли, т.е. машинните цикли необходими за превключване между изпълнението на текущата задача и изпълнението на следващата, като в това число влизат (понеже говорим за мултитаск при риъл тайм ОС) и машинните цикли за интерпретация на инструкция, но те от гледна точка на потребителя са непроизводителни. И това имах предвид, че както и ти казваш, не е строго зададено съотношение, а си варира, всеки си го избира, според приложенията си, и производителността на системата. Позволих си някакви числа да цитирам така като от личен опит. Или?

Едит: тези съотношения, които съм цитирал всъщност съвпадат също, защото като гледам 10%=1:10, 15%=1:7.

@evc: Сори, и аз не съм те разбрал съвсем правилно, напълно съм съгласен

Да попитам и аз: как си организирате стековете на отделните задачи?

Бате, в какъв смисъл как са организирани стековете - какво записвам в стека ли
точката на прекъсване, WREGs, статус и някой регистри...
Всъщност не съм работил със RTOS и реших да си спретна един елементарен за да понауча малко повече

При пиковете ми нарастват нагоре. Push-ването става с movwf PREINC2 или MOVFF REG,PREINC2. Обратното от POSTDEC2. Така винаги имам достъп до данните на върха (INDF2), което често, го ползвам за временна променлива. Не знам някои производители на компилатори от какви съображения са избрали обратната посока, но на мен така повечи ми допада, заради горното. Не ме интересува през колко банки минава, операциите за бъркане в него ги чрез другите индексни ги извършвам с пълно 12-битово адресиране. Контекста на задачата се запазва като се почне от стека с адреси за връщане (понеже е с променлива дължина), след това общо използваните регистри FSR0,FSR1,PROD,TBLPTR,TABLAT,BSR,STATUS,WREG. Като WREG е последен. В някои ситуации ползвам запазеното съдържание WREG, а и на останалите като параметри при изчакване/следене за някакво събитие.

за dsPIC30 и за новите пик24
прекъсването записва автоматично PCL & PCH
аз дозаписвам

push.d w0
push.d w2
push.d w4
push.d w6
push.d w8
push.d w10
push.d w12
push w14
push ACCAL
push ACCAH
push ACCAU
push ACCBL
push ACCBH
push ACCBU
push TBLPAG
push PSVPAG
push RCOUNT
push DCOUNT
push DOSTARTL
push DOSTARTH
push DOENDL
push DOENDH
push SR
push CORCON

WREG15 не се записва в стека - той е стек пойтнера, него го записвам във индексен масив(индекс на текущия таск) unsigned int *
масива мисля да го разширя във структора за инфо на таска

Ако на някой му е интересно, още някои подробности по организацията която прилагам при PIC18F.
Всичко е само на асемблер, като ползвам многопасов асемблер, понеже кода не е разположен линейно и се подрежда по време на асемблирането.
За всяка задача заделям една банка, същото и за OS-а. За ОС-а и "драйверите" заделям втората ( адрес 0x100), следват банките на задачите, накрая са разположени стековете, буферите и масивите.
Не ползвам опашки от съобщения, а така да ги нареча софтуерни прекъсвания на задачите (при обработка на събития извън прекъсване). Примерно извеждане на текущото време на всяка една секунда на дисплея.
Всяка задача има 3 нива на прекъсване (т.е. общо са 4 с основното състояние на задачата). При настъпване на събитие състоянието на задачата се запазва, след това се стартира обработката на прекъсването. Ако то бъде прекъснато от друга по-високо приоритетна задача или друго софтуерно прекъсване, контекста се запазва отново в стека на избраната задача. Задачата може динамично да променя нивото си на прекъсване, примерно за синхронизиране на достъпа до общи ресурси ( примерно дисплея ).
В банката на всяка задача първите 16 адреса ги ползвам за временни данни (нещо като overlay). Така имам общи подпрограми които могат да бъдат викани едновременно от всичките задачи (ака реетрантни).
Нивата на приоритет са също 4. Според събитието, което се изчаква/обработва, текущия приоритет също може да се променя динамично).

Off topic: The Wizard виждам ползваш dsPIC и PIC24. Ако нямаш нищо на против може ли да отвориш една тема за приложението им и какви ти са впечатленията. Просто ми е интересно.

Практически не съм ги ползвал, интересни са ми и ги разучавам
До колкото знам dsPIC на 30 Мипса греят и искат радиатор - 24ките са ги подобрили в това отношение и мах са на 40 мипса
От АСМ-то и С-то(микрочипските - други компилатори не ползвам за ПИК) - как да ти кажа - доста по добри са от 18ките

@БатеАз: Най-простия случай (не-preemptive) операционна система лесно се прави изцяло на С, като задачите не е нужно да работят в отделни стекове ... Така времето за превключване се минимизира. Е, има си съответните недостатъци