Мучаюсь сомнениями - намечается проект относительно сложного устройства. Электроника будет управлятся через fpga процессором под управлением операционки. Код со временем разрастется и не хочется ошибится вначале.
ОС нужна чтобы библиотеки использовать, а всего то надо сделать
- достаточно сложную калибровку
- хранить множество настроечных параметров
- продвинутый лог о работе прибора
- сделать доступ к устройству через сеть
- сделать CAN мастера, или подключить библиотеку.
- может и EtherCAT мастер потребуется.
- сложной индикации не будет, может и не будет вообще.

что быстрее освоить? опыт есть только в windows и микроконтроллерах.
для желаемого процессора достал linux BSP но мало разработанную, более хорошая wince bsp стоит денег.

Думаю точно не ecos. Если linux работает "из коробки" можно его, а иначе только винды.
Да и с сетью и файловыми системами в ecos не очень. Хотя с другой стороны это под описываемые задачи наверняка более чем достаточно.

с виндами проблема в том что они к железу более требовательны. ARM от Hilscher, который собрался использовать имеет MMU и работает с виндами, однако в переспективе может только NIOS использовать буду, тогда linux лучше.
Только за linux братся страшно, хочется тратить усилия только на написание приложения, а не на изучение инструмента.

Хе, я когда-то из праздного интереса занялся изучением пингвина. Вот уже 5-й год дома живу под ним... С месяц назад купил ноут, через пару недель снес висту, просто не осилил существовать под ней -- этого нельзя, того неможно... Ужас...
Я это к тому -- может имеет смысл наоборот плюнуть на все и изучить? ;-) Глядишь, понравиться. Во всяком случае, я бы однозначно предпочел бы пингвина. Есть (на мой взгляд) прекрасный компилер (gcc), да и денег не просят. Море документашки, в том числе по устройству и написанию дров.
Вот только, увы, за месяц не изучишь его, это факт. Времени много уйдет. Но, тем неменее, может имеет смысл плюнуть на сиюминутную выгоду и освоить инструмент?

Некорректно даже их сравнивать, все-таки eCos – это RTOS.
Если реальное время не требуется, значит, выбираем между WinCE и Linux.
Если нужен развитый GUI, то скорее - WinCE, если поддержка сети – Linux.

нужно писать приложение и драйверы для доступа к железу. сеть нужна.

проблеммы не нужны

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

Вопрос исчерпан - пингвин. Доступ к железу будет проще в разы.

Что-то не видно в перечисленных задачах необходимости применения "тяжелых" операционных систем, кои в основном полезны либо при навороченных графических интерфейсах либо бескомпромисных TCP/IP стеках с роутингом и прочими наворотами.

Что за неоправданный наезд на eCos? Нормальный TCP/IP стек. Даже три штуки, на выбор.
Файловые системы - спорный вопрос. Там где применяют eCos, ext3 обычно не нужна. :-)

eCos и Linux вообще нельзя сравнивать. eCos статически линкуется с приложением, не поддерживает MMU и т.д.
Все зависит от задач и оборудования. Попробуйте-ка запустить linux на 2M RAM. А eCos замечательно работает.

Ну тогда точно Линукс. ИМХО особенно по второму пункту.

Удивлен, что Вам удалось скомпилировать программу с помощью eclipse. Eclips - это не компилятор.
А что-бы получить приемлемый код, как по размеру, так и по быстродействию в GCC нужно правильно использовать его опции.

WinCE тоже декларируется как RTOS, а по факту они все RTOS (или нет), хехе

Linux+: Поддержка большого кол-ва оборудования, бесплатность.
Linux-: С "реальным временем" придется туговато, также отсутствуют нормальные тулзы и документация (относительно win, конечно) - по началу будет непривычно, кроме ядра еще нужна rootfs (впрочем, это мелочи).

WinCE+: Куча готовых прикладных библиотек и интерфейсов, знакомый GUI, "реальное время", очень хорошая документация и инструментарий "из коробки".
WinCE-: Довольно дорогая (~1к) + платные рантайм лицензии, поддержка оборудования и файловых систем довольно ограниченная.

И в том и в другом случае Вам придется изучать архитектуру ОС "с нуля", сложность примерно одинаковая (хотя linux более "наворочен"). Также Вам придется писать BSP, по трудоемкости тоже особых различий нет. Математику реализовывать все равно для какой ОС, остаются драйвера. Свои собственные писать все равно под что, а вот для стандартного оборудования (сетевого контроллера) в WinCE могут драйвера отсутствовать.
А по требованиям к железу WinCE будет как раз попроще linux при одинаковом функционале.

P.S. Рассматривалась WinCE 4.2-5.0 и последние ядра linux.
P.P.S. Если выберете WinCE закладывайтесь на 6.0 версию, т.к. там довольно сильно поменялась архитектура и модель драйверов.
P.P.P.S. Про eCos сказать нечего, т.к. не работал с ней.

Для Линукса есть RTAI и этим реалтаймовость его не ограничивается.

я понимаю что используя Eclipse, я использую GCC, но Eclipse как раз позволяет проще настроить опции компиляции. Но как не настраивай, код даже для ARM не очень получается, а уж для NIOS вообще отстойный был. Этот опыт с GCC и заставляет задумыватся, стоит использовать Linux или лучше платить деньги за операционнку и компилятор микрософта. Однако посмотрев на выставке Embedded World, еще раз убедился что различных решений на Linux больше чем на WinCE.


еще они полезны большим количеством библиотек. Например для работы с XML.


чтобы защиты и регулировки реального времени иметь надеюсь обойтись fpga & vhdl.
процессор должен все проинициализировать и вспомогательные задачи делать раз в несколько милисекунд.

а вот про требования к железу я не понял что значит при одинаковом функционале? для snmp в linux потребуется больше памяти или MMU станет обязательным?

и еще я не пойму - если все мое железо управляется записью чтением в некоторую область памяти зачем надо писать драйверы и глубоко разбирася в устройстве OS? Пользователь своих программ в устройстве делать не будет, то есть только мое приложение и операционка

Правильный подход

И linux и wince довольно хорошо конфигурируются, позволяя выкидывать ненужный функционал и снижать требования к памяти и быстродействию. Сугубо личная оценка "на глазок": wince покомпактнее Однако наличие MMU для нее обязательно. Впрочем, у майкрософта есть .NET Micro Framework (http://msdn2.microsoft.com/en-us/embedded/bb267264.aspx), для которого MMU не требуется (вот ведь плодовитая компания )

Хмм, для простых устройств можно обойтись без драйверов и педалировать железо прямо из прикладной программы. Однако такой подход в линуксе имеет существенные ограничения, связанные с недоступностью многих сервисов ядра и непредсказуемостью выполнения кода (во времени). В wince можно вообще стереть грань между ядром и программой, но не думаю, что это хорошее решение (обычно такое требуется при жестких ограничениях на производительность цпу). А простенькие драйвера можно ваять и без глубокого погружения в устройство ОС, интерфейсы там простые, не то что в NT.

Да, чуть не забыл. Можно скачать/заказать пробную версию PlatformBuilder'а, которая будет делать вполне рабочие образы (нелицензионные, конечно). И "пощупать" самому все три варианта.

Постоянно делаю такие дивайсы и скажу вам, что Linux и WinCE здесь рядом не лежали.
Нормальных быстрых мультизадачных стеков прикладных протоколов ни под CAN ни под EtherCAT на халяву вы не найдете ни для Linux ни для WinCE.
Разработку интерфейса пользователя ни WinCE ни Linux никак не облегчают по сравнению с разработкой для того же uCOS.
В вашем приложении совсем ни к чему драйвера, у вас фиксированное железо.
Так зачем выбирать операционку требующую драйвера, а потом мужественно их писать, бороться за их совместимость и получить в результате лишь тормоза?
А как вы будете отлаживать баги? В Линуксе с JTAG практически нечего делать.
Для файловой системы вам достаточно FAT16. Так этого добра навалом для любой операционки.
Сетевых стеков гораздо более быстрых чем под Linux-ом тоже навалом для простых RTOS.
Для действительно стоящего железа все драйвера в Линуксе исключительно бинарные, т.е. прикрутить какой-нить произвольный Wi-Fi, Bluetooth, USB дивайс к вашему произвольному Линуксу будет такой же нереальной задачей как прикрутить то же к uCOS.
Более сложные сетевые сервисы чем стек TCP/IP вам на Линуксе будет поднять также сложно как и на uCOS-е
А eCOS - тот, что лежит в открытых исходниках вообще недееспособен.

Слишком много безапелляционных утверждений...

Ну это вам показалось

Жду возражений.

Если Вы постоянно такие девайсы делаете не на Linux или WinCE то как можно так заявлять?


Пример: http://developer.berlios.de/projects/socketcan/ - финансируется фольксвагеном, скоро будет включен в ядро. В общем, ищущий всегда найдет

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

Не совсем понял фразу. Если Вы сетуете на дополнительную абстракцию в виде драйвера (которая, кстати, не всегда вносит оверхед), то она окупается с лихвой в будущем, даже для несложных устройств. Пара режимов энергосбережения + несколько состояний железяки + несколько таких железяк + код, размазанный по всему проекту приведет к увлекательному тестированию, ага

Не стоит обобщать собственный негативный опыт, имхо. И пафоса много

Конечно нечего, за ненадобностью. Это только плюс.

Опять 25. Если носитель флеш, то фат никак не подойдет, флеш будет портится быстро. И т.д. и т.п.

Сетевой стек под линуксом хотя бы отлажен. А то потом придется разбираться, почему с этим свичем работает, с этим не работает, а этот свитч сам перестает работать. И скорость у него вполне приемлема. Даже очень.

Из действительно стоящего железа бинарные драйвера существуют только у известного производителя видеокарт. Наряду с опенсорсными драйверами, кстати. Все остальные случаи - либо суперновая железка, либо китайский нонейм.

Т.е. поднять так же сложно как портировать?

Но комментс. Просто не в курсе.

Вообще, не покидало ощущение что мы говорим немного о разных железках, Вы максимум о меге128, я - минимум арм7

И еще, Вы какую ось имели ввиду: uC/OS-II или eCOS?

и не только ему

eCOS замечательно собирается из исходников (используем для PPC, SPARC, ARM)

сравнивать uCOS и eCOS все равно, что DOS3.0 c ВИСТОЙ - совершенно разные весовые категории

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

мое мнение по теме - всегда предпочтительней иметь контролируемость кода, то есть доступ к исходникам. потому что разбирать, если что-то не работает в "екзешниках" крайне малоприятная задача (очень давно имел такой опыт с WinCE + ARM)

ну и естественно брать те инструменты, которыми умеешь пользоваться (если проект имеет срочность / важность и т.п.)

gcc - хороший компилятор, но не для всякой платформы он генерит хорошо оптимизированный код (сравнимый с "фирменым" компилятором) - например, для того же BF, я предпочитаю VDSP

ARM-ом давно не занимаюсь, но предполагаю, что IAR может генерить лучший код (когда сравнивал с ADS-ом 1.1, вроде было одинаково gcc vs ADS)

Что то меня это "замечательно" не убедило.
Сколько времени потратили на портирование на первый проц?
Вы сами портировали?
Платформу сами делаете?
Из тех самых открытых исходников?
Какой нибудь промышленный протокол используете или что нибудь хитрое над TCP вроде VPN, SNMP3, SOAP, CORBA, VoIP?

Логично учиться на чужих ошибках.
Я профессионально занимаюсь переводом дивайсов с Линукса на малые RTOS-ы.
Хуже было бы если бы я был уже подсевшим на Линукс. Тогда объективности было бы ноль.




Тут вы дали че-та непонятное. Этож просто невразумительная концепция и даже незаконченная.




Ничего хорошо известного нет в неизвестной и плохо документированной операционке. В первую очередь в eCOS, чуть меньше в Линуксе и WinCE




Ничего не окупается, чел пишет все сам и для себя ему ни к чему чужие абстракции.




Мысль была о том, что умный в гору не пойдет! Определение "пафос" здесь выбрано неправильно.




JTAG ускорояет отладку на порядок, это студенты должны знать.



Применить FAT на SD, MMC, CF, USB или IDE карте самый легкий и верный путь.




Для промышленных применений скорость обычного TCP стека неприемлема.
А может вы пробовали открытые исходники EtherCAT? Так это убожество. Отличный способ убить жизнь на доводку.



Для большинства современных SoC драйвера закрыты поскольку закрыта архитектура самих SoC-ов.
И уже думаю не будет больше открыта.



Именно, вы правильно схватили.
Портировать под RTOS типа uCOS может быть гораздо проще чем поднять на Линуксе.




Мы говорим как быстро и эффективно выполнить задачу любыми средствами как она проглядывается в контексте первого поста. При этом не потерять здоровье.



Кстати, какие бывают порты и платформы под uCOS можете посмотреть еще здесь: http://aly.ogmis.lt/Subjects/RTOS/rtos.htm
Такой проект как SmartARM2200 с uCOS заткнет по эффективности любой самопальный Линукс или eCOS проект на той же плате в рамках обсуждаемой задачи.

>>> Ничего хорошо известного нет в неизвестной и плохо документированной операционке. В первую очередь в eCOS, чуть меньше в Линуксе и WinCE

там же код открытый - все доступно для понимания (впрочем как и в uCOS или scmRTOS)
на форумах по линуксу/екосу мне гораздо проще найти солушин, чем в мсдн-е или каких-то виндо-хакерских форумах

и если это плохая дока - то хм....
http://ecos.sourceware.org/docs-latest/ref/ecos-ref.html

сам я порты делал для ARMa SPARСа
за 1 день делается минимальная (работа ОС и вывод по уарту) , причем я не программист, а HDL дизайнер по штатному расписанию

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

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

в продуктах используется вся шняга TCP, USB драйвера, всякие крипто-библиотеки, JFFS и т.д.

Я еще поговорил с разработчиками приборов, для которых будет применятся указанная плата и выяснилось, что опционально touchscreen все-таки желателен. И по этому выбираю wince, чтобы потом окошки рисовать быстро было. Понял что драйверы писать не буду. Первую версию скорее всего сделаю с Dimm PC платкой. Потом когда все отлажу сделаю одну плату.

По поводу uC/OS-II - поддерживается она конечно хорошо, но для наших маленьких партий приборов будет слишком дорогая. У них неподходящая нам политика лицензирования.

WinCE наверное самая дешевая операционка для нашего случая. За лицензию всего 3 евро, средства разработки тоже достаточно дешевые.

EtherCAT стек можно за 10000 взять, но пока решил обходится без него.


заказчик на просьбу выбрать любые 2 слова из "быстро, хорошо, дешево"
выбрал быстро и хорошо. придется немного больше затратить на железо.

Ага, ясно.

Чесно вам скажу, что та дока на которую вы дали ссылку является просто пародией на доку!
Для сравнения взгляните на описания ThreadX, uCOS, VxWorks и т.д.
Там по каждому пункту, как: TCP стек, WEB сервер, FTP сервер, SSL библиотека, файловая система, крипто библиотеки, графика и т.д. описания размером в целые книги.
Мануал на VxWorks около 2000 листов!
А здесь умудрились по каждой теме отделаться парой параграфов каждый не более 100 строк.

Ну наверно они расчитывают, что вы будете читать исходники.
А вы умеете читать плохо комментированные исходники как книгу?
Я нет, и даже не собираюсь этому учиться. Потому что есть гораздо более легкие пути.
Еще из той доки, что вы привели явствует, что тому же uCOS этот eCOS значительно уступает по объему и качеству прикладных библиотек.

За 1 день порт не делается ни на одну операционку. Если, конечно, вы под этим процессом не подразумеваете запуск готового BSP на готовой плате стороннего производителя.
Но такую работу я не считаю достойной упоминания.

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

3 доллара это без графической оболочки, только консоль. С графикой ~$17 примерно.

Это для платы стороннего производителя.
А поставить официально CE на плату собственной разработки стоит 1500$ минимум.

Откуда дровишки? Из лесу, вестимо
В двух словах вот: http://msembedded.ru/licensing.aspx

Ну и? Стоимость средств разработки+минимальный пакет лицензий это сколько? При этом даже о стоимости собственно компилятора умолчим.

Там речь идет о лицензии для производителя устройств.
Я же имею в виду условия для производителей оригинальных плат. Чувствуете разницу?
Вы удивитесь, но в CE надо и BSP лицензировать. Вот это вам и влетит.

http://www.msembedded.ru/windowsCE6.0.aspx тыкаем на Приобрести Windows CE 6.0 (справа) получаем http://www.ntshop.ru/shop/subdept.asp?dept=2133
Считаем: WinCE Platform Builder 6.0 EMB English ESD OEI DVD 1,094.00 у.е + Windows CE Vertical 6.0 EMB ESD OEI Set Top Box Runtime 10-Pack 172.00 у.е. = 1266 у.е. с 10 рантаймами.
CLA, конечно, нужно подписать, но это бесплатно (не считая работу юристов).


Так у производителя устройств на выходе получаются платы, цитата: "собственной разработки".
BSP лицензировать не обязательно. Просто такой BSP не будет на сайте майкрософта проходить под категорией "Microsoft Certified" (http://msdn2.microsoft.com/en-us/embedded/aa714506.aspx).
AlexandrY, Вы так и не объяснили происхождение числа $1500


В средства разработки компилятор входит. А для CE 6.0 туда же входит студия 2005 проф. И еще кой-чего

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

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

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

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

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

Возможно, это был 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 оправдано, имхо, только там, где пользователь хочет увидеть "знакомые" окошки - то есть всякие наладонники, коммуникаторы и т.п.
если есть возможность скрыть от пользователя "внутренности" встраиваемого устройства или пользователь удовлетворится нестандартным ГУЕм - то от виндовса можно (имхо, НУЖНО) отказаться

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

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

Чесно не въехал в логику вашего бизнеса.
Если бухать столько денег в разработку ASIC-а (или всетаки SoC-а?), то зачем экономить на софте?
Хотя, правда, нынче SoC-и можно себе сделать и с бюджетом в 100-200 тыс. баксов.
А вот тот же стек мобильных устройств стоит под пол лимона для примера.
Сорсы VxWorks под 120 тыс. баксов.

Опять странность, у вас там подробно расписыватся периферия для чипа который вы не собираетесь продавать. А вашему рядовому юзеру это надо? Или может они понимают нафига несколько CAN интерфейсов GPS модулю?
Там где описания фичей OEM модулей с трудом можно понять вообще какой коммуникационный софт и какие протоколы они используют.
Т.е. можно понять, что есть голые хардварные порты CAN и USB, а то что есть еще софтварные профили и стеки поверх них ваши спецы как бы не знают, или почему о них умолчали. Или их действительно нет?
Хотя, конечно, за ту цену за которую вы предлагаете свои модули можно наскоряк под каждого заказчика состряпать некое подобие стека протоколов.

Весь стек TCP ограничен Raw TCP сервером (интересно что это такое ;-)) и FTP только на чтение (вообще атас). Неужто eCOS больше ничего не может предоставить. Ну хоть для рекламы бы перечислили все заявленные фичи стека lwIP.

Это я все к тому, что имеено ваши модули вызывают огромные вопросы, а правильно ли вы выбрали ОС-ь, если не можете ничего продемонстрировать в плане богатства фичей и совместимости со стандартными коммуникационными решениями в индустрии для того же CAN и Ethernet.
А как там с SMS-ами для коммуникации с мобильного модема, или тоже нет?

Вообщем далекоо.. не убедили, скорее наоборот

Отрасль просто несколько специфическая. Наиболее дорогая часть софта вообще не зависит от операционной системы. USB, CAN и прочее - "обвеска".

2AlexandrY, как правильно заметил dezzer, клиент платит за решение своей задачи (в этом случае геодезический сурвийинг),
объем данных производимый приемником мал, а в другую сторону вообще только команды

почему нужен АЗИК - спутниковый сигнал принимать,

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

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

Однако, в новых версиях уже RTEMS...

А при чем здесь JTAG? Это если без ОС то понятно, но не всегда однако выгодно.
А в Линукс gdb есть. В том числе и на уровне ядра. И ошибки находятся (и в драйверах и даже подсистеме виртуальной памяти) быстро.
Может я чего-то не понимаю, но кто мне мешает посмотреть - исправить - перекомпилировать модуль?
Что значит

И кто (а главное на каком основании и по какому праву) его "прекомпилил" если это не я?