[Evgeny_CD 0]

добавлю про всякие фишечки в Nucleus

поддержка разных железок там богаче.

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

 

 

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

А сколько RAM скушала? По коду близка к eCos - может, ее [eCos] и имеет смысл ковырять? Но RAM eCos надо немало - 32к самый минимум, 64к - практический минимум. + eCos:

* лицензия правильная

* виртуальные вектора (точки входа) - так что GPL Вас не колышит, Ваш бинарник может быть слинкован отдельно, и Вы не обязаны код раскрывать

* IP, FS - все есть изначально

* вполне нормальная по системны возможностям, ближе к "большим" осям, чем к "таск свитчерам"

* синтетческий порт на Linux - можно отлаживать логику без железа.

 

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

[DASM 0]

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

[zltigo 1]

в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах.

...

Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот.

...

У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало). Остальное смогу сказать после нормального запуска её

Ну лично я от FreeRTOS отплясывать начал. Правда покромсал уже заметно :-(.

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

 

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

 

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

выложите?

 

 

в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах.

...

Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот.

...

У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало). Остальное смогу сказать после нормального запуска её

Ну лично я от FreeRTOS отплясывать начал. Правда покромсал уже заметно :-(.

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

 

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

 

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

выложите?

[Rst7 5]

с FTP... сурцы все на месте и дока pdf 320 страниц.

 

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

[VAI 0]

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

 

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

[ig_z 0]

главной "изюминкой" которого автор считал быстрое табличное получение

максимально приоритетной задачи. C тех пор этот заплесневелый изюм там и лежит :-(

 

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

Во всяком случае в вытесняемых осях соизмеримое время занимает сохранение восстановление контекста.

Скажем, в scmrtos вообще применяется линейный поиск наиболее приоритетной задачи. На сегодня, имхо, наиболее оптимальный вариант. Harry Zhurov большой респект. :a14:

 

Что касается нюклеуса, мне довелось работать с портом под вин32. Осталось впечатление излишне тяжелого апи и не совсем оптимального выбора для относительно слабых контроллеров.

Простой пример: пакетный обмен по уарту. Если пакет большой, а фифо маленький , либо вообще отсутствует, что нюклеус, что мюкос - дают огромный оверхед.

Для подобных ситуаций в осекоподобных осах есть два типа прерываний - с вызовом ос апи и без такового. Изящный механизм програмных прерываний использовал и Harry Zhurov в последней версии scmrtos.

[Andrew2000 0]

Интересно, а Ваша оценка - чем она "интереснее" uCOS?

Plus надо сравнивать с eCos - на мой взляд - близнецы-братья.

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

 

 

... Скормил я это дело ADS1_2. Собственно только скомпилировал, ну и в main пару нужных вызовов сделал, .... Счас буду вектора нормально ставить и шедулер настраивать.

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

И такой вопрос - а зачем main? и что понимается под "шедулер настраивать"? разве там есть настройки времени компиляции?

[Andrew2000 0]

...У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало)...

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

а что они делают в TCC_Time_Slice (tcc.c) я так и не понял - надо разбираться

(порт под Infineon Tricore)

[zltigo 1]

Имхо вполне разумное и сбалансированное решение.

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

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

систему.

[dxp 58]

Имхо вполне разумное и сбалансированное решение.

Ага, если кого устраивают все задачи с разными приоритетами

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

 

, ну и принципиально ограниченное

количество задач.

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

 

А все остальные должны или "балансировать" уже свои решения, либо переписывать

систему.

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

[zltigo 1]

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

...

просто должны взять другую ОС, которая их в этой части удовлетворит. И расплатиться за это

...

Сабжевая ОС (и eCOS) просто толще, чем uCOS, и ниши и них немного другие, хотя и пересекающиеся.

1.Мы уже, кажется, беседовали на эту тему и с "примерами". Не думаю, что стоит повторять.

2.Что и было сделано.

3.Именно по этой причине я к ней и буду присматриваться, ибо для нижнего уровня выбор сделан

(FreeRTOS) и сейчас выбор, либо по мере необходимости самостоятельно развивать возможности, либо что-то eCOS образное в качестве более можной платформы выбрать. Nucleus пока не вдохновил, но

буду смотреть еще более пристально.

[dxp 58]

1.Мы уже, кажется, беседовали на эту тему и с "примерами". Не думаю, что стоит повторять.

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

[zltigo 1]

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

 

http://electronix.ru/forum/index.php?showt...698&hl=freertos

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

Ну в дополнение - вот прямо в текущем проекте у меня обслуживается несколько SHDSL железяк. Они равноправны и асинхроннны друг от друга и их обслуживание не является основным назначением устройства. Чем это не случай одной задачи запущенной несколько раз с одним уровнем приоритета? Какой вариант более "кошерный" нужно изобразить?

[dxp 58]

Ну в дополнение - вот прямо в текущем проекте у меня обслуживается несколько SHDSL железяк. Они равноправны и асинхроннны друг от друга и их обслуживание не является основным назначением устройства. Чем это не случай одной задачи запущенной несколько раз с одним уровнем приоритета? Какой вариант более "кошерный" нужно изобразить?

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

[zltigo 1]

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

Может я не написал прямо, что железяки ОДИНАКОВЫЕ, само устройство по количеству таких

железяк масштабируемое, но мне казалось, что это и так понятно. Железки не так, что-бы простые,

но и не чрезмерно сложные.

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

Вот именно за такое и боролся - по завершению обслуживания первой железки, если требует

обслуживания вторая... третья... железка-близнец к обслуживанию ее и переходим.

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

критический предел сложности (для конкретного разработчика?) и разбивка ее на задачи запускаемые под упралением системы принесет пользу.

 

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

постулатами:

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

 

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

 

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

 

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

 

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

 

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