Мучаюсь сомнениями - намечается проект относительно сложного устройства. Электроника будет управлятся через 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 - тот, что лежит в открытых исходниках вообще недееспособен.