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 и т.д.