Дэбаг непрерывного процесса?, IAR 4.41A, AT91SAM7S256 Опции

[coolibin]

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

[coolibin]

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

Сообщение отредактировал coolibin - Jun 16 2009, 15:27

[defunct]

А почему так радикально? есть какое то недоверие отладчику?

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

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

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

[zltigo]

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

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

[SM]

Использование вместо простого, как лом и требующего минимальные ресурсы UART

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

[zltigo]

Вы похоже не знаете, что сейчас позволяет JTAG.

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

Зачем что-то городить свое, если за Вас все уже нагородили - только пользуй.

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

[SM]

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

Поэтому я и заострил внимание на среде разработки. Типовой контроллер жтага, поддерживаемый 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 не тормозится. Разумеется, все это реализовано в библиотеках, идущих со средой, и не требует от программиста чего-то неординарного.

[zltigo]

и поддерживает блочный поллинг, то поллинг быстрый.

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

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

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

Это механизм, применяемый для ARM7TDMI. При этом ARM не тормозится. Разумеется, все это реализовано в библиотеках, идущих со средой, и не требует от программиста чего-то неординарного.

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

[SM]

Теоретически (если железо и чепочка и софт позволят гнать) более высокая скороть последовательного интерфейса. Все?

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

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

[zltigo]

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

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

Просто вызвал функцию и послал данные.

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

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

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

Скажу так...

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

[SM]

И чего-то Вы как-то молчите в ответ на предложение рассказать о практической реализации оного счастья на майнстримовом наборе LPC+J-Link+IAR.

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

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

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

1) Использовать только "правильные" контроллеры

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

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

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

[zltigo]

Нука-нука поподробнее тут. Обычно самая основная проблема при разводки - обеспечить качество сигналов JTAG именно на процессоре, чтобы он без сбоев работал на 30..50 МГц по TCK

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

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

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

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

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

[SM]

Ага, хорошие мегагерцы. Теперь навешаем на тот-же JTAG согласование уровней с 2,5V FPGA и в цепочке и на TCK, подумаем, что будет, с задержками на этих мегагерцах и как обеспечить нормальные форонты без звона и overshot/undershot опасных для FPGA.

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

Заодно, узнаем, что ARM арму рознь и на фантастических 30...50 MHz ни массовые ARM и массовые JTAG адаптеры под них (а еще встечаются живые поклонники Wigler и подобных )просто работать не будут.

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