Идею jtag, если не вдаваться в тонкости, можно описать довольно быстро. Сам интерфейс задумывался для граничного сканирования. У каждого подключенного к jtag устройства (например, память, процессор) на плате есть свой внутренний tap-контроллер (test access point), который управляет режимами интерфейса, а он в свою очередь управляется двумя сигналами - tck (clock) и tms (test mode select). Tap-контроллер на плате управляет ячейками bsr (boundary scan register), а вот bsr - это по сути не регистр, а множество идущих подряд ячеек с относительно простой схемой. Каждая ячейка устанавливается на один вход или выход тестируемой микросхемы и позволяет в зависимости от режима: а) просто быть отключенной; б) читать приходящие извне данные; в) каким-то образом "генерировать" исходящие данные от ячейки, чтобы передавать их на следующую, г) каким-то образом "генерировать" входящие сигналы, чтобы подавать их внутрь микросхемы. причем в последних режимах плата "отключается" от окружающего мира, т.е. по сути поданные тестовые сигналы являются ее входами либо выходами. Ячейки устроены одинаково, но tap-контроллер "знает", какие из них подключены к входным сигналам, какие к выходным - проще говоря, провода так "распаяны" и соответствующим образом всей этой красотой управляет. Теперь осталось разобраться с "генерацией" тестового сигнала. На самом деле, генерацией занимается внешнее устройство, которое связано с регистром bsr двумя проводами - tdi (test data input) и tdo. Получается, что все ячейки BSC на плате, от каждого устройства связаны с собой в огромный "регистр", входом для ячейки является tdi - туда подаются данные и сдвигаются на нужное число ячеек, чтобы попасть на нужную ногу требуемой платы, а выходом для каждой ячейки служит tdo, и мы через определенное число тактов можем на контакте tdo считать значение, которое было на такой-то ноге такого-то устройства. Поэтому К.В. назвал медленным этот интерфейс - потому что тестовые данные проходят через ячейку в каждой ноге каждого устройства, прежде чем попасть с tdi в tdo. А контактов у jtag 4 - tms, tck, tdi, tdo. Есть еще опциональный контакт для ресета
А работает это так. У каждого устройства, поддерживающего jtag, уже есть внутри ячейки BSC, tap-контроллер и другие элементы, обеспечивающие функциональность. Например, device id register. Т.е. по сути от платы нужно только предоставить 4 пина и подвести нужные дороги к каждой микросхеме. При старте платы микросхемы по дефолту переходят в режим сообщение device id (забавно, что по станадрту этот режим вообще не является обязательным, но де факто все устройства его используют как дефолтный) и мы можем прочитать с выхода tdo последовательно айди устройства. Зная айди, мы можем понять, что за схема перед нами, какова ее конфигурация, т.е. знаем длину получившегося bsr и поддерживаемые команды. А зная длину BSR, мы точно знаем, через сколько времени данные, поданные на вход TDI, достигнет нужных нам ножек. И через сколько тактов с выхода TDO мы прочитаем ответ микросхемы на поданный сигнал (это называется режим intest). Таким образом, если хотим например протестировать сумматор, мы можем ему на ноги отправить входные данные (т.к. доставка "длинная", в момент доставки ячейка bsc не подключена к сумматору), а потом считать с выходных ног результат. Тем самым проверим корректность работы
Тут конечно недостаточно написал для понимания, переоценил свои возможности. Но еще хотел добавить важное замечание - к интерфейсу jtag относятся эти 4 выхода, наличие tap-контроллера и схема работы tap-контроллера (конечный автомат), а также наличие bsr и регистра для инструкций. Все остальное, даже входящее в стандарт, управляется снаружи. Допустим, мы хотим провести режим intest. Для этого надо путем подачи сигнала tms дойти до состояния автомата, отвечающего за instruction register, а далее - перейти в сдвиг данных (все это выбирается параллельно в каждом tap-контроллере). А дальше мы уже по входу tdi отправляем команды в instruction register, нужные нам. Это - ответственность тестирующего устройства, а не jtag. Например, мы можем в один tap-контродлер записать код команды bypass (причем код может отличаться для разных микросхем, мы контролируем это только снаружи), в тестируюмую микросхему - как раз команду INTEST, а в еще одну микросхему - какой-нибудь код расширенной команды, не входящей в стандарт, (например, для прошивки этой микросхемы). Далее, опять отсчитывая такты снаружи, мы знаем, что все коды команд достигли своих instruction register и можем путем подачи сигнала на tms перейти собственно к ркдиму тестирования - учитывая, что мы включили на определенной микросхеме bypass и соотвественно, длина bsr "сократилась"
с стм32 его нужно сравнивать(а как отладочную- с дискавери) а не с ардуино.. ардуино это подправил пример и забыл. ваеринг не раскрывает и десятую часть возможностей атмеги.. пс но вполне удобно для обработчика сигналов датчиков и управления чем нибудь простым, в связке с мощным контролером чтобы разгрузить его от рутины и не тратить процесорное время. моё мнение и ещё.. ни один нормальный человек не будет писать на ассемблере и тем более прямо работать с инструкциями.. что за хрень
Поверьте, если кому-то надо заморочиться по микроконтроллерам, то только ради этого поступать не будут, CS не единственный в своём роде, хотя и очень не плох. В любом случае информацию можно получить из нескольких источников, если CS прекратит выкладывать лекции то это конечно будет печально, но не непоправимо. И да, вопрос в качестве, отсутствие некоторых моментов в видео есть показатель качества, на который и было указано.
7:40 Не милиамперы а микроамперы.
Идею jtag, если не вдаваться в тонкости, можно описать довольно быстро. Сам интерфейс задумывался для граничного сканирования. У каждого подключенного к jtag устройства (например, память, процессор) на плате есть свой внутренний tap-контроллер (test access point), который управляет режимами интерфейса, а он в свою очередь управляется двумя сигналами - tck (clock) и tms (test mode select). Tap-контроллер на плате управляет ячейками bsr (boundary scan register), а вот bsr - это по сути не регистр, а множество идущих подряд ячеек с относительно простой схемой. Каждая ячейка устанавливается на один вход или выход тестируемой микросхемы и позволяет в зависимости от режима: а) просто быть отключенной; б) читать приходящие извне данные; в) каким-то образом "генерировать" исходящие данные от ячейки, чтобы передавать их на следующую, г) каким-то образом "генерировать" входящие сигналы, чтобы подавать их внутрь микросхемы. причем в последних режимах плата "отключается" от окружающего мира, т.е. по сути поданные тестовые сигналы являются ее входами либо выходами. Ячейки устроены одинаково, но tap-контроллер "знает", какие из них подключены к входным сигналам, какие к выходным - проще говоря, провода так "распаяны" и соответствующим образом всей этой красотой управляет. Теперь осталось разобраться с "генерацией" тестового сигнала. На самом деле, генерацией занимается внешнее устройство, которое связано с регистром bsr двумя проводами - tdi (test data input) и tdo. Получается, что все ячейки BSC на плате, от каждого устройства связаны с собой в огромный "регистр", входом для ячейки является tdi - туда подаются данные и сдвигаются на нужное число ячеек, чтобы попасть на нужную ногу требуемой платы, а выходом для каждой ячейки служит tdo, и мы через определенное число тактов можем на контакте tdo считать значение, которое было на такой-то ноге такого-то устройства. Поэтому К.В. назвал медленным этот интерфейс - потому что тестовые данные проходят через ячейку в каждой ноге каждого устройства, прежде чем попасть с tdi в tdo. А контактов у jtag 4 - tms, tck, tdi, tdo. Есть еще опциональный контакт для ресета
А работает это так. У каждого устройства, поддерживающего jtag, уже есть внутри ячейки BSC, tap-контроллер и другие элементы, обеспечивающие функциональность. Например, device id register. Т.е. по сути от платы нужно только предоставить 4 пина и подвести нужные дороги к каждой микросхеме. При старте платы микросхемы по дефолту переходят в режим сообщение device id (забавно, что по станадрту этот режим вообще не является обязательным, но де факто все устройства его используют как дефолтный) и мы можем прочитать с выхода tdo последовательно айди устройства. Зная айди, мы можем понять, что за схема перед нами, какова ее конфигурация, т.е. знаем длину получившегося bsr и поддерживаемые команды. А зная длину BSR, мы точно знаем, через сколько времени данные, поданные на вход TDI, достигнет нужных нам ножек. И через сколько тактов с выхода TDO мы прочитаем ответ микросхемы на поданный сигнал (это называется режим intest). Таким образом, если хотим например протестировать сумматор, мы можем ему на ноги отправить входные данные (т.к. доставка "длинная", в момент доставки ячейка bsc не подключена к сумматору), а потом считать с выходных ног результат. Тем самым проверим корректность работы
Тут конечно недостаточно написал для понимания, переоценил свои возможности. Но еще хотел добавить важное замечание - к интерфейсу jtag относятся эти 4 выхода, наличие tap-контроллера и схема работы tap-контроллера (конечный автомат), а также наличие bsr и регистра для инструкций. Все остальное, даже входящее в стандарт, управляется снаружи. Допустим, мы хотим провести режим intest. Для этого надо путем подачи сигнала tms дойти до состояния автомата, отвечающего за instruction register, а далее - перейти в сдвиг данных (все это выбирается параллельно в каждом tap-контроллере). А дальше мы уже по входу tdi отправляем команды в instruction register, нужные нам. Это - ответственность тестирующего устройства, а не jtag. Например, мы можем в один tap-контродлер записать код команды bypass (причем код может отличаться для разных микросхем, мы контролируем это только снаружи), в тестируюмую микросхему - как раз команду INTEST, а в еще одну микросхему - какой-нибудь код расширенной команды, не входящей в стандарт, (например, для прошивки этой микросхемы). Далее, опять отсчитывая такты снаружи, мы знаем, что все коды команд достигли своих instruction register и можем путем подачи сигнала на tms перейти собственно к ркдиму тестирования - учитывая, что мы включили на определенной микросхеме bypass и соотвественно, длина bsr "сократилась"
с стм32 его нужно сравнивать(а как отладочную- с дискавери) а не с ардуино..
ардуино это подправил пример и забыл. ваеринг не раскрывает и десятую часть возможностей атмеги..
пс но вполне удобно для обработчика сигналов датчиков и управления чем нибудь простым, в связке с мощным контролером чтобы разгрузить его от рутины и не тратить процесорное время.
моё мнение
и ещё.. ни один нормальный человек не будет писать на ассемблере и тем более прямо работать с инструкциями.. что за хрень
Минус всех этих лекций в том, что видно слайд но не видно доску, препод что-то показывает, а что - непонятно.
все понятно, если понимать о чем речь идет.
Можете гордится своей понятливостью, а я указываю на недоработки, не всегда бывает что препод описывает словами куда показал.
А мне кажется вообще стоит радоваться, что CS центр выкладывает лекции. Люди готовятся и поступают туда, если им это надо=)
Поверьте, если кому-то надо заморочиться по микроконтроллерам, то только ради этого поступать не будут, CS не единственный в своём роде, хотя и очень не плох. В любом случае информацию можно получить из нескольких источников, если CS прекратит выкладывать лекции то это конечно будет печально, но не непоправимо.
И да, вопрос в качестве, отсутствие некоторых моментов в видео есть показатель качества, на который и было указано.
Шлак