Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: STR912 + CW 1.7
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
Страницы: 1, 2
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 )?
MALLOY2
Цитата(SimpleSoft @ Feb 5 2008, 19:13) *
День добрый.
Есть задача сделать съём с линейной 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 )?


При такой задаче я бы вобще с ОС не заморачивался...
Или мож я чего упустил ?
SimpleSoft
Цитата(MALLOY2 @ Feb 5 2008, 17:58) *
При такой задаче я бы вобще с ОС не заморачивался...
Или мож я чего упустил ?


Ну так а как запускать Ethernet? uIP?
MALLOY2
Ну не вижу тут никаких проблем, у меня LwIp str912, на нем крутится telnet, ftp, http, и рабочий порт для обмена информацией, все это без ОС. Хотя при такой связке я бы уже рекомендовал бы ОС. Но сложилось так что изначально никаких http и ftp не планировалось.
Vladimir_T
Есть книга самого автора uC/OS. В ней имеется глава по портированию системы на нужную платформу. При использовании средств отладки процесс портирования сокращает время и количество ошибок. Да и работа системы становится нагляднее, что важно для четкого понимания.
Правда, я -то свой проект под uC/OS делаю на основе проекта AlexandrY, под Keil. ОС прекрасно работает.
jasper
Цитата(Vladimir_T @ Feb 6 2008, 11:21) *
Есть книга самого автора uC/OS. В ней имеется глава по портированию системы на нужную платформу. При использовании средств отладки процесс портирования сокращает время и количество ошибок. Да и работа системы становится нагляднее, что важно для четкого понимания.
Правда, я -то свой проект под uC/OS делаю на основе проекта AlexandrY, под Keil. ОС прекрасно работает.

Зачем портировать самому? 07.gif
Когда есть официальный порт для STR91x: http://www.micrium.com/st/STR9xx.html
Alex B._
Цитата(jasper @ Feb 6 2008, 09:41) *
Зачем портировать самому? 07.gif
Когда есть официальный порт для STR91x: http://www.micrium.com/st/STR9xx.html

у микриума для ARMов порты, как правило, под IAR
Dron_Gus
"Портировать" между средами разработки явно приятней чем "портировать" между железяками.
SimpleSoft
Спасибо, всем кто отозвался. Вообщем пока сооружу 2 производную а потом займусь портированием с IAR на CrossWorks 1.7. Пока за это время гляну доку uCOS__The_Real_Time_Kernel.

Подскажите, пожалуйста, насколько проблематично перенести из IAR в CrossWorks? Какие есть подводные камни? Ограничивается это только исправлениями в векторах прерываний, поправке ассемблерных файлов?
zltigo
Цитата(SimpleSoft @ Feb 6 2008, 18:20) *
Пока за это время гляну доку uCOS__The_Real_Time_Kernel.

FreeRTOS для такого уровня камней более органична будет.
SimpleSoft
Цитата(zltigo @ Feb 6 2008, 17:28) *
FreeRTOS для такого уровня камней более органична будет.


Если не трудно, поясните, пожалуйста, почему?

А в чём заключается 45-дневная тестовая версия uCOS? Что после 45-дней? У неё наступает апокалипсис или это просто ограничение на продажу в коммерческих девайсах?
zltigo
Цитата(SimpleSoft @ Feb 6 2008, 19:05) *
Если не трудно, поясните, пожалуйста, почему?

На этом форуме уже отвечал. В двух словах - просто начинали делать с другого уровня развития контроллеров - нет дивных "родовых" ограничений uCOS одна задача - один приоритет, принципиальное наличие в системе менеджера памяти, все сделано более "сложно", но и более бескомпромисно с точки зрения использования системных сервисов. В свое время она максимально совпала с моими личными представлениями (предстваления базируются на собственном опыте многолетнего написания легоньких систем для разнообразных контроллеров) о построении системы весовой категории действительно выходящей за рамки наилегчайшего веса и которую можно развивать дальше не покушаясь на самые ее основы.
SimpleSoft
Цитата(zltigo @ Feb 6 2008, 18:33) *
На этом форуме уже отвечал. В двух словах - просто начинали делать с другого уровня развития контроллеров - нет дивных "родовых" ограничений uCOS одна задача - один приоритет, принципиальное наличие в системе менеджера памяти, все сделано более "сложно", но и более бескомпромисно с точки зрения использования системных сервисов. В свое время она максимально совпала с моими личными представлениями (предстваления базируются на собственном опыте многолетнего написания легоньких систем для разнообразных контроллеров) о построении системы весовой категории действительно выходящей за рамки наилегчайшего веса и которую можно развивать дальше не покушаясь на самые ее основы.


Спасибо. Буду разбираться. Как заведу устройство - отпишусь с результатами.
KonstantinT
Если в CrossWorks то зачем туда укос тащить, если в нем есть своя CTL библиотека? Причем с открытым кодом. Что-вы можете сделать на укосс и не сделать на CTL
SimpleSoft
Цитата(KonstantinT @ Feb 6 2008, 22:08) *
Если в CrossWorks то зачем туда укос тащить, если в нем есть своя CTL библиотека? Причем с открытым кодом. Что-вы можете сделать на укосс и не сделать на CTL


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

Если проблема лишь в том где достать дешевый JTAG для Keil RealView, то ARM выложил у себя апликуху как к RealView подключить халявный JTAG из проекта H-Jtag.

На бесплатные и проч GPL оси тоже покупаться бы не рекомендовал.
Дело тут не в оси, что она там умеет по большому счету не важно.
Важно какой софт для нее еще можно достать.
Для uCOS вы можете достать оптимизированный по производительности и отлично документированный TCP стек с интерфейсом BSD сокетов. В этом стеке предусмотренна в частности мультиинтерфейсность.
Можете достать очень мощную GUI с симулятором, оконным движком и проч. прибамбасами.
Можете достать многодисковую файловую систему, с полным набором функций и т.д.

А теперь узнайте, что предлагают opensource варианты. Это будут жалкие варианты TCP стеков, без мультиинтерфейсности, без нормального роутинга с ограниченным применением мультипоточности и без нормальной документации.
Файловый системы поголовно однопоточные и без защиты от мультизадачности и с урезанным набором файловых функций. Найдите, например, какую нибудь способную форматировать диск.
C GUI тоже плачевно.
Вот такие проблемы в перспективе тянут за собой opensource RTOS-ы.


Цитата(SimpleSoft @ Feb 7 2008, 14:56) *
Честно говоря даже не знаю что такое CTL. Поясните пожалуйста.
У юкоса есть готовый стек и связанный с STR91x ENET. Именно от него мне надо брать только функции accept, bind, listen итд. А к CTL, я так понимаю, надо прикручивать lwip. Не хотелось бы тратить время на прикручивание lwip, тем более что уже начал разбирать юкос. Хотя спасибо. smile.gif
SimpleSoft
Цитата(AlexandrY @ Feb 7 2008, 16:30) *
CrossWorks я у себя давно снес, и по его проблемам помоч не могу.
Но настоятельно не рекомедую использовать тулcы на базе GCC для ARM-ов.
Ухудшение параметров кода быстродейстие-объем получается чуть ли не в разы.

Если проблема лишь в том где достать дешевый JTAG для Keil RealView, то ARM выложил у себя апликуху как к RealView подключить халявный JTAG из проекта H-Jtag.


Можно поподробнее? Честно говоря, после вашего поста, у меня всё опустилось... эээ.... как сказать smile.gif
Launching H-JTAG Server and Configuring for Keil - эта я так понимаю... радости мне с FT2232 не видать?
zltigo
Цитата(AlexandrY @ Feb 7 2008, 17:30) *
Ухудшение параметров кода быстродейстие-объем получается чуть ли не в разы.

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

Достать хорошее слово, но мне, например, писать приходится а не только компилировать smile.gif - короче, возможны варианты.
Цитата
Для uCOS вы можете достать оптимизированный по производительности и отлично документированный TCP стек с интерфейсом BSD сокетов.

Кстати, если не сложно - где "достать" свеженький? Для так сказать посмотреть и решить вопрос о дальнейшем использовании своего либо о сдаче на милость других.
AlexandrY
С некоторых пор за обновлениями у Микриума не слежу, но выложил рабочий проект годичной давности на этой странице:
http://aly.ogmis.lt/OpenProjects/ARMDomina...RMDominator.htm

там портирован стек, тесты и операционка Микриума и многое другое.
Надежность и понятность стека на высоком уровне, я видел офигенно коммерческие стеки гораздо хуже выполненные.


Цитата(zltigo @ Feb 7 2008, 19:50) *
Ну далеко не все так трагично и на реальных проектах, а не попугаемерах идущих в комплекте с Keil все далеко не в разы, но тем не меннее мир GCC имеет свою специфику, которую либо надо признать за фичи, либо действительно пользоваться коммерческими продуктами.

Достать хорошее слово, но мне, например, писать приходится а не только компилировать smile.gif - короче, возможны варианты.

Кстати, если не сложно - где "достать" свеженький? Для так сказать посмотреть и решить вопрос о дальнейшем использовании своего либо о сдаче на милость других.
zltigo
Цитата(AlexandrY @ Feb 7 2008, 20:06) *
Надежность и понятность стека на высоком уровне

Хорошо, Ваше мнение для меня существенно. Посмотрю. Я тут для себя неожиданно выяснил, что свой стек, который не трогал лет шесть просто напросто подзабыл sad.gif Вот и подумал, может чей-то действительно хороший взять, раз свой код уже как-бы и не свой sad.gif
Цитата
, я видел офигенно коммерческие стеки гораздо хуже выполненные.

Ну с этого "добра" к сожалению навалом - не критерий sad.gif


Цитата(AlexandrY @ Feb 7 2008, 20:06) *
выложил рабочий проект годичной давности...

Тупо собрал IARовсий порт. Ну Remark, конечно, полезли smile.gif. Но и две ошибки на отсутсствующие функции.
Read_C15_ControlReg referred in STR91x_ports (...\STR91x_ports.r79 )
Write_C15_ControlReg referred in STR91x_ports ( ...\STR91x_ports.r79 )

Впрочем, это к делу отношения не имеет. На первый взгляд никакого сильного отторжения исходники стека не вызвали. Поищу посвежее и покопаюсь на досуге.
KonstantinT
Цитата(SimpleSoft @ Feb 7 2008, 14:26) *
Честно говоря даже не знаю что такое CTL. Поясните пожалуйста.
У юкоса есть готовый стек и связанный с STR91x ENET. Именно от него мне надо брать только функции accept, bind, listen итд. А к CTL, я так понимаю, надо прикручивать lwip. Не хотелось бы тратить время на прикручивание lwip, тем более что уже начал разбирать юкос. Хотя спасибо. smile.gif

CTL несложная переключалка задач, входит в состав CW. Там есть под нее визард
По поводу GNU - не принимайте так близко к сердцу заявление нашего уважаемого коллеги, он очень любит заниматься пиписькомерянием компиляторов maniac.gif .
Если Вам "ехать" а не "шашечки" , то обычный вигглер+СW и сразу начнете работать.
SimpleSoft
Цитата(KonstantinT @ Feb 8 2008, 15:08) *
Если Вам "ехать" а не "шашечки" , то обычный вигглер+СW и сразу начнете работать.


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

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

З.Ы.: Вот за что уважаю нашего брата, так за желание помочь ближнему... буржуи же даже чихают в кредит...
Dir
Цитата(SimpleSoft @ Feb 8 2008, 18:08) *
З.Ы.: Вот за что уважаю нашего брата, так за желание помочь ближнему... буржуи же даже чихают в кредит...


Не удержался. А Вы у них там не пробовали вопросы позадавть, прежде чем вот так огульно "не уважать"? Как на мой взгляд практически ничем, кроме языка, ни там, ни тут люди не отличаются. Тем более, что ничего нашего никто не предложил. Все только ихнее - "буржуйское". И ничего такого, чего бы не было на их официальных сайтах.
SimpleSoft
Цитата(Dir @ Feb 9 2008, 10:08) *
Не удержался. А Вы у них там не пробовали вопросы позадавть, прежде чем вот так огульно "не уважать"? Как на мой взгляд практически ничем, кроме языка, ни там, ни тут люди не отличаются. Тем более, что ничего нашего никто не предложил. Все только ихнее - "буржуйское". И ничего такого, чего бы не было на их официальных сайтах.


Задайте вопрос Cypress'у.... особенно часов эдак в 12 дня. Вообщем ИМХО пустая полемика.

Вопрос: поясните, пожалуйста, что это за RDI драйвера (или Third-Party) для JTAG (которые так хочет IAR и прочие среды)? Есть ли исходники RDI драйверов или... вообщем я новичёк в этом... но хотелось бы знать точно.
Dir
Цитата(SimpleSoft @ Feb 9 2008, 12:24) *
Задайте вопрос Cypress'у.... особенно часов эдак в 12 дня. Вообщем ИМХО пустая полемика.

Вопрос: поясните, пожалуйста, что это за RDI драйвера (или Third-Party) для JTAG (которые так хочет IAR и прочие среды)? Есть ли исходники RDI драйверов или... вообщем я новичёк в этом... но хотелось бы знать точно.


IARу RDI (Remote Debugger Interface) не надо. Это надо Keilу. Он через них с Segger-овским отладчиком J-link (JTAG) работает.
IAR с этим отладчиком работает напрямую.
Вся информация по J-link, в том числе и драйвера - у так нелюбимых буржуев http://www.segger.de/
Ключики к RDI - на FTP.
Нагло содранные аналоги J-Link: JetLink, JetLink-5, MT-Link.
Купить можно у MT-systems (Россия)
или тут: http://rusar.net/ru/file/jetlink.html (Украина)
Так что, ИМХО, понять буржуев можно. Они работают, а мы, по их мнению, норовим то, что ини разработали (т.е. потратили свое время и деньги) уворовать бесплатно. А люди они везде примерно одинаковы. Т.е. всякие есть...
SimpleSoft
Цитата(Dir @ Feb 9 2008, 17:29) *
IARу RDI (Remote Debugger Interface) не надо. Это надо Keilу. Он через них с Segger-овским отладчиком J-link (JTAG) работает.
IAR с этим отладчиком работает напрямую.
Вся информация по J-link, в том числе и драйвера - у так нелюбимых буржуев http://www.segger.de/
Ключики к RDI - на FTP.
Нагло содранные аналоги J-Link: JetLink, JetLink-5, MT-Link.
Купить можно у MT-systems (Россия)
или тут: http://rusar.net/ru/file/jetlink.html (Украина)
Так что, ИМХО, понять буржуев можно. Они работают, а мы, по их мнению, норовим то, что ини разработали (т.е. потратили свое время и деньги) уворовать бесплатно. А люди они везде примерно одинаковы. Т.е. всякие есть...


Спасибо.
Вообщем всё это оправдывает мой выбор CrossWorks + FT2232 smile.gif

Если не трудно, поделитесь (на мыло) полным юкосом. Тот что был на сайте производителя - я запустил на CW.
Aprox
Цитата(AlexandrY @ Feb 7 2008, 20:06) *
С некоторых пор за обновлениями у Микриума не слежу, но выложил рабочий проект годичной давности на этой странице:
http://aly.ogmis.lt/OpenProjects/ARMDomina...RMDominator.htm

там портирован стек, тесты и операционка Микриума и многое другое.
Надежность и понятность стека на высоком уровне, я видел офигенно коммерческие стеки гораздо хуже выполненные.

Скажите, вы тестировали стек на скорость передачи данных по Ethernet? Хотя бы в простейшем случае- точка в точку, без свитчей? Какую максимальную производительность показал стек на STR91 по TCP? UDP?
vsasha
ИМХО ucos не очень хороший выбор. Просмотрите форум, у нее достаточно много недостатков.
ucos хороша, если вы хотите (по чисто русской традиции) натырить много готовых кусков (файловую систему, сетьевой стек), и быстренько из них чтото слепить, не особо вдаваясь в то как все это работает.

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

Посмотрите в сторону SCMRTOS, она имеет не официальный порт под GCC, имеет не плохой функционал, еще и документацию на русском (по крайней мере для 2 версии). В ней на сколько я слышал в переключалке задач для ARM9 используется специальная инструкция CLZ, что уже даст заметный выигрыш на STR912.
Aprox
Цитата(vsasha @ Feb 13 2008, 11:55) *
Посмотрите в сторону SCMRTOS, она имеет не официальный порт под GCC, имеет не плохой функционал, еще и документацию на русском (по крайней мере для 2 версии). В ней на сколько я слышал в переключалке задач для ARM9 используется специальная инструкция CLZ, что уже даст заметный выигрыш на STR912.

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

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

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

А лучше отыскать на этом форуме ветку посвященную этой ОС, и предварительно ее почитать.
Русское описание, см. старые документы, для версии 2.
Aprox
Цитата(vsasha @ Feb 13 2008, 14:37) *
Порт на GCC есть в репозитории. см.http://sourceforge.net/projects/scmrtos/
А лучше отыскать на этом форуме ветку посвященную этой ОС, и предварительно ее почитать.
Русское описание, см. старые документы, для версии 2.


Документацию нашел. Однако, на ARM9 портов по-видимому в ближайшее время не предвидится, судя по занятости разработчиков другими делами. В указанной вами ветке говорится, что из серии STR армов сейчас выгребаются последние баги для ARM7, т.е. кристаллы STR7x . Об ARM9 и кристаллах STR91x речь вообще не заходит. Можно, конечно, самому взять за прототип порт для STR7x и пытаться что-то там подправить. Hо при этом затратишь столько времени и сил, что забудешь про основное свое занятие. Собственно, этот недостаток scmRTOS (сложная адаптация под различные платформы), честно признают и сами авторы.
SimpleSoft
Я запустил юкос на STR912FW44 под CrossWorks 1.7. Кому надо, могу кинуть порт.
dxp
Цитата(Aprox @ Feb 14 2008, 02:00) *
Собственно, этот недостаток scmRTOS (сложная адаптация под различные платформы), честно признают и сами авторы.

Можно указать, где про это сказано (сложность адаптации под различные платформы)?
Сергей Борщ
Цитата(Aprox @ Feb 13 2008, 22:00) *
Однако, на ARM9 портов по-видимому в ближайшее время не предвидится, судя по занятости разработчиков другими делами.
Не предвидется, но по другой причине - я с ARM9 не работаю и в обозримом будущем не собираюсь (нет соответствующих задач). Изучать его специально, чтобы написать порт, которым не буду пользоваться сам - не вижу смысла. Если кто-то с ними работает и желает сделать (или уже сделал) порт - добро пожаловать. Помощь и консультации через ICQ или мылом гарантирую. В репозитории лежит рабочий порт имени ReAlа под GCC для AVR и кое-какие наброски порта под GCC для ARM7 (пока работает только компиляция в режиме ARM и схема переключения 0). Вот он пишется в свободное время параллельно с освоением GCC.
Цитата(Aprox @ Feb 13 2008, 22:00) *
Можно, конечно, самому взять за прототип порт для STR7x и пытаться что-то там подправить. Hо при этом затратишь столько времени и сил, что забудешь про основное свое занятие.
Это уже каждый решает для себя сам - есть такое же готовое или придется приложить усилия. Для начала определитесь - будут у вас процессы создаваться в процессе выполнения, или их количество фиксировано на этапе компиляции? Если нужно создавать процессы в процессе laughing.gif работы, то scmRTOS вам не подойдет.
Aprox
Цитата(dxp @ Feb 14 2008, 10:22) *
Можно указать, где про это сказано (сложность адаптации под различные платформы)?

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

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

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

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

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

У меня процессы статические и ваша scmRTOS прекрасно подошла бы для работы. Она мне нравится по самой идее, простоте использования и отработанности механизмов взаимодействия процессов. Действительно, очень хорошая задумка, но, увы, - к современным кристаллам нет готовых портов. Вы призываете к самостоятельному портированию. В принципе можно, если бы в документации был-бы раздел "Портирование. Что надо проделать". Практической пользы от такого раздела было бы несравнимо больше, чем от от описаний, как устроен диспетчер - переключатель процессов.
zltigo
Цитата(Aprox @ Feb 14 2008, 16:42) *
У меня процессы статические и...

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

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

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

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


P.S.
Только бога ради не воспринимайте вышенаписанное, как критику scmRTOS. Это все было писано для расширения кругозора.
Aprox
Цитата(zltigo @ Feb 14 2008, 17:02) *
Насколько я понимаю, с системамы Вы пока не работали, но тем не менее уже утверждаете, что процессы будут статические. ARM9, с возможно внешней памятью, механизмами виртуализации памяти. А подумать?

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

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

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

Спорно.
zltigo
Цитата(Aprox @ Feb 14 2008, 21:06) *
как теперь я вижу в сравнении с scmRTOS, было стрельбой из пушки по воробьям.

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

В продукции этой фирмы, как и в Linux, так и в других больших системах работа с ядром сделана очень удобно, очень продумано, очень надежно и очень дуракоустойчиво. Цена таких решений для STR9 уже, на мой взгляд, великовата. Хотя в отдельных случаях из-за удобных, полных и надежных реализаций, например, IP стеков (Linux) или Графики (Win) могут уже использоваться и они. Об абстрактных удобствах сложных систем в комплекте с приложениями делающих все и вся порассуждаете, когда на scmRTOS сделаете десктопную OS smile.gif.
Aprox
Цитата(zltigo @ Feb 14 2008, 21:35) *
... сколько байтов и тактов рассчитываете сэкономить при переходе со знакомой уже системы к scmRTOS и насколько эти байты и такты критичны для контроллера уровня STR9, а не, например, для среднего AVR8?

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

Я потребитель. И рассуждаю как потребитель. Делать десктопную OS не моя специализация.
zltigo
Цитата(Aprox @ Feb 15 2008, 13:32) *
а время разработки и отладки прикладной программы для однокристального исполнения системы.

Вы ошибаетесь. У меня много причин по которым я не использую uCOS, но с точки зрения документирования, развитости интерфейса и дуракоустойчивости/надежности его использования и надежности системы вообще, uCOS очень очень хороша.
Своего рода стандарт.
Цитата(Aprox @ Feb 15 2008, 13:32) *
Я потребитель.

Тогда не рассуждайте о построении ядер операционных систем smile.gif. И не надо разговор о минималистичных ядрах пытаться на дежурную тему о MS перевести.
Aprox
Цитата(zltigo @ Feb 15 2008, 14:11) *
Вы ошибаетесь. У меня много причин по которым я не использую uCOS, но с точки зрения документирования, развитости интерфейса и дуракоустойчивости/надежности его использования и надежности системы вообще, uCOS очень очень хороша.
Своего рода стандарт.

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

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

Код
    template<typename T, word size, class S = byte>
    class ring_buffer
    {
    public:
        ring_buffer() : Size(size), Count(0), First(0), Last(0) { }

    private:
        S  Size;
        S  Count;
        S  First;
        S  Last;
        T  Buf[size];
    };


Зачем нужно поле Size? Я не нашел места в коде, где бы оно изменялось - то есть оно хранит константу, которую можно спросить у компилятора (а не читать из RAM).
zltigo
Цитата(Aprox @ Feb 15 2008, 15:33) *
Для пользователя-прикладника - это затягивание времени, никакой стандарт и прочий академизм его не окупает.

Величину этого затягивания времени в минутах назвать сможете?
Aprox
Цитата(zltigo @ Feb 16 2008, 20:20) *
Величину этого затягивания времени в минутах назвать сможете?

Расскажу по своему опыту работы с uCOS. Когда делал с помощью uCOS драйверы периферии, например I2C, в виде отдельных процессов, получающих задания от многих других процессов приложения, то пришлось нагородить из стандартных компонентов uCOS довольно сложную вещь. Hа выяснение всех неприятностей реального времени и отладку затрачено было примерно 2 месяца. Теперь же, читая документацию на scmRTOS, я вижу- все нагороженное уже реализовано очень просто и я бы не потерял те 2 месяца с возней на uСOS. Речь идет о шаблоне canal.
zltigo
Цитата(Aprox @ Feb 17 2008, 11:10) *
Hа выяснение всех неприятностей реального времени и отладку затрачено было примерно 2 месяца.

Это находится за гранью моего понимания.
SimpleSoft
Простите что прерываю вашу беседу, но в процессе работы с ЮКОСом возникла загвоздка:
Я создаю поток со следующим содержанием:

Код
static  void  AppTaskUserIF (void *p_arg)
{
    INT8U    s[20];
    INT8U    user_if_state;
    INT32U   value;

    int                     rfSocket,
                            rfClientSocket;
    int                     sockStatus;
    struct  sockaddr_in     sa_server,
                            sa_client;
    int                     client_addr_size;


    rfSocket = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP);

    /* Проверяем, создал нам сокет */
    if (rfSocket < 0)
      return;

    memset(&sa_server, 0, sizeof(struct sockaddr_in));
    sa_server.sin_family       = AF_INET;
    sa_server.sin_addr.s_addr  = htonl(INADDR_ANY);
    sa_server.sin_port         = htons(311);

    sockStatus = bind(rfSocket,  
                     (struct sockaddr *)&sa_server,
                      sizeof(struct sockaddr_in));
    

    listen(rfSocket, 1);

    while (TRUE) {                                   /* Task body, always written as an infinite loop. */

        client_addr_size = sizeof(sa_client);
        
        rfClientSocket = accept(rfSocket, (struct sockaddr*)&sa_client,&client_addr_size);
        if(rfClientSocket < 0)
            {
                close(rfSocket);
                return;
            }    
                        
                sockStatus = 0;
                
                while ( sockStatus >= 0)
                {
                  sockStatus = recv(rfClientSocket, (char *)&s, 1, 0 );

                  if (sockStatus >= 0)
                    send(rfClientSocket, (char *)&s, 1, 0 );
                }

                close(rfClientSocket);

        OSTimeDlyHMSM(0, 0, 0, 100);
    }
}


После запуска данного потока, система "висит" на процедуре accept. Всё было бы ничего, если бы не подвисание всей RTOS. Т.е. просто система не пингуется. Если же поток отключаешь - система номально отвечает на ICMP запросы.

Подскажите, в чём дело? Неужели надо пользовать Non-blocked функции (типа NetSock_Bind и тд)?
dxp
Цитата(meister @ Feb 16 2008, 21:58) *
Зачем нужно поле Size? Я не нашел места в коде, где бы оно изменялось - то есть оно хранит константу, которую можно спросить у компилятора (а не читать из RAM).

Да, наверное, следовало бы объявить поле Size как const, только это скорее всего мало что поменяло бы. smile.gif
meister
Цитата(dxp @ Feb 18 2008, 07:58) *
Да, наверное, следовало бы объявить поле Size как const, только это скорее всего мало что поменяло бы. smile.gif


Поле Size следовало не объявлять.
Aprox
Цитата(zltigo @ Feb 17 2008, 13:32) *
Это находится за гранью моего понимания.

Тогда просто поверьте, что имея в руках шаблон canal из scmRTOS, я бы не потерял 2 месяца на изобретение велосипедов.
dxp
Цитата(meister @ Feb 18 2008, 14:36) *
Поле Size следовало не объявлять.

А где размер хранить?
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.