Цитата(Oldring @ Dec 27 2006, 11:17)

Цитата(impatt @ Dec 27 2006, 10:39)

Занимаюсь, находясь в Линуксе, программирование AVR-ок. Может, ARM-ы будут, не знаю.
Отлаживать что-то по JTAG-у великогиморно, ибо для отладчика (скажем, GDB) нет способа связи через JTAG с чипом.
Вы совершенно правильно указали, что главная проблема с JTAG - закрытость и нестандартность протоколов отладки уровня приложения.
Это да, наверное, но имел в виду закрытость драйверов кокретных изделий, которые вы назвали сериализатором. Кстати, название неплохое.
Сам JTAG прост, как SPI. Всякие регистры и команды - да, кто-то их прячет. Но если надо, многие вещи можно реверс-инжинирить, как мне кажется. Было бы желание. К примеру, как уж зажопились атмэльщики, но кто-то там навыковыривал из сессии отладки команды, и они перестали быть секретом, по крайней мере, на каком-то этапе.
Цитата(Oldring @ Dec 27 2006, 11:17)

То есть просто одним сериализатором этот вопрос не решить.
Часть - решить. Когда вопрос останется только за командами и регистрами - может стать проще.
Цитата(Oldring @ Dec 27 2006, 11:17)

Для AVR не опубликованы даже отладочные регистры, поэтому особо лучше ни на что не надейтесь.
Они не опубликованы просто так, и не факт ,что не будут опубликованы по просьбе трудящихся. Там написано: для 3-d party vendors. Я, например, хочу попробовать побыть кандидатом в эти вендоры

К примеру, с филипсом сходный трюк прокатил на ура (не на тему JTAG).
Цитата(Oldring @ Dec 27 2006, 11:17)

Для ARM для GDB вроде бы ситуация гораздо лучше.
GDB посылает элементарные команды "держателю" среды исполнения программы. Либо через поток ввода-вывода, либо через TCP. Этот "держатель" должен как-то общаться с микроконтроллером, если речь о микроконтроллере, например. Стало быть, необходима софтина, которая слушает запросы GDB и преобразует их в элементарные действия, специфичные для конкретного микроконтроллера и отправлять их в конкретную модель сериализатора.
Так что конкретно с GDB вообще проблем нет. Сам GDB есть и это решает большую часть проблем по отладке.
И ещё: универсальный сериализатор, который может быстро и просто работать (USB2, регулируемая скорость тактирования JTAG и так далее) имеет больше шансов на интерес со стороны кого-бы то ни было, а значит, и шанс на их помощь, советы и замечания.
Лично мне неинтересно делать очередной айс, в котором будет за каким-то хреном спрятан волшебный сложный алгоритм, могущий, пока не глючит, работать с конкретным чипом в конкретных условиях. Надо простой сериализатор. Драйвер, библиотеки с высокоуровневыми функциями, и gdb-серверы (те "держатели" среды исполнения) для конкретных чипов, сделанные на тех библиотеках - вот что интересно.
И ещё: полно JTAG-оснащённых вещей, не являющихся контроллерами, например, ПЛИСы. Там айсы нафик не нужны, имхо.
По поводу FTDI или как там их. Некошерно и небыстро шевелить ногами. Например, какой-нибудь быстрый процессор на плате выгребает с быстрого АЦП данные со скоростью 10 мегабайт в секунду. Нужно отлаживать, снимать копию потока к себе на машину. Или, к примеру, надо периодически дампить с платы содержимое памяти размером 64 мегабайта. В реалтайме ногами много не нашевелишь, однако. Тем более, какой-то комрад в этом-же форуме ругается на кривизну драйверов FTDI. Так что FTDI, если исходить из того, что они не предназначены для JTAG, не есть гут.
ЗЫ: если бы нужный чип или схема сериализатора существовала, с нормально документированным интерфейсом на уровне USB, я бы занялся написанием драйвера и библиотеки к этому. Купил рассыпухи и всё такое (конечно, жизнь может внести коррективы в такие планы, например, лишить меня свободного времени). Или иначе: я бы затеял открытый проект, запросил бы помощи у спецов в Verilog-е, если бы уже умел написать требуемый софт для устройства.