Библиотека поддержки многопоточности для ATmega

[ellioh]

-

[ARV]

чем OSA не устраивает?

[ellioh]

-

[a_skr]

мне когда-то удалось запустить на AVR picoOS и FreeRTOS ради баловства. Сейчас уже немало ОСРВ на AVR портировано.

[ellioh]

-

[avreal]

Вытеснялка тут http://scmrtos.sourceforge.net/ScmRTOS (С++)
Но вытеснялка сразу жрёт больше памяти на отдельные стеки, так что думайте.

[ellioh]

-

[svd71]

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

PS: я экспериментировал с мегой8. думаю при большей памяти проблем не будет. вот с тини проблема - 52 байт выделится только на стеки.

[ellioh]

-

[svd71]

Источник:
Цель GNU GPL — предоставить пользователю права копировать, модифицировать и распространять (в том числе на коммерческой основе) программы (что по умолчанию запрещено законом об авторских правах), а также гарантировать, что и пользователи всех производных программ получат вышеперечисленные права. [Прим. 1] Принцип „наследования“ прав называется «копилефт» (транслитерация c англ. copyleft) и был придуман Ричардом Столлмэном. По контрасту с GPL, лицензии проприетарного ПО «очень редко дают пользователю такие права и обычно, наоборот, стремятся их ограничить, например, запрещая восстановление исходного кода»[2].

Лицензируя работу на условиях GNU GPL, автор сохраняет за собой авторство[Прим. 2].
Содержание


GPL предоставляет получателям компьютерных программ следующие права, или «свободы»:[3]

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

[ellioh]

-

[svd71]

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

[ellioh]

-

[avreal]

Спасибо, по возможности погляжу, хотя пока мне кажется, что меня устроит scmRTOS. В её потрохах я пока не успел покопаться, только пособирал примеры, почитал доки

Ещё сюда загляните http://real.kiev.ua/scmrtos/1-eventflag/

Если бы речь шла о больших машинах, есть LGPL, но я не берусь самостоятельно понять правовые аспекты её применения в условиях, когда о динамической линковке вопрос не стоит.

Именно поэтому у scmRTOS в своё время лицензия была изменена с *GPL на MIT-подобную.

[ellioh]

-

[avreal]

Да, посмотрел. Кстати, как я понимаю, вы -- автор порта scmRTOS на AVR?

AVR/GCC порта. И потихоньку беру на себя сопровождение AVR/IAR- порта, ради чего пришлось поставить "кик-старт"-овую версию IAREWB (для примеров ограничения по коду хватает )

На пробу сделал себе аналог pin_macros (кстати, идея pin_macros тоже очень понравилась) на C++'ных шаблонах в стиле порождающего программирования

«Волковские» макросы в развитии использую уже денадцать лет, поэтому они и в порт scmRTOS перетекли.
Сейчас у меня в «TODO» стоит пункт портирования на AVR тех шаблонов работы с портами, которые AHTOXA сделал для CortexM3/GCC порта. Мы их немного допилили в сторону испольования bit-band (с анализом того, где bit-band даёт преимущества, а где его применение не имеет смысла) и теперь для STM32 я использую эти шаблоны.
Я их буду переносить на AVR 1:1 для увеличения совместимости портов/примеров. Вот только закончу проверку AVR-ских портов/примеров для v4.00, чтобы не задерживать релиз. Шаблоны в примере можно будет и позже добавить.

[ellioh]

-

[avreal]

«на днях, а то и раньше»
Ситуация такая - все хотелки добавлены, все наболелки реализованы.
Теперь каждый в зоне своей ответственности должен подтянуть порты/примеры, отчитаться о готовности и тогда релиз, лежащий сейчас в ветке репозитория branches/pre-v400, будет утверждён.
Кажется, у меня всё нормально, но нужно ещё раз сверить со свежими изменениями.

Тут https://groups.google.com/group/scmrtos-ru?hl=ru идёт обсуждение, но через web-интерфес там почему-то существенная часть кирилицы портится. Так что рекомендую подписаться на рассылку (справа вверху «присодиниться к этой группе»).

[ellioh]

-

[Dimone]

Я , конечно, же не называю то что использую "ртос"-ом, -заюзал интересный планировщик с вытесняющей многозадачностью,
"раунд робины" уже не подходят, а юзать то, что для переключения контекста требует дополнительных вызовов из текущей задчи (не гарантированно детерменированных во времени) посчитал абсурдным. Да и"мега" , берем вариант без внешней "срам" не даст развернуться со стеками, безопасно их использовать будет можно лишь при постоянном контроле его использования, т.е. лишняя вложеность в вызове, и приехали, что вкорне рвет парадигмы высокоуровневого программирования. Поэтому, основной задачей было стек юзать лишь стандартный CSTACK и RSTACK("иар"). Соответственно, единственное что требуется от функции, и то при условии использования ее многими процсами например bin2bcd, это "reentant" возможность, что достаточно освещено в описаниях обработчиков прерываний. Посути, для сохранения/восстановления используются механизмы работы со стеком компилятора, соответственно все управление сводится к установке безопасных значений CSTACK и RSTACK в баланс с имеющейся свободной ОЗУ. Единственный минус, -невозможность снять задачу не получив от нее "return",т.е. зависшую,подозреваю что этим грешны и многие кооперативные ядра, но тем не менее даже получив задачу с "мертвым циклом", или ожидающую какои-то дивайс, не повлияет на работу задач с высшим приоритетом. Пока хардваные прерывания существуют отдельно, работа с ними идет своим обработчиком, управление ядром идет через несложный "api" , пока есть возможность,установить задаче приоритет выполнения, запустить задачу однократно, отсрочить задачу, запустить с указанным периодом,заблокировать/разблокировать, снять задачу. "overhead" снимает около 0.5MHz ,при системной временной сетке 1mS ,и пока 24maх параллельных задачах, ну и чуть памяти на кэш планировщика ...Доволен как слон, проэкт с несколькими АЦП, использованием всех интерфейсов 128 "мэги", собственным байт-код интерпретатором (т.е. "behavioг" программы не компилится а даунлодится , как в "plс".)
-Не представляю как подругому бы такое потянул...
П.С. но так это первый опыт вынужденного написания подобной управляющей надстройки, думаю должно быть и круче...
Респект "avreal"-у за программатор...