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 стоит денег.

[path_finder]

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

По поводу 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

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

[AlexandrY]

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 в данном случае будет раза в два короче чем на Линуксе.

По поводу 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

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

[amw]

Благодаря инструментам трассировки, внутрисхемной отладки на базе JTAG, человек освобождается от написания бесконечных отладочных вставок и логов, которые сами искажают код в свою очередь и могут иметь местные эффекты.
В Линуксе если ошибка в ядре в каком-нибудь прекомпилированном модуле, только поиск может занять пару дней.

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

прекомпилированном модуле

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

[AlexandrY]

JTAG позволяет просмотреть значения всех абсолютно переменных и без остановки программы и без единой строчки диагностического кода и без всяких отладочных движков на целевой платформе.
Он позволяет остановить программу мгновенно как только происходит несанкционированная запись или даже чтение переменной, области памяти или периферии.
Он позволяет вместе с процессором заморозить периферию и смотреть неизмененный ничем снимок системы в момент краха и т.д. Трассировка же через JTAG дает еще больше возможностей.
Все это приправляется эффективными визуальными отладочными оболочками как в RealView, IAR, Multi, Tasking и т.д. к которым делаются визуальные же add-on всяких компактных RTOS.
У знакомых разработчиков мобильных дивайсов трассер есть у каждого на столе.

Проблема же Линукса и других монструозных осей в их величине.
Компиляция целиком занимает столько времени, что приходится все оформлять в виде библиотек и заранее компилировать.
Если ошибка попадается в таком скомпилированном модуле, то надо переключать проект на работу с исходниками модуля, исправлять, компилировать и снова оформлять как прекомпилированную библиотеку.
А если ошибка снова там?
А как ядро гранулировать на библиотеки если оно вам с готовым make файлом досталось гигантских размеров считая все включения?
Значит не гранулируем, пытаемся сделать ядро и делать динамически линкующиеся модули.
А если ошибки всетаки в ядре, то кошмар с полной перекомпиляцией повторяется, а динамические модули не отладить JTAG-ом.

Вообщем такой секс позволителен только на уже кем-то отлаженных платформах.
Имею богатый опыт по отладке прог под Win mobile через ихний ActiveSync. Больше похоже на шаманство и игру в рулетку. Такие средства отладки сами на ладан дышат и падают при любом сбое в ядре.

Тут еще отмечу, что веду речь только об этапе подъема оси на голой платформе.
Но для проекта по контексту этим этапом все и заканчивается практически.

Никто, конечно, никому не мешает.
Все решает время, кто реально знает сравнительные расклады по времени на те или иные действия в технологии разработки тот и на коне.

Интересно, как пользователи eCOS объясняют существование лицензии VxWors стоимостью 12 штук баксов при такой раздольной халяве какую дает eCOS или RTEMS?

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

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

[amw]

JTAG позволяет просмотреть значения всех абсолютно переменных и без остановки программы и без единой строчки диагностического кода и без всяких отладочных движков на целевой платформе.

Я знаю что такое JTAG и зачем он нужен.

У знакомых разработчиков мобильных дивайсов трассер есть у каждого на столе.

У меня тоже есть. Помогает. Но при отладке в Линукс - он только обуза и ничего больше.

Проблема же Линукса и других монструозных осей в их величине.

Простите меня, но мне кажется Вы слишком зациклились на "монстроидальности" того, что лично Вам не нравится (в самом широком смысле этого слова, включая, но не ограничиваясь, повышенными требования к железу, сложностью, (не)целесообразностью на данной задаче и т.п.) с одной стороны, и "минимализмом" - с другой.
Всему свое место.
Есть задачи, где я с Вами полностью соглашусь в ненужности, избыточности и сложности того-же Линукс.
И есть задачи - где я не смогу с Вами согласится по поводу нецелесообразности применения Линукс.
То-же касается и и других ОС.

Компиляция целиком занимает столько времени, что приходится все оформлять в виде библиотек и заранее компилировать.
Если ошибка попадается в таком скомпилированном модуле, то надо переключать проект на работу с исходниками модуля, исправлять, компилировать и снова оформлять как прекомпилированную библиотеку.
А если ошибка снова там?
А как ядро гранулировать на библиотеки если оно вам с готовым make файлом досталось гигантских размеров считая все включения?
Значит не гранулируем, пытаемся сделать ядро и делать динамически линкующиеся модули.
А если ошибки всетаки в ядре, то кошмар с полной перекомпиляцией повторяется, а динамические модули не отладить JTAG-ом.

Это уже с какой стороны посмотреть.
Когда мне приходится отлаживать программы для МК без ОС или в простых RTOS я применяю JTAG так как других способов понять что происходит - просто нет!
Но при этом очень жалею, что нет чего нибудь типа kprobe (как в Линукс).
Лично мое мнение JTAG это иллюстрация поговорки "На безрыбье и сам раком станеш."

Вообщем такой секс позволителен только на уже кем-то отлаженных платформах.
Имею богатый опыт по отладке прог под Win mobile через ихний ActiveSync. Больше похоже на шаманство и игру в рулетку. Такие средства отладки сами на ладан дышат и падают при любом сбое в ядре.

Никогда не видел "уже кем-то отлаженных платформ" так как строю и отлаживаю эти самые платформы.
Потому - без коментариев.

Тут еще отмечу, что веду речь только об этапе подъема оси на голой платформе.

Именно этим и занимаюсь. Начиная с обсуждения схемы платформы.

Но для проекта по контексту этим этапом все и заканчивается практически.

Никто, конечно, никому не мешает.
Все решает время, кто реально знает сравнительные расклады по времени на те или иные действия в технологии разработки тот и на коне.

+1

Интересно, как пользователи eCOS объясняют существование лицензии VxWors стоимостью 12 штук баксов при такой раздольной халяве какую дает eCOS или RTEMS?