Кто-нибудь что-нибудь скажет плохого/хорошего о Nucleus ? Опции

[DASM]

Вроде симпатичная, в 40 кил уложилась.. UCOS не предлагать вместо.. скучная.

[zltigo]

Например, задача обрабатывает пакет данных от оной железяки.

Может я не написал прямо, что железяки ОДИНАКОВЫЕ, само устройство по количеству таких
железяк масштабируемое, но мне казалось, что это и так понятно. Железки не так, что-бы простые,
но и не чрезмерно сложные.

И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной)

Вот именно за такое и боролся - по завершению обслуживания первой железки, если требует
обслуживания вторая... третья... железка-близнец к обслуживанию ее и переходим.
При этом "более приоритетной" здесь явно лишнее. Естественно, что задачи можно делать не комплексные а как Вы предлагаете - ориентированные на железку а ориетнированные на одну из функций железки, а уж с количеством железок путь задача внутри разбирается.... Можно? - МОЖНО! Будет работать - БУДЕТ! Нужет такой подход? - НУЖЕН!, когда комплексная задача начнет превышать
критический предел сложности (для конкретного разработчика?) и разбивка ее на задачи запускаемые под упралением системы принесет пользу.

Стоит, однако провозглашать такой путь практически единственно правильным? Оперируя
постулатами:

"И код получается прозрачным и предсказуемым"

"И эффектиность распределения тут не хуже, чем схеме карусели"

"планировщик такой (чисто приоиритетный) заметно попроще"

"а значит занимающий меньше места (это, в общем, мелочь)"

"работающий быстрее (а вот это уже не мелочь)"

Вот тут вынуждет ответить - НЕ ТАК ОДНОЗНАЧНО ВСЕ.

[dxp]

И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной)

Вот именно за такое и боролся - по завершению обслуживания первой железки, если требует
обслуживания вторая... третья... железка-близнец к обслуживанию ее и переходим.
При этом "более приоритетной" здесь явно лишнее. Естественно, что задачи можно делать не комплексные а как Вы предлагаете - ориентированные на железку а ориетнированные на одну из функций железки, а уж с количеством железок путь задача внутри разбирается.... Можно? - МОЖНО! Будет работать - БУДЕТ! Нужет такой подход? - НУЖЕН!, когда комплексная задача начнет превышать
критический предел сложности (для конкретного разработчика?) и разбивка ее на задачи запускаемые под упралением системы принесет пользу.

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

Вот тут вынуждет ответить - НЕ ТАК ОДНОЗНАЧНО ВСЕ.

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