В ОЗУ. Весьма мало.

Формировать в отладочных целях "3 строчки текста по 3 слова" каждые 8 мкс - это явный перебор.

А что нельзя в ОЗУ буферизировать и без Debug UART'а? обычным введение доп. переменных? ну а про 3 строчки по 3 слова, это я так с запасом одно число Debug UART сможет передать?

Типичный позволяет, как минимум не более того, что, что позволяет физически железо конкретного конкконтроллера зачастую накладявая на это дополнительные ограничения собственного железа и софта. А типовой ARM с типовым механизмом JTAG не представляет в этом отношении из себя ничего особенного - один из пары имеющихся аппаратных брекпойнтов стоит ввиде заглушки на "putchar()" и при останове, хост узнав об этом офакте по опросу цепочки драйвер-USB-JTAG вычитывает этот самый байт в следующем цикле опроса. При этом имеющийся последовательный интерфейс JTAG на передачу этого самого байта на типичной скорости в мегабит дополняет его многими байтами для обеспечения прохождения по JTAG цепочке. Да, да есть продвинутое железо JTAG автоматов в некоторых контроллерах с буферизацией и прочим, есть фирменные инкапсулируемые в JTAG протоколы для общения с этим железом. Но типичный JTAG "для переслать" байт и по скорости, и по загрузке вчистую проигрывает балальному UART работаюшему на даже на ничтожных десятках килобод.

Отлично, готов "только пользовать". Я есть чайник. Готов выслушать Ваш конкретный совет, как из имеющегося, ну допутим, чего-то майнстримового - LPC2148 c помощью ну, пусть будет распросраненного J-Link V4 и не менее распространенного IARовского отладчика выкачать ну чего-нибудь на скорости эквивалентной ну хотябы банальным 115200 UART.

Можно, конечно. Не важно по большому счету, чем эту информацию потом вытаскивать.
Другое дело, что сам подход "запишем кучу мегабайт, а потом разберемся" не представляется правильным, ввиду отсутствия большого количества ОЗУ и быстрых интерфейсов.
Ошибки не каждые 8 мкс возникают ведь? Вот и ставьте простые ловушки с коротким выводом.


8 мкс - это 125кГц, чтобы передать даже одно число в 32-бита нужен интерфейс с пропускной способностью примерно 1МБайт/с, UART не поможет.

Поэтому я и заострил внимание на среде разработки. Типовой контроллер жтага, поддерживаемый CCS (xds510 или xds560), и типовой драйвер, включенный в CCS, позволяют две вещи - первая, то что Вы сказали, заглушка на putchar. С учетом того, что жтаг-контроллер (xds510 на usb) работает на USB 2.0 hs, и поддерживает блочный поллинг, то поллинг быстрый. Не говоря уже о применении PCI-платы жтаг-контроллера, или самого шустрого XDS560 (но он мало у кого есть из-за цены). А вот вторая вещь заслуживает особого внимания - это RTDX. Физически обмен происходит так - ARM (или DSP, любой, поддерживаемый средой процессор) имеет в себе буфер, который заполняется реалтайм-потоком данных. По заполнению буфера процессор выставляет бит 0 Debug comms control register в EmbeddedICE, начиная передачу, после чего хост, обнаружив поллингом по JTAG этот бит, не прерывая исполнения кода процессора, вычитывает данные через Debug comms data register. Это механизм, применяемый для ARM7TDMI. При этом ARM не тормозится. Разумеется, все это реализовано в библиотеках, идущих со средой, и не требует от программиста чего-то неординарного.

Блочный, это хорошо, блочный это классно, если интефейс болочный и Вы лихо льете, ну тот-же фрейм кадра 30 раз в секунду. А вот если вы 30 раз в секунду будете лить по байту отладочной печати, это труба дело.

Только вот ARM7 в себе волшебного буфера в железе не имеет, значит должен быть некий софтовый его заменяющий. Ну и софт его поддтерживающий и софт о нем знающий и быстро болоком перекачивающий, и софт блок принимающий и обрабатывающий. Какие в результате всех этих наворотов и нагромождений и условий преимущества по отншению к такой-же, но более простой (и что характерно не зависящий ни от JTAG, ни от стоимости JTAG, ни от среды разработки, ни от софта сторонних производителей) организации дела для банального UART (тоже между прочим обычно имеющий и FIFO, и DMA)? Теоретически (если железо и чепочка и софт позволят гнать) более высокая скороть последовательного интерфейса. Все?

Только вот у ARM7 со штатным JTAG автоматом от ARM-же таких волшебных железных буферов просто нет. Все, что дальше - написано уже выше.

Вы письмо дедушке пишете или отлаживаете?
1. Процессы, которые совсем быстрые (время обслуживания крайне критично) отлаживаются осциллографом. Выводите на пин (какой-нибудь) простой сигнал.
2. Чуть более менее критичные процессы. Пишем число-сигнал напрямую в регистр передатчика. Тут будет засада. Если повторный вызов будет раньше, чем закончится передача, то предыдущая передача может накрыться (если UART не имеет двойной буферизации).
2а. Пишем число-сигнал в кольцевой буфер. А фоновая программа потихоньку выдает этот буфер наружу. Занимает чуть больше времени, чем предыдущий пункт, но более надежна. Но зато предыдущий пункт не требует никакой писанины, кроме настройки порта на передачу.

3. Организовавываем нормальный ввод\вывод по UART c прерываниями как по приему, так и по передаче. И более ни о чем не беспокоимся. Отладочный код будет жить на полных правах с нормальным кодом. Т.е. будет существовать веки вечные. Это будет гарантировать, что отладка не вносит ни плохих побочных эффектов, ни хороших.

А кроме того - уарт - всегда пригодится для вусякого разного.

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

А кто мешает вывести псевдотрассу проги в этот кольцевой буфер?

Честно, я уже начинаю путаться. кто с кем разговаривает? Если Вы думаете, что эта инфа мне поможет, тогда выскажите тоже самое только более доступными словами, потому что я не понял и половины того что здесь было сказано. Я не просто так выбрал форум для новичков

Что непонятно - кольцевой буфер? трассы?

ага, они самые

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

Пардон за ссылку, но погуглить можно и самостоятельно.

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

Что касается 30 раз в секунду по байту - а для таких потоков и совершенно пофигу, через что и как гнать. Можно позабыть про все поллинги, про flow control, про все на свете. "выплевывай" в любую удобную дырку, хост по любому принять успеет.

А давайте приведем пример. К примеру.

Как выводится отладка у жестких дисков? Там реалтайм - будь здоров.
Что используется для заливки прошивки?

Ответ - тот самый уарт.

Наверняка разработчики пользовались всем арсеналом средств. Но конечному потребителю отдан УАРТ.
Кнечно, это не совсем отладка, больше похоже на диагностику и лог, но тем не менее его хватает, чтобы как-то локализовать неисправность или баг...
Что и требуется.

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

Отлично! Тема простоты мне нравится)) Debug UART может передать 4 байта за 8 мкс?