WinCE vs Linux vs eCos Опции

[DimaM]

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

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

[dezzer]

причем 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 отлично работает на 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-а

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

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

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

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

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