WinCE vs Linux vs eCos Опции

[DimaM]

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

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

[Kirill Frolov]

что быстрее освоить? опыт есть только в windows и микроконтроллерах.

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

[DimaM]

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

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

[Damon]

Только за linux братся страшно, хочется тратить усилия только на написание приложения, а не на изучение инструмента.

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

[jasper]

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

[DimaM]

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

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

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

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

[beer_warrior]

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

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

[zltigo]

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

[axle]

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

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

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

[amw]

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

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

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

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

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

[vshemm]

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

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 сказать нечего, т.к. не работал с ней.

[Andy Great]

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

[DimaM]

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

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

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

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

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

А по требованиям к железу WinCE будет как раз попроще linux при одинаковом функционале.

P.P.S. Если выберете WinCE закладывайтесь на 6.0 версию, т.к. там довольно сильно поменялась архитектура и модель драйверов.

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

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

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

[vshemm]

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

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

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

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

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

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

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

[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]

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

[AlexandrY]

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

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

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

[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?

[yes]

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

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

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

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

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

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

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

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

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

[AlexandrY]

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

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

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

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

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

[DimaM]

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

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

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

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


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

Сообщение отредактировал DimaM - Mar 7 2008, 14:17

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

[vshemm]

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

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

[AlexandrY]

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

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

[vshemm]

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

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

[zltigo]

В двух словах вот: http://msembedded.ru/licensing.aspx

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

[AlexandrY]

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

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

[vshemm]

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, конечно, нужно подписать, но это бесплатно (не считая работу юристов).

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

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

При этом даже о стоимости собственно компилятора умолчим.

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

Сообщение отредактировал vshemm - Mar 7 2008, 18:01

[zltigo]

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

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

[DimaM]

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

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

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

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

Сообщение отредактировал DimaM - Mar 7 2008, 18:48

[vshemm]

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

Возможно, это был OEM Pre-installation Kit.
По факту, для СЕ5.0 в средства разработки входят Platform Builder (для постоения имиджа из готовых компонентов) + эмулятор + Embedded VC 4.0 (с компиляторами для всех платформ).
Для СЕ6.0 в средства разработки входят сам билдер (как плагин к студии 2005), сама студия проф, мсдн соответствующий, и еще что-то с MSSQL связанное (диски на работе, если нужно - уточню) + эмуляторы + компиляторы для всех поддерживаемых платформ.

[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]

Что-то вы даете ссылки которые сами видать не читаете.
Цитирую: "A testing fee of $1,500 US per BSP"
http://msdn2.microsoft.com/en-us/embedded/aa714500.aspx

Они, конечно, тему пытаются замнуть, но я думаю они пошлют вас далеко если попытаетесь качать права про траблы CE на несертифицированном BSP.
Остается также вопрос, кто даст право копировать референс дизайны плат с 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 проф. И еще кой-чего

А вот если есть деньги, то потратить их можно на гораздо более умные ОС-и чем eCOS с командой халявщиков из ecoscentric (приходилось общаться), и разговор можно начинать сначала, потому что тогда начинается совсем другая тема.

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

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

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

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

[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/

[DimaM]

чтобы было понятно какие что мы делаем дам ссылку на конкурентов. у них пока спектр продукции пошире будет
http://www.trumpf-laser.com/207.index.html

[vshemm]

Что-то вы даете ссылки которые сами видать не читаете.
Цитирую: "A testing fee of $1,500 US per BSP"
http://msdn2.microsoft.com/en-us/embedded/aa714500.aspx
Они, конечно, тему пытаются замнуть, но я думаю они пошлют вас далеко если попытаетесь качать права про траблы CE на несертифицированном BSP.

Читаю Вот, например: "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 производителей железок, на основе которых другие компании разрабатывают законченные устройства. Т.е. фактически это реклама.

[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

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

[vshemm]

Например, потребуются к вашим устройствам подключать USB-принтеры - где возьмете USB-хост стек, принтерную подсистему?
Есть ли это в Windows CE?

Есть Там еще много чего есть, например directX/windows media, что позволяет довольно просто выводить видеопотоки.

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

Совершенно верно.

[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

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

[DimaM]

Я как то поговорил с продавцами uCOS. для случая с большим количества разнообразных устройств у них нет нормальной лицензии. Хотя можно скачать все исходники использовать их без оплаты не позволяет совесть(законы) а платить заметно дороже wince получается.
И подобная ситуация у множества производителей мелких и не очень RTOS.

[AlexandrY]

Посмотрите на систему лицензий ThreadX.
Там есть лицензии на все возможные стратегии разработки и выпуска изделий.

Я как то поговорил с продавцами uCOS. для случая с большим количества разнообразных устройств у них нет нормальной лицензии. Хотя можно скачать все исходники использовать их без оплаты не позволяет совесть(законы) а платить заметно дороже wince получается.
И подобная ситуация у множества производителей мелких и не очень RTOS.

[path_finder]

Итак, я даю вам MonataVista на своей плате с iMX27 и оригинальным внешним Phy USB host-а мультиплексированным с ATA (такое уж решение в реф. дизайне было применено), а вы мне хотябы в течении месяца прилепите любой USB-WiFi адаптер при сохранении соответствующей скорости?

Проблема драйверов чуть ли не самая мертвая в Линуксе если речь идет о своих платах.
А задача именно ориентирована на свои платы, поскольку иначе оказываетесть привязаны к сторониим производителям и они в бизнес вносят серьезный риск и тормоза.

Все уже разработано за нас:
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
Это не показатель, просто попавшийся пример.

Ok! Тема видно народ волнует.

Но здесь очень важен контекст.
Я не обсуждаю здесь абстрактные тренды.
Человек описал достаточно ясные рамки задачи.

Тот роутер, что вы у нас нашли, во первых как раз то случай ребрендинга, а во вторых я хорошо знаю R&D контору которая это делает. Их цикл разработки такого роутера более года! при том, что они уже с десяток лет в той области.
Это совершенно недопустимые сроки для стартапного проекта, когда вы хотите срочно догнать и перегнать конкурентов имея вдесятеро меньший бюджет.

Поскольку речь идет о достаточно понятной линейке промышленных дивайсов, локальных, с хорошей проводной связью, абсолютно ясной прикладной функциональностью, то человеку явно не надо гадать какие такие выдающиеся прибамбасы понадобятся там в будущем.
Достаточно быстрого TCP стека, простенькой файловой системы. GUI вообще не нужен.
Хотя для uCOS есть выбор разных GUI.
Опять же GUI уткнутся в драйвер дисплея и опять с Линуксом будет ступор.
Тачскрин - это вообще элементарный прибамбас который к любой GUI на любой RTOS прикручивается за день. И даже без GUI.
В поставке компилятора IAR есть эффектные примеры, как тачкскрин и скины из BMP делают крутой интерфейс вообще без ОС.
Логично просто сделать в дивайсе HTML интерфейс на базе встроенного WEB сервера для управляющего PC, или выносной панели на основе PC.
HTML интерфейс как известно кроссплатформенный, тут вообще не важно под какую OC он написан.

Денег у человека на специализированные стеки нет, т.е. акцент на самостоятельное написание.
Тут компактность OS абсолютно необходима. Если одна итерация исправления, перекомпиляции, загрузки на целевую платформу и запуска отладки полного имиджа включая RTOS длиться всего пару десятков секунд, то человек гарантированно может исправить любую ошибку в системе за день.
Благодаря инструментам трассировки, внутрисхемной отладки на базе JTAG, человек освобождается от написания бесконечных отладочных вставок и логов, которые сами искажают код в свою очередь и могут иметь местные эффекты.
В Линуксе если ошибка в ядре в каком-нибудь прекомпилированном модуле, только поиск может занять пару дней.
А ошибки в ядре обязательно будут, поскольку ядро очень большое и монолитное и, как правило, пропатченное неизвестно кем.
Учтем, что человек с embedded Linux никогда не сталкивался.

Итого мой диангоз - цикл разработки на RTOS в данном случае будет раза в два короче чем на Линуксе.

Здесь я абсолютно с Вами согласен.
Единственно - экономические условия мы додумали сами. А здесь, мы как раз можем и ошибаться - так как задача обрисована в общих чертах.
Я, глядя на приведенные устройства (которые с лазером), не решился сам додумать всю возможную функциональность. Может для них время разработки не принципиально, а важна определенная фича - "конкурент киллер" и без нее не жизнь? Или действительно минимум на разработку, минимум денег минимум функциональности?
Оптимальное же решение включает учет многих деталей, которые здесь не обсуждаются, да и не должны. Поэтому, в вопросах (точнее ответах) на извечные вопросы хочется слышать ответы более развернутые, что ли. Ведь ответы "ставь Линукс и будет тебе счастье" или "все Г.." как-то не вдохновляют.
Если с маленькими RTOS становится все более-менее понятно, то с большими - много тумана.
Да и с маленькими - тоже оказывается не все так просто - попытка посчитать деньги привела к мысли, что решение очень дорого. Кстати, а если посчитать, сколько времени и соответственно денег, будет потрачено, и сколько сэкономлено, то может быть все окажется не так плохо?

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

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

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

[AlexandrY]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[dezzer]

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

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

[yes]

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

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

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

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

[dezzer]

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

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

[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?

[yes]

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

нет, RTEMS это как раз старые версии - "legacy support" так сказать

продукты с RTEMS появились до того как появилась eCos
ну а потом ветка с PPC продолжается на RTEMS, хотя неоднократно поднимался вопрос - хорошо бы перенести, но нет ресурсов под эту задачу

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

JTAG без останова встречается очень редко, практически нет в популярных архитектурах
и если код поддержки отладчика скрыт в среде разработки/пзу/и т.п. и "невнимательный" пользователь его не видит - это не значит, что его нет

попытки сделать безостановочный JTAG есть в DSP Аналога (BTC) и Тексаса (RTDX), но он требует поддержки в пользовательском коде

при отладке real-time обычно не получается ничего отладить по JTAG-у, и пользуются либо "светодиодом", либо каким-либо отладочным printf-ом

JTAG обычно это только начальный этап, когда осваивается чип, пишется стартап и библиотечки
управления железом
возможно, какой-то малый фрагмент кода (но это лучше делать симулятором, а в линуксе (и POSIX-ных RTEMS/eCos) можно делать на хосте )

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

а почему 80% бизнес приложений написано на COBOLе?
почему столько бабок было заплачено за проблему 2000?
почему Билл Гейтс имеет коммерческий успех со всякими уродливыми Вистами, когда есть Линукс для РС?
почему люди не летают как птицы?

[AlexandrY]

Я поздравляю, что вы всем этим занимаетесь, теперь осталось только это доказать.

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

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

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

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

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

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

+1

[vshemm]

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

Особенно если целевая платформа - х86, ага

Я поздравляю, что вы всем этим занимаетесь, теперь осталось только это доказать.

Кому и, главное, зачем?

[AlexandrY]

Без останова JTAG отлично работает на Cortex M3 на которых теперь бум.
Без останова проги может работать JTAG на популярных MIPS-ах в составе чипов PIC32
Также такая фишка может работать на STR912.
Т.е. это уже совсем не редкость, а я бы сказал норма.

Про JTAG я и говорю, что он в основном актуален на начальном этапе.
Но многие тут видать либо намеренно либо по незнанию принижают значение этого этапа.
Когда начинаем отлаживать верхние уровни приложений, например на уровне прикладных слоев как SNMP, WEB, маршрутизация, GUI то, конечно, JTAG помогает незначительно, там уже нужны инструменты глубокого анализа, а не просто просмотр переменных.
И опять где вы такие инструменты найдете как не в малых RTOS?

Далее народ почему-то забывает актуализирующуюся тему сырости железа.
А не признаетесь сколько вы лет разрабатывали свой ASIC от идеи до момента когда обнаружили последний аппаратный баг в кристалле?

Вот, например, в STR912 баги обнаруживаются спустя 2-а года после начала их продаж.
У иных процов, как OMAP сама дока по некоторым периферийным узлам может только через год поспеть после начала продаж.
Там без JTAG вообще нечего делать, это единственное спасение.

нет, RTEMS это как раз старые версии - "legacy support" так сказать

продукты с RTEMS появились до того как появилась eCos
ну а потом ветка с PPC продолжается на RTEMS, хотя неоднократно поднимался вопрос - хорошо бы перенести, но нет ресурсов под эту задачу
JTAG без останова встречается очень редко, практически нет в популярных архитектурах
и если код поддержки отладчика скрыт в среде разработки/пзу/и т.п. и "невнимательный" пользователь его не видит - это не значит, что его нет

попытки сделать безостановочный JTAG есть в DSP Аналога (BTC) и Тексаса (RTDX), но он требует поддержки в пользовательском коде

при отладке real-time обычно не получается ничего отладить по JTAG-у, и пользуются либо "светодиодом", либо каким-либо отладочным printf-ом

JTAG обычно это только начальный этап, когда осваивается чип, пишется стартап и библиотечки
управления железом
возможно, какой-то малый фрагмент кода (но это лучше делать симулятором, а в линуксе (и POSIX-ных RTEMS/eCos) можно делать на хосте )

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

а почему 80% бизнес приложений написано на COBOLе?
почему столько бабок было заплачено за проблему 2000?
почему Билл Гейтс имеет коммерческий успех со всякими уродливыми Вистами, когда есть Линукс для РС?
почему люди не летают как птицы?

[yes]

Без останова JTAG отлично работает на Cortex M3 на которых теперь бум.

OFF : если Вы интересовались Cortex-ами, с фичей TrustZone не сталкивались? интересна ее поддержка софтом - как коммерческими OS|компилерами/библиотеками так и Линуксом?
это более старшие Cortex-ы А8/А9 ...

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

а по поводу RUN-TIME JTAG на них - сильно подозреваю (по-крайней мере у нас в чипе так сделано), что JTAG висит как еще один мастер на АМBA шине и может смотреть некие ресурсы, доступные по шине. но при этом доступ к внутренностям процессора закрыт (пока процессор не остановлен)
со всякой периферией, которая сбрасывается по чтению - тоже проблема

ну и даже имея доступ к общей памяти через жтаг нужно иметь некий протокол синхронизации при передаче сообщений (то есть что-то типа упоминавшихся BTC/RTDX)

то есть функционирование JTAG в этом случае не дает особого выигрыша перед передачей данных по другому каналу (UART)

может интересно содержимое TRACE буфера, но и его можно по UART передать

по крайней мере усилия на это затрачиваются минимальные, а пропускная способность УАРТ на 460кбод выше чем у JTAG-а

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

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

[path_finder]

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

В этом случае хорошо помогает вынос отлаживаемого куска в отдельный модуль.
Далее - make, insmod, rmmod.
Все компилируется очень быстро.

[AlexandrY]

Ну да JTAG имеет доступ ко всей системе через порт-мастер к шине AHB, но и все регистры процессора может смотреть через специальный механизм и без останова процессора.

И опять же, я не вдаюсь в тех. детали на кой они мне?
Я знаю одно и самое важное: в Keil с операционкой ARTX я имею к этим фичам доступ, а в eCOS c GCC нет!

UART? А время у вас на портирование отладочного монитора на UART не уйдет? Или это с неба падает?
А сам монитор на состояние системы что, не влияет?
Я не говорю о специализированных мониторах процессов RTOS и прикладных задач, это у всех есть.
Но следить за локальными переменными через UART, это извините прошлый век в прямом смысле слова.
Не говоря уже что сам UART жалко на отладку отдавать.

И откуда сведения о пропускной способности JTAG. Это как минимум зависит от системной частоты, но вообще для JTAG нормальная скорость 10 Mbit.


Насчет TrustZone, насколько можно понять из рекламных брифов (технология то засекречена), то она нисколько не отличается от применяющихся сейчас в OMAP, iMX, PXA и прочих платформах.
Никто из них не публикует спецификации на свои движки защиты.
Но отладочные платы для OMAP и iMX идут с тулсами которые готовят загрузочные имиджи и ключи к их секретным движкам.
От компилятора ничего не зависит, дают API и хидеры на функции защищенного монитора. Дальше все пишите сами согласно своей концепции.
В свободной продаже только версии чипов с отключенными механизмами защиты.
С защитой чипы делаются только по прямой договоренности с производителем.
На глаза попадались доки с описанием концепции защиты построенной на основе технологии TI применяемой в их платформе Calypso.
В конечном итоге там все сводилось к хешу мастер ключа хранившемуся в неких энергонезависимых ячейках на кристале. Делали декапсуляцию чипов, и с точки зрения взлома вообщем пришли к выводу что особых технических проблем нет.
Во всяком случае Semiconductor Insight говорил, что проблем не видит.
Т.е. это не решение для защиты софтварных ноухау, а только лишь коммерческий ход для производства субсидируемых дивайсов.

OFF : если Вы интересовались Cortex-ами, с фичей TrustZone не сталкивались? интересна ее поддержка софтом - как коммерческими OS|компилерами/библиотеками так и Линуксом?
это более старшие Cortex-ы А8/А9 ...

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

а по поводу RUN-TIME JTAG на них - сильно подозреваю (по-крайней мере у нас в чипе так сделано), что JTAG висит как еще один мастер на АМBA шине и может смотреть некие ресурсы, доступные по шине. но при этом доступ к внутренностям процессора закрыт (пока процессор не остановлен)
со всякой периферией, которая сбрасывается по чтению - тоже проблема

ну и даже имея доступ к общей памяти через жтаг нужно иметь некий протокол синхронизации при передаче сообщений (то есть что-то типа упоминавшихся BTC/RTDX)

то есть функционирование JTAG в этом случае не дает особого выигрыша перед передачей данных по другому каналу (UART)

может интересно содержимое TRACE буфера, но и его можно по UART передать

по крайней мере усилия на это затрачиваются минимальные, а пропускная способность УАРТ на 460кбод выше чем у JTAG-а

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

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

[blackfin]

И откуда сведения о пропускной способности JTAG. Это как минимум зависит от системной частоты, но вообще для JTAG нормальная скорость 10 Mbit.

На JTAG-эмуляторе ADDS-HPUSB-ICE можно выставить частоту клока 50 МГц,
так что пропускная способность будет около 50 Mbit/s.

[yes]

На JTAG-эмуляторе ADDS-HPUSB-ICE можно выставить частоту клока 50 МГц,
так что пропускная способность будет около 50 Mbit/s.

а какая будет при этом скорость передачи (пропускная способность) того же BTC ?
я с HPUSB немного работал - это конечно не такой тормоз как USB-ICE, но все равно он медленно работал - заливка блока памяти на 33кбод УАРТе быстрее получалась...

накладные расходы в самом ТАР контроллере небольшие - где они умудряются так производительность терять - непонятно

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

AlexandrY TrustZone затрагивает ядро - есть специальные биты в PSR и MMU, поэтому должна поддерживаться как операционкой, так и (наверно) компилятором - что-то типа ARM-THUMB interworking-а

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

[lyakhovich]

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

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

[ATname]

По поводу JTAG'а. Эта штука имеет свой канал доступа к "внутренним потрохам" железяки, конкретно, к каждой контрольной точке камня (обычно это все внутренние шины проца и устройства управления доступа к ним, включая адресацию). Запись контрольной информации в сдвиговый регистр JTAGа идет на рабочей частоте проца, а вот дальше, вывод этих данных, идет по последовательному интерфейсу JTAG, под управлением его внутреннего автомата, и идет уже не так "шоколадно".

Грубо: JTAG это сдвиговый регистр подключаемый к необходимой контрольной точке в кристалле. Хошь на ввод, хошь на вывод. Отсюда его плюсы: можно "заглянуть" внутрь кристалла в нужной точке, ДОЙДЯ ДО НЕЁ НА РЕАЛЬНОЙ ЧАСТОТЕ, но вот дальше... все определяется архитектурой камня.
Для АРМ'а максимальная частота JTAG'а равна 1/6 частоты ядра.

Малая скорость заливки по JTAG следствие того, что данные передаются по последовательному интерфейсу. 50 МГц HPUSB-ICE это максимальная скорость сканирования порта JTAG, т.е. величина определяющая скорость работы, но не абсолютно однозначно. Для "сурьёзного" кристалла длина "сдвигового регистра" составляет тысячи бит (может варьироваться в зависимости от адреса контролируемого узла) а нужные биты информации где-то там в этиъх дебрях. Для контроля пинов изготовитель поставляет BDSL описалку, там можно докопаться что где лежит, при контроле внутренних "потрохов" тайна сия известна только производителю кристалла. В подавляющем большинстве случаев.

Поднять ОС на новой борде без JTAG (для серьезного камня) это мазахизм, в особо извращенной форме. Тот же АД не открывает разводку БФ, что гарантирует наличие "сюрпрайзов" в вашей колобахе. Как бы тщательно вы не считали её хайпером. Причем, где и когда это безобразие вылезет, одному Аллаху ведомо...

А вообще, оно конечно правильно, что для минимизации затрат при решении задачи надо уметь правильно выбирать ОС. Вот только где взять мудрость для оного выбора...