Vit (14.06.2008 13:33, просмотров: 494) ответил Evgeny_CD на Так....... Тема lightweight threads оказалась куда интереснее, чем я когда-то думал.А на NesOS и TinyTimber не смотрел? http://www.sm.luth.se/csee/courses/smd/138/TinyTimber.pdf
http://www.nilsenelektronikk.no/neprod.html
Я-то юзаю варианты на тему Protothreads уже не один год. Основные действия обычно в моих задачах выполняются в "мягком" риалтайме, большинство функций ввода-вывода являются неожидающими, а задачи побиты руками на достаточно короткие по выполнению куски (обычно в едином теле задачи), ну и после каждого кусочка отдаётся управление (yield()). При отсутствии явной необходимости шедулер не применяется. Хотя в системе обычно наличествует шедулер или несколько для обеспечения жесткого риалтайма требующим того подсистемам ("функциональные генераторы" дискретных выходов, счетчики событий/частоты, "обычные" дискретные входы, разруливание управлением передачи УАРТа и т.п.). Конечно существуют системные задачи, например, обслуживание очередей логгеров, ведение календаря и т.п., но они спокойно запускаются такими же задачами как и все остальные, только порядок их вызова обычно определён жестко - что-то в "начале" большого цикла, что-то в конце. Неожидающие функции позволяют избавиться от множества проблем, хотя и требуют другого подхода, ну и имеют свои сложности (синхронизация, блокировки и т.п.). Отсутствие основного планировщика во встраиваемых приложениях зачастую вполне допустимо, так как количество задач обычно определяется на этапе сборки, затраты на локальные проверки флагов активности невелики, а распределение памяти важно в части использования ОЗУ, потому как тело задачи при её даже однократном использовании из ПЗУ уже не выбросишь, поэтому борьба в основном за эффективность использования ОЗУ (в том числе всё чаще за счёт ПЗУ - флеши производители дают всё больше за те же деньги, а вот с ОЗУ не так хорошо, хоть тенденции есть). Как по мне, то использование подсистемы динамического распределения памяти, конечно, возможно, но честно - ни разу в проге для контроллера не применил malloc. А хранение стека это, ИМХО, не та задача, для которой нужна ОС (ИМХО, сохранение чего-либо не есть самоцель, но лишь необходимость) - как по мне это сохранение контекста и баста, а где его кто положил - в стеке или в статическую переменную не суть важно при кооперативной многозадачности. Но вот, например, на днях пришлось по ряду причин применить самописный планировщик (из известных мне махоньких ОС ни одна к сожалению не подошла) для построения одной и той же задачи уже не на Protothreads (на "птыцах" - так их называю - уже написал и оно даже работает), потому как потребовалось в системе с очень жестким режимом энергопотребления всего-лишь поднимать задачи (из спящего состояния проца) при возникновении различного рода событий (приход данных по УАРТу, срабатывание будильника, приход данных по радиоканалу, по прерыванию АЦП и прочая). И здесь граф машины состояний крутится вокруг фиксированной точки ожидания пробуждения, потому линейный баальшой цикл тупо не годится (разве что для одной задачи, с чего и начал, но упёрся). Переписывание кода задачи заняло не более получаса;) Подходы бывают разными - ИМХО, в каждом случае лучше освоить и применять более соответствующий конкретной задаче. А это прямые линки на фесь код TinyTimber - почему-то у её родителей линков не видать http://www.sm.luth …s/smd/138/TinyTimber.h http://www.sm.luth …s/smd/138/TinyTimber.c
http://www.nilsenelektronikk.no/neprod.html
Я-то юзаю варианты на тему Protothreads уже не один год. Основные действия обычно в моих задачах выполняются в "мягком" риалтайме, большинство функций ввода-вывода являются неожидающими, а задачи побиты руками на достаточно короткие по выполнению куски (обычно в едином теле задачи), ну и после каждого кусочка отдаётся управление (yield()). При отсутствии явной необходимости шедулер не применяется. Хотя в системе обычно наличествует шедулер или несколько для обеспечения жесткого риалтайма требующим того подсистемам ("функциональные генераторы" дискретных выходов, счетчики событий/частоты, "обычные" дискретные входы, разруливание управлением передачи УАРТа и т.п.). Конечно существуют системные задачи, например, обслуживание очередей логгеров, ведение календаря и т.п., но они спокойно запускаются такими же задачами как и все остальные, только порядок их вызова обычно определён жестко - что-то в "начале" большого цикла, что-то в конце. Неожидающие функции позволяют избавиться от множества проблем, хотя и требуют другого подхода, ну и имеют свои сложности (синхронизация, блокировки и т.п.). Отсутствие основного планировщика во встраиваемых приложениях зачастую вполне допустимо, так как количество задач обычно определяется на этапе сборки, затраты на локальные проверки флагов активности невелики, а распределение памяти важно в части использования ОЗУ, потому как тело задачи при её даже однократном использовании из ПЗУ уже не выбросишь, поэтому борьба в основном за эффективность использования ОЗУ (в том числе всё чаще за счёт ПЗУ - флеши производители дают всё больше за те же деньги, а вот с ОЗУ не так хорошо, хоть тенденции есть). Как по мне, то использование подсистемы динамического распределения памяти, конечно, возможно, но честно - ни разу в проге для контроллера не применил malloc. А хранение стека это, ИМХО, не та задача, для которой нужна ОС (ИМХО, сохранение чего-либо не есть самоцель, но лишь необходимость) - как по мне это сохранение контекста и баста, а где его кто положил - в стеке или в статическую переменную не суть важно при кооперативной многозадачности. Но вот, например, на днях пришлось по ряду причин применить самописный планировщик (из известных мне махоньких ОС ни одна к сожалению не подошла) для построения одной и той же задачи уже не на Protothreads (на "птыцах" - так их называю - уже написал и оно даже работает), потому как потребовалось в системе с очень жестким режимом энергопотребления всего-лишь поднимать задачи (из спящего состояния проца) при возникновении различного рода событий (приход данных по УАРТу, срабатывание будильника, приход данных по радиоканалу, по прерыванию АЦП и прочая). И здесь граф машины состояний крутится вокруг фиксированной точки ожидания пробуждения, потому линейный баальшой цикл тупо не годится (разве что для одной задачи, с чего и начал, но упёрся). Переписывание кода задачи заняло не более получаса;) Подходы бывают разными - ИМХО, в каждом случае лучше освоить и применять более соответствующий конкретной задаче. А это прямые линки на фесь код TinyTimber - почему-то у её родителей линков не видать http://www.sm.luth …s/smd/138/TinyTimber.h http://www.sm.luth …s/smd/138/TinyTimber.c