В смысле - бывают дрова под железо?


А сколько RAM скушала? По коду близка к eCos - может, ее [eCos] и имеет смысл ковырять? Но RAM eCos надо немало - 32к самый минимум, 64к - практический минимум. + eCos:
* лицензия правильная
* виртуальные вектора (точки входа) - так что GPL Вас не колышит, Ваш бинарник может быть слинкован отдельно, и Вы не обязаны код раскрывать
* IP, FS - все есть изначально
* вполне нормальная по системны возможностям, ближе к "большим" осям, чем к "таск свитчерам"
* синтетческий порт на Linux - можно отлаживать логику без железа.

В какие камни планируете Nucleus засунуть?

самой оси надо 1.5 кило рама. Работаю с LPC2148

Ну лично я от FreeRTOS отплясывать начал. Правда покромсал уже заметно :-(.
Сейчас до 4.00 доросла, добавлены (даже не знаю как назвать, ибо термин Автора "co-routines" явно избит и навевает другие ассоциации) "недозадачи". Kак раз под маленькие с ограниченными ресурсами. В принципе я такое руками обычно пишу, но сама идея стандартизации интересна. Кстати, я посылал Вам когда-то для разборок с MT-Link проектик, так он на практически еще не изменненой FreeRTOS.

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

FTP поднимется - скачаю, посмотрю. Если добьетесь более-менее рабочего порта и будет не жалко,
выложите?



Ну лично я от FreeRTOS отплясывать начал. Правда покромсал уже заметно :-(.
Сейчас до 4.00 доросла, добавлены (даже не знаю как назвать, ибо термин Автора "co-routines" явно избит и навевает другие ассоциации) "недозадачи". Kак раз под маленькие с ограниченными ресурсами. В принципе я такое руками обычно пишу, но сама идея стандартизации интересна. Кстати, я посылал Вам когда-то для разборок с MT-Link проектик, так он на практически еще не изменненой FreeRTOS.

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

FTP поднимется - скачаю, посмотрю. Если добьетесь более-менее рабочего порта и будет не жалко,
выложите?

Так а все-же можно ссылочку?

Доступ только для группы "Свой"

Имхо на языке "заплесневелой кабернетики" это называется двухуровневое восьмиточечное дерево. На каждом уровне которого выполняется линейный поиск. Совершенно очевидно почему восьми и почему линейный. Максимальное время поиска - восемь (семь) сравнений байта на 0 плюс восемь (семь) битовых сдвигов. Имхо вполне разумное и сбалансированное решение.
Во всяком случае в вытесняемых осях соизмеримое время занимает сохранение восстановление контекста.
Скажем, в scmrtos вообще применяется линейный поиск наиболее приоритетной задачи. На сегодня, имхо, наиболее оптимальный вариант. Harry Zhurov большой респект.

Что касается нюклеуса, мне довелось работать с портом под вин32. Осталось впечатление излишне тяжелого апи и не совсем оптимального выбора для относительно слабых контроллеров.
Простой пример: пакетный обмен по уарту. Если пакет большой, а фифо маленький , либо вообще отсутствует, что нюклеус, что мюкос - дают огромный оверхед.
Для подобных ситуаций в осекоподобных осах есть два типа прерываний - с вызовом ос апи и без такового. Изящный механизм програмных прерываний использовал и Harry Zhurov в последней версии scmrtos.

Plus надо сравнивать с eCos - на мой взляд - близнецы-братья.
(вот чего мне не хватает в eCos, так это "partition memory" - выделение памяти блоками фиксированного размера (или плохо искал?), другим видом динамической памяти пользоваться боюсь)



А почему не ASD2.2 ? а чем их среда Nucleus EDGE не устраивает (Eclipse + ADS2.2 + ARMulator, кстати, и демо Plus под Armulator прилагается, без исходников).
И такой вопрос - а зачем main? и что понимается под "шедулер настраивать"? разве там есть настройки времени компиляции?

"каку сделало" и еще какую, и такое впечатление, что специально - в планировщике запрещали прерывание после доступа к глобальной структуре - две строчки поменяли местами.
а что они делают в TCC_Time_Slice (tcc.c) я так и не понял - надо разбираться
(порт под Infineon Tricore)

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

А можно обосновать настоятельную необходимость в задачах с одинаковыми приоритетами? Желательно на примерах.


Максимальное количество поддерживаемых задач - не прихоть, а компромисс. Чем больше задач, тем больше накладных расходов для их обработки. И сложность планировщика, как следствие. Здесь и проявляется сбалансированность.


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

1.Мы уже, кажется, беседовали на эту тему и с "примерами". Не думаю, что стоит повторять.
2.Что и было сделано.
3.Именно по этой причине я к ней и буду присматриваться, ибо для нижнего уровня выбор сделан
(FreeRTOS) и сейчас выбор, либо по мере необходимости самостоятельно развивать возможности, либо что-то eCOS образное в качестве более можной платформы выбрать. Nucleus пока не вдохновил, но
буду смотреть еще более пристально.

Не помню, что-то. Ссылкой не покажете?

http://electronix.ru/forum/index.php?showt...698&hl=freertos
Только, действительно, тема оказалась :-( несколько другая - "зачем невытесняющая", но похожая - задачи одного приоритета могут не вытеснять друг друга.
Ну в дополнение - вот прямо в текущем проекте у меня обслуживается несколько SHDSL железяк. Они равноправны и асинхроннны друг от друга и их обслуживание не является основным назначением устройства. Чем это не случай одной задачи запущенной несколько раз с одним уровнем приоритета? Какой вариант более "кошерный" нужно изобразить?

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

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

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

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


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