Evgeny_CD 0 29 марта, 2006 Опубликовано 29 марта, 2006 · Жалоба добавлю про всякие фишечки в Nucleus поддержка разных железок там богаче. В смысле - бывают дрова под железо? Вроде симпатичная, в 40 кил уложилась..А сколько RAM скушала? По коду близка к eCos - может, ее [eCos] и имеет смысл ковырять? Но RAM eCos надо немало - 32к самый минимум, 64к - практический минимум. + eCos: * лицензия правильная * виртуальные вектора (точки входа) - так что GPL Вас не колышит, Ваш бинарник может быть слинкован отдельно, и Вы не обязаны код раскрывать * IP, FS - все есть изначально * вполне нормальная по системны возможностям, ближе к "большим" осям, чем к "таск свитчерам" * синтетческий порт на Linux - можно отлаживать логику без железа. В какие камни планируете Nucleus засунуть? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DASM 0 29 марта, 2006 Опубликовано 29 марта, 2006 · Жалоба самой оси надо 1.5 кило рама. Работаю с LPC2148 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 29 марта, 2006 Опубликовано 29 марта, 2006 · Жалоба в данном случае все-таки я просто ищу подходящую ось, доступную в сурцах и без вопросов работающую на маленьких армах. ... Такое ошущение что Автор взял книгу с правилами хорошего тона на "С" и сделал наооборот. ... У 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 30 марта, 2006 Опубликовано 30 марта, 2006 · Жалоба с FTP... сурцы все на месте и дока pdf 320 страниц. Так а все-же можно ссылочку? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VAI 0 30 марта, 2006 Опубликовано 30 марта, 2006 · Жалоба Так а все-же можно ссылочку? Доступ только для группы "Свой" Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ig_z 0 30 марта, 2006 Опубликовано 30 марта, 2006 · Жалоба главной "изюминкой" которого автор считал быстрое табличное получение максимально приоритетной задачи. C тех пор этот заплесневелый изюм там и лежит :-( Имхо на языке "заплесневелой кабернетики" :) это называется двухуровневое восьмиточечное дерево. На каждом уровне которого выполняется линейный поиск. Совершенно очевидно почему восьми и почему линейный. Максимальное время поиска - восемь (семь) сравнений байта на 0 плюс восемь (семь) битовых сдвигов. Имхо вполне разумное и сбалансированное решение. Во всяком случае в вытесняемых осях соизмеримое время занимает сохранение восстановление контекста. Скажем, в scmrtos вообще применяется линейный поиск наиболее приоритетной задачи. На сегодня, имхо, наиболее оптимальный вариант. Harry Zhurov большой респект. :a14: Что касается нюклеуса, мне довелось работать с портом под вин32. Осталось впечатление излишне тяжелого апи и не совсем оптимального выбора для относительно слабых контроллеров. Простой пример: пакетный обмен по уарту. Если пакет большой, а фифо маленький , либо вообще отсутствует, что нюклеус, что мюкос - дают огромный оверхед. Для подобных ситуаций в осекоподобных осах есть два типа прерываний - с вызовом ос апи и без такового. Изящный механизм програмных прерываний использовал и Harry Zhurov в последней версии scmrtos. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrew2000 0 30 марта, 2006 Опубликовано 30 марта, 2006 · Жалоба Интересно, а Ваша оценка - чем она "интереснее" uCOS? Plus надо сравнивать с eCos - на мой взляд - близнецы-братья. (вот чего мне не хватает в eCos, так это "partition memory" - выделение памяти блоками фиксированного размера (или плохо искал?), другим видом динамической памяти пользоваться боюсь) ... Скормил я это дело ADS1_2. Собственно только скомпилировал, ну и в main пару нужных вызовов сделал, .... Счас буду вектора нормально ставить и шедулер настраивать. А почему не ASD2.2 ? а чем их среда Nucleus EDGE не устраивает (Eclipse + ADS2.2 + ARMulator, кстати, и демо Plus под Armulator прилагается, без исходников). И такой вопрос - а зачем main? и что понимается под "шедулер настраивать"? разве там есть настройки времени компиляции? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andrew2000 0 30 марта, 2006 Опубликовано 30 марта, 2006 · Жалоба ...У Nucleus же код ясный и выглядит красиво. (да и компания Accelerated Technology, подразделение Mentor вряд ли каку сделало)... :) "каку сделало" и еще какую, и такое впечатление, что специально - в планировщике запрещали прерывание после доступа к глобальной структуре - две строчки поменяли местами. а что они делают в TCC_Time_Slice (tcc.c) я так и не понял - надо разбираться (порт под Infineon Tricore) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 31 марта, 2006 Опубликовано 31 марта, 2006 · Жалоба Имхо вполне разумное и сбалансированное решение. Ага, если кого устраивают все задачи с разными приоритетами, ну и принципиально ограниченное количество задач. А все остальные должны или "балансировать" уже свои решения, либо переписывать систему. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 31 марта, 2006 Опубликовано 31 марта, 2006 · Жалоба Имхо вполне разумное и сбалансированное решение. Ага, если кого устраивают все задачи с разными приоритетами А можно обосновать настоятельную необходимость в задачах с одинаковыми приоритетами? Желательно на примерах. , ну и принципиально ограниченное количество задач. Максимальное количество поддерживаемых задач - не прихоть, а компромисс. Чем больше задач, тем больше накладных расходов для их обработки. И сложность планировщика, как следствие. Здесь и проявляется сбалансированность. А все остальные должны или "балансировать" уже свои решения, либо переписывать систему. Остальные просто должны взять другую ОС, которая их в этой части удовлетворит. И расплатиться за это накладными расходами по памяти и быстродейтсвию. Если целевой процессор это позволяет. Ничего беслатно не быват, вся жизнь - сгусток компромиссов. Сабжевая ОС (и eCOS) просто толще, чем uCOS, и ниши и них немного другие, хотя и пересекающиеся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 31 марта, 2006 Опубликовано 31 марта, 2006 · Жалоба А можно обосновать настоятельную необходимость в задачах с одинаковыми приоритетами? Остальные ... просто должны взять другую ОС, которая их в этой части удовлетворит. И расплатиться за это ... Сабжевая ОС (и eCOS) просто толще, чем uCOS, и ниши и них немного другие, хотя и пересекающиеся. 1.Мы уже, кажется, беседовали на эту тему и с "примерами". Не думаю, что стоит повторять. 2.Что и было сделано. 3.Именно по этой причине я к ней и буду присматриваться, ибо для нижнего уровня выбор сделан (FreeRTOS) и сейчас выбор, либо по мере необходимости самостоятельно развивать возможности, либо что-то eCOS образное в качестве более можной платформы выбрать. Nucleus пока не вдохновил, но буду смотреть еще более пристально. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 31 марта, 2006 Опубликовано 31 марта, 2006 · Жалоба 1.Мы уже, кажется, беседовали на эту тему и с "примерами". Не думаю, что стоит повторять. Не помню, что-то. Ссылкой не покажете? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 31 марта, 2006 Опубликовано 31 марта, 2006 · Жалоба Не помню, что-то. Ссылкой не покажете? http://electronix.ru/forum/index.php?showt...698&hl=freertos Только, действительно, тема оказалась :-( несколько другая - "зачем невытесняющая", но похожая - задачи одного приоритета могут не вытеснять друг друга. Ну в дополнение - вот прямо в текущем проекте у меня обслуживается несколько SHDSL железяк. Они равноправны и асинхроннны друг от друга и их обслуживание не является основным назначением устройства. Чем это не случай одной задачи запущенной несколько раз с одним уровнем приоритета? Какой вариант более "кошерный" нужно изобразить? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 58 1 апреля, 2006 Опубликовано 1 апреля, 2006 · Жалоба Ну в дополнение - вот прямо в текущем проекте у меня обслуживается несколько SHDSL железяк. Они равноправны и асинхроннны друг от друга и их обслуживание не является основным назначением устройства. Чем это не случай одной задачи запущенной несколько раз с одним уровнем приоритета? Какой вариант более "кошерный" нужно изобразить? Обслуживание железяк занимает все вермя? Или таки не все? Видимо, не все, иначе проц просто не справлялся бы с задачей по параметру быстродействие. Тогда, если производительности хватает, то и распределить работу по событиям и приоритетам. Например, задача обрабатывает пакет данных от оной железяки. Обрабоатала - отдала управление. В следующий раз она получит управление, когда придет очередной пакет. Отдав управление (встав на ожидание семафора), задача ждет, а управление переходит следующей задаче, если для нее есть работа (пришел ее пакет данных, о чем был взведен соотвествующий семафаор). Поскольку обе задачи из класса фоновых, то их приоритетность друг относительно друга практически никакой роли не играет. И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной) ко второй - по окончании обработки пакета, к первой - по приходу ее пакета. И эффектиность распределения тут не хуже, чем схеме карусели. И управление полностью по событиям - т.е. более предсказуемо с точки зрения внешних событий. А планировщик такой (чисто приоиритетный) заметно попроще, чем комбинированный (приоритетно-карусельный), а значит занимающий меньше места (это, в общем, мелочь) и работающий быстрее (а вот это уже не мелочь). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 1 апреля, 2006 Опубликовано 1 апреля, 2006 · Жалоба Например, задача обрабатывает пакет данных от оной железяки. Может я не написал прямо, что железяки ОДИНАКОВЫЕ, само устройство по количеству таких железяк масштабируемое, но мне казалось, что это и так понятно. Железки не так, что-бы простые, но и не чрезмерно сложные. И код получается прозрачным и предсказуемым - управление от одной задачи переходит к другой вполне предсказуемо - от первой (более приоритетной) Вот именно за такое и боролся - по завершению обслуживания первой железки, если требует обслуживания вторая... третья... железка-близнец к обслуживанию ее и переходим. При этом "более приоритетной" здесь явно лишнее. Естественно, что задачи можно делать не комплексные а как Вы предлагаете - ориентированные на железку а ориетнированные на одну из функций железки, а уж с количеством железок путь задача внутри разбирается.... Можно? - МОЖНО! Будет работать - БУДЕТ! Нужет такой подход? - НУЖЕН!, когда комплексная задача начнет превышать критический предел сложности (для конкретного разработчика?) и разбивка ее на задачи запускаемые под упралением системы принесет пользу. Стоит, однако провозглашать такой путь практически единственно правильным? Оперируя постулатами: "И код получается прозрачным и предсказуемым" "И эффектиность распределения тут не хуже, чем схеме карусели" "планировщик такой (чисто приоиритетный) заметно попроще" "а значит занимающий меньше места (это, в общем, мелочь)" "работающий быстрее (а вот это уже не мелочь)" Вот тут вынуждет ответить - НЕ ТАК ОДНОЗНАЧНО ВСЕ. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться