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

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

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

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

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

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


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

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

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


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

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


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


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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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




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

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

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

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

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

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

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

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

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

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


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

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

правда?
Кто конкретно ?, Вы уже подсказали...
для отладки USB интерфейса это особенно ценно...
Ethernet пока не подогнали...
предложите разумную схемму мультиплексирования модбаса...
Спасибо, иногда курю...

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

Покупателям проекта 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 и т.д.

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

Вам не кажется что консоль на композитном USB девайсе выводящая дамп при попадании в дата аборт
это несколько оригинальное решение ?
то есть JTAG таки бывает нужен...
иногда длиннее иногда короче, сильно зависит от ошибки.
А кто мешает компилить всегда с отладочной инфой а шить из параллельно создаваемого BIN ?
Для вменяемой отладки мне хватает снижения до 1
иначе во флеш уже не лезет...

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

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

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

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

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

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