Вопрос к пользователям наиболее часто обсуждаемых здесь embedded операционных систем:
1)можно ли в них организовать режим когда процессор будет 80% времени находиться в ISR?
Т.е. прерывания идут с такой большой частотой, что процессор 80% времени занимается обработкой прерываний. Или такой режим нагрузки в этих ОС не предусмотрен?
2) Можно ли получить в них частоту следования прерываний каждые 200 тактов (200Т) процессора при том что сам обработчик прерывания (ISR) выполняется 150Т? Если нет, то какая максимальная частота (выраженная в тактах) поддерживается?

ИМХО: При указанных загрузках процессора в ISR (еще не известно в них должны использоваться сервис или нет) полноценно использовать OS не получиться (с сервисами в ISR просто невозможно).
Почитайте книжки/доки по указанным системам, тогда станет более понятно зачем OS вообще и когда ее следует и можно пользовать, в двух словах этого не рассказать.

Не.., отлично будет работать. 20% же остается.
У какого нибудь ARM11 эти 20% будут как 200% у какой нить меги.
А вот с тактами напряженка, никто их прецизионно не считает на серьезных чипах ибо невозможно посчитать, сложная шинная архитектура мешает.
Можно ориентироваться только в доверительных интервалах тактов или времени.
Но даже при 99% загрузке проца чем угодно, хоть ISR, хоть DMA операционка работает как ни в чем не бывало. Важно только чтоб real-time задачи укладывались в тот оставшийся процент.

Много написано, что всегда и везде необходимо обеспечивать минимальное время пребывания в процедурах обработки прерывания. 80% времени в прерываниях - это потому, что так обработчики написаны, или прерывания прут сплошным потоком?

Зря значит писали.
Есть разные подходы в операционках.
Есть подходы где практически без разницы где обрабатывать логику приложения, хоть в ISR хоть в основном потоке.
Вот только ISR имеют иерархию.
Есть прерывания вообще вне контекста операционки. Вот они обычно и занимают много времени, хоть до 90% поскольку обслуживают скоростную периферию.
Есть легкие прерывания, в которых разрешение только пара тройка сервисов RTOS. И есть тяжелые прерывания где разрешены почти все сервисы оси. И еще есть вариации, как отложенные прерывания и т.д.

У меня получилось... Меня интересовало: а как с этим дело обстоит во всяких юкосах/микосах/эмбедед-линуксуниксах/эсцээмРтосах? Они это позволяют сделать?



Да я не предлагаю их считать, просто прикинув частоту прерываний я написал, что они будут происходить каждые 200 тактов и спросил справяться ли RTOS, используемые участниками форума с такой задачей


Да



Вот их то я имею в виду в своём вопросе

Тут вы зацепили за живое, конечно.
В портах публикуемых для uCOS действительно нет техники и примеров реализации ISR вне контекста RTOS и как в них сохранить связь с RTOS.
Это глубоко интимное дело для каждого семейства микроконтроллеров.
Решение всегда находится, но непереносимое на другие платформы. Поэтому оно наверно и не обсуждается в рамках RTOS, это дело драйверов и BSP.

Зря зацепились. Полагаю, что под "операционкой" которая у Автора топика "получилась", подразумевается на самом деле вариации на тему вечного цикла . Вы пытаетесь объяснять совсем другое.

Откуда такие предположения? Когда что-то кажется - креститься надо.
У меня полноценная (насколько это возможно сделать в условиях: 4Мгц тактовой и Target MCU = ATmega8515 и 512 байт RAM) RTOS, поддерживающая две политики диспетчеризации: карусель со сменой потоков по истечению выделенного им кванта и вытесняющую, со сменой потока по Евентам. Причём вытесняющая политика поддерживает как статические так и динамические приоритеты потоков.
Поддерживаются блокирующие ине блокирующие сервисы ядра.. Монопольный режим захвата CPU (при отключенной диспетчеризации). Да много чего ещё....

Вы уж как-то определитесь либо карусель, либо кому-то кванты времени выделяют и тогда это не карусель из потоков .

Естественно, только исключительно из чтения Ваших сообщений. Коих, впочем, достаточно много для того, что-бы составить мнение.

Не собираюсь дальше упражняться с Вами в жонглировании терминологией и заниматься схоластикой (говоря по простому флудом)..
Может я не настолько силён в терминологии (или просто мы с Вами читали разные книги и доки), но я разработал свою RTOS (не знаю как Вы?). И она прекрасно работает.
Если у Вас есть что сказать по существу вопроса - говорите.. А флуд не украшает на форуме даже Админа.
И если Вы делаете какие-то свои умозаключения из моих сообщений, я бы попросил Вас приводить тогда цитаты, на основании которых Вы делаете такие умозаключения

И кстати Вы правы... Поспешишь-людей насмешишь... Никакие не равные кванты времени у меня выделяются каждому потоку карусели... Следующий поток в карусели запускается после того как предыдущий сам по свой инициативе пошлёт сигнал ядру типа "я закончил"

А через равные кванты времени у меня запускается не очередной поток карусели, а вся карусель (т.е. диспетчер карусели). Вот я и описАлся. Т.е. через равные промежутки времени у меня управление передаётся диспетчеру карусели, который начинает крутить свои потоки пока его не вытеснят... Т.е. я реализовал это так, чтобы низкоприоритетной каруселе по-любому доставалось время.

Пожалуй три штуки. Естественно, то, что не стыдно (не жонглируя терминами на карусели) операционной системой назвать. Последние годы веду собственную веточку FreeRTOS.

По существу, насколько можно было, ответил AlexandrY. Добавить особо нечего из-за собственно отсутствия сколь-нибудь конкретного вопроса.

Вот именно, посему разговоры в стиле "А у нас в квартире газ операционная система, а у вас?"
не стоило даже начинать.

Если Вы не заметили, то привожу "шапку" этой темы



P.S. zltigo !!! Несколько раз прочитал все сообщения в теме...Как не старался не смог НИ ОДНОГО СЛОВА найти из всех Ваших высказываний, хотя бы отдалённо относящихся к теме... И тогда какой смысл Вашего литературного творчества в этой теме? Как другие участники не будут флудить если сам Админ флудит и появляется в теме, чтобы просто посеять недовольство автором темы

А я Вам ничего и не говорил ввиду полного отсутстствия "темы" для разговора. Я говорил AlexandrY. С ним разговор на затронутую ИМ тему готов продолжить.

А разве это вежливо в теме автора разговаривать с другим участником на совсем другие темы? Или этим Вы хотели продемонстировать своё неуважение ко мне?

Короче я вижу что благодаря Вашим стараниям (поздравляю Вас. Вы добились своего - вывели меня из себя. Троллинг работает на ура) тема засрана нашими с Вами разборками... Можете смело её удалять, потому что никто в ней по теме уже писать не будет....Спасибо Вам большое. Вы маладец..

А чего ждали, что все кинуться обсуждать неочемную тему?
А потом еще выяснилось что вами изобретен "вечный двигатель", который еще и показать нельзя.
После этого тему точно можно закрыть, зачем воду в ступе толочь, а "вечный двигатель" пусть трудится...

А можно посмотреть на это чудо (или хотя бы на его интерфейс)?
И еще пара вопросов - на чем писали, насколько она универсальна?
Если вытесняющая многозадачность - по идее нужны отдельные стеки на каждый процесс - как же вам удалось уложиться в 512 байт?

Ну и что тут невыполнимого? Я на ATmega48 с scmRTOS 3-4 процесса безболезненно запускаю. Всё от задачи зависит.

Не знаю чего я ждал, но уж чего я никак не ожидал, что сам модератор начнёт заниматься троллингом в моей теме.
Я бы Вас всё-таки попросил бы (хоть Вы и модератор) вести себя более политкорректно и воздерживаться от такого рода оценок, а говорить по существу обсуждаемого вопроса. Советую просто не читать мои "неочёмные" темы. От этого только нервы целей будут как у меня, так и у Вас



Писал на АСМ-е разумеется. Универсальна настолько, что может работать на всех микроконтроллерах AVR.

Есть отдельные PC- и DATA-стеки: 8 байт PC-стек и 12 байт DATA-стек на каждую "тяжеловесную" нить

P.S. А вообще, Господа, здесь не мной разработанная RTOS обсуждается. Смотрите внимательней головное сообщение темы

Отсутствует даже место для сохранения всего контекста задачи. Посему говорить о том, что существует некая "вытесняющая многозадачность" совершенно не приходится. Соответственно такты на "якобы переключение" сравнивать у этой системы и на реальное переключение контекста у систем помянутых в заголовке совершенно бессмысленно.

Здесь, с Вашей подачи обсуждается и некоторая "система" которая якобы отбеспечивает заявленные при начале темы параметры. Собственно на "вопросы" в шапке темы, могу еще практически повторить
(для реально желающих узнать ответы на вопрос) сказанное другими:
- система совершенно спокойно может находится 80% в прерывании;
- время реакции на прерывание использующее системные вызовы определяется в основном длительностью критических секций операционной системы из коих самая тяжелая это шедулер и работа с контекстом задач;
- для прерываний не использующих системные сервисы, или не использущих некоторве тяжелые, например то-же переключение контекста, при соответствующих усилиях зависящих от возможносей конкретной платфрмы времена реакций могут быть других порядков.
- прежде, чем проектировать нечто c 80% загрузкой в прерывании надо крепко подумать о правильности подхода к делу вообще.

А подобные завления по отношению ко мне, я оставлю на Вашей совести, хотя, как Модератор попрошу воздержаться от замусоривания тем.

Делаете априори не верное предположение и как следствие не верные выводы. Разве я Вам говорил, что у меня не сохраняется контекст задачи? Очень даже сохраняется: каждой задаче выделяется 16 байт под дамп контекста. Вы, на будущее, если что не ясно - лучше спросите, а не стройте свои домыслы. Вы же не телепат? Или телепат?


Во-первых, меня интересовало не совсем то, о чём Вы говорите. Незря же я говорил про такты в головном сообщении темы
А во-вторых, Вы отвечаете в общем (не приводя конкретных цифр). А меня интересует конкретная реализация в конкретных, перечисленных в названии темы RTOS, с приведением конкретных цифр

В данном конкретном случае я больше, чем телепат - я знаю, что у AVR 32 регистра общего назначения, которые в поминаемых Вами 16 байтах не сохранить. Посему речь о системе с вытесняющей многозадачностью просто не идет. Даже если Вы и будете повторять "халва...халва...халва" "вытесняющая многозадачность...вытесняющаяя многозадачность" "во рту слаще не станет" это в реальности ничего не изменит. Пока, с каждым Вашим постом я получаю очередное подтверждение своему диагнозу изложенному ранее:



Ну так изучите этот вопрос по их исходникам. Узнаете много полезного уже после ознакомления в первыми несколькими.

Это уже вообще пипец.... А если б там было 512 регистров? То я долже бы был обязательно их все использовать? А иначе это будет не RTOS? Тем более не вытесняющая?

Ну так и выкладите исходники, как здесь уже предлагалось. Разговор станет более предметным. :-) А так, бить себя пяткой в грудь и кричать "Да Я, да Я ... !" мы все умеем...

А Вы тоже считаете, что вытесняющая RTOS или не вытесняющая зависит от того, входят в контекст потока вообще все имеющиеся в процессоре регистры или нет?

А насчёт "пятки в грудь" и выкладывания исходников....
Когда я создам тему, посвящённую своей RTOS, тогда и выложу.. А в этой теме речь не о ней.. Прочтите внимательно головное сообщение темы

Зачем, тогда было все остальное Ваше неумное бахвальство? Вас кто-то за язык тянул? Вроде нет.