mRTOS-кооперативная операционная система, порт CodeVision, порт WinAvr, mRTOS-кооперативная операционная система для AVR Опции

[LVII]

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

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

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

Сообщение отредактировал LVII - Oct 30 2009, 11:58

[oll]

Предлагаю на рассмотрение уважаемым ембеддерам кооперативную операционную систему реального времени

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

[LVII]

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

[alcosar]

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

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

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

Все приведенные ниже рассуждения, оценки, выводы основаны на личном опыте и знаниях автора и вследствие этого обладают известной долей субъективизма, что обуславливает наличие как неточностей, так и ошибок.

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

[_Pasha]

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

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

[oll]

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

А чего "пухленькая"?
Простой пример из 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...

[LVII]

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

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

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

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

[alcosar]

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

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

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

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

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

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

Таким образом, исходя из того, что основная функция ОС – поддержка
параллельного асинхронного исполнения разных процессов и взаимодействия
между ними, встает вопрос о планировании (Scheduling) процессов, т.е. когда ка-
кой процесс должен получить управление, когда отдать управление другому про-
цессу и проч. Эта задача возлагается (хоть и не полностью) на часть ядра ОС, на-
зываемой планировщиком (Scheduler). По способу организации работы плани-
ровщики бывают:

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

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

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

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

Data Stack используется для динамического хранения локальных
переменных, посредством его передаются параметры функций и сохраняются регистры во
время вызова функций обработки прерываний. В CodeVision для хранения адреса
вершины Data Stack используется Y-регистр (регистровая пара r28 и r29), в WinAVR
используется регистровая пара r24 и r25, а в ICCAVR регистровая пара r16 и r17.

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

Call-saved registers (r2-r17, r28-r29):
May be allocated by gcc for local data. Calling C subroutines leaves them unchanged. Assembler subroutines are responsible for saving and restoring these registers, if changed. r29:r28 (Y pointer) is used as a frame pointer (points to local data on stack) if necessary. The requirement for the callee to save/preserve the contents of these registers even applies in situations where the compiler assigns them for argument passing.

* Function call conventions:
Arguments - allocated left to right, r25 to r8. All arguments are aligned to start in even-numbered registers (odd-sized arguments, including char, have one free register above them). This allows making better use of the movw instruction on the enhanced core.

If too many, those that don't fit are passed on the stack.

[LVII]

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

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

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

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

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

Сообщение отредактировал LVII - Nov 1 2009, 07:40

[sensor_ua]

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

[AHTOXA]

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

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

[LVII]

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

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

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

[AHTOXA]

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

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

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

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

Видимо по существу дела толковых мнений не дождусь.

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

[Petka]

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

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

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

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

[LVII]

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

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

Сообщение отредактировал LVII - Nov 1 2009, 13:12

[klen]

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

[Petka]

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

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

[ReAl]

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

+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
но это требует совсем другого подхода.

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

[oll]

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

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

Сообщение отредактировал oll - Nov 1 2009, 17:32

[sensor_ua]

и все это на одном таймере

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

[LVII]

Хитрая хитрость с "приоритетами"... Что это даёт?
Пусть есть четыре задачи(с приоритетами)
A(10) B(3) C(3) D(3)
Тогда, при условии, что все задачи что-то молотят, не переходят в ожидание, вызовы будут идти так
AAAAAAABCDABCDABCD

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

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

[ReAl]

Может "ОЗУ и код даром выброшены", но мне эта ос оказалась по силам для понимания (ну тупой - scmRTOS не осилил).

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

Показалось что удобно:
в одной задаче обслуживается семисегментный индикатор, в другой кнопки, в третей энкодер, в четвертой тиристор, в пятой шим для полевика и все это на одном таймере (остальные заняты). Может можно было и по другому сделать, но с использованием mRTOS получилось наглядно и главное работает.

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

Будет так - ABACADABACADABACAD....... - именно когда все молотят.
Проверьте в AVR Studio. Это просто.

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

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

Например?

[LVII]

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

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

[haker_fox]

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

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

[ReAl]

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

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

Поскольку таки не в avr studio, а глазками по исходнику ходил - по дороге заметил, что

Код

        // Поиск задач в состоянии задержки.
        if (!tasks[i_shed].delay && tasks[i_shed].st == Wait) {
            pri = tasks[i_shed].current_pri;

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

Кстати, мелочь, но в среднем

Код

        if (tasks[i_shed].st == Wait && tasks[i_shed].delay == 0)  {

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

Например?

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

[oll]

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

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

[_Pasha]

С ОС приоритет индикатора самый высокий, далее энкодер, потом кнопки и прочее. Знкодер используется без int 0 - пропусков нет, индикатор не мигает.

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

[oll]

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

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

[MrYuran]

для 1-WIRE нужны точные временные интервалы (задаю delay_us()),
прерывания делают временные интервалы непредсказуемыми,
как Вы решили бы подобную проблему?

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

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

[_Pasha]

как Вы решили бы подобную проблему?

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

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

[MrYuran]

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

[LVII]

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

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

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

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

Сообщение отредактировал LVII - Nov 2 2009, 11:37

[_Pasha]

Даже синхронно передавая управление, процесс может остаться в разных состояниях. При возврате анализируем статусный регистр.

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

[ReAl]

Асинхронно, синхронно. Асинхронно формируются(могут формироваться) event(прерывание). Синхронно передается управление.

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

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

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

А теперь смотрим код:

Код

// Макрос - контекст текущей задачи                  
#define CPU_STATE (tasks[current_task].cpu_state)
// Макрос - переключатель задач
#define DISPATCH dispatch_task(CPU_STATE);
...
// Номер текущей задачи
extern char current_task;
// Массив структур TCB
extern struct TCB tasks[MAXTASKS];

Перед вызовом dispatch_task(switch_buf cpu_state) надо вычислить адрес начала массива cpu_state типа switch_buf.

Код

tasks[current_task].cpu_state

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

Код

    c = a + b;
    DISPATCH;
    if( SREG & (1<<SREG_Z) ) {
         // c присвоен 0 перед вызовом диспетчера
    }

Накладные расходы на это ничтожны

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

[Огурцов]

ОС была намеренно минимизирована

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

[plus]

попался линк на "Embedded Multitasking with small microcontrollers" Keith E. Curtis.
hчсp://rapidshare.com/files/123380312/Embedded_Multitasking_with_small_microcontrollers.rar

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

[LVII]

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

Код

    c = a + b;
    DISPATCH;
    if( SREG & (1<<SREG_Z) ) {
         // c присвоен 0 перед вызовом диспетчера
    }

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

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

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

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

[RA3WUM]

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

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

Сообщение отредактировал RA3WUM - Nov 3 2009, 10:59

[mempfis_]

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

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

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

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

Сообщение отредактировал mempfis_ - Nov 3 2009, 11:57

[LVII]

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

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

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

Сообщение отредактировал LVII - Nov 3 2009, 11:44

[Огурцов]

На просторах Интернета огромное количество разнообразных

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

[_Pasha]

место вакантно, занимайте.

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

[ReAl]

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

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

[Огурцов]

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

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

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

[ReAl]

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

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

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

[_Pasha]

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

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

[defunct]

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

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

[oleg_lwd]

Посмотрел mRTOS, решил до кучи написать свою переключалку задач под CVAVR (1.25.3) кооперативная, карусельная со своими стеками.  MyOS.zip ( 4.18 килобайт ) Кол-во скачиваний: 257

[oleg_lwd]

В процессе отладки реального проекта, пришлось немножко все облагородить. Вроде работает.  MyOS.zip ( 8.1 килобайт ) Кол-во скачиваний: 289

[oleg_lwd]

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

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

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

[oll]

Сделал вариант для мелких AVR.

Спасибо. Хотелось бы (для тупых) легонькое описание типа как у LVII.

[oleg_lwd]

Даже не и знаю что тут объяснять

void OS_yeld(void) - Смена стеков Z-указывает на текущий своп стека.

Идея сохранения локальных регистровых переменных (ЛРП) основана на том, что CV(У меня 1.25.3 у новых CV не знаю) при входе в функцию сохраняет их в стек данных в последнюю очередь (до 6 регистров ), этот стек и используется для сохранения ЛРП при смене задач, но задачи и сопроцедуры теперь НЕ сохраняют ЛРП, эта задача теперь возложена на ВЫЗЫВАЮЩЮЮ задачу.
Код для сохранения восстановления в стеке ЛРП такой же, как у самого компилятора, но что делает компилятор автоматически при входе и выходе из функции, для смены задач приходится делать вручную (подсмотрев код для сохранения восстановления в стеке ЛРП в asm файле, для CV 1.25.3 - шесть вариантов).

пример допустим 4 ЛРП, Swp –своп стека.

#asm("adiw R28,4");#asm("rcall __SAVELOCR4"); - сохранили ЛРП (__SAVELOCR4-подсмотрели asm)

Swp; Z указывает на Swp (в CV 1.25.3 работает)

OS_yeld(); - переход

#asm("rcall __LOADLOCR4");-восстановили ЛРП

Попытался как-то это автоматизировать с помощью дефайнов.

Начальная инициализация свопов стеков и первого входа в задачи дело вкуса разработчика как у меня сделано мне не нравится неудобно.
Таймеры , события, mutex – тоже дело вкуса разработчика.

Передача данных задаче через R22R23, пример есть для варианта для mega128

Кстати подобная идея для IAR где то на форуме уже была.

[rembas]

[quote name='LVII' date='Nov 3 2009, 15:38' post='671658']
ОС создает скелетон кода. Далее подключайте необходимые драйвера. Для последовательных портов, параллельной и последовательной FLASH, параллельной и последовательной ОЗУ, индикаторами, разнообразными дачиками написал сам. Драйвера для контроллера Ethernet предоставляются фирмой-производителем. На просторах Интернета огромное количество разнообразных открытых библиотек, особенно под компилятор WinAVR, просто портируемых на CodeVision. Если очень упрощенно, то далее так - для отдельного устройства(драйвера), отдельный процесс(ы) с приоритетом(и), установленным по степени важности событий происходящим на этом устройстве.

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


Уважаемый LVII проверил Ваш вариант mRTOS на Atmega 128. Собственно проект дергает 3-мя ножками с помощью 3-х тасков(инверсия пина). есть ряд вопросов:
1. если запускаю 1 таск есть разрывы между соседними "пачками" - откуда вообще пачки ? В мануале о них не слова. выход по DISPATCH.
2. если запускаю таск с выходом WAIT(x). Идет повторение со скважностью "пачек". ситуация от изменения х не зависит.
3. запуск 2 и более тасков дает такой же результат .
что с этим делать ? (сделано все по мануалу).

[rembas]

HELP Уважаемый LVII проверил Ваш вариант mRTOS на Atmega 128. Собственно проект дергает 3-мя ножками с помощью 3-х тасков(инверсия пина). есть ряд вопросов:
1. если запускаю 1 таск есть разрывы между соседними "пачками" 05.gif 05.gif - откуда вообще пачки ? В мануале о них не слова. выход по DISPATCH.
2. если запускаю таск с выходом WAIT(x). Идет повторение со скважностью "пачек". ситуация от изменения х не зависит.
3. запуск 2 и более тасков дает такой же результат .
что с этим делать ? (сделано все по мануалу).

[gabd]

Даже не и знаю что тут объяснять

Не знаю, актуален ли этот форум, тем более для oleg_lwd.
Но поинтересуюсь в целях повышения своей компьютерной безграмотности, что означает выделенное:
#define OS_DEF_TASK(n,x)Tswap x={ST_##n,DATA_ST_##n};char PST_##n @(ST_##n+1)

#define _YELD(x) {x;OS_yeld();}
, где x типа Tswap:

Код

typedef struct {
    #ifdef _STACK_ONE_BYTE_
    unsigned char sp;
    #else
    unsigned int sp;
    #endif
    #ifdef _DATA_STACK_ONE_BYTE_
    unsigned char dp;
    #else
    unsigned int dp;
    #endif
} Tswap;

[arhiv6]

В образовательных целях решил попробовать разобраться, как устроена это ОС. В процессе изучения исходного кода появились пару вопросов:
1) Насколько я понимаю, у каждой задачи есть свой контекст (стек вызовов и локальные переменные), при переключении между задачами контекст текущей задачи должен сохраняться и, когда это потребуется, восстанавливаться. В других ОС обычно при создании задачи пользователем явно указывается размер выделяемой памяти для хранения её контекста, а в этой ОС такого нет - я не вижу. Как в этой ОС в памяти хранится стек и локальные переменные для каждой задачи?
2) В исходниках есть несколько функций, написанных на ассемблере - насколько я понял, в них проводятся какие-то манипуляции с указателями на вершину стека. А почему написано на ассемблере - это такая максимальная оптимизация по скорости или на СИ этого просто не сделать?
Заранее спасибо за ответы!

[gabd]

Если об ОС от oleg_lwd, имхо (я сам учусь )

1) явно указывается размер выделяемой памяти

в main2.c

Код

// глубина стека данных
#define L_SD_MAIN 16
#define L_SD_1    16
#define L_SD_2    16
#define L_SD_3    16
// глубина стека
#define L_S_MAIN 16
#define L_S_1    16
#define L_S_2    16
#define L_S_3    16

(для реальной задачи 16 - маловато)
далее os2.h

Код

// абсолютные стеки      
#define DATA_ST_MAIN SRAM_BEGIN+_DATA_STACK
#define DATA_ST_1 DATA_ST_MAIN-L_SD_MAIN
#define DATA_ST_2 DATA_ST_1-L_SD_1
#define DATA_ST_3 DATA_ST_2-L_SD_2
#define DATA_ST_4 DATA_ST_3-L_SD_3
#define DATA_ST_5 DATA_ST_4-L_SD_4
#define DATA_ST_6 DATA_ST_5-L_SD_5

#define _STACK _HEAP_START_-1
#define ST_MAIN _STACK
#define ST_1 ST_MAIN-L_S_MAIN-2
#define ST_2 ST_1-L_S_1
#define ST_3 ST_2-L_S_2  
#define ST_4 ST_3-L_S_3  
#define ST_5 ST_4-L_S_4  
#define ST_6 ST_5-L_S_5

[arhiv6]

gabd, нет, вопросы были о mRTOS.

[gabd]

Наконец-то, скачал этот mRTOS (на работе narod блокирован, дома - забываю )
Мои наблюдения - поправьте, если не прав.
Похоже, всё упрощено. (Имхо, можно ещё проще - simple task switcher)

стек вызовов и локальные переменные

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


Сообщение отредактировал gabd - Mar 15 2016, 07:49