STR912 + CW 1.7, Выбор ОС для работы. Опции

[SimpleSoft]

День добрый.
Есть задача сделать съём с линейной CCD матрицы данных и передачи их по сети 100мбит или UART (RS-485) на ПК, предварительно прогнав данные через фильтр (посчитать производную 2 порядка).

С половиной задачи справился - сделал на DMA и внешней шине считывание данных с матрицы. Работает отлично - даёт максимальное кол-во кадров, которые можно снять с матрицы - это радует. Передаю всё это через UART (RS-232) в ПК.

Осталось реализовать фильтр и передачу через Ethernet. Думаю задействровать в этом DSP инструкции процессора.
Стал вопрос в выборе ОС для работы.

Рабочая среда: CrossWorks 1.7 build 3
Отладочная плата: Olimex STR-E912
JTAG: Собран на FTDI FT2232C

Пробовал брать шаблон портирования от AlexandrY - MicriumDemo_CW.
Сразу ничего не вышло. ОС не стартует.

1) Подскажите, пожалуйста, с чего начинать портирование uCOS на STR912? Стоит ли портировать uCOS на STR912 при моей задаче.

2) Стоит ли смотреть в сторону связки FreeRTOS + lwip? Где глянуть доки на портирование FreeRTOS под STR912 ( в среде CW 1.7 )?

[KonstantinT]

Если в CrossWorks то зачем туда укос тащить, если в нем есть своя CTL библиотека? Причем с открытым кодом. Что-вы можете сделать на укосс и не сделать на CTL

[SimpleSoft]

Если в CrossWorks то зачем туда укос тащить, если в нем есть своя CTL библиотека? Причем с открытым кодом. Что-вы можете сделать на укосс и не сделать на CTL

Честно говоря даже не знаю что такое CTL. Поясните пожалуйста.
У юкоса есть готовый стек и связанный с STR91x ENET. Именно от него мне надо брать только функции accept, bind, listen итд. А к CTL, я так понимаю, надо прикручивать lwip. Не хотелось бы тратить время на прикручивание lwip, тем более что уже начал разбирать юкос. Хотя спасибо.

Сообщение отредактировал SimpleSoft - Feb 7 2008, 10:31

[KonstantinT]

Честно говоря даже не знаю что такое CTL. Поясните пожалуйста.
У юкоса есть готовый стек и связанный с STR91x ENET. Именно от него мне надо брать только функции accept, bind, listen итд. А к CTL, я так понимаю, надо прикручивать lwip. Не хотелось бы тратить время на прикручивание lwip, тем более что уже начал разбирать юкос. Хотя спасибо.

CTL несложная переключалка задач, входит в состав CW. Там есть под нее визард
По поводу GNU - не принимайте так близко к сердцу заявление нашего уважаемого коллеги, он очень любит заниматься пиписькомерянием компиляторов .
Если Вам "ехать" а не "шашечки" , то обычный вигглер+СW и сразу начнете работать.

[SimpleSoft]

Если Вам "ехать" а не "шашечки" , то обычный вигглер+СW и сразу начнете работать.

Всё таки сел за uCOS. Но выбора нет особо... есть JTAG на FT2232 и перелазить на виглер не могу по причине отсутствия LPT)) да и плату JTAG развёл уже так что бы при желании и I2C EEPROM можно было прочитать с помощью этого JTAG.

Думаю что потрачу время на uCOS не зря. Хотя за инфу спасибо.

З.Ы.: Вот за что уважаю нашего брата, так за желание помочь ближнему... буржуи же даже чихают в кредит...

Сообщение отредактировал SimpleSoft - Feb 8 2008, 16:11

[vsasha]

ИМХО ucos не очень хороший выбор. Просмотрите форум, у нее достаточно много недостатков.
ucos хороша, если вы хотите (по чисто русской традиции) натырить много готовых кусков (файловую систему, сетьевой стек), и быстренько из них чтото слепить, не особо вдаваясь в то как все это работает.

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

Посмотрите в сторону SCMRTOS, она имеет не официальный порт под GCC, имеет не плохой функционал, еще и документацию на русском (по крайней мере для 2 версии). В ней на сколько я слышал в переключалке задач для ARM9 используется специальная инструкция CLZ, что уже даст заметный выигрыш на STR912.

[Aprox]

Посмотрите в сторону SCMRTOS, она имеет не официальный порт под GCC, имеет не плохой функционал, еще и документацию на русском (по крайней мере для 2 версии). В ней на сколько я слышал в переключалке задач для ARM9 используется специальная инструкция CLZ, что уже даст заметный выигрыш на STR912.

Подскажите, где можно взять SCMRTOS, портированную на ARM9 и документацию на русском. В сети, при всем старании, найти не удалось.

[vsasha]

> Подскажите, где можно взять SCMRTOS, портированную на ARM9 и документацию на русском. В сети, при всем старании, найти не удалось.

По этим вопросам лучше подскажет Сергей Борщ, разработчик этой ОС. Он тоже посещает этот форум.

Порт на GCC есть в репозитории. см.http://sourceforge.net/projects/scmrtos/

А лучше отыскать на этом форуме ветку посвященную этой ОС, и предварительно ее почитать.
Русское описание, см. старые документы, для версии 2.

[Aprox]

Порт на GCC есть в репозитории. см.http://sourceforge.net/projects/scmrtos/
А лучше отыскать на этом форуме ветку посвященную этой ОС, и предварительно ее почитать.
Русское описание, см. старые документы, для версии 2.

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

[dxp]

Собственно, этот недостаток scmRTOS (сложная адаптация под различные платформы), честно признают и сами авторы.

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

[Aprox]

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

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

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

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

>Можно, конечно, самому взять за прототип порт для STR7x и пытаться что-то там подправить. Hо при этом >затратишь столько времени и сил, что забудешь про основное свое занятие.

Это уже каждый решает для себя сам - есть такое же готовое или придется приложить усилия. Для начала определитесь - будут у вас процессы создаваться в процессе выполнения, или их количество фиксировано на этапе компиляции? Если нужно создавать процессы в процессе работы, то scmRTOS вам не подойдет.

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

[zltigo]

У меня процессы статические и...

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

Она мне нравится по самой идее...

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

, простоте использования..

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

... и отработанности механизмов взаимодействия процессов.

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


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

[Aprox]

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

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

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

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

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

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

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

Спорно.

[zltigo]

как теперь я вижу в сравнении с scmRTOS, было стрельбой из пушки по воробьям.

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

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

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

[Aprox]

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

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

... Об абстрактных удобствах сложных систем в комплекте с приложениями делающих все и вся порассуждаете, когда на scmRTOS сделаете десктопную OS .

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

[zltigo]

а время разработки и отладки прикладной программы для однокристального исполнения системы.

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

Я потребитель.

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

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

[Aprox]

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

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

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

[zltigo]

Для пользователя-прикладника - это затягивание времени, никакой стандарт и прочий академизм его не окупает.

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