Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: mRTOS-кооперативная операционная система, порт CodeVision, порт WinAvr
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > AVR
Страницы: 1, 2
LVII
Предлагаю на рассмотрение уважаемым ембеддерам кооперативную операционную систему реального времени для малых и средних контроллеров AVR, правда никто не запрещает использовать ее для всех типов контроллеров. Существует два порта - под CodeVision и WinAVR.
Сразу же хочу оговориться, что понятие реального времени в случае кооперативных систем достаточно условно - это описано в статье на сайте и документации к ОС.
Используя эту систему начинаю разработку с проектирования ПО - используя упрощенную нотацию UML в бесплатном редакторе DIA.
Разрабатывать проекты получается быстрее, существенно легче стало обеспечивать модификацию, сопровождение и отладку программного обеспечения. Понятнее и прозрачнее стали тексты программ.

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

Зайти в раздел "Статьи", выбрать статью - "mRTOS - кооперативная операционная система для микроконтроллеров".
Для загрузки доступны сама ОС, документация и примеры использования.
oll
Цитата(LVII @ Oct 30 2009, 16:53) *
Предлагаю на рассмотрение уважаемым ембеддерам кооперативную операционную систему реального времени

Спасибо уже опробовал - понравилось.
LVII
Благодарствую за положительную оценку!
Буду рад увидеть Ваши мнения, пожелания и критику.
Стоит ли дорабатывать до preemptive версии?
alcosar
Начинаем читать документацию, идущую в файле с mRTOS(стр. 2) :
Цитата
Всю приведенные ниже выкладки, рассуждения и оценки являются результатом личного опыта и знаний автора, поэтому обладают долей субъективизма и могут содержать ряд неточностей и спорных моментов.

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

Ну и так далее - цельнотянутые куски из документации к scmRTOS.
crying.gif
_Pasha
Цитата(alcosar @ Oct 30 2009, 20:14) *
Ну и так далее - цельнотянутые куски из документации к scmRTOS.
crying.gif

И к тому же ось позиционируется как кооперативная, но от чего же такая пухленькая ? crying.gif
oll
Цитата(_Pasha @ Oct 30 2009, 23:16) *
И к тому же ось позиционируется как кооперативная, но от чего же такая пухленькая ? crying.gif

А чего "пухленькая"?
Простой пример из 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
Цитата(alcosar @ Oct 30 2009, 19:14) *
Ну и так далее - цельнотянутые куски из документации к scmRTOS.
crying.gif


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

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

Насчет preemptive ОС - уже несколько раз брался. Но при решении конкретных задач(проектов), существующая ОС, удовлетворяла всем требованиям. Проекты включали подключение к TCP/P, используя WizNET 5100. Работа с GSM, через модули SIMCOM. Куча датчиков.
Но тем не менее, все это уже на этапе проектирования отлично вписывалось в mRTOS.
Да и само пректирование упрощалось.
Т.е. пока не вижу проекта для 8-ми битных микроконтроллеров с необходимостью preemptive ОС.
Может быть не прав. Поправьте.
alcosar
Цитата(LVII @ Oct 31 2009, 15:19) *
До решения о написании собственной ОС, были изучены все доступные ОС, естественно и 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 есть какие-то претензии? К коду?

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

На досуге подумаю как изменить документацию, так, чтобы сказать то же самое, только совсем другими словами.
sensor_ua
Не буду разбираться кто где плагиатор. Вот попался линк на "Embedded Multitasking with small microcontrollers" Keith E. Curtis.
hчсp://rapidshare.com/files/123380312/Embedded_Multitasking_with_small_microcontrollers.rar
AHTOXA
Цитата(LVII @ Nov 1 2009, 12:00) *
Вообще в чем Вы меня обвиняете. В том, что опубликовал свою ОС для свободного использования, а подложил чужую документацию, не иначе как в каких-то темных целях?


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

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

Видимо по существу дела толковых мнений не дождусь.
Ну и да ладно - любое хорошее дело не должно остаться безнаказанным!
AHTOXA
Цитата(LVII @ Nov 1 2009, 16:56) *
Один человек только протестировал!

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

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

Да уж, теперь вряд ли.
Petka
Цитата(LVII @ Nov 1 2009, 14:56) *
Один человек только протестировал!

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

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

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

Если кто-либо действительно прочел документацию до конца, то там понятна разница в подходе и реализации.
А если бы уже проверили на простеньком прилагающемся демо, ну наверное так совсем все ясно стало!
klen
че за базар?
граждане? код смотрите который вам предлагают, не нравится используйте другое.
я книгу пишу по GNU tools for ARM, часть текста будет "как я перевел из ...." и примеры не все мною будут писаны! и че теперь я плагиатор?
цель - дать информацию в нужном виде для решения поставленной задачи
Petka
Цитата(klen @ Nov 1 2009, 16:18) *
че за базар?
граждане? код смотрите который вам предлагают, не нравится используйте другое.
я книгу пишу по GNU tools for ARM, часть текста будет "как я перевел из ...." и примеры не все мною будут писаны! и че теперь я плагиатор?
цель - дать информацию в нужном виде для решения поставленной задачи

Спокуха. Вы же ссылки не забудете сделать? Есть ссылка - это уже не плагиат а цитата =) Ссылки нужны ещё для того, если возникнут вопросы, можно было заглянуть в первоисточник и узнать ошибка возникла в процессе перевода или так и задумано было...
ReAl
Цитата(Petka @ Nov 1 2009, 15:34) *
Спокуха. Вы же ссылки не забудете сделать? Есть ссылка - это уже не плагиат а цитата =) Ссылки нужны ещё для того, если возникнут вопросы, можно было заглянуть в первоисточник и узнать ошибка возникла в процессе перевода или так и задумано было...
+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.хх.
sensor_ua
Цитата
и все это на одном таймере

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


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

Сохранение статусного регистра позволяет произвести анализ состояния, которое было до выхода из процесса.
Существует такая необходимость.
ReAl
Цитата(oll @ Nov 1 2009, 19:23) *
Может "ОЗУ и код даром выброшены", но мне эта ос оказалась по силам для понимания (ну тупой - scmRTOS не осилил).
Причём тут это? Я где-то хоть слово сказал про то, что обсуждаемая ОС фигня, потому что не вытесняющая?
ОЗУ и код даром выброшены на вещи абсолютно не нужные (сохранение SREG в невытеснялке) и в данном исполнении при анализе на худший случай бесполезные ("кагбе" приоритеты)

Цитата(oll @ Nov 1 2009, 19:23) *
Показалось что удобно:
в одной задаче обслуживается семисегментный индикатор, в другой кнопки, в третей энкодер, в четвертой тиристор, в пятой шим для полевика и все это на одном таймере (остальные заняты). Может можно было и по другому сделать, но с использованием mRTOS получилось наглядно и главное работает.
Ну так и скажите - что будет хуже, если из обсуждаемой ОС убрать то, про что я сказал, что на него даром выброшены ресурсы. Неужели данные "приоритеты" так Вам помогли? Расскажите, какие они были и что это дало.
Возможно, всего два приоритета - "высокий" и "низкий" - два массива задач, задачи из второго вызываются по одной по очереди после полного прокрута первого массива - было бы ничем не хуже, ОЗУ было бы потрачено меньше, кода тоже, переключение быстрее.
А может и одного массива хватило бы, искать тех, кто дождался события (точно так же, как это сделано сейчас), при отсутствиии таковых продолжать топать по кругу по массиву.

Цитата(LVII @ Nov 1 2009, 21:11) *
Будет так - ABACADABACADABACAD....... - именно когда все молотят.
Проверьте в AVR Studio. Это просто.
Хм. Я просто смотрел код. Может чего недосмотрел, гляну позже ещё.

Цитата(LVII @ Nov 1 2009, 21:11) *
Сохранение статусного регистра позволяет произвести анализ состояния, которое было до выхода из процесса.
Существует такая необходимость.
Например?
LVII
Цитата(oll @ Nov 1 2009, 19:23) *
Да еще вопрос автору - в старых версиях Кодевижена почему-то не удалось запустить, только в версии 2.хх.


Странно. Разрабатывалась на версии 1.25.3.
И еще человек 5 работают в 1-ой версии.
Я конечно проверил и на 2-ой версии, тоже было все хорошо.
Но сам до сих пор сам сижу на 1.25.9.
haker_fox
Цитата(klen @ Nov 1 2009, 21:18) *
я книгу пишу по GNU tools for ARM, часть текста будет "как я перевел из ...." и примеры не все мною будут писаны! и че теперь я плагиатор?

Для исключения подобного рода недоразумений, должны быть обязательно ссылки на первоисточник!
ReAl
Цитата(ReAl @ Nov 1 2009, 21:17) *
Я просто смотрел код. Может чего недосмотрел, гляну позже ещё.
Да, пропустил с наскоку то, что текущая задача на время поиска следующей принудительно переводится в suspend а после поиска назад в active.

Поскольку таки не в avr studio, а глазками по исходнику ходил - по дороге заметил, что
Код
        // Поиск задач в состоянии задержки.
        if (!tasks[i_shed].delay && tasks[i_shed].st == Wait) {
            pri = tasks[i_shed].current_pri;
.delay анализируется без запрета прерываний и без явного специального порядка чтения старшего-младшего байта. Могут быть глюки.
Вроде бы ж я не пропустил нигде cli, хоть уже и почти три часа ночи smile.gif

Кстати, мелочь, но в среднем
Код
        if (tasks[i_shed].st == Wait && tasks[i_shed].delay == 0)  {
будет отрабатывать быстрее (даже если забыть на время про неатомарность доступа к delay), так как для не-ожидающих задач не будет зря зачитываться и проверяться delay. Да и логика понятнее -
если задача ожидает - то посмотрим, не пора ли её по таймеру проснуться
а не
если таймер занулился - то надо ещё глянуть, важно ли это
Аналогично с поиском по приоритету - да какая разница какой он, если задача не в active

Цитата(ReAl @ Nov 1 2009, 21:17) *
Например?
А вот для чего может быть нужно сохранять статусный регистр процессора при переключении задач в кооперативной ОС - всё таки хотелось бы услышать. Тем более, что в avr-gcc варианте он восстанавливается.
oll
для чего этот таймер использовали?
Это я про системный таймер 0.

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

Это же совсем простая программа. А как быть, если одну из задач нагрузить на 1-WIRE ? wink.gif
oll
Цитата(_Pasha @ Nov 2 2009, 11:28) *
Это же совсем простая программа. А как быть, если одну из задач нагрузить на 1-WIRE ? wink.gif

Согласен - 1-WIRE трудновато. У меня там используется KTY. Придется поставить дополнительную Tiny13 biggrin.gif (шутка).
Кстати, это из другой темы (к ОС не имеет отношения), может подскажете, для 1-WIRE :
есть прерывания для обслуживания 7-сегментного индикатора,
есть датчик DS18B20,
для 1-WIRE нужны точные временные интервалы (задаю delay_us()),
прерывания делают временные интервалы непредсказуемыми,
как Вы решили бы подобную проблему?
MrYuran
Цитата(oll @ Nov 2 2009, 10:20) *
для 1-WIRE нужны точные временные интервалы (задаю delay_us()),
прерывания делают временные интервалы непредсказуемыми,
как Вы решили бы подобную проблему?

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

А если есть лишний УАРТ - то на него повесить - святое дело. И забыть микросекунды, как страшный сон.
_Pasha
Цитата(oll @ Nov 2 2009, 10:20) *
как Вы решили бы подобную проблему?

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 каждой равномерно будет передано управление исходя из приоритетов. Приведенная схема проектирования упрощена. Но даже так работает!

Сохранение и восстановление статусного регистра. Сохраняем состояние процесса. Даже синхронно передавая управление, процесс может остаться в разных состояниях. При возврате анализируем статусный регистр. Иначе для сохранения состояния пришлось использовать статическую переменную. Экономия - не знаю? Но работает. Накладные расходы на это ничтожны. А возможность использования остается.
_Pasha
Цитата(LVII @ Nov 2 2009, 14:34) *
Даже синхронно передавая управление, процесс может остаться в разных состояниях. При возврате анализируем статусный регистр.

Да не нужен он, поскольку состояния описываются однозначно набором локальных переменных и счетчиком команд. Передача управления реализуется в точках, доступных на уровне сишного текста и прерывать выполнение сишного выражения никто не будет. А также глобально разрешать /запрещать прерывания и отдавать управление, не выходя из критической секции - такая свобода действий не нужна задачам.
Для preemptive -версии он только нужен - также, как и сохранять все регистры, РС и указатель стека.
ReAl
Цитата(LVII @ Nov 2 2009, 13:34) *
Асинхронно, синхронно. Асинхронно формируются(могут формироваться) event(прерывание). Синхронно передается управление.
О чём я и говорю - управление передаётся только синхронно на верхнем уровне функций процессов, поэтому кроме точки возврата ничего не надо сохранять, статусный регистр в том числе.

Цитата(LVII @ Nov 2 2009, 13:34) *
Сохранение и восстановление статусного регистра. Сохраняем состояние процесса. Даже синхронно передавая управление, процесс может остаться в разных состояниях. При возврате анализируем статусный регистр. Иначе для сохранения состояния пришлось использовать статическую переменную. Экономия - не знаю? Но работает. Накладные расходы на это ничтожны. А возможность использования остается.
Я прошу конкретный пример, а не "есть возможность".

А теперь смотрим код:
Код
// Макрос - контекст текущей задачи                  
#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
Огурцов
Цитата(LVII @ Nov 2 2009, 12:34) *
ОС была намеренно минимизирована

Я бы хотел ось, которая поддерживает все. Опциями конечно, а не все сразу. Например, последовательные порты, работа с файловой системой, с ммс, с флешью, с озу, с индикаторами и т.д. А в урезанных осях против "своего цикла" я смысла не вижу.
plus
Цитата(sensor_ua @ Nov 1 2009, 10:41) *
попался линк на "Embedded Multitasking with small microcontrollers" Keith E. Curtis.
hчсp://rapidshare.com/files/123380312/Embedded_Multitasking_with_small_microcontrollers.rar

Тогда уж и волшебное слово впридачу к нему: mbandala
LVII
Цитата(ReAl @ Nov 2 2009, 14:24) *
Таким образом, при входе в 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
Цитата(sensor_ua @ Nov 1 2009, 10:41) *
Не буду разбираться кто где плагиатор. Вот попался линк на "Embedded Multitasking with small microcontrollers" Keith E. Curtis.
hчсp://rapidshare.com/files/123380312/Embedded_Multitasking_with_small_microcontrollers.rar

Спасибо, очень полезная книга smile.gif
mempfis_
Цитата(RA3WUM @ Nov 3 2009, 14:58) *
Спасибо, очень полезная книга smile.gif

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

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

To plus спасибо за волшебное слово smile.gif
LVII
Цитата(Огурцов @ Nov 2 2009, 20:01) *
Я бы хотел ось, которая поддерживает все. Опциями конечно, а не все сразу. Например, последовательные порты, работа с файловой системой, с ммс, с флешью, с озу, с индикаторами и т.д. А в урезанных осях против "своего цикла" я смысла не вижу.

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

"Embedded Multitasking with small microcontrollers" Keith E. Curtis. - http://www.onlinedisk.ru/file/257940/
Огурцов
Цитата(LVII @ Nov 3 2009, 12:38) *
На просторах Интернета огромное количество разнообразных

А то я не знаю. Но вот собрать все вместе, оттестировать и опубликовать (бесплатно!) желающих не видно - место вакантно, занимайте. И в минусе не останетесь - найдутся желающие на заплатить за бесплатное, но адаптированное специально под них.
_Pasha
Цитата(Огурцов @ Nov 3 2009, 17:00) *
место вакантно, занимайте.

Давайте не будем забывать о качестве хлама кода, болтающегося по просторам инета. Место Сизифа всегда вакантно sad.gif
ReAl
Цитата(Огурцов @ Nov 2 2009, 20:01) *
Я бы хотел ось, которая поддерживает все. Опциями конечно, а не все сразу. Например, последовательные порты, работа с файловой системой, с ммс, с флешью, с озу, с индикаторами и т.д. А в урезанных осях против "своего цикла" я смысла не вижу.
Nut/OS (ethernut), если если говорить о кооперативных ОС. Но она "тяжёлая" в том смысле, что в мелкий кристалл всё равно не полезет.
Огурцов
Так и не надо в мелкий. Надо мало секса с этими камнями и осями.

Цитата(_Pasha @ Nov 3 2009, 15:34) *
Давайте не будем забывать о качестве хлама кода, болтающегося по просторам инета.

Так и я о том же. Достойно будет собрать под одним, а не говорить, что де мол поищи оно в инете.
ReAl
Цитата(Огурцов @ Nov 3 2009, 23:20) *
Так и не надо в мелкий. Надо мало секса с этими камнями и осями.
Ну так вещь вроде как проверенная временем. Даже платы продаются в терре и у нас в имраде, но схемы открыты все и ось открыта.
Я давно смотрел, по железу там только два варианта, кажется, было (ethernut1 на мега103 с последующим апгрейдом на мегу128 и ethernut2 на атмеловском АРМ at91r4008, если не путаю), сейчас больше.
Управление памятью, система драйверов к железу, разные дополнительные платки, включая mp3-шную на VS1001
Всё подробно описано.
www.ethernut.de

Хотелось как-то посмотреть поплотнее, так как это хороший и большой пример того, что я плохо понимаю (если уж каждой задаче выделен свой стек - чего такого сильно экономит кооперативка по сравнению с вытеснялкой). Но как-то не срослось.
_Pasha
Цитата(ReAl @ Nov 4 2009, 01:46) *
если уж каждой задаче выделен свой стек - чего такого сильно экономит кооперативка по сравнению с вытеснялкой.

Только прыгать от задачи к задаче может чаще, пмсм, ввиду меньшего переключаемого контекста.
defunct
Цитата(ReAl @ Nov 4 2009, 00:46) *
если уж каждой задаче выделен свой стек - чего такого сильно экономит кооперативка по сравнению с вытеснялкой

время программиста экономит при межзадачном взаимодействии, за счет простого обращения с общей памятью.
не нужно ни локов, ни крит секций.
oleg_lwd
Посмотрел mRTOS, решил до кучи написать свою переключалку задач под CVAVR (1.25.3) кооперативная, карусельная со своими стеками. Нажмите для просмотра прикрепленного файла
oleg_lwd
В процессе отладки реального проекта, пришлось немножко все облагородить. Вроде работает.Нажмите для просмотра прикрепленного файла
oleg_lwd
Сделал вариант для мелких AVR. Прерывания теперь имеют свой стек данных, что позволяет сделать глубины стеков данных задач оптимальными. Требования для малых стеков:

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

ОЗУ: 2 байта на задачу, байт на прерывания , 2 байта на задачу для каждого стека задачи (т.к. возникновение прерывания случайно в любом из стеков) , того на три задачи 13 байт лишнего ОЗУ .
Нажмите для просмотра прикрепленного файла
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.