Дэбаг непрерывного процесса?, 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.

[zltigo]

А завести на ПЛИСово JVCC (питание пинов жтага) 3.3 совесть не позволяет?

т.е. 2.5 логика ПЛИСов она 3.3-толерантная.

Расскажите об об этом разаработчикам Циклон3 и заодно попросите их, дабы перестали "пугать" снижением ресурса при overshot.

А еще заодно узнаем, что у эмуляторов есть адаптивное тактирование...

Отличная вещь, только скорсти тактирвания за счет такого контроля падают у масовых (если они ее вообще имеют) падает до единиц мегагерцев (например, у того-же J-Link за 250 а не за 4000 баксов RTCK заведен на прерывание контроллера, максимальную скорость такой обработка стоящим там ARM7 можете прикинуть сами )

А также смотрим даташиты на "массовые ARM", которые без адаптивного тактирования - например AT90RM9200

А есть еще не только "массовые ARM9", но и массовые "ARM11". Но в заголовке написано всего про ARM7, однако.

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

Несомненно, только что при этом будет с обещаниями волшебных перекачек результатов printf().
P.S.
Если Вы думаете, что я не держал в руках JTAG-и и не пытался получить от владения ими максимум всего, чего возможно, то это совсем не так

Действительно. Не знал, что такие бывают. Но все равно, 10 MHz это не мало.

А NXP вообще для ARM7 не нормирует

[SM]

Расскажите об об этом разаработчикам Циклон3 и заодно попросите их, дабы перестали "пугать" снижением ресурса при overshot.

Maximum Allowed Overshoot During Transitions over a 10-Year Time Frame
3.95V 100% оf time of HIGH level.

Этого что, мало что-ли? Это из даташита на циклон-3. Какие же у вас там по жтагам овершоты?

Отличная вещь, только скорсти тактирвания за счет такого контроля падают у масовых (если они ее вообще имеют) падает до единиц мегагерцев (например, у того-же J-Link за 250 а не за 4000 баксов RTCK заведен на прерывание контроллера, максимальную скорость такой обработка стоящим там ARM7 можете прикинуть сами

Да причем тут J-link? Я понимаю, есть фанаты сделать самому себе что-то через UART, или через Ethernet, или еще через что-то, что на борту дают, и потом через это успешно отлаживать. А другие просто купят более мощный эмулятор, и будут пользоваться готовыми средствами. Редкий проект не позволяет повысить сумму затрат на его разработку на $1K. Тут каждому свое. Я же не требую ото всех начинать сразу с мощных жтагов. Просто информирую о наличии альтернативы.

Что касается куда заводить RTCK - можно просто завести через инвертор на TCK - получится автогенератор TCK допустимой скорости. Ну и в эмулятор его соотв. подать, не используя клок, генерируемый самим эмулятором. Дешево и сердито. Вигглер, конечно, не поймет такого, ибо не умеет, а тот же XDS работает только по сигналу RTCK. А TCK просто генерирует, не обязывая использовать именно его, т.е. допуская подачу TCK с отлаживаемого устройства и игнорируя TCK с эмулятора.

Несомненно, только что при этом будет с обещаниями волшебных перекачек результатов printf().

Как чего - раза в два-три скорость уменьшится. Но все равно не до 115200

А NXP вообще для ARM7 не нормирует

А у них адаптивка - ядро само себя ограничит, вот и не нормируют. Как я понимаю - ограничение будет в частоту ядра, деленную на 4.

Если Вы думаете, что я не держал в руках JTAG-и и не пытался получить от владения ими максимум всего, чего возможно, то это совсем не так

Я думаю, что Вы не держали в руках всех эмуляторов. Например xds510 родного, и xds560. И не пробовали через них работать с ARM. Я вот тоже j-link не держал в руках... И ничего, честно об этом говорю.

[zltigo]

Как чего - раза в два-три скорость уменьшится. Но все равно не до 115200

Да, на десятках килогерц это не 115200, это много, много, меньше..... И на сотнях килогерц тоже меньше....
А 115200 это ведь не восьминогих восьмибитовиках речь идет. 921600, которые тянут мои писишные порты редкий ARM не сможет обеспечить. А это при 8 полезных битах на 10bit фрейм и близко не лежало к среднепотолочным несколькомегагерцовым JTAG подключенных к контролерам без навороченых JTAG автоматов, тем более пропихивающим инфу по цепочке.

Этого что, мало что-ли? Это из даташита на циклон-3. Какие же у вас там по жтагам овершоты?

Это если вдруг банк от 3.3 питается а не от 2.5 и сделано все в цепочке правильно, буферизировано пороблемы решимы. А так, на кусок кабеля, да на многоточке, да на тех фронтах которые FPGA гонят счастья ввиде 0.6V и близко не будет . Я ведь не разрешимости проблемы писал, а о, цитирую:

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

Я вот тоже j-link не держал в руках... И ничего, честно об этом говорю.

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

[SM]

Тоже информация к размышлению.

Ну в общем да. Окончательно подтверждает то, что при наличии xds-а и CCS-а ни J-link, ни, соответственно, IAR для работы с ним, покупать не стоит.

Касаемо скорости - 900 килобит (передача PC -> память таргета) точно получается на TCK в 2 МГц. Может и на меньшей получится, не пробовал. Это какой же ARM не выдержит 2 МГц на TCK?

Насчет кабелей, фронтов, и прочего - НЕ ВЕДЕТСЯ речь о кривых эмуляторах, в которых нет согласования с кабелем, нет подстройки уровней под питание таргета, и т.п. Речь идет только о XDS. Про другие, применяемые при отладке АРМ, я просто не знаю. Может они и выжгут ПЛИСину своими сигналами, если мер не предпринимать. Но они-то вообще причем, если они не позволяют осуществить реалтайм-передачу потока данных! И если банк питается от 2.5, то все равно допустим пожизненный овершот до 3.94. Если от 1.8 - то тоже допустим. От питания банка это не зависит.

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

А я и не удивлен. Описанное поддерживает CCS, а в нем ни J-link, ни вигглер не поддерживаются. Описанное с UART получится на эмуляторах серии xds510, а с видео - xds560. И ни на каких других.

[zltigo]

IAR для работы с ним, покупать не стоит.

IAR к J-Link имеет отношение опрсредованное. J-Link совершено отдельный продукт работающий через RDI с любым поддерживающим отладчиком. Можете и c другим фаворитом ознакомиться ULINK2, прямо, можно считать от ARM Company. Для него тоже обещают

Performance
JTAG Clock <= 10MHz
Memory R/W ≈ 28KB/s
Flash R/W ≈ 25KB/s
Data Trace Streaming 1Mb/s

Не похоже на передачу реалтного видео. Совсем.

Касаемо скорости - 900 килобит (передача PC -> память таргета) точно получается на TCK в 2 МГц. Может и на меньшей получится, не пробовал.

Прежде, чeм пробовать, как позиционирующий себя в качестве знатока JTAG, может раскажете в сопроождении скольких бит идет по JTAG цепочке из нескольких чипов восьмибитовая посылка "терминала"? Да, да про буфера в JTAG автомате коноролера спасаюшние положение повторять не надо - помню.

От питания банка это не зависит.

Сильное заявление ;(

Сообщение отредактировал zltigo - Jun 17 2009, 17:09

[SM]

Прежде, чeм пробовать, как позиционирующий себя в качестве знатока JTAG, может раскажете в сопроождении скольких бит идет по JTAG цепочке из нескольких чипов восьмибитовая посылка "терминала"?

А кто Вам сказал, что я передаю 8-битовыми посылками? Сами придумали? Я вообще-то сказал передача хост -> память таргета. И изначально вел речь о передаче реалтайм-потоков, а не printf-ов, которые бесплатное приложение. Если подробнее, то я передавал отнюдь не данные терминала, а тестовый аудиосигнал 2 канала 16 бит 16 кГц. А скорость мерял ради интереса, узнать, есть ли запас и сколько.

Сильное заявление ;(

Зато, в отличие от Вашего, соответствующее истине. Уровень до 3.95 вольта на любом входе циклона3 допускается всегда. Даже без питания вообще. Ах, ну да, наверное Вы не читали этот документ, а поверили кому-то на слово... http://www.altera.com/literature/hb/cyc3/cyc3_ciii52001.pdf И таблицу 1-2 в нем...

Можете и c другим фаворитом ознакомиться ULINK2,

ха-ха. Тоже мне фаворит. Это средненький эмулятор навроде xds510. По скорости RTDX вот фаворит http://www.spectrumdigital.com/product_inf...16b5584f56424ce

[zltigo]

И изначально вел речь о передаче реалтайм-потоков, а не printf-ов, которые бесплатное приложение.

Я совершенно четко понимаю, что Вы "изначально ведете речь" о чем-то "своем" не имеющем отношения к большинству реальностей.

[SM]

Я совершенно четко понимаю, что Вы "изначально ведете речь" о чем-то "своем" не имеющем отношения к большинству реальностей.

ну-да ну-да... потребность прогнать аудиосигнал с компа в устройстве на ARM это за гранью реального....