WinCE vs Linux vs eCos Опции

[DimaM]

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

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

[AlexandrY]

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

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

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

[vshemm]

Постоянно делаю такие дивайсы и скажу вам, что Linux и WinCE здесь рядом не лежали.

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

Нормальных быстрых мультизадачных стеков прикладных протоколов ни под CAN ни под EtherCAT на халяву вы не найдете ни для Linux ни для WinCE.

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

Разработку интерфейса пользователя ни WinCE ни Linux никак не облегчают по сравнению с разработкой для того же uCOS.

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

В вашем приложении совсем ни к чему драйвера, у вас фиксированное железо.

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

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

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

А как вы будете отлаживать баги? В Линуксе с JTAG практически нечего делать.

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

Для файловой системы вам достаточно FAT16. Так этого добра навалом для любой операционки.

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

Сетевых стеков гораздо более быстрых чем под Linux-ом тоже навалом для простых RTOS.

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

Для действительно стоящего железа все драйвера в Линуксе исключительно бинарные, т.е. прикрутить какой-нить произвольный Wi-Fi, Bluetooth, USB дивайс к вашему произвольному Линуксу будет такой же нереальной задачей как прикрутить то же к uCOS.

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

Более сложные сетевые сервисы чем стек TCP/IP вам на Линуксе будет поднять также сложно как и на uCOS-е

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

А eCOS - тот, что лежит в открытых исходниках вообще недееспособен.

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

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

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

[AlexandrY]

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

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

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

Нормальных быстрых мультизадачных стеков прикладных протоколов ни под CAN ни под EtherCAT на халяву вы не найдете ни для Linux ни для WinCE.

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

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

Разработку интерфейса пользователя ни WinCE ни Linux никак не облегчают по сравнению с разработкой для того же uCOS.

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

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

В вашем приложении совсем ни к чему драйвера, у вас фиксированное железо

.

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

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

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

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

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

А как вы будете отлаживать баги? В Линуксе с JTAG практически нечего делать.

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

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

Для файловой системы вам достаточно FAT16. Так этого добра навалом для любой операционки.

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

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

Сетевых стеков гораздо более быстрых чем под Linux-ом тоже навалом для простых RTOS.

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

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

Для действительно стоящего железа все драйвера в Линуксе исключительно бинарные, т.е. прикрутить какой-нить произвольный Wi-Fi, Bluetooth, USB дивайс к вашему произвольному Линуксу будет такой же нереальной задачей как прикрутить то же к uCOS.

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

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

Более сложные сетевые сервисы чем стек TCP/IP вам на Линуксе будет поднять также сложно как и на uCOS-е

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

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

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

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

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

[yes]

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

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

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

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

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

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

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

[AlexandrY]

Ага, ясно.

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

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

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

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

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

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

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

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

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

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

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

[yes]

может я отстал от жизни - имел дело с 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/

Ага, ясно.

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

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

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

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

[AlexandrY]

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

может я отстал от жизни - имел дело с 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/

[yes]

Не понял от чего там надо тащиться
Пошарил, нигде упоминаний eCOS не нашел.
Тем более в таких фирмах фиг отличиш где ребрендинг, а где свое.

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

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

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

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

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

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

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

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

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

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

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

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

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

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