Комментарии 22
Думаю это будет очень полезно. Ибо живешь-живешь, и не думаешь что JTAG это что-то кроме прошивки. Особенно когда коснулся FPGA после микроконтроллеров.
А сколько еще других вещей скрыто...
А сколько еще других вещей скрыто...
Именно :)
Полагаю, что желающие принять участие (согласно опросу, таких - уже больше двух), могут отписываться здесь (либо в личные сообщения), чтобы с ними можно было связаться.
Ну. И так как я, вроде как, предложил подобный формат, то в качестве пробного мероприятия, я бы мог побыть ведущим на первый раз.
Что-то вспомнилось:
"Договорившись о терминологии Человечество решит 50% своих проблем")
Всегда люблю в этот момент напоминать, что у МОП-транзистора четыре вывода, один из которых в принципе не имеет названия на русском языке. Куда уж нам про JTAG рассуждать)
Действительно, JTAG в среде (не)профессиональных embedded разработчиков JTAG рассматривается как инструмент для прошивки. Более опытные - знают про возможность отладки. Про boundary scan - знают немногие. Веселья добавляет существование SWD, который boundary scan не поддерживает (кажется). Соответственно частенько можно встретить выражение "JTAG/SWD" в смысле "ну какой-то аппаратный интерфейс для отладки". И, кстати, софт для работы с JTAG, который используют программисты (OpenOCD, Segger JLINK, Lauterbach Trace32, TI XDS, etc...) чаще всего вообще не умеет boundary scan в принципе. Поэтому программистам даже неоткуда узнать про такую штуку.
Такая ситуация с JTAG на микроконтроллерах абсолютно не удивляет, навскидку:
общая тенденция перехода с JTAG на SWD
Полное отсутствие поддержки тестирования от производителей МК: набортные отладчики демоплат умеют отлаживать, но не умеют тестировать, нужен некий отдельный сторонний интерфейс, софт к нему итд, да те же BSDL-файлы далеко не все публикуют.
Само тестирование межсоединений - некая отдельная операция, требующая своего подхода, нередко видится более простым встроить в код некий функциональный тест вида «внешний EEPROM пишется/читается», «внешний АЦП гонит данные» итд, который и соединения протестирует, и сами внешние компоненты.
Более того, JTAG именно в предназначении Test может использоваться для программирования устройства. Если к процессору подключена внешняя флэшь, то программатор, дёргая ногами процессора через JTAG, может на линиях флэши разворачивать временнУю диаграмму программирования.
Доводилось делать и такое, причём, на чипе без документации/распиновки/BSDL: чип не желал отлаживаться, но давал сканировать, по огромным длинам DR угадал инструкции сканирования, отпаял flash с известной распиновкой, дальше, гоняя в цикле сканирование и заземляя иголкой поочерёдно пины flash, нашёл биты DR, соответствующие им, заскриптовал шинные циклы чтения/записи и дальше уже команды по datasheet flash.
Однако, при наличии режима отладки и документации, в целом проще запустить на процессоре некий софтовый «загрузчик» и общаться уже с ним. Да и в целом, параллельные flash ушли в прошлое.
Вот бы статейку на эту тему с практическим(и) примером(ами) почитать...
Вместо того, чтобы развешивать пафос по параграфам и толочь воду в стакане, автор мог бы написать коротенькую заметку про то, как работает "Boundary Scan" фича у JTAG и какими опенсорсными тулами ею можно воспользоваться. Про коммерческие тулы рассказывать не стоит, так как они жутко дорогие и доступны в основном под винду.
Вместо того, чтобы развешивать пафос по параграфам и толочь воду в стакане, автор мог бы написать коротенькую заметку про то, как работает "Boundary Scan" фича у JTAG
Автор даже не знает, что и сказать на это ))))
Автор целый цикл написал (и продолжает его, в общем) на тему JTAG и Boundary Scan.
Автор сослался на этот цикл в данной статье ("Поэтому в цикле статей про JTAG я постарался уделить максимум внимания именно техническим аспектам")
"Boundary scan" никакая не фича JTAG, а его основная функция, его прямое предназначение.
Тогда зачем нужна была эта статья ? Выразить своё негодование тупому быдло которое считает, что JTAG это для программирования flash памяти ?
Ваш цикл статей почему-то прошел мимо меня, уж извините. Но я сейчас пробежался по статьям и вижу что в нём нет ни слова про опенсорсные решения, ни слова про OpenOCD и как его настроить. Вы используете проприетарную, платную виндовую тулзу, что совершенно бесполезна для подавляющего числа разработчиков.
Тогда зачем нужна была эта статья?
"Тогда" - это когда?
Выразить своё негодование тупому быдло которое считает, что JTAG это для программирования flash памяти?
Упомянутого в статье автора @lorc я ни в коем случае не считаю "тупым быдлом". Уверен, что и он, прочтя статью, не увидел в ней присутствия подобных смыслов, направленных в его адрес.
Ваш цикл статей почему-то прошел мимо меня...
...как и ссылка на него внутри статьи.
А всё потому, что вас бомбит и вы принялись читать текст "по диагонали" :)
А бомбит вас, выскажу смелое предположение, потому, что вы сами себя считаете мм... не вполне компетентным специалистом.
Но с внутренними переживаниями - это не ко мне.
Железячники токсичные.
Радиолюбителей с теорией антенн и зайчатками основами работы с переменным током берете? Сложных вопросов и вопросов с подвохом не предвидится, однако имею стойкое убеждение, что достаточно много околотехнического люда живет в миру глубоких заблуждений в отношении таких базовых вещей как реактивная мощность, электрический резонанс и тому подобного, на самом деле не так уж и интуитивного, поэтому не всегда постигаемого отдельно взятым здравым смыслом в отрыве от объективных знаний. А уж касательно антенн - объекта безусловной любви и обожания каждого радиолюбителя, недавняя вполне годная статья меня опечалила некоторыми комментариями.
Эпилогом статьи статьи, пожалуй, может быть: "В "проклятьи знания" (см. Вики) есть дополнительной вариант - когда разные люди имеют правильные взгляды на нечто с разных точек зрения."
Что касается игры... Один вопрос, пожалуй, есть. Надо только подумать над формулировкой (см. эпилог). А вот ещё один-два придумать...
Об особенностях электротехнических (и не только) сообществ: параллельные IT‑миры задают каверзные вопросы про JTAG