Документацию нашел. Однако, на ARM9 портов по-видимому в ближайшее время не предвидится, судя по занятости разработчиков другими делами. В указанной вами ветке говорится, что из серии STR армов сейчас выгребаются последние баги для ARM7, т.е. кристаллы STR7x . Об ARM9 и кристаллах STR91x речь вообще не заходит. Можно, конечно, самому взять за прототип порт для STR7x и пытаться что-то там подправить. Hо при этом затратишь столько времени и сил, что забудешь про основное свое занятие. Собственно, этот недостаток scmRTOS (сложная адаптация под различные платформы), честно признают и сами авторы.

Я запустил юкос на STR912FW44 под CrossWorks 1.7. Кому надо, могу кинуть порт.

Можно указать, где про это сказано (сложность адаптации под различные платформы)?

Не предвидется, но по другой причине - я с ARM9 не работаю и в обозримом будущем не собираюсь (нет соответствующих задач). Изучать его специально, чтобы написать порт, которым не буду пользоваться сам - не вижу смысла. Если кто-то с ними работает и желает сделать (или уже сделал) порт - добро пожаловать. Помощь и консультации через ICQ или мылом гарантирую. В репозитории лежит рабочий порт имени ReAlа под GCC для AVR и кое-какие наброски порта под GCC для ARM7 (пока работает только компиляция в режиме ARM и схема переключения 0). Вот он пишется в свободное время параллельно с освоением GCC.Это уже каждый решает для себя сам - есть такое же готовое или придется приложить усилия. Для начала определитесь - будут у вас процессы создаваться в процессе выполнения, или их количество фиксировано на этапе компиляции? Если нужно создавать процессы в процессе работы, то scmRTOS вам не подойдет.

В документации на русском видел эту фразу в контексте обсуждения компиляторов C++. Впрочем, могу ошибаться в оценках и готов взять слова о трудностях адаптации обратно.


Спасибо, я примерно так и понимаю ситуацию с SCMRTOS.


У меня процессы статические и ваша scmRTOS прекрасно подошла бы для работы. Она мне нравится по самой идее, простоте использования и отработанности механизмов взаимодействия процессов. Действительно, очень хорошая задумка, но, увы, - к современным кристаллам нет готовых портов. Вы призываете к самостоятельному портированию. В принципе можно, если бы в документации был-бы раздел "Портирование. Что надо проделать". Практической пользы от такого раздела было бы несравнимо больше, чем от от описаний, как устроен диспетчер - переключатель процессов.

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

Любая система получившая признание обладает некоторыми набором идей. Может другие идеи тоже неплохи? Кстати, а какая по Вашему основная идея у scmRTOS?

Любая система при нынешнем уровне развития концепции систем обеспечиваеи простоту и удобство использования. Причем простота и удобство использования прямо зависят от сложности системы - чем сложнее, тем можно сделать удобнее. На ARM9 можно позволить систему и посложнее...

Джентельменский набор обязателен для любой системы.


P.S.
Только бога ради не воспринимайте вышенаписанное, как критику scmRTOS. Это все было писано для расширения кругозора.

Данный тред раскручивается с кристалла STR912F. Данный кристалл идеален по набору периферии вокруг ядра ARM9 и позволяет реализовать системы типа SCM в аббревиатуре авторов операционки. Т.е. все на одном кристалле. Мои интересы лежать тоже в этой плоскости, поэтому никаких внешних памятей с механизмами виртуализации не требуется. Что касается "с системами не работал", то это не совсем так- я работал с uCOS-II на процессоре с ядром ColdFire-II. Сделал устройство радиосвязи с WEB-сервером на борту. Создавать и убирать динамически процессы совершенно не потребовалось. Использование uCOS-II, как теперь я вижу в сравнении с scmRTOS, было стрельбой из пушки по воробьям.

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

Я придерживаюсь противоположного мнения- чем сложнее, тем менее удобно в применении (продукция MS). Особенно в тех случаях, когда заложенные сложности на практике не нужны и не используются.

Спорно.

Ну а теперь без образных пушек и воробъев - сколько байтов и тактов рассчитываете сэкономить при переходе со знакомой уже системы к scmRTOS и насколько эти байты и такты критичны для контроллера уровня STR9, а не, например, для среднего AVR8?

В продукции этой фирмы, как и в Linux, так и в других больших системах работа с ядром сделана очень удобно, очень продумано, очень надежно и очень дуракоустойчиво. Цена таких решений для STR9 уже, на мой взгляд, великовата. Хотя в отдельных случаях из-за удобных, полных и надежных реализаций, например, IP стеков (Linux) или Графики (Win) могут уже использоваться и они. Об абстрактных удобствах сложных систем в комплекте с приложениями делающих все и вся порассуждаете, когда на scmRTOS сделаете десктопную OS .

Я рассчитываю при переходе на scmRTOS сэкономить не байты и не такты, а время разработки и отладки прикладной программы для однокристального исполнения системы. После знакомства с документацией на scmRTOS вижу, что механизмы взаимодействия процессов там построены лучше с точки зрения простоты применения и надежности работы. Чтобы реализовать, например, что-то подобное canal-у из scmRTOS, средствами uCOS-а придется городить целый огород из FiFо и пары семафоров. Меня лично привлекает в scmRTOS именно продуманность механизмов обмена между процессами, которая и сократит время time-to-market. Тип же кристалла в данном случае значения не имеет.

Я потребитель. И рассуждаю как потребитель. Делать десктопную OS не моя специализация.

Вы ошибаетесь. У меня много причин по которым я не использую uCOS, но с точки зрения документирования, развитости интерфейса и дуракоустойчивости/надежности его использования и надежности системы вообще, uCOS очень очень хороша.
Своего рода стандарт.

Тогда не рассуждайте о построении ядер операционных систем . И не надо разговор о минималистичных ядрах пытаться на дежурную тему о MS перевести.

Сообщение отредактировал zltigo - Feb 15 2008, 11:22

Вполне возможно, что и стандарт. Однако, продуманность взаимодействия процессов в scmRTOS много полезнее и проще в использовании. Могу еще раз повторить пример с шаблоном canal, котрый решает практически все самые трудные моменты передачи данных одним движением в scmRTOS. В то время, как в uCOS-II для того же результата придется нагородить многое из "стандартных" и хорошо "задокументированных" компонентов. Для пользователя-прикладника - это затягивание времени, никакой стандарт и прочий академизм его не окупает.

Заложенные в scmRTOS идеи мне, как прикладнику, очень нравятся. И очень жаль, что эта OS не получит, скорей всего, развития и широкого признания из-за того, что авторы занимаются ею урывками, исключительно под свои потребности.

У меня есть вопросик по scmRTOS.



Зачем нужно поле Size? Я не нашел места в коде, где бы оно изменялось - то есть оно хранит константу, которую можно спросить у компилятора (а не читать из RAM).

Величину этого затягивания времени в минутах назвать сможете?

Расскажу по своему опыту работы с uCOS. Когда делал с помощью uCOS драйверы периферии, например I2C, в виде отдельных процессов, получающих задания от многих других процессов приложения, то пришлось нагородить из стандартных компонентов uCOS довольно сложную вещь. Hа выяснение всех неприятностей реального времени и отладку затрачено было примерно 2 месяца. Теперь же, читая документацию на scmRTOS, я вижу- все нагороженное уже реализовано очень просто и я бы не потерял те 2 месяца с возней на uСOS. Речь идет о шаблоне canal.

Это находится за гранью моего понимания.