Есть участки программы, где я не могу поставить брейкпоинт, т. к. нарушу процесс приема/передачи данных, но все равно хотелось бы посмотреть, что там происходит, например, в программе на Win32 я бы все вывел в лог файл. Как быть с ARM'ом? Вводить дополн. переменные для дебага?

Выкидываете отладчик, берете UART, прикручиваете к нему FIFO, подключаете терминал и спокойно отлаживаетесь.

А почему так радикально? есть какое то недоверие отладчику? а если не затруднит, можно поподробней что куда подключать и где это что то брать?

Отладчик - инструмент мало пригодный для работы с живым процессом.

Подключать к PC при помощи RS232 или другого доступного буферизированного интерфейса. Брать нигде ничего не надо, отладочный вывод можно написать самостоятельно.

Да не слушайте всякую радикальную дурь.


printf() поставить в нужных точках,
а поток printf'а, тобиш соответвующий "putchar" делать куда удобно, хоть в UART, хоть в JTAG, хоть просто в память складывать (виртуальный файл) который потом под отладкой и просмотрите..

Выбирайте выражения. Понимаю, что больная для вас тема, но все же.

А что printf() работает через JTAG? я слышал что нет

Работает. И файловый ввод/вывод тоже. Можно, например, отлаживать файловую систему, прикрутив при помощи нехитрых манипуляций физический диск хоста, и тем самым сэкономить время на перетыкании носителя.

Выражение выбрано адекватно, и касается исключительно радикальной дури насчет "выкидывайте отладчик".

В некоторых средах разработки через JTAG есть доступ к файловой системе компьютера, и через fopen/fprintf/fwrite/fread из отлаживаемого проца можно работать прямо с файлами на диске, где пущена среда разработки. printf - выдает сообщения в окно среды разработки. Без каких либо хитростей, просто сразу есть по умолчанию. А также есть технологии реалтайм потоковой передачи данных от отлаживаемого процессора на хост по JTAG.

подскажите где можно почитать про printf? какой заголовочный файл нужно включить для его использования?

Полагаете, что агрессивное хамство поможет в борьбе с "радикальной дурью", в вашем понимании?


Для использования printf нужно подключить <stdio.h> Почитать следует книжку по 'C' и документацию на компилятор по
вопросам перенаправления потока.

Если "процесс" - это прерывание таймера раз в секунду, то можно и принтфом.
А если прерывание раз в микросекунду - то замучаетесь пыль глотать с принтэфом.

То, что предлагает aaarrr, занимает пару машинных команд. Т.е. вмешательство в реалтайм будет минимальным.
А в большинстве случаев, вмешательство принтэф будет фатальным.

Разве что написать свой принтэф. Но в этом случае - гораздо проще его не писать.

Оч. интересно! на сколько фатальным будет стандартный printf?

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

stdio.h, и если работаете с Code Composer Studio (Texas Instruments) - то ничего перенаправлять никуда не надо, по умолчанию printf работает через JTAG в отладочную консоль. Если надо гнать более толстые потоки - там для этого предусмотрены спец. механизмы RTDX и HSRTDX. Все это полностью поддержано и для ARM 7,9,11, и для cortex-M, -R и -A, а не только для DSP-семейств (об этом многие даже и не догадываются).

Недопонял. Т.е. если я работаю с Code Composer Studio, то скорость не передачи через printf не будет фатальной?

Будет-будет, printf - он и в Африке printf.

Смотря чем определяется фатальность. в CCS принтф вызывает emulation stop, пересылку буфера в хост и run - т.е. процессор встает на какое-то, пусть небольшое, время. Основной тормоз тут - это поллинг ARMа по JTAGу на предмет того, встал он или нет. После того, как хост узнал, что встал, остальное очень быстро. В отличие от RTDX - при этом обмен идет через буфер, который выкачивается через JTAG механизмами DMA, не прерывая программы. Ну и обратно аналогично - вкачивается по DMA, после чего вызывает прерывание.

Хм, а CCS с чужим процессором подружить можно? У нас ведь тут AT91SAM7S256.

Пробовать надо. Для начала нужно иметь эмулятор техасского происхождения - совместимый с XDS510 или XDS560 (второй наверное излишен, он позволяет в реалтайме гнать мегабиты вплоть до видеопотоков). Это главное. Так как CCS нельзя подружить с другими JTAG-ами. В свое время я коннектил CCS 2-ой версии к альтерскому ARM9 (Excalibur EPXA3) без каких либо шаманств. Но это было давно, композер уже 4-й на подходе, дрова там совершенствовались не один десяток раз. Так что они могли и вставить проверку на то, что ARM техасского происхождения (кстати, а это возможно? по JTAG IDCODE? Или по какому признаку?). Но... Тут как говорится - если что, как вставили, так и вынем

В общем - ни в 3-ем композере, ни в 4-ом я не пробовал коннектиться к нетехасским АРМ, а 2-ой коннектился без вопросов. Меня самого этот вопрос очень интересует, если попадется под руку что-то ARMообразное нетехасское, попробую однозначно.

Использование вместо простого, как лом и требующего минимальные ресурсы UART - JTAG с его непрерывным проможением контроллера, подьема по поллингу, мутными многослойными драйверами на стороне РС, эмуляторами терминалов..... Теперь "радикальная дурь". Приехали .

Вы похоже не знаете, что сейчас позволяет JTAG. По нему практически без торможения PC и девайса передается в комп в реалтайме видеопоток 30 fps 640x480 (это что я лично видел в работе). И при этом нет практически никаких затрат в программировании ни на той стороне, ни на этой. Интересно, сколько сил Вы положите на аналогичное по UART. И сколько UARTов задействуете. Да ладно, видео. Хотя бы простое стерео аудио, 2 канала 96 килогерц 24 бит. Это Вам не в терминал сообщение об ошибке плюнуть! (тут согласен, UART самое то, не надо дорогих жтагов). Речь то о реалтаймовых потоках данных! Зачем что-то городить свое, если за Вас все уже нагородили - только пользуй.

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

Вот и тут, когда дают откровенно неверный совет - хочу назвать вещи своими именами. Почему "выбросить отладчик" - это дурь, да потому что логичным завершением мысли будет не использовать UART - а "выбросить плату вместе ARM'ом" и на PC делать программу, записывая все в лог файл, как и раньше.


UART'у - uart'ово
JTAG'у - JTAG'ово.
Радикальная дурь - это лозунги, типа большивистского - "Мы старый мир разрушим, до основанья, а затем... "...

Я сравниваюсь по уровню разлагающего влияния с самим Р.? Пора задуматься о мировом господстве.


Не надо пытаться за меня "логично завершать мысли" - что-то совсем не логично получается.

То хамство, то сравнение с самим Р.
Да не берети все на свой счет-то.


Я за себя так завершаю, как читатель. Можно?

У вас богатая фантазия. Можно, кто ж запретит? Только это никаким образом не соотносится с тем, о чем тут писалось.

Тогда такой вопрос. Смогу ли я раз в 8мкс предавать через Debug UART, ну хотя бы 3 строчки текста приблизительно по 3 слова в строчке?

Нет, не сможете, конечно. Эти данные придется где-то буферизировать, чтобы потом спокойно вычитать.

А где их буферизировать? и сколько Debug UART может пропустить за 8мкс?

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

Формировать в отладочных целях "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 мкс?

Скажу так... Современный правильный переходник UART->USB это может принять, если он не буферирован для RS-232... А вот может ли передать UART в Вашем арме - это сами смотрите.

Только
1) Использовать только "правильные" контроллеры
2) Купить "правильный" JTAG
3) Ну и соответственно "правильную" среду разработки
4) развести JTAG, и сочеетать его с возможно другими имеющимися чипами, что вслучае всяких ныне идущих тугой струей низковольтных и шустрых FPGA себе не левой ногой делается.
Ну а дальше, все конечно просто

Если, конечно, вся эта байда не взглючит в "нужный" момент.

Здорово-то как. Зачем Вы тогда НЕ ПРО USB JTAG поминали? Почему тот-же самый блекфиновский USB-JTAG (кстати, тоже совсем не дешевый, дотя по сравнению с их-же PCI, конечно почти лимонад) и при постановки банальной точки остановки тоскливо впадает в ступор надолго?
И чего-то Вы как-то молчите в ответ на предложение рассказать о практической реализации оного счастья на майнстримовом наборе LPC+J-Link+IAR.

Добавлю - "обычная" система с JTAG этого и близко не сможет.

Потому, что я не знаю, делается ли это на таком наборе, и если делается, то как. Я не знаю ни J-Link-a, ни IARа. Я рассказываю лишь то, что знаю. А знаю я все недра вплоть до глубин драйверов и схемотехники эмуляторов у TI CCS. Кому с чем нравится, тот с тем и работает. И я не настаиваю на переходе с чего-то куда-то. Я лишь объясняю начинающим, что есть такая среда, есть такие эмуляторы, в которых возможно то-то и то-то, и кому-то наверняка эта информация станет полезной. Возможно ли это в других средах и на других эмуляторах я просто без понятия, и на эту тему что-то высказывать не могу. И вообще не понимаю, на кой мне этот ж-линк с иаром, если у меня есть xds с ccs

Любая байда может взглючить в "нужный момент" На то и есть разработчики всех этих байд, чтобы глюки устранять, и техподдержку оказывать тем, у кого вдруг что-то сглючивает в тех байдах, в которых они сами не бум-бум. Хотя, впрочем, нельзя сказать, что "байда" сглючит сильно вероятнее, чем просто винда на компе.

Это бы еще с чего? ARM он и в Африке ARM. Я вот в CCS писал под Excalibur-ARM, он уж никак не является "правильным контроллером" с точки зрения CCS, однако все работало, коннектилось и отлаживалось без каких либо лишних действий.

Нука-нука поподробнее тут. Обычно самая основная проблема при разводки - обеспечить качество сигналов JTAG именно на процессоре, чтобы он без сбоев работал на 30..50 МГц по TCK, а фпга-то они так, сбоку-припека, загрузил на любой скорости, хоть на мегагерце TCK, и ладно. Вообще, какая-то надуманная проблема в сложности организации JTAG цепочки из нескольких микросхем. А эмуляторы обеспечивают уровни сигналов JTAG 1.65...5.5 вольт, причем автоматически, тут и думать не надо.

Ага, хорошие мегагерцы. Теперь навешаем на тот-же JTAG согласование уровней с 2,5V FPGA и в цепочке и на TCK, подумаем, что будет, с задержками на этих мегагерцах и как обеспечить нормальные форонты без звона и overshoot/undershoot опасных для FPGA.
Заодно, узнаем, что ARM арму рознь и на фантастических 30...50 MHz ни массовые ARM и массовые JTAG адаптеры под них (а еще встечаются живые поклонники Wigler и подобных )просто работать не будут.

Дык я это сразу просек, повтояюсь:

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

А завести на ПЛИСово JVCC (питание пинов жтага) 3.3 совесть не позволяет? Или его в той стороне платы нет, а дорожку длинную тянуть ломает? Да и уровни совместимы у 3.3 и у 2.5 логики без какого либо дополнительного согласования, т.е. 2.5 логика ПЛИСов она 3.3-толерантная. В общем проблема очень и очень надуманная. Или эта ПЛИС пообще с этим АРМом никак и нигде не соединена?

А еще заодно узнаем, что у эмуляторов есть адаптивное тактирование, а у ARMов, в т.ч. массовых, в которых максимальная TCK зависит от тактовой ядра - возвратный клок RTCK, позволяющий эмуляторам автоматически выставлять максимально допустимую частоту. А также, что у эмуляторов есть ручное задание тактовой частоты начиная от десятков килогерц... А также смотрим даташиты на "массовые ARM", которые без адаптивного тактирования - например AT90RM9200, который массовый уже лет 10, допускает как раз 50 МГц по TCK. Так что все массовые АРМ будут работать либо автоматом на таких частотах, которые сами допускают, либо допускают вполне достаточно. Кстати, интересно, а какой именно ARM, из тех, что без RTCK, не протянет 30 МГц по JTAG? Это про ARMы. А про "массовые" jtag-адаптеры речь в моем контексте не идет. Потому, что CCS поддерживает только другие массовые адаптеры, совместимые с XDS510 или XDS560.