Привет, всем!

Кто бы рассказал какая принципиальная разница между средствами эмуляции (MulitICE vs Angel vs J-Link vs RDI vs ULINK и т.д.).

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

Ну ты и свалил все в кучу!

Multi-ICE - железка от самой ARM, позволяющая подключить JTAG к компьютеру. Изготовить скорее всего не удасться. Стоит дорого. Поддерживаеся главным образом софтом от ARM (ADS/SDT).

J-Link - назначение точно такое же. Стоит заметно дешевле, но о возможности его копировании ничего не слышал. Софт от ARM его не поддерживает (если ничего не изменилось). Зато он работает с софтом некоторых третьих фирм (Вроде CrossWorks).

Angel - протокол удаленной отладки через COM или Ethernet. Придуман компанией ARM. Вроде бы поддерживается в GDB. Опиание на сайте ARM-а

RDI - Remote Debug Interface - это стандарт на DLL-и, подключаемые к отладочному софту от ARM (ADS/SDT). Типа если ты хочешь сделать свою железку для отладки, можешь написать DLL и твоя железка будет поддержваться в ADS и SDT. Более подробную информацию найти не удалось.

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

Спасибо за ответ!

Картина понемногу наинает проясняется. Технологии отладки можно разделить на две группы:
- использующая JTAG
- соответсвенно не использующея его.
Для примера тот же gdb может ходить по RS или по TCP при наличии на gdbserver'a на целевой железке. Но вроде бы и по JTAG gdb пустить можно?! Только я пока точно незнаю как
Если пользовать ICE, то необходимости в сервера на целевой машине нет

Как я понял существуют три класса отладочный средств (отладчик, протокол обмена между отладчиком и конверторм, интерфейс на хост машине):
1. Дешёвые и медленные (Все отладчики которые могут работать по LPT,Wiggler, параллельный)
2. Менее дешёвые и более быстрые (OCD Commander+OCDRemote, Raven/usbDemon, LPT/USB).
3. High-end (продуция ARM/(OCD Commander+OCDRemote), (MutlICE, MultiTrace)/mpDemon, TCP/USB).

Похоже на правду, но если есть сомнения прошу внести свои изменения

Возможны также смешанные варианты, например:
1. в пустую память через JTAG/Wiggler (а больше и нечем) зашивается загрузчик, который...
2. ... загружает всё остальное (приложение и средства отладки) по Ethernet/COM.

Вариант приемлемый, но для этого надо:
1. Иметь на целевой машине Ethernet (в моём случае это аксиома) или СОМ (можно обойтись штырькями, чтобы подключить модуля с СОМ интерфейсом. Что тоже устраивает).
2. Иметь работающий драйвер СОМ/Ethernet (или собственного производства или GNU gdbserver. Допустим).
3. Кроме того нужно окошко, в котором есть кнопка "грузить в память". А где взять это окошко с такой кнопкой? Я могу вспомнить только тот же gdb

Вариант с заливкой через COM-порт, а отладкой/первичной загрузкой через JTAG (wiggler)-
это используется CrossWorks - причем загрузчик можно и свой - несколько функций реализуются - в зависимости от конкретного железа, а дальше собирается и используется.
Подход весьма здравый в случае вигглера - через послед. порт грузится в несколько раз быстрее (на 115200).
Еще вариант - с резидентным отладочным монитором - RedBoot от eCos - а, может общатся с GDB по послед. порту или через Ethernet - RedBoot можно взять готовый с CVS eCos-а. Есть
для целой кучи платформ, а при необходимости для своего железа не трудно перенести.

OCDRemote - в принципе явл. только драйвером по отношению к устройствам, им поддерживаемым - тому же Wiggler- у, Raven и т.д. - (кстати, Raven тоже работает
через LPT и является реализацией низкоуровнего протокола JTAG на PLD) - с другого конца - порт TCP, а уж к этому порту может подключатся отладчик.
Ну еще он реализует протокол высокого уровня - от RDP от GDB. Кстати, (to GMavr) -
Angel - это все-таки монитор. А протокол называется ADP, и совершенно точно поддерживается GDB, как и RDI - в обоих варинтах - послед. порт и TCP.