Предлагаю на рассмотрение уважаемым ембеддерам кооперативную операционную систему реального времени для малых и средних контроллеров AVR, правда никто не запрещает использовать ее для всех типов контроллеров. Существует два порта - под CodeVision и WinAVR.
Сразу же хочу оговориться, что понятие реального времени в случае кооперативных систем достаточно условно - это описано в статье на сайте и документации к ОС.
Используя эту систему начинаю разработку с проектирования ПО - используя упрощенную нотацию UML в бесплатном редакторе DIA.
Разрабатывать проекты получается быстрее, существенно легче стало обеспечивать модификацию, сопровождение и отладку программного обеспечения. Понятнее и прозрачнее стали тексты программ.

Адрес сайта - http://movilavn.narod.ru/

Зайти в раздел "Статьи", выбрать статью - "mRTOS - кооперативная операционная система для микроконтроллеров".
Для загрузки доступны сама ОС, документация и примеры использования.

Спасибо уже опробовал - понравилось.

Благодарствую за положительную оценку!
Буду рад увидеть Ваши мнения, пожелания и критику.
Стоит ли дорабатывать до preemptive версии?

Начинаем читать документацию, идущую в файле с mRTOS(стр. 2) :

А теперь прочитаем документацию к scmRTOS(стр. 7):

Ну и так далее - цельнотянутые куски из документации к scmRTOS.

И к тому же ось позиционируется как кооперативная, но от чего же такая пухленькая ?

А чего "пухленькая"?
Простой пример из 4 задач:
AVR Memory Usage
----------------
Device: atmega8535
Program: 1660 bytes (20.3% Full)
(.text + .data + .bootloader)
Data: 72 bytes (14.1% Full)
(.data + .bss + .noinit)
Build succeeded with 0 Warnings...

Стоит ли дорабатывать до preemptive версии?
Стоит. Хотя и так вполне работает хорошо (у меня в реальном проекте).
Еще бы порт на IAR...

До решения о написании собственной ОС, были изучены все доступные ОС, естественно и scmRTOS. Память у меня очень неплохая. Так, что ненароком повторил "цельнотянутые куски из документации к scmRTOS", но в документации это только общие слова(видно из вышеприведенных примеров). Но на всякий случай прошу прощения! Действительно важная, особенно техническая, часть документации - это эксклюзив. Это же касается идеи и кода.

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

Насчет preemptive ОС - уже несколько раз брался. Но при решении конкретных задач(проектов), существующая ОС, удовлетворяла всем требованиям. Проекты включали подключение к TCP/P, используя WizNET 5100. Работа с GSM, через модули SIMCOM. Куча датчиков.
Но тем не менее, все это уже на этапе проектирования отлично вписывалось в mRTOS.
Да и само пректирование упрощалось.
Т.е. пока не вижу проекта для 8-ми битных микроконтроллеров с необходимостью preemptive ОС.
Может быть не прав. Поправьте.

Это не память хорошая и не ненароком. Брать чужое и выдавать за свое называется по-другому.
Документация к scmRTOS:

Документация к mRTOS:


Документация к scmRTOS:

Документация к mRTOS:

Ну и так далее.

В документация к mRTOS читаем следующее(стр.13):

У avr-gcc нет отдельного Data Stack, а есть единый стек для хранения адресов возврата и данных. Указатель на верхушку стека также хранится в регистровой паре Y. Через r24, r25 передаются параметры в функцию.
avr-libc

alcosar - по существу вопроса у Вас, что нибудь есть?
Это о функционировании и удобстве применения предложенной ОС.
То, что Вы "цельнотянуто" процитировали из документации по GCC, поверьте я знаю.
Это просто вопрос терминологии - что и как называть Data Stack в разных компиляторах.

Брать чужое, что? Беллетристику?
Почитайте на досуге - "Embedded Multitasking with small microcontrollers" Keith E. Curtis.
Там найдете те же самые слова, только по английски.

Хочу напомнить, что на рассмотрение было представлено ПО, а не учебник по написанию ОС для встроенных систем.
К самой mRTOS есть какие-то претензии? К коду?

Вообще в чем Вы меня обвиняете. В том, что опубликовал свою ОС для свободного использования, а подложил чужую документацию, не иначе как в каких-то темных целях?

На досуге подумаю как изменить документацию, так, чтобы сказать то же самое, только совсем другими словами.

Не буду разбираться кто где плагиатор. Вот попался линк на "Embedded Multitasking with small microcontrollers" Keith E. Curtis.
hчсp://rapidshare.com/files/123380312/Embedded_Multitasking_with_small_microcontrollers.rar

Вас обвиняют в плагиате. И никакие благие цели типа "для свободного использования" этот плагиат не оправдывают.
Может вы и саму ОС откуда-то "одолжили"?

Один человек только протестировал!

Остальные контролеры из комитета по защите авторских прав видимо сверяли слово в слово документацию.
Общие фразы об устройстве ОС(плагиат) встречаются во многих учебниках посвященных операционным системам.
Кстати прежде чем бросаться словами надо понимать их значение. Плагиат подразумевает корыстные цели.

Видимо по существу дела толковых мнений не дождусь.
Ну и да ладно - любое хорошее дело не должно остаться безнаказанным!

А вы думали все прям ломанутся тестировать? С какой стати? Имхо, если человек не может описать своими словами, как работает его собственная операционка, то ничего хорошего от неё ждать не приходится.

Не надо изворачиваться. Речь идёт не об общих фразах, а о передирании один-в-один, причём бездумном. Плагиат - он всегда плагиат, независимо от целей.

Да уж, теперь вряд ли.

Не обижайтесь, просто принято перед использованием/тестированием чего-либо читать документацию. Поэтому первые вопросы возникли по документации. Если документация продукта "A" один в один повторяет документацию продукта "Б", то встаёт резонный вопрос. А чего такого в продукте "А"? По поводу "плагиата": лучше-бы вместо тупого копирования, сделали-бы просто ссылку "такой-то подход хорошо описан там-то". И написали только то, что касается вашего проекта (его особенности, плюсы и минусы, подходы, идеология, тесты, примеры использования и.т.п). И люди к вам потянутся =)

Проверил сам - да действительно почти совпадают несколько вступительных фраз!
Дико прошу извинений! Посыпаю голову пеплом! И т.д. и т.п.
Обязательно сделаю ссылку на scmRTOS. Отличная, кстати говоря ОС. Но не захотела работать на CodeVision.
Также и на остальную литературу с которой работал:
1. Иртегов Д.В. Введение в операционные системы. – СПб.: БХВ-
Петербург, 2002. – 624 с.: ил.
2. Столлингс В. Операционные системы, 4-е издание.: Перев. с англ. – М:
Издательский дом «Вильямс», 2002. – 848 с.: ил.
3. Гордеев А.В., Молчанов А. Ю. Системное программное обеспечение. –
СПб.: Питер, 2002. – 736 с.: ил.
4. Олифер Н.А., Олифер В.Г. Сетевые операционные системы. – СПб.:
Питер, 2001. – 544 с.: ил.
5. Таненбаум Э. Современные операционные системы. 2-е изд. – СПб.:
Питер, 2002. – 1040 с.: ил.
6. Алгоритмы планирования процессорного времени. И.С. Гусев

Если кто-либо действительно прочел документацию до конца, то там понятна разница в подходе и реализации.
А если бы уже проверили на простеньком прилагающемся демо, ну наверное так совсем все ясно стало!

че за базар?
граждане? код смотрите который вам предлагают, не нравится используйте другое.
я книгу пишу по GNU tools for ARM, часть текста будет "как я перевел из ...." и примеры не все мною будут писаны! и че теперь я плагиатор?
цель - дать информацию в нужном виде для решения поставленной задачи

Спокуха. Вы же ссылки не забудете сделать? Есть ссылка - это уже не плагиат а цитата =) Ссылки нужны ещё для того, если возникнут вопросы, можно было заглянуть в первоисточник и узнать ошибка возникла в процессе перевода или так и задумано было...

+1
Особенно учитывая то, что в "процитированных" фрагментах несколько раз повторяется слово "асинхронный", тогда как обсуждаемая ОС - кооперативка и там все переключения происходят синхронно.

Ну а по сути предложенных исходников

Мелочи, но сильно затрудняющие чтение - "исходные исходники" отформатированы так, как будто кто-то вставил цитату в форум без тега code. Понятно, что это исправляет один вызов indent или пара тыков в редакторе, но... "осадок остался"
А портированные на avr-gcc (с которых я начал) изобилуют маслом масляным комментариями вида
mRTOS_Tasks[mRTOS_InitTasksCounter].CurrentPriority = Priority; // установить текущий приоритет задачи
что тоже только затрудняет чтение.

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

Ну и - это уже касается порта avr-gcc - обёртки ATOMIC_BLOCK(ATOMIC_RESTORESTATE) всё равно напрочь затирают сохранённое в блоке задачи и восстановленное значение тем, которое "получили в наследство" от той задачи, с которой идёт переключение. Тот, кто портировал - мог бы это и заметить и вместе с автором оси задуматься над смыслом проделываемых операций.

Хитрая хитрость с "приоритетами"... Что это даёт?
Пусть есть четыре задачи(с приоритетами)
A(10) B(3) C(3) В(3)
Тогда, при условии, что все задачи что-то молотят, не переходят в ожидание, вызовы будут идти так
AAAAAAABCDABCDABCD
Итого на начальном участке выполняется только задача А, а на конечном идёт так, как будто у неё приоритет такой же, как у всех.
Если "приоритет", означает "суммарное время, отданное задаче", то зачем так сложно?
А есливтрое более высокий приоритет означает более выскоую частоту вызова, то задача решена в объёме средней температуры по больнице.
К примеру, сначала AAAAAAA просто тупо прокуртится в if( !flag ) DISPATCH; а потом флаг взведётся, но сначала выполнятся все низкоприоритетные, и только потом вернётся управление к А, она не будет вызываться чаще на этом участке.
Тут бы
ABACADABACADABACADA
но это требует совсем другого подхода.

А в таком виде, как оно есть, на мой взгляд, не имеет смысла. Только ОЗУ и код даром выброшены.

Может "ОЗУ и код даром выброшены", но мне эта ос оказалась по силам для понимания (ну тупой - scmRTOS не осилил).
Показалось что удобно:
в одной задаче обслуживается семисегментный индикатор, в другой кнопки, в третей энкодер, в четвертой тиристор, в пятой шим для полевика и все это на одном таймере (остальные заняты). Может можно было и по другому сделать, но с использованием mRTOS получилось наглядно и главное работает. Использовал Кодевижн, хотя пробовал и GCC.

Да еще вопрос автору - в старых версиях Кодевижена почему-то не удалось запустить, только в версии 2.хх.

для чего этот таймер использовали?

Не совсем так, точнее совсем не так. В документации нарисован алгоритм переключения. Он прост, но не до такой степени.
Будет так - ABACADABACADABACAD....... - именно когда все молотят. Т.е. задача А получит в три раза больше времени.
Проверьте в AVR Studio. Это просто.

Сохранение статусного регистра позволяет произвести анализ состояния, которое было до выхода из процесса.
Существует такая необходимость.

Причём тут это? Я где-то хоть слово сказал про то, что обсуждаемая ОС фигня, потому что не вытесняющая?
ОЗУ и код даром выброшены на вещи абсолютно не нужные (сохранение SREG в невытеснялке) и в данном исполнении при анализе на худший случай бесполезные ("кагбе" приоритеты)

Ну так и скажите - что будет хуже, если из обсуждаемой ОС убрать то, про что я сказал, что на него даром выброшены ресурсы. Неужели данные "приоритеты" так Вам помогли? Расскажите, какие они были и что это дало.
Возможно, всего два приоритета - "высокий" и "низкий" - два массива задач, задачи из второго вызываются по одной по очереди после полного прокрута первого массива - было бы ничем не хуже, ОЗУ было бы потрачено меньше, кода тоже, переключение быстрее.
А может и одного массива хватило бы, искать тех, кто дождался события (точно так же, как это сделано сейчас), при отсутствиии таковых продолжать топать по кругу по массиву.

Хм. Я просто смотрел код. Может чего недосмотрел, гляну позже ещё.

Например?

Странно. Разрабатывалась на версии 1.25.3.
И еще человек 5 работают в 1-ой версии.
Я конечно проверил и на 2-ой версии, тоже было все хорошо.
Но сам до сих пор сам сижу на 1.25.9.

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

Да, пропустил с наскоку то, что текущая задача на время поиска следующей принудительно переводится в suspend а после поиска назад в active.

Поскольку таки не в avr studio, а глазками по исходнику ходил - по дороге заметил, что
.delay анализируется без запрета прерываний и без явного специального порядка чтения старшего-младшего байта. Могут быть глюки.
Вроде бы ж я не пропустил нигде cli, хоть уже и почти три часа ночи

Кстати, мелочь, но в среднем
будет отрабатывать быстрее (даже если забыть на время про неатомарность доступа к delay), так как для не-ожидающих задач не будет зря зачитываться и проверяться delay. Да и логика понятнее -
если задача ожидает - то посмотрим, не пора ли её по таймеру проснуться
а не
если таймер занулился - то надо ещё глянуть, важно ли это
Аналогично с поиском по приоритету - да какая разница какой он, если задача не в active

А вот для чего может быть нужно сохранять статусный регистр процессора при переключении задач в кооперативной ОС - всё таки хотелось бы услышать. Тем более, что в avr-gcc варианте он восстанавливается.

для чего этот таймер использовали?
Это я про системный таймер 0.

Ну так и скажите - что будет хуже, если из обсуждаемой ОС убрать то, про что я сказал, что на него даром выброшены ресурсы. Неужели данные "приоритеты" так Вам помогли? Расскажите, какие они были и что это дало.
Я только за, просто хотел сказать, что использовал эту ОС как есть и меня это устраивает. Буду рад если Вы поможете автору усовершенствовать его ОС.
Это моя первая проба ОС. Исходник не изучал - попробовал пример. До этого делал без ОС - динамическая индикация на прерывании таймер 0, знкодер на int 0, кнопки в общем цикле. С ОС приоритет индикатора самый высокий, далее энкодер, потом кнопки и прочее. Знкодер используется без int 0 - пропусков нет, индикатор не мигает.
Хотелось бы, чтобы из одной задачи можно было остановить другую - типа STOP(N)

Это же совсем простая программа. А как быть, если одну из задач нагрузить на 1-WIRE ?

Согласен - 1-WIRE трудновато. У меня там используется KTY. Придется поставить дополнительную Tiny13 (шутка).
Кстати, это из другой темы (к ОС не имеет отношения), может подскажете, для 1-WIRE :
есть прерывания для обслуживания 7-сегментного индикатора,
есть датчик DS18B20,
для 1-WIRE нужны точные временные интервалы (задаю delay_us()),
прерывания делают временные интервалы непредсказуемыми,
как Вы решили бы подобную проблему?

Там критично только начало слота, первые 10-20 мкс.
На это время прерывания можно и отключить. А окончание слота довольно расплывчатое, там лишний десяток мкс роли не играет.
Если, конечно, в прерывании не стоит delay_us(), или ещё круче, delay_ms()

А если есть лишний УАРТ - то на него повесить - святое дело. И забыть микросекунды, как страшный сон.

1. Миллисекундные задержки строгому контролю не подлежат.
2. Для микросекундных помещаю текст приема /передачи бита в ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
3. После отработки одного бита не спешу переходить к следующему - вызываю idle() или отдаю управление, если использую protothread-подобную организацию сопрограмм, итд итп.

MrYuran: "А окончание слота довольно расплывчатое" - кстати да, это тоже за пределы ATOMIC_BLOCK выносится.

По теме:
Подробно не смотрел, времени особо не было, да и АВР как-то неактуален пока.
Какие есть сервисы межпроцессного взаимодействия? (сообщения, очереди и т.д.)
При беглом осмотре не нашёл упоминания. (кроме эвентов)

ОС была намеренно минимизирована. Чтобы уместилась даже на малые AVR типа 2313. Поэтому средства межпроцессорного взаимодействия такие, как сообщения, очереди, mailbox отсутствуют. В документации есть упоминание о том, как используя event организовать все это самостоятельно.

Асинхронно, синхронно. Асинхронно формируются(могут формироваться) event(прерывание). Синхронно передается управление. Это кооперативная операционная система - это + код вносят некоторые возможности RTOS.

Приоритеты. Кооперативная операционная система это сама ОС + прикладной код. Только тогда она может в какой мере заменить preemtive систему. Мой подход к проектированию таков - предположим есть 4 задачи. Есть период времени T приблизительно определенный суммой приоритетов процессов. Одна (первая) главная, вторая за период T может сгенирить 3 события, третья 2, четвертая 1. Назначаем приоритеты 1-ой 200, 2-ой 150, 3-ей 100, 4-ой 50. За время T каждой равномерно будет передано управление исходя из приоритетов. Приведенная схема проектирования упрощена. Но даже так работает!

Сохранение и восстановление статусного регистра. Сохраняем состояние процесса. Даже синхронно передавая управление, процесс может остаться в разных состояниях. При возврате анализируем статусный регистр. Иначе для сохранения состояния пришлось использовать статическую переменную. Экономия - не знаю? Но работает. Накладные расходы на это ничтожны. А возможность использования остается.

Да не нужен он, поскольку состояния описываются однозначно набором локальных переменных и счетчиком команд. Передача управления реализуется в точках, доступных на уровне сишного текста и прерывать выполнение сишного выражения никто не будет. А также глобально разрешать /запрещать прерывания и отдавать управление, не выходя из критической секции - такая свобода действий не нужна задачам.
Для preemptive -версии он только нужен - также, как и сохранять все регистры, РС и указатель стека.

О чём я и говорю - управление передаётся только синхронно на верхнем уровне функций процессов, поэтому кроме точки возврата ничего не надо сохранять, статусный регистр в том числе.

Я прошу конкретный пример, а не "есть возможность".

А теперь смотрим код:
Перед вызовом dispatch_task(switch_buf cpu_state) надо вычислить адрес начала массива cpu_state типа switch_buf.
для чего в регистры будет загружено значение переменной current_task, умножено на sizeof(struct TCB) и сложено с адресом начала массива tasks и смещением offsetof(struct TCB, cpu_state).
Таким образом, при входе в dispatch_task в регистре SREG всегда будут флаги, оставшиеся от этих вычислений, а не мифическое "состояние процесса". Я думал, что после критического замечания "по сути", которое Вы просили, Вы сможете сами критически глянуть на свой код.
Ещё понятно было бы, если бы dispatch_task() не принимал аргументов (какая разница - всё равно макрос берёт их из тех же глобальных параметров, кстати, это тоже несколько уменьшило бы код), тогда действительно в SREG был бы результат последних операций процесса перед вызовом диспетчера. Ну и как это применать? Так, чтоли?


Байт на задачу, при 4 задачах - больше 3% ОЗУ упомянутой tiny2313

Я бы хотел ось, которая поддерживает все. Опциями конечно, а не все сразу. Например, последовательные порты, работа с файловой системой, с ммс, с флешью, с озу, с индикаторами и т.д. А в урезанных осях против "своего цикла" я смысла не вижу.

Тогда уж и волшебное слово впридачу к нему: mbandala

Вы были полностью правы. Непростительная небрежность с моей стороны. Как при написании, так и при тестировании.
Также правы в том, что это никому не надо. Пообщался с народом использующим mRTOS и уже наклепавших кучу проектов, проектиков. Так они даже и не знали о сохранение и восстановлении SREG - потому как оно им совершенно не нужно! И как использовать тоже не понимают. У них и так все хорошо работало и работает.
Когда я писал этот код, то как приверженец автоматного стиля программирования для микроконтроллерных систем считал, что сохранение состояния процесса в момент передачи управления - это хороший стиль. Но в данном случае - действительно ни к чему.
Переписал, протестировал. Экономия небольшая - откомпилировал последний проект на ATMega162.
Старая версия - 2997 words 36.6% Flash
Новая версия - 2989 words 36.5% Flash
Но убран лишний код.

Перепаковал и залил на сайт. Доступно по прежней ссылке.

Благодарю за конструктивную критику!

Спасибо, очень полезная книга

А вы могли-бы выложить её в этом топике?
С рапиды доступно скачивание только преиум-пользователям по этому скачать не получилось.

Вопрос снят - с работы удалось зайти и скачать

To plus спасибо за волшебное слово

ОС создает скелетон кода. Далее подключайте необходимые драйвера. Для последовательных портов, параллельной и последовательной FLASH, параллельной и последовательной ОЗУ, индикаторами, разнообразными дачиками написал сам. Драйвера для контроллера Ethernet предоставляются фирмой-производителем. На просторах Интернета огромное количество разнообразных открытых библиотек, особенно под компилятор WinAVR, просто портируемых на CodeVision. Если очень упрощенно, то далее так - для отдельного устройства(драйвера), отдельный процесс(ы) с приоритетом(и), установленным по степени важности событий происходящим на этом устройстве.

"Embedded Multitasking with small microcontrollers" Keith E. Curtis. - http://www.onlinedisk.ru/file/257940/

А то я не знаю. Но вот собрать все вместе, оттестировать и опубликовать (бесплатно!) желающих не видно - место вакантно, занимайте. И в минусе не останетесь - найдутся желающие на заплатить за бесплатное, но адаптированное специально под них.

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

Nut/OS (ethernut), если если говорить о кооперативных ОС. Но она "тяжёлая" в том смысле, что в мелкий кристалл всё равно не полезет.

Так и не надо в мелкий. Надо мало секса с этими камнями и осями.


Так и я о том же. Достойно будет собрать под одним, а не говорить, что де мол поищи оно в инете.

Ну так вещь вроде как проверенная временем. Даже платы продаются в терре и у нас в имраде, но схемы открыты все и ось открыта.
Я давно смотрел, по железу там только два варианта, кажется, было (ethernut1 на мега103 с последующим апгрейдом на мегу128 и ethernut2 на атмеловском АРМ at91r4008, если не путаю), сейчас больше.
Управление памятью, система драйверов к железу, разные дополнительные платки, включая mp3-шную на VS1001
Всё подробно описано.
www.ethernut.de

Хотелось как-то посмотреть поплотнее, так как это хороший и большой пример того, что я плохо понимаю (если уж каждой задаче выделен свой стек - чего такого сильно экономит кооперативка по сравнению с вытеснялкой). Но как-то не срослось.

Только прыгать от задачи к задаче может чаще, пмсм, ввиду меньшего переключаемого контекста.

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

Посмотрел mRTOS, решил до кучи написать свою переключалку задач под CVAVR (1.25.3) кооперативная, карусельная со своими стеками. Нажмите для просмотра прикрепленного файла

В процессе отладки реального проекта, пришлось немножко все облагородить. Вроде работает.Нажмите для просмотра прикрепленного файла

Сделал вариант для мелких AVR. Прерывания теперь имеют свой стек данных, что позволяет сделать глубины стеков данных задач оптимальными. Требования для малых стеков:

FLASH: 20 байт переключение задач, 6 байт на опрос задачи, 12 байт инициализация задачи, 4-14 (+10 прерывания) байт на сохранение в стек локальных регистровых переменных при каждом переключении, того на три задачи 74 байта FLASH, если не считать сохранений при переключении

ОЗУ: 2 байта на задачу, байт на прерывания , 2 байта на задачу для каждого стека задачи (т.к. возникновение прерывания случайно в любом из стеков) , того на три задачи 13 байт лишнего ОЗУ .
Нажмите для просмотра прикрепленного файла