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

[coolibin]

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

[aaarrr]

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

[coolibin]

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

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

[aaarrr]

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

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

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

[defunct]

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

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

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

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

[aaarrr]

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

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

[coolibin]

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

[aaarrr]

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

[defunct]

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

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

[SM]

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

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

[coolibin]

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

[aaarrr]

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

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

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

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

[DpInRock]

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

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

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

[coolibin]

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

[aaarrr]

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

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

[SM]

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

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

[coolibin]

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

[aaarrr]

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

[SM]

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

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

[aaarrr]

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

[SM]

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

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

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

[zltigo]

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

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

[SM]

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

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

[defunct]

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

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

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

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

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

[aaarrr]

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

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

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

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

[defunct]

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

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

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

[aaarrr]

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

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

[coolibin]

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

[aaarrr]

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

[coolibin]

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

[aaarrr]

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

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

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

[coolibin]

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

[zltigo]

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

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

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

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

[aaarrr]

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

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

одно число Debug UART сможет передать?

8 мкс - это 125кГц, чтобы передать даже одно число в 32-бита нужен интерфейс с пропускной способностью примерно 1МБайт/с, 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-же таких волшебных железных буферов просто нет. Все, что дальше - написано уже выше.

[DpInRock]

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

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

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

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

[SasaVitebsk]

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

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

[coolibin]

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

[aaarrr]

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

[coolibin]

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

[aaarrr]

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

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

[SM]

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

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

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

[DpInRock]

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

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

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

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

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

[coolibin]

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

[SM]

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

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

[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.

[aaarrr]

Кстати, интересно, а какой именно ARM, из тех, что без RTCK, не протянет 30 МГц по JTAG?

Да вот хоть из этого топика - у AT91SAM7S256 TCK < 10MHz.

[SM]

Да вот хоть из этого топика - у AT91SAM7S256 TCK < 10MHz.

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

[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

[singlskv]

(а еще встечаются живые поклонники Wigler и подобных )просто работать не будут.

Я живой поклонник Wigler
У меня нет ни одного свободного интерфейса,
-все UART заняты(и DBGU тоже)
-все SPI заняты
- USB занят
- CAN тоже
- I2C тоже, если его пины не заняты чем-нить другим...

предложите мне хоть какой-нить способ отладки...

[zltigo]

У меня нет ни одного свободного интерфейса

Странно, что у Вас, видимо совершенно случайно, оказался контролер не занятый чем-нибудь другим не имеющим отнощения к программам.
Загнав себя себя у угол можете там и сидеть - каждый сам себе Буратино.
P.S.
Насколько я помню, Вы не понимаете отладки в терминале, c чего это вдруг занитересовались терминалом, да еще эмулирумым через самое убогое железо?

[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-ов, которые бесплатное приложение.

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

[singlskv]

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

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

Загнав себя себя у угол можете там и сидеть - каждый сам себе Буратино.

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

P.S.
Насколько я помню, Вы не понимаете отладки в терминале,

Кто Вам сказал что я такими возможностями не пользуюсь совсем ?

c чего это вдруг занитересовались терминалом, да еще эмулирумым через самое убогое железо?

Убого - не убого... главное в этом вопросе результат, я вот отлаживаюсь при полном отсутствии спец интерфейсов
для этого, а Вам слабо... ?

[SM]

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

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

[zltigo]

ха-ха. Тоже мне фаворит. Это средненький эмулятор....

Фаворит не по цене, фаворит не по наворотам. Фаворит по применимости в эмбеддерском мире. Реальная такая парочка c J-Link

Убого - не убого... главное в этом вопросе результат, я вот отлаживаюсь при полном отсутствии спец интерфейсов
для этого, а Вам слабо... ?

Мне даже не слабо и без используемого Вами действительно "специнтефейса" ака JTAG, и "спецсофта" ака дебагер, и уж тем более без "спецдевайса" Wiggler (который, кстати, наряду со многими JTAG девайсами у меня имеется )

[singlskv]

Мне даже не слабо и без используемого Вами действительно "специнтефейса" ака JTAG, и "спецсофта" ака дебагер, и уж тем более без "спецдевайса" Wiggler (который, кстати, наряду со многими JTAG девайсами у меня имеется )

Видимо Вы недопоняли, консоли не будет в принципе...
предложите способ отладки...

[zltigo]

Видимо Вы недопоняли, консоли не будет в принципе...
предложите способ отладки...

Я все понял и ответил - чем отлаживаться с Wiggler, я лучше начну махать пином изображая 7bit посылки. При этом еще могу "гордо" утверждать, что для JTAG у меня тоже даже типа пинов не осталось а я все еще отлаживаюсь . Вот такой я "крутой"

[singlskv]

Я все понял и ответил - чем отлаживаться с Wiggler, я лучше начну махать пином изображая 7bit посылки. При этом еще могу "гордо" утверждать, что для JTAG у меня тоже даже типа пинов не осталось а я все еще отлаживаюсь . Вот такой я "крутой"

Ну ни знаю..., мне хватает мозгов просто тормознуть прогу и разобраться в проблеммах...

[zltigo]

Ну ни знаю..., мне хватает мозгов просто тормознуть прогу и разобраться в проблеммах...

Ну тогда я типа:

- А когда я учился в Оксфорде, нас учили не ссать на руки.

Это я к типа к тому, что я вообще могу не делать ошибок
Скажите, а к чему Вы это ответвление с "тормознуть прогу" в теме "Дэбаг непрерывного процесса" затеяли? Может хватит?

[SM]

При этом еще могу "гордо" утверждать, что для JTAG у меня тоже даже типа пинов не осталось а я все еще отлаживаюсь

Хм. А что же это такое отлаживается, что JTAG-пины можно под что-то кроме отладки задействовать? BIST какой нибудь через них сделан? Во всем том АРМовом, с чем я дело имел (альтерский excalibur, который гибрид АРМ+фпга, TMS470R1, TMS320C5471) переназначение жтаг-пинов во что-то другое было невозможно. Да и судя по даташиту в обсуждаемом AT91SAM7 нельзя.

[zltigo]

Да и судя по даташиту в обсуждаемом AT91SAM7 нельзя.

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

[SM]

А вот такой вопрос, оффтопный слегка, Вы тут RDI упоминали, а где-бы стандартиком разжиться, не знаете? Что-то не нагугливается... Есть идейки сделать RDI-либу для XDS.

[singlskv]

Я все понял и ответил - чем отлаживаться с Wiggler, я лучше начну махать пином изображая 7bit посылки.

Флаг в руки и танк на встречу...,
однако Вы так и не смогли(не захотели...) ответить на вопрос по отладке при отсутствии свободных интерфейсов...

Скажите, а к чему Вы это ответвление с "тормознуть прогу" в теме "Дэбаг непрерывного процесса" затеяли? Может хватит?

А Вы не умеете отлаживаться при включенных прерываниях ? научить ?
и поток окажеться таки непрерывным...(почти...)

[AlexandrY]

Здесь как раз все очень просто, так просто, что проффесионалы леняться даже подсказывать.
У USB всегда есть свободные конечные точки (тока не говорите что вы все заняли).
Так вот делают композитный дивайс и отлаживают через виртуальный COM порт.
Есть также Ethernet, в нем при любых раскладах отладочный канал можно сделать.
Даж на якобы занятом UART-е можно сделать отладочный канал путем мультиплексированных протоколов.
Короче курите Линукс. Обретете много идей по отладке.

однако Вы так и не смогли(не захотели...) ответить на вопрос по отладке при отсутствии свободных интерфейсов...

[singlskv]

Здесь как раз все очень просто,

правда?

так просто, что проффесионалы леняться даже подсказывать.

Кто конкретно ?, Вы уже подсказали...

У USB всегда есть свободные конечные точки (тока не говорите что вы все заняли).
Так вот делают композитный дивайс и отлаживают через виртуальный COM порт.

для отладки USB интерфейса это особенно ценно...

Есть также Ethernet, в нем при любых раскладах отладочный канал можно сделать.

Ethernet пока не подогнали...

Даж на якобы занятом UART-е можно сделать отладочный канал путем мультиплексированных протоколов.

предложите разумную схемму мультиплексирования модбаса...

Короче курите Линукс. Обретете много идей по отладке.

Спасибо, иногда курю...

[AlexandrY]

Раз уж пошел такой маркетинг, то похвалю и свое.

Покупателям проекта ARM-Ultimator передаю бесплатно полный комплект документации на JTAG-USB адаптер Y-Link:



Вот результат контрольного теста скорости работы Y-Link:


Т.е. скорость чтения внешней по отношению к чипу NOR FLASH через JTAG получаем 1.6 Mbit/s в среднем при тактовой JTAG = 12 MHz
Ну и также не забываем что этот класс адаптеров работает через RDI, через GDB, через TCP/IP. А также как родной принимается компиляторами IAR, Keil, Multi и т.д.

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

[zltigo]

Здесь как раз все очень просто, так просто....

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

[AlexandrY]

Естественно, я прикидываю чего стоит занять осмысленным делом стока интерфейсов, чтоб на SAM-е ни одного свободного не осталось.
Понты, конечно, но поболтать можно

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

[zltigo]

для отладки USB интерфейса это особенно ценно...

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

предложите разумную схемму мультиплексирования модбаса...

А что, каие могут проблемы? Если, кончно, делать а не сразу говорить о "неразумности". На вскидку я даже не могу назвать ни одного интерфейса/протокола на котром сложно изобразить служебный канал.

[singlskv]

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

Хотите схемы посмотреть ? на условиях NDA в привате ?
Нету у меня отладочных интерфейсов и все тут...
"отладочным" становиться первый отлаженный
ну и без JTAG при таком раскладе просто скучно, когда почти все интерфейсы завязаны на все остальные,
типа маршрутизация между ними и ее нужно отладить...

[zltigo]

Понты, конечно, но поболтать можно

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

[SM]

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

Ну это у кого как У других же видна четкая тенденция расширения JTAG-интерфейса пинами EMU0...EMUnn для повышения пропускной отладочных реалтайм-каналов...

[singlskv]

А что, каие могут проблемы? Если, кончно, делать а не сразу говорить о "неразумности". На вскидку я даже не могу назвать ни одного интерфейса/протокола на котром сложно изобразить служебный канал.

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

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

ага, и Nexus это практически однопроводной сериальный интерфейс...

[zltigo]

Хотите схемы посмотреть ? на условиях NDA в привате ?

Нет судя по набору интерфейсов это достаточно не интересно для меня.

Нету у меня отладочных интерфейсов и все тут...
"отладочным" становиться первый отлаженный

Ну и славненько.

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

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

[aaarrr]

единственная возможность это добавить набор отладочных регистров

А набор левых адресов - никак? Только не говорите, что все заняты.

[singlskv]

А набор левых адресов - никак? Только не говорите, что все заняты.

регистр в модбасе фактически == адрес
так и делаю, только еще раз, это другая схема отладки,

Как отладить маршрутизацию от всех интерфейсов ко всем ? без отладчика

[aaarrr]

регистр в модбасе фактически == адрес

Да причем здесь модбасовские регистры? Я имел в виду Address field в PDU. Фильтруем сразу пакет и все.

[zltigo]

ага, и Nexus это практически однопроводной сериальный интерфейс...

Угу, не видете разницы, между отладкой программ и отладкой ядер процессоров? Тяжело,небось, стало без чего-нибуть хотя-бы типа древнего ETM (http://www.segger.com/jtrace_general.html) роутинг отлаживать . А время последовательных, причем дейсвительно изначально многофункциональных интерфейсов наступило. C унификацией не очень , на конкретных производителей западать пока не очень хочется, посему пока на вечно молодом UART.

[SM]

и отладкой ядер процессоров?

????????? А это-то тут каким боком. Их, ядра, в симуляторах, да на прототипах ФПГА-шных отлаживают, а никак не встраивают для этого что-то в серийные микросхемы. Все, что дают в серийной ИМС - либо для отладки софта, либо для ускорения выходного контроля ИМС.

А последовательные интерфейсы для отладки это хорошо... Лично я за 3.125-гигабитный сериальный линк навроде RapidIO

[singlskv]

Я имел в виду Address field в PDU. Фильтруем сразу пакет и все.

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

[zltigo]

????????? А это-то тут каким боком.

Имеется ввиду Nexus 5001 где-то конца ПРОШЛГО века? Или что? Не поедставляю, зачем трассировка в реалтайме для "отладки софта".

[singlskv]

Угу, не видете разницы, между отладкой программ и отладкой ядер процессоров? Тяжело,небось, стало без чего-нибуть хотя-бы типа древнего ETM (http://www.segger.com/jtrace_general.html) роутинг отлаживать . А время последовательных, причем дейсвительно изначально многофункциональных интерфейсов наступило. C унификацией не очень , на конкретных производителей западать пока не очень хочется, посему пока на вечно молодом UART.

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

[SM]

Не поедставляю, зачем трассировка в реалтайме для "отладки софта".

Трассировка в самом реалтайме, разумеется, не нужна. Она нужна, если по результатам анализа данных, поступивших в реалтайме, остановили процессор, и хотят узнать, где он был "тогда". Ну и в общем смысле, посмотреть историю за некоторое время до возникновения ошибочной ситуации, приведшей к останову, так как останов может случиться далеко не в том месте, где произошла ошибка. А к отладке ядер оно отношения не имеет никакого. Да и nexus, собственно, не определяет физические провода, он разрешает и JTAG, и другие порты, думаю, и против чего-нить быстрого сериального, например RapidIO-линка - всего два провода, а 3 Гбит/с, иметь не будет...

[defunct]

RDI упоминали, а где-бы стандартиком разжиться, не знаете? Что-то не нагугливается... Есть идейки сделать RDI-либу для XDS.

Доки на RDI только под NDA идут (в бумаге).. закрытый он.

[AlexandrY]

Вот и расказали бы о своей конкретной грусти. Т.е. больше конкретики, Use Case-ов как говорится.
Аргумент что все порты заняты как бы не принимаются. Композитный дивайс на USB это классика, и нас применяется повсеместно.
Вот для подъема USB логично применить JTAG.

Но дальше проблемки есть, среди них:
JTAG не видит состояния памяти так как видит ее процессор через свой кэш. Т.е. на стопе дамп дает неправильный снимок памяти
JTAG не видит буфферизацию записи. Опять же на стопе дамп дает неправильный снимок памяти
Что JTAG видит в SoC-ах с акселераторами доступа FLASH тож тайна покрытая мраком.
Чтение через JTAG в реал-тайме используя семихостинг вносит местный эффект в выполнение кода. Баги могут временно пропадать.
Призводители умеют манипулировать JTAG сигналами когда вы пытаетесь лезть в области содержащие защищенный код или периферию, это еще вносит путаницу.
Наконец цикл отладки под JTAG просто длинее по времени чем отладка средствами встроенными в сам код. Для старта отладки
по JTAG нужен длиный период загрузки символьной отладочной информации, а перед этим скомпилить надо с отладочной информацией, а перед этим оптимизацию снизить до 0.
Вообщем лучше всех бы нам рассказал о всех неудобствах отладки через JTAG это SM поскольку CCS для ARM самый медленный и дубовый компилятор в мире.

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

[SM]

Вообщем лучше всех бы нам рассказал о всех неудобствах отладки через JTAG это SM

Могу сказать совершенно точно, что драйвера отладки обеспечивают видимость всего через кеши и прочие буфера и акселераторы именно так, как это видит процессор. И, при надобности, сливают или инвалидатят кеши, обеспечивая когерентность. Это совершенно надуманная проблема. Кеши не мешают отладке ни на каком из семейств процессоров, поддерживаемых CCS. Гораздо больше неприятностей от MMU, если его задействовать, так как ни драйвера, ни среда о нем без понятия, и "куда уехал цирк", а именно адреса внешних устройств, оно не догадывается.

Доки на RDI только под NDA идут (в бумаге).. закрытый он.

Ясно, спасибо, работаем . По ходу он уже и устарел, нынче RDDI заменил RDI. И он, все же, не в бумаге, но под лицензией.

[singlskv]

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

Вам не кажется что консоль на композитном USB девайсе выводящая дамп при попадании в дата аборт
это несколько оригинальное решение ?

Вот для подъема USB логично применить JTAG.

то есть JTAG таки бывает нужен...

Наконец цикл отладки под JTAG просто длинее по времени чем отладка средствами встроенными в сам код.

иногда длиннее иногда короче, сильно зависит от ошибки.

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

А кто мешает компилить всегда с отладочной инфой а шить из параллельно создаваемого BIN ?

а перед этим оптимизацию снизить до 0.

Для вменяемой отладки мне хватает снижения до 1
иначе во флеш уже не лезет...

[zltigo]

А кто мешает компилить всегда с отладочной инфой а шить из параллельно создаваемого BIN ?
...
Для вменяемой отладки мне хватает снижения до 1

И с таким уровнем считаем, что система "рабочая" .

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

[SM]

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

Не понял???? Поясните! Я что-то никакого длинного периода никогда не видел. Куда загрузки? Она и так уже в самой среде куда-то видимо сразу загружена, и символьная, и номера строк исходников. Еще думать об этом. А в таргет ее грузить, разумеется, не нужно. Когда делается "Load Program" из дебаггера нет никакой разницы по времени, есть там в загружаемом модуле отладочная информация, или нет.

[singlskv]

И с таким уровнем считаем, что система "рабочая" .

уровень снижаеться только на время отладки,
после нахождения бага он опять меняеться на -O2 или -Os
кстати разница в размере кода между -Os и -O1 в моем случае всего ~10%

Остается более-менее посмотреть буфера какие-нибудь. А при сбросе уровня оптимизации "для посмотреть", все, что более-менее зависит от времени хорошо уплывает.

Дык так и используеться, сбросил уровень оптимизазии, нашел багу, поднял уровень,
смотрим через "консоль".

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

[SM]

А при сбросе уровня оптимизации "для посмотреть", все, что более-менее зависит от времени хорошо уплывает.

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