JTAG USB adapter, это только одна неболь часть проблеми, ещо нужен
и совт для одладки, прораммировании FLASH ...
По этому и интересно сделать щтото совместимое по железу или на уровне
драйверов (хоть паченных).

Могу предложить вариант для Keil - железо делаешь свое, а для общения с этим железом пишешь библиотеку по предложенной Keil'ом методе. Есть такой господин pin он уже путь написания библиотеки прошел. Кстати для системы разработки выпускаемой ARM, если мне память не изменяет, тоже раскрыт процесс общения м/у средой и отладчиком. Как дело обстоит с IAR и CW даже не знаю.

Добрый всем день

Я смотрю что тема уже созрела. Так может того... Потянем сами проект

Я предлагаю такую структуру. Нажмите для просмотра прикрепленного файла

Необходимо:
Техническая часть
1. Найти описание RDI (1.5.1, 1.5.2). Реализацию можно подсмтреть в GNU gdb-server.
2. Разработать интерфейс общения с встроенным монитором (за базу можно взать Ангел!а)
3. Подготовить ТЗ для ПО для хоста, адаптера.
4. Выбрать Мегу.

Организационная
1. Найти энтузиастов для
- Разработка хост дров (1-3 человека)
- Разработка мидлвареза (1-2 человека)
- Создания схемы и платы (1-2 человека)
- Документация (1-3 человека)

Итого:
4 человека за 3-4 месяца
10 человек за 1-2 месяца

Жду коментарии, предлжения и критику

Идея интересная!
Кстати в соседнем топике обсуждается идея повторения J-Link. И там народ обсуждает вариант портирования схемы на другое железо.
Наверное пора объединять усилия.

Но есть несколько замечаний:
1. Имеет смысл отказаться от связки FTDI+Mega в пользу процессора со встроенным USB. Мне например нравиться вариант AT91SAM7A3 - вот сейчас начинаю его оживлять (раз уж отладчик для ARM - сделаем на ARM).
2. Если уж делать JTAG со своим ПО, имеет смысл создать универсальную систему для программирования (и отладки) различных девайсов. Моё предложение - ARM, MSP430, AVR, Xilinx, Altera. Можно добавить еще PIC и различные варианты FLASH-памяти.
3. Развитие системы в дальнейшем -- (перекликается с п.2) ПО JTAG тестирования / программирования внешней FLASH памяти (Boundary Scan).
4. Определиться со статусом проекта (GPL или что другое). По значимости пункт должен идти в самом начале!
5. Подобный проект требует постоянного развития и поддержки, поэтому вариант "собрались-сделали-разбежались" не пройдет. Но может это и к лучшему.

ЗЫ. Со своей стороны могу обеспечить разработку аппаратуры. Как-то я пытался начать, но забросил подобный проект. Дальше черновой разработки схемы дело не пошло, поскольку необходимы серьезные знания в дровописательстве, а у меня их нет (и времени тоже мало). У меня прорабатывался вариант на USB2.0 HighSpeed -> TUSB6250+MSP430+CPLD (соответственно: реализация USB; сервис. и доп. функции; JTAG).

В принципе я могу так же железом заняться. помимо всего прочего интересен п. 2 сделать на этом железе универсальный программатор и дергатель ногами для отладки различных переферийных схем, LCD и т.д. программированием специальным СИ подобным скриптом как вариант.

Самый простой вариант для железа получается просто FT2232C ...

Библиотека для реализации интерфейса JTAG для микросхемы FT2232C ZIP PDF

Данная библиотека позволяет посредством простых API функций реализовать интерфейс JTAG через микросхему FT2232C. Использование этой библиотеки скрывает все сложности использования режима MPSSE микросхемы и значительно сокращает время написания приложения.

http://www.ftdichip.com/Projects/MPSSE/FTCJTAG.htm
http://www.ftdichip.com/Support/Knowledgeb...ntroduction.htm

p.s.
JTAG DLL даже работает

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



Скрипты - хороший вариант реализации доп. функций. Это я поддерживаю. Кстити, в посте выше я немного соврал (забыл за давностью) - в варианте с TUSB6250 я прорабатывал применение FPGA (а не CPLD) для реализации JTAG и еще нескольких функций типа лог. анализатора / генератора внешних воздействий. В основном поэтому и склонился к USB HighSpeed. А если будут скрипты + генератор/анализатор внешних воздействий на 8-16 каналов, можно реализовать практически любую функциональность.
Минус - сложность такого решения и, соответственно, невозможность повторения людьми с малым опытом. А это для открытого проекта большой минус. Кстати и цена будет высокая.
Вот вариант на AT91SAM7A3 - практически только контроллер + буферные элементы на JTAG. И по отношению стоимость/функциональность может получиться наилучший результат (IMHO).



Самый простой вариант - обычно не самый лучший. Кроме того, такая реализация не позволит легко расширять функционал, как указано выше (уж логический анализатор точно не получится). Да и цена FTDI+ATMega будет повыше, чем контроллер со встроенным USB (SAM7A3 < $13 обещают).

А зачем для простого и универсального JTAG контролера нужен еще ATMega ???
Второй порт FT2232C остается полностю свободным для I/O.

У меня была задумка добавить к FT2232 FPGA для универсальности, а в развитии корку контроллера. Тогда на все случаи жизни

Добрый день, уважаемые

1. Проект отрытый (OpenSource, GPL)

1. FTDI выбран из-за наличия дров к ниму. Если есть дрова для предлогаемого ЦПУ, можно подумать. Иначе, самому дрова писать - гиблое дело. А на счёт цены, я бы сказал, что торг здесь неуместен

2. ЦПУ нужен, если необходимо организовать интелектуальный обмен между хостом и целевым устройством. (например для организации универсального интерефеса с встраиваемым монитором типа IAR ROM-monitor). ЦПУ добавляет большей гибкости.

3. Что требуется поменять в схеме для совместимости с другими ЦПУ (AVR, MSP430)? Как применить это устройство для конфигурации ПЛМ, я не знаю. Скорее всего совместимость определяется на уровне EDA. Потэтому я рекоммендую пока оставить эту задачу.

Для начала задача минимум: Разработать адаптер для отладки ЦПУ АРМ через ДжТаГ с программным интерфейсом RDI.

Для этого надо собраться компании в человек (5-10), распределить обязаности, начать работать.

У кого есть желание и возмжности - пишити прямо. Могу и хочу (вакансии в посте от May 27 2005, 14:19).

По поводу поддержки программирования ПЛИС: Xilinx Impact (программа-конфигуратор) видит виртуальные порты под виндами. Т.е. можно сделать универсальный JTAG-кабель для ARM и Xilinx, при этом для совместимости нужно будет как-то на ходу изменять его конфигурацию.

PS: Ведь есть же изделия типа http://www.xjtag.com/xjlink.htm. Можно попытаться сделать что-то подобное.

Даже ARM выпускает
ARM® RealView™ ICE Micro Edition на FT2232С и FPGA ....

Уже хочу - где лежит?

У меня только драйвера ....

Тобишь ядро АРМа грузить можешь?
А само ядро?

Непонял ???

Я просто нашол што имеется силки на FT2232 и FPGA.
CD from RealView_v2.1
\Utilities\FTDI\D2XX\
\RVI-ME \

Имеется и Bitfile from FPGA ....

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

Давно не читал конференцию. Был занят. Как раз делал J*T*A*G на F*T*C*2*2*3*2 в частности для X*i*l*i*n*x и ARM в т.ч. Задача программировать и тестировать средствами BSDL. ЗА основу брал широко известный OpenSource проект N*A*X*JP. Супербезоны должны знать, он только недавно закрылся.
Сделал. Работает с CPLD до проверки с АРМ не дошел ход. Пришлось срочно бросаться спасать другую тему. Так что могу сменить NIC на "NEDODEL"

Делюсь опытом.
-------------------
1. От DLL F*T*D*I для JTAG пришлось отказаться.
Начал ковырять и задавать вопросы - служба поддержки, в лице некого Гордона Лунна, начала слать исправленные версии DLL без замены на сайте. Через некоторое время сдалась и задрала лапки к верху и созналась, что DLL просто пример написанный на Visual Васике.
--------------------
2. Написал используя микрокоманды FTC
Работает медленнее, чем с LPT.
Ожидать приходимся 2 мС, минимум, данные на чтение - быстрее не может драйвер. А это связано с типом потока BULK выбранным фирмой для микросхемы. Писать вынужден пакетами по 32 бита - формат регистра назначения, а так же SVF и JEDEC форматов файлов данных.
FTC не имеет возможности исполнения "холостых" тактов, поэтому задержки 100 мкС и пр., по требованию алгоритма программирования, остаются на совести ПО. При этом остается вероятность гонки пакетов, и как результат, поломка TAP.
--------------------
3. На шине USB1.1 загрузка интерфейса получается неравномерная. Победить этого так и не смог. Загрузка шины USB2 более равномерна, где то 30%
Появилась возможность одновремменого запуска нескольких копий программы (для меня это имеет значение)
--------------------
4. Время прошивки XC9572 на шине USB1 ~60 секунд, USB2 16 секунд.
CPLD LV шьются раза в 4 быстрее.
Для нужд boundary scan , считаю, таких скоростей не достаточно.
Позже буду делать JTAG с микроконтроллером. Чтобы TAP и задержки делать на уровне firmware.
Кстати, прирост производительности такого решения по сравнению с 115200 СОМ-ом, даже без применнеия DMA со стороны MPU, от 4 до 8 крат. Зависит от длины пакета конечно же. "Проверено электроникой"
--------------------
5. Самый шустрый драйвер, какой я тестировал - J*U*N*G*O.
Этот смарт алик умудряется даже по шине 1.1 до 9 запросов в миллисекунду делать на убогом селероне 700-м (моя тестовая лошадка)
-------------------------

Резюме.
------------------
F*T*D*I дает добротное решение для виртуального COM-а.
Я, лично всю контору обвесил виртуальными комами, счет уже за 200 шт. скоро пойдет. Очень благодарен им за это.
Все остальные решения только для тех, кого устраивает какой-то результат. Главное что бы быстро получить этот результат.

Желаю всем удачи!

Вот и думаю грузить в FPGA core MCU через USB и потом этот MCU выполняет код дерганья ногами JTAG-а и решает проблему синхронизации.

Вот и думаю грузить в FPGA core MCU через USB и потом этот MCU выполняет код дерганья ногами JTAG-а и решает проблему синхронизации.

[/quote]

Простите, что опять лезу с свинным рылом в калашный ряд, но...
Почему бы не поставить МК, во флэш которого зашит начальный загрузчик. При начале работы загрузчик заливает (через USB, RS-232 и т.п.) рабочую программу в ОЗУ (внутреннее желательно) и передает ей управление.
При этом модификация рабочей программы достаточно проста и система получается гибкой.

[quote=iit,Jun 10 2005, 04:59]
Вот и думаю грузить в FPGA core MCU через USB и потом этот MCU выполняет код дерганья ногами JTAG-а и решает проблему синхронизации.

[/quote]

Простите, что опять лезу с свинным рылом в калашный ряд, но...
Почему бы не поставить МК, во флэш которого зашит начальный загрузчик. При начале работы загрузчик заливает (через USB, RS-232 и т.п.) рабочую программу в ОЗУ (внутреннее желательно) и передает ей управление.
При этом модификация рабочей программы достаточно проста и система получается гибкой.

[/quote]

А если прочитать весь тред???
К контроллеру еще FPGA цеплять?

[/quote]

А если прочитать весь тред???
К контроллеру еще FPGA цеплять?

[/quote]

Зачем FPGA вообще нужна? Для того чтобы сделать JTAG, пусть даже с использованием выводов ETM, достаточно процессора с соответствующим количеством выводов.

Это действительно проблема организации bulk посылок в Windows. Каждый пакет отсылается раз в 1 мс. И скорость может быть повышена за счет посылки более длинных пакетов за раз. А это тут же тянет за собой необходимость некоторого буферного устройства.

Взять,например, at91rm3400 - firmware заливать через usb в любой момент - 96к RAM хватит и на jtag и на любой программатор, да и цена (~10$) сравнима с FT2232C.

ЗЫ
Но думаю людям просто лень что-то самим писать, вот если бы были готовые сишные сорцы может что-нибудь и получилось.

MT-Link
Далее цитата:
Однако при всех перечисленных выше достоинствах J-Link от Segger имеет весьма высокую цену. Поэтому на базе новейшего 32-битного ARM микроконтроллера LPC2142 /Philips/ со встроенным USB портом был разработан полный функциональный аналог J-Link, получивший название MT-Link. (В оригинальном устройстве J-Link используется 16-битный микроконтроллер M30245FCGP /Renesas/, а в первых партиях MT-Link установлен микроконтроллер AT91SAM7S64).

http://www.mt-system.ru/pub/6a835acfa20541...1286a3f89df.pdf

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

А не сделать ли новую ветку (корневую) типа JTAG интерфейс. Вопросов и нюансов много.

Кстати интересно, а почему отказались от атмела в пользу филипса ?

PS
Сюда бы ещё добавить поддержку avr c debug-wire, то народ бы расхватывал
и по 100$.

МТ-систем торгует самими АРМ-филипками - вот и отказались от атмела. .а почему атмел сначала был - наверное наемный программист лучше атмел знал))
(или еслине путаю - ARM c USB у атмела раньше появилось)

я поставил Atmel именно потому что он появился первый. Ну а насчет наемности - немного не так, просто сделал для себя, народу понравилось :-)

Фирмваре на Сях писАл???

да, на С. Только процедуру вывода на конечные TCK TMS TDO заооптимизировал донельзя. Глядя на асмовый листинг и корректируя сурец на С. В итоге на асме бы и лучше не написал. Ну и еще все скоростные функции являются ramfunc - то есть исполняются из RAM