Не претендую на всеобъемлимость знаний, но то, что я видел лицензионнное у коллег на Windows CE не содержало в себе компилятора в принципе - только софт для конфигурации образа из всего готового.

ну студия у нас все равно есть, хотя пока старая.

но суть в другом. давайте сравним с ценой на eCos, которую в общем то зря ругают -
можно прикупить ее с

eCosPro-PEG+ графическая библиотека
eXtremeDB база данных
CANopen protocol stack
и ethercat, хоть простой но есть

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

Сообщение отредактировал DimaM - Mar 7 2008, 18:48

Возможно, это был OEM Pre-installation Kit.
По факту, для СЕ5.0 в средства разработки входят Platform Builder (для постоения имиджа из готовых компонентов) + эмулятор + Embedded VC 4.0 (с компиляторами для всех платформ).
Для СЕ6.0 в средства разработки входят сам билдер (как плагин к студии 2005), сама студия проф, мсдн соответствующий, и еще что-то с MSSQL связанное (диски на работе, если нужно - уточню) + эмуляторы + компиляторы для всех поддерживаемых платформ.

может я отстал от жизни - имел дело с uCOS 2.51 - это была примитивная переключалка задач, достоинством которой можно считать сопровождающую книжку по написанию примитивной RTOS

сравнивать ее (ядро) можно с scmRTOS , возможно с минимальной конфигурацией RTEMS

в uCOS отсутствует "вращение приоритетов", spinlock-и ну и вообще нормальные сервисы (я пускал uCOS на 86 и BF и немного представляю ее возможности)
ну и я не прикладной программист - сервисами RTOS в больших проектах не пользуюсь, написал то с чем сталкивался - но у нас прикладников RTEMS не удовлетворяет (а это тоже далеко не uCOS)

возможно, что для каких-то задач отложенные прерывания, SMP (для ARM-а мы пускали ее на двухядерном камне) и пр. свойства eCOS покажутся излишними - ну дык флаг в руки.
во вторых eCOS поддерживает промышленные стандарты - тот же uITRON

описать ее в виде книжки - как сделано для uCOS - трудно из-за совершенно другой весовой категории (скажем так - из-за количества строк кода)

конфигурируется eCOS путем исправления неких конфигурационных файлов, после чего из этого генерится С++ код (как правило h-файлы)

перенос платформы с какой-либо похожей выполняется весьма просто

---------------------

я ни в коей мере не хочу сказать - если задача решена минималистическим способом, то это плохо,
скорее наоборот
но при достижении проекта размера в пол-лимона строк смысл выигрыша за счет примитивного ядра - теряется
по поводу надежности - тоже сильно сомневаюсь, так как пользовательский код приходится извращать (любимый пример с тремя процессами, когда низкоприоритетный захватил семафор, который ждет высокоприоритетный - это не надумано, а часто бывает)

и ресурс (как правило самый критический) - это время разработки, я убежден - что после некоторого порогового значения (тыщь 100 строк) uCOS начнет по этому ресурсу сильно проигрывать у eCOS

ссылочку дайте, на Ваши конкурентноспособные решения
вот наша продукция
http://javad.com/jgnss/
http://javad.com/jns/index.html

ну и здесь софт на eCOS или RTEMS
http://www.topconpositioning.com/products/gps/

Что-то вы даете ссылки которые сами видать не читаете.
Цитирую: "A testing fee of $1,500 US per BSP"
http://msdn2.microsoft.com/en-us/embedded/aa714500.aspx

Они, конечно, тему пытаются замнуть, но я думаю они пошлют вас далеко если попытаетесь качать права про траблы CE на несертифицированном BSP.
Остается также вопрос, кто даст право копировать референс дизайны плат с CE и по каким критериям будет считаться, что референс дизайн скопирован достаточно точно чтобы не сертифицировать повторно BSP.





А вот если есть деньги, то потратить их можно на гораздо более умные ОС-и чем eCOS с командой халявщиков из ecoscentric (приходилось общаться), и разговор можно начинать сначала, потому что тогда начинается совсем другая тема.

Не понял от чего там надо тащиться
Пошарил, нигде упоминаний eCOS не нашел.
Тем более в таких фирмах фиг отличиш где ребрендинг, а где свое.
Конечно спасибо, что хоть это показали, стал понятен ваш контекст.
OEM борды, если вы их делаете сами, впечатления не производят, изредка упоминаемый софт на них весьма беден, как раз уровень uCOS-а (не считаем специализированно-прикладного, возможно достойного уважения).
Наверно из-за оригинального ядра вы привязаны к GCC. Тогда это многое объяснеет.
Не надо только думать, что я тут агент Micrium-а.
Мы тож GPS балуемся: http://www.teltonika.lt/en/pages/view/?id=17
RTOS ARTX , если слышали о такой, нашим спецам по уши хватает.
По еСOS у меня книжка есть, могу поделиться если надо.

чтобы было понятно какие что мы делаем дам ссылку на конкурентов. у них пока спектр продукции пошире будет
http://www.trumpf-laser.com/207.index.html

Читаю Вот, например: "If you want to list your BSP as a "Non-Certified," just complete and send in the appropriate request form above without sending in your CETK test logs and ignore the "Submitting Your Device" process below." И никаких $1500. BSP сертифицировать не обязательно, можно его вообще не отправлять в майкрософт, это не помешает купить рантайм лицензии и клеить на свои устройства наклейки.
Вся эта бодяга придумана для OEM производителей железок, на основе которых другие компании разрабатывают законченные устройства. Т.е. фактически это реклама.

По поводу Wi-Fi, Bluetooth, USB дивайс огласите пожалуйста действительно стоящее железо, которое вы не смогли прикрутить.
По поводу интерфейса пользователя - чем uCOS так сильно облегчает его построение? Тем, что графическая библиотека всего одна, и у Вас нет выбора?
По моему мнению недостатки uCOS есть продолжение его достоинств - она маленькая и понятная. Соответственно для того чтобы быть маленькой у нее нет абстракции железа. А раз так, то становится проблематично обмениваться приложениями, разрабатывать приложения на продажу. Соответственно нельзя ожидать, что под нее вы найдете даже за деньги все, что вам надо,
придется разрабатывать самим даже очень простые приложения или прикручивать из другой RTOS.

Следующая проблема - потребуется ли Вам развивать дальше Ваше устройство - сегодня пользовательский интерфейс, а завтра?

Например, потребуются к вашим устройствам подключать USB-принтеры - где возьмете USB-хост стек, принтерную подсистему?
Есть ли это в Windows CE? В uCOS этого нет и не предвидится.
Тоже самое с Bluetooth - вставляете USB-донгл или подключаете RS-232 модуль - и работаете.
А в uCOS?
В Линукс это уже есть и уже работает, и как раз благодаря наличию драйверной подсистемы - это живет на очень
разнообразном железе и с очень разнообразным ПО.
Да, есть недостатки. Мало документации, часто она устарела. Система очень быстро развивается, поэтому все быстро меняется. Система сложная и "тяжелая". Отлаживать ее тоже довольно трудно. Получить реальное время на ней тоже сложно.
Однако это не мешает ее успешно применять.
Даже уважаемый AlexanderY ее применяет:
http://www.teltonika.lt/en/pages/view/?id=858

Поэтому все приходится взвешивать и в каждом конкретном случае - решение получается свое.

Есть Там еще много чего есть, например directX/windows media, что позволяет довольно просто выводить видеопотоки.

Совершенно верно.

Ok! Тема видно народ волнует.

Но здесь очень важен контекст.
Я не обсуждаю здесь абстрактные тренды.
Человек описал достаточно ясные рамки задачи.

Тот роутер, что вы у нас нашли, во первых как раз то случай ребрендинга, а во вторых я хорошо знаю R&D контору которая это делает. Их цикл разработки такого роутера более года! при том, что они уже с десяток лет в той области.
Это совершенно недопустимые сроки для стартапного проекта, когда вы хотите срочно догнать и перегнать конкурентов имея вдесятеро меньший бюджет.

Итак, я даю вам MonataVista на своей плате с iMX27 и оригинальным внешним Phy USB host-а мультиплексированным с ATA (такое уж решение в реф. дизайне было применено), а вы мне хотябы в течении месяца прилепите любой USB-WiFi адаптер при сохранении соответствующей скорости?

Проблема драйверов чуть ли не самая мертвая в Линуксе если речь идет о своих платах.
А задача именно ориентирована на свои платы, поскольку иначе оказываетесть привязаны к сторониим производителям и они в бизнес вносят серьезный риск и тормоза.

Поскольку речь идет о достаточно понятной линейке промышленных дивайсов, локальных, с хорошей проводной связью, абсолютно ясной прикладной функциональностью, то человеку явно не надо гадать какие такие выдающиеся прибамбасы понадобятся там в будущем.
Достаточно быстрого TCP стека, простенькой файловой системы. GUI вообще не нужен.
Хотя для uCOS есть выбор разных GUI.
Опять же GUI уткнутся в драйвер дисплея и опять с Линуксом будет ступор.
Тачскрин - это вообще элементарный прибамбас который к любой GUI на любой RTOS прикручивается за день. И даже без GUI.
В поставке компилятора IAR есть эффектные примеры, как тачкскрин и скины из BMP делают крутой интерфейс вообще без ОС.
Логично просто сделать в дивайсе HTML интерфейс на базе встроенного WEB сервера для управляющего PC, или выносной панели на основе PC.
HTML интерфейс как известно кроссплатформенный, тут вообще не важно под какую OC он написан.

Денег у человека на специализированные стеки нет, т.е. акцент на самостоятельное написание.
Тут компактность OS абсолютно необходима. Если одна итерация исправления, перекомпиляции, загрузки на целевую платформу и запуска отладки полного имиджа включая RTOS длиться всего пару десятков секунд, то человек гарантированно может исправить любую ошибку в системе за день.
Благодаря инструментам трассировки, внутрисхемной отладки на базе JTAG, человек освобождается от написания бесконечных отладочных вставок и логов, которые сами искажают код в свою очередь и могут иметь местные эффекты.
В Линуксе если ошибка в ядре в каком-нибудь прекомпилированном модуле, только поиск может занять пару дней.
А ошибки в ядре обязательно будут, поскольку ядро очень большое и монолитное и, как правило, пропатченное неизвестно кем.
Учтем, что человек с embedded Linux никогда не сталкивался.

Итого мой диангоз - цикл разработки на RTOS в данном случае будет раза в два короче чем на Линуксе.

Я как то поговорил с продавцами uCOS. для случая с большим количества разнообразных устройств у них нет нормальной лицензии. Хотя можно скачать все исходники использовать их без оплаты не позволяет совесть(законы) а платить заметно дороже wince получается.
И подобная ситуация у множества производителей мелких и не очень RTOS.

Посмотрите на систему лицензий ThreadX.
Там есть лицензии на все возможные стратегии разработки и выпуска изделий.

Все уже разработано за нас:
http://rt2x00.serialmonkey.com/wiki/index....title=Main_Page

Проблема драйверов мертвая в том смысле, что производители устройств не предоставляют спецификации на эти устройства. И эта проблема будет мертвая не только в Линуксе, но и в любой другой операционной системе, а тем более в маленькой RTOS за исключением больших Windows. (я думаю, что и в не маленькой QNX, будет ровно такая же проблема).

Хотелось бы услышать мысли по-поводу драйверов представителей WinCE
Насколько легко/трудно добыть драйвера для устройств?

Например, упомянутые WiFi модули от Ralink драйверов для WinCE не предоставляют:
http://www.ralinktech.com/ralink/Home/Support/Windows.html
Это не показатель, просто попавшийся пример.



Здесь я абсолютно с Вами согласен.
Единственно - экономические условия мы додумали сами. А здесь, мы как раз можем и ошибаться - так как задача обрисована в общих чертах.
Я, глядя на приведенные устройства (которые с лазером), не решился сам додумать всю возможную функциональность. Может для них время разработки не принципиально, а важна определенная фича - "конкурент киллер" и без нее не жизнь? Или действительно минимум на разработку, минимум денег минимум функциональности?
Оптимальное же решение включает учет многих деталей, которые здесь не обсуждаются, да и не должны. Поэтому, в вопросах (точнее ответах) на извечные вопросы хочется слышать ответы более развернутые, что ли. Ведь ответы "ставь Линукс и будет тебе счастье" или "все Г.." как-то не вдохновляют.
Если с маленькими RTOS становится все более-менее понятно, то с большими - много тумана.
Да и с маленькими - тоже оказывается не все так просто - попытка посчитать деньги привела к мысли, что решение очень дорого. Кстати, а если посчитать, сколько времени и соответственно денег, будет потрачено, и сколько сэкономлено, то может быть все окажется не так плохо?

это все свое (собственная разработка), одна группа основных разработчиков участвовала, поэтому "ядра" в продуктах разных фирм одинаковое
то что eCos во всех кроме PPC (там RTEMS) - поверьте. сообщать эту информацию финальным пользователям нет смысла

там используются чипы собственной разработки (JNScore - двухядерный, который я упоминал и делал начальный порт ecos во время разработки чипа), то есть это к утверждению о легкости портирования и доступности этого малыми силами

а протащиться - ну если посмотрите стоимость - то такие платы (не говоря уже о приборных комплексах) могут стоить 50к$ и выше - что несколько отличает от "обычного" GPS - то есть всю [добавленную] стоимость представляет софт

=======================

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

НО Линукс требует большИх ресурсов (памяти, выч. мощности и т.п.). с Линуксом труднее сделать реал-тайм (мы использовали ОМАР и реал-тайм крутился на DSP) и сделать энергосбережение.

то есть для большинства эмбедерских задач Линукс избыточен.

например, у меня есть две китайские книжки с e-ink-овскими экранами (к разработке я отношения не имел ) - при этом линуксовская сжирает аккумулятор в 3-4 раза быстрее (там экран не жрет, а все затраты на "вычисление") и глючит почаще. но зато Линуксовская книжка "читает" все форматы - то есть дофига софта уже написано и можно было его быстренько заиспользовать.

думаю - такая же ситуация будет с любым эмбедерским девайсом - если есть необходимость писать много "гуд-инаф-софтварь", то линукс. если нужно более надежное решение - то RTEMS, eCos
если достаточно примитивного набора функций - то scmRTOS, uCOS, salvo и т.п.

я не сталкивался с VxWorks, Tornado, Symbian и пр. коммерческими операционками, поэтому не берусь судить о них. но опыт использования (общения с саппортом) крупных производителей софта, сильно смещает симпатии в сторону активных open source проектов

=======================

использование WinCE оправдано, имхо, только там, где пользователь хочет увидеть "знакомые" окошки - то есть всякие наладонники, коммуникаторы и т.п.
если есть возможность скрыть от пользователя "внутренности" встраиваемого устройства или пользователь удовлетворится нестандартным ГУЕм - то от виндовса можно (имхо, НУЖНО) отказаться

=======================
=======================

сейчас в конторе идет обсуждение перспективного железа (конкретно, АЗИКа для будущих продуктов) и не во все споры мне удается вступить - вот оттягиваюсь в конфе простите за многословность