Интерфейсная шина CAN. Назначение, форматы передачи данных, основные технические характеристики
Интерфейс CAN (Controller Area Network – буквально сеть контроллеров) был разработан в конце 80-х годов фирмой Bosch для связи электронных устройств, применяемых в автомобилях. В то время не существовало единого стандарта для этой цели. До появления интерфейса CAN типичная электропроводка грузового автомобиля содержала около 5 км проводов весом свыше 100 кг, которая связывала различные электронные устройства. Интерфейс CAN был разработан, чтобы удовлетворить следующим требованиям:
1. Высокая скорость обмена (до 1 Мбит/с).
2. Нечувствительность к электромагнитным помехам.
3. Простота, небольшое количество разъемных контактов (для обеспечения механической надежности).
4. Легкость подключения и удаления устройств.
В настоящее время используются спецификации CAN версий 2.0А и 2.0В фирмы Bosch. Шина CAN получила международное признание, выразившееся в опубликовании стандарта ISO 11898. ISO (International Standard Organization) – международная организация по стандартизации. Сейчас интерфейс CAN широко применяется на транспорте, в промышленной автоматике, энергетике, медицине и бытовой технике. Таким образом, интерфейс CAN – это стандарт промышленной сети, ориентированный на объединение в единую сеть различных исполнительных устройств и датчиков.
Общее описание CAN. Сеть предназначена для коммуникации так называемых узлов, которые могут быть приемниками или передатчиками. Каждый узел состоит из двух составляющих: CAN-контроллера и приемопередатчика (трансивера). Контроллер реализует протокол обмена по сети CAN, а трансивер обеспечивает взаимодействие с сетью (передачу и прием сигналов).
Физическая среда в CAN может быть самой разной: витая пара, плоский кабель, оптоволокно, инфракрасные каналы, радиоканалы и даже линии электропередач. Однако на практике, согласно стандарту ISO 11989, шина CAN обычно представляет собой витую пару (экранированную или неэкранированную), по которой передаются сигналы дифференциальным методом.
На рис. 1 приведена структура CAN-сети. Обычно в качестве контроллера используется микроконтроллер, имеющий CAN-модуль, который имеет выход передатчика TxD последовательного кода и вход приемника RxD кода. Трансивер преобразует логические сигналы, то есть логические 0 и 1, в дифференциальное напряжение, поступающее на два провода шины, обозначенные CAN_H и CAN_L. Согласно стандарту линия должна иметь волновое сопротивление в пределах 108-132 Ом. Для уменьшения отражений сигналов на каждом конце шины должны быть подключены согласующие (по-другому, оконечные или терминальные) резисторы RС сопротивлением 120 Ом. Для повышения надежности передачи и повышения помехоустойчивости иногда используют третий провод – общий, обозначаемый как GND. Питающее напряжение UCC (или UDD) по стандарту равно +5 В относительно GND (или USS).
Для абстрагирования от физической среды передачи спецификация CAN определяет два логических состояния (то есть логические 0 и 1) как рецессивное (recessive) и доминантное (dominant). При этом предполагается, что при передаче одним узлом сети рецессивного бита, а другим доминантного, принят будет доминантный бит.
Стандарт ISO 11898 определяет дифференциальное напряжение UDIFF между линиями CAN_H и CAN_L для представления рецессивного и доминантного состояний на шине следующим образом.
В рецессивном состоянии (то есть логическая 1 на входе TxD трансивера) дифференциальное напряжение UDIFF =UCANH – UCANL меньше минимального порога (0,5 В на входе приемника или 0,05 В на выходе передатчика).
В доминантном состоянии (то есть логический 0 на входе TxD трансивера) дифференциальное напряжение UDIFF больше минимального порога (0,9 В на входе приемника или 1,5 В на выходе передатчика).
Максимальное число узлов, подключенных к шине CAN, фактически определяется нагрузочной способностью примененных трансиверов (теоретических ограничений нет). Например, при использовании трансивера PCA82C250 фирмы Philips оно равно 110.
Рис. 1. Структура CAN-сети
Сообщения в CAN. Интерфейс использует короткие сообщения: максимальный размер – 94 бита. В CAN-сообщении нет явного адреса. Такой тип рассылки сообщений называется «схема адресации, ориентированной на содержимое». Другими словами, содержимое данных в CAN-сообщении как бы неявно определяет адрес источника этого сообщения и адреса приемников, кому эта информация необходима. Например. один CAN-узел выдает на шину сообщение «Температура масла двигателя 80о С». Все другие узлы принимают это сообщение, но используют эту информацию только те узлы, кому она необходима.
Сообщения, передаваемые по CAN-шине, именуются кадрами или фреймами. В зависимости от инициатора передачи и ее цели существуют 4 типа кадров:
1) кадр данных (Data Frame), используется для передачи данных;
2) кадр запроса данных (Remote Frame), используется для дистанционного запроса данных от удаленного узла;
3) кадр ошибки (Error Frame), когда обнаруживаются ошибки на шине;
4) кадр перегрузки (Overload Frame), передается для задержки передачи пакетов Data Frame и Remote Frame, например, при неготовности приемника.
Каждый тип кадра используется для определенных целей. Кадры Error Frame и Overload Frame, когда это необходимо, передаются CAN-узлом автоматически. Наполнение информацией кадров Data Frame и Remote Frame осуществляет разработчик системы.
Собственно для передачи данных используется Data Frame. Он имеет поле арбитража (Arbitration Field) и информационное поле (Data Field), которое может содержать до 8 байт данных. Поле арбитража кадра включает в себя идентификатор (ID), однозначно определяющий содержание и приоритет сообщения. Стандартным форматом сообщений (CAN 2.0A) предусмотрен 11-битный идентификатор, позволяющий различать до 20348 типов сообщений. Расширенный формат (CAN 2.0B) имеет 29-битный идентификатор с теоретически возможным числом типов сообщений более 536 миллионов.
Стандартный формат сообщения Data Frame состоит из семи различных битовых полей:
· Поле начала кадра (Start of Frame – SOF) состоит из одного доминантного бита, который служит также для синхронизации генераторов приемников и передатчика.
· Поле арбитража (Arbitration Field) содержит 11-битный идентификатор ID и бит RTR – Remote Transmission Request (запрос передачи данных). Для кадра данных этот бит должен иметь доминантный уровень.
· Управляющее поле (Control Field) состоит из шести битов. Два самых старших бита в настоящее время не используются. Четырехбитный код длины данных (DLC – Data Length Code) указывает число байтов в поле данных.
· Поле данных (Data Field) содержит от нуля до восьми байтов данных.
· Поле контрольной суммы (CRC Field) включает в себя контрольную сумму сообщения (15 бит) и бит-разделитель рецессивного уровня.
· Поле подтверждения (ACK Field) состоит из двух битов. Старший бит с именем Slot выставляет передающий узел рецессивного уровня. В случае, когда передача прошла успешно, приемный узел сигнализирует об этом установкой этого бита в доминантный уровень. Второй бит в этом поле является битом-разделителем рецессивного уровня.
· Поле конца кадра (EOF – End of Frame) состоит из семи битов рецессивного уровня.
После конца кадра (EOF) следует поле промежутка (Intermission Field), состоящее из трех битов рецессивного уровня. После этого промежутка шина считается свободной. Новый цикл обмена может начаться в любой момент после промежутка Intermission Field.
Все CAN-узлы на шине синхронизируются доминантным битом поля SOF и далее восстанавливают синхронизацию в моменты перепадов битов в кадре. Для исключения потери синхронизации при передаче длинной последовательности одинаковых битов в пределах полей начала кадра, арбитража, управления, данных и контрольной суммы используется механизм бит-стаффинга – вставка дополнительного бита противоположного значения после подряд идущих пяти одинаковых, то есть последовательностей типа …00000… или …11111… При приеме производится обратная операция (дебит-стаффинг), то есть удаление дополнительного бита.
Кадр запроса данных Remote Frame также может иметь стандартный и расширенный форматы. Отличия его от кадра данных Data Frame – в отсутствии поля данных и рецессивном уровне бита RTR. При получении кадра запроса данных запрашиваемый узел отвечает передачей кадра данных.
Обнаружение и обработка ошибок. CAN протокол имеет мощные средства обнаружения ошибок. В CAN реализовано 5 механизмов проверки на наличие ошибок. Следует отметить, что все они реализованы аппаратным способом.
Ошибка контрольной суммы (CRC Error). 15-разрядное значение кода CRC рассчитывается узлом передачи во время формирования сообщения. Все узлы сети принимают это сообщение, вычисляют CRC и сравнивают его с принятым значением. При несовпадении контрольных сумм (полученных в кадре в поле CRC Field и вычисленной) сообщение считается ошибочным. Если хотя бы один узел не примет данные должным образом, будет сформировано сообщение об ошибке.
Ошибка подтверждения (Acknowledgement Error). В поле подтверждения ACK Field передающий узел проверяет наличие доминантного бита (логического 0). Если хотя бы один узел принял сообщение правильно, то доминантный бит будет сформирован в поле подтверждения. Если был получен рецессивный бит (логическая 1), значит ни одно устройство не приняло сообщение, и передающий узел регистрирует ошибку подтверждения.
Ошибка формата (Form Error). Все CAN узлы проверяют соответствие структуры принимаемого сообщения его фиксированному формату и его размеру. Если формат сообщения нарушен, то узлы генерируют ошибку формата.
Ошибка бита (Bit Error). Каждый узел во время передачи битов в сеть сравнивает значение передаваемого им бита со значением бита, которое появляется на шине. Если эти значения не совпадают, то узел генерирует ошибку бита. Естественно, что во время арбитража на шине (передачи идентификатора в шину) этот механизм проверки ошибок отключается.
Ошибка бит-стаффинга (Stuff Error). При передаче сообщения в CAN работает механизм бит-стаффинга – вставка дополнительного бита после пяти подряд идущих бит с одинаковым значением. Принимающий узел этот дополнительный бит удаляет. Если приемник обнаруживает на шине больше 5 последовательных бит с одинаковым значением, то он генерирует ошибку бит-стаффинга.
Каждый узел сети CAN во время работы пытается обнаружить одну из пяти возможных ошибок. Если ошибка обнаружена, узел передает в сеть фрейм ошибки Error Frame, разрушая тем самым весь текущий трафик сети (передачу и прием текущего сообщения). При этом передатчик, сообщение которого прервано, автоматически должен повторить передачу своего сообщения.
Скорость передачи и длина сети. Спецификация CAN исходит из предположения, что все узлы принимают сигналы с шины одновременно, то есть в одно и то же время один и тот же бит принимается всеми узлами в сети. С одной стороны такое положение вещей делает возможным побитовый арбитраж, а с другой стороны ограничивает длину сети. Каждый узел, вовлеченный в арбитраж, должен быть способен осуществлять выборку каждого бита в пределах одного и того же интервала передачи бита. Обычно выборка производится примерно в середине интервала передачи бита. При передаче и приеме сигналов по шине неизбежно появляется задержка распространения tDEL, которая определяется как сумма времени прохождения сигнала по шине tBUS, выходной задержки передатчика tTRANSM и входной задержки приемника tRECEIVE. Очевидно, что с увеличением скорости передачи интервал передачи бита сокращается, а это может привести к ошибочной выборке действительного значения бита из-за влияния задержки распространения.
Стандарт ISO 11898 определяет, что при максимальной скорости передачи 1 Мбит/с длина кабеля шины CAN не должна превышать 40 метров. При использовании гальванической развязки максимальная протяженность сети при скорости передачи 1 Мбит/с ограничена 9 метрами.
В документах промышленной CAN-группы CiA (CAN in Automation) приведены следующие практическим путем полученные соотношения «скорость – протяженность» для проводной сети без гальванической развязки:
1000 кбит/с - 30 м
500 кбит/с - 100 м
……………………………………….
50 кбит/с - 1000 м
10 кбит/с - 5000 м
5 кбит/с - 10000 м
Достоинства интерфейса CAN:
· возможность работы в режиме жесткого реального времени;
· простота реализации и минимальные затраты на использование;
· высокая устойчивость к помехам;
· надежный контроль ошибок передачи и приема;
· широкий диапазон скоростей работы;
· большое распространение технологии, наличие широкого ассортимента продукции от различных поставщиков.
Недостатки:
· максимальная длина сети обратно пропорциональна скорости передачи;
· большой размер служебных данных в пакете (по отношению к полезным данным);
· отсутствие единого общепринятого стандарта на протокол высокого уровня.
Общие принципы и основные этапы разработки микроконтроллерных систем. Разработка и отладка аппаратных средств и программного обеспечения. Методы совместной отладки аппаратных и программных средств
Микропроцессорные системы можно условно разделить на два основных класса: универсальные, которые используются для решения широкого круга задач обработки информации, и управляющие, которые специализируются на решение задач управления различными процессами и объектами. Типичным примером универсальных МПС являются персональные компьютеры, которые применяются в самых различных сферах деятельности. Управляющие МПС в настоящее время выпускаются, в основном, на основе микроконтроллеров, что позволяет значительно упростить и удешевить такие системы. В технической литературе их обычно именуют микроконтроллерными системами (МКС).
Основные этапы разработки микроконтроллерных систем
Общая процедура разработки МКС включает этапы, показанные на рис.1. Процесс разработки МКС содержит ряд специфических этапов, обусловленных наличием в системе как аппаратных, так и программных средств.
Начальным этапом разработки МКС является составление технического задания. Техническое задание (ТЗ) состоит из набора требований, которые должна выполнять проектируемая МКС. На этом этапе из общей задачи, часто поставленной абстрактно и независимо от техники ее реализации, формируются конкретные четкие технические требования к МКС и выполняемые функции на основе принятых для технического описания терминов и определений параметров, характеристик и режимов работы.
Следующий этап – разработка архитектуры МКС подразумевает определение оптимального состава аппаратных и программных средств для решения поставленной задачи. При этом разработчик решает, какие функции системы будут реализованы аппаратными средствами (АС), а какие – программным обеспечением (ПО). Определяется номенклатура АС: выбирается тип микроконтроллера, объем и тип памяти, номенклатура периферийных устройств, протоколы обмена информацией и состав требуемых сигналов управления системой. Определяется также состав ПО: номенклатура необходимых программных модулей, характер их взаимодействия, используемый язык программирования. Результатом выполнения этого этапа являются частные технические задания на проектирование АС и ПО.
Дальнейшая разработка МКС может производиться раздельно и параллельно для аппаратных и программных средств (программного обеспечения ПО). Методы, применяемые при их разработке, будут рассмотрены далее.
Далее следует этап комплексной отладки аппаратных средств и программного обеспечения МКС. Хотя аппаратные и программные средства в отдельности проходят этапы, которые тоже называются отладкой, комплексная, являющаяся наиболее сложным этапом, осуществляется при непосредственном взаимодействии и взаимосвязи программных и аппаратных средств, т.е. рабочей программы и прототипа аппаратуры МКС. Основной задачей на этом этапе является объединение или, по-другому, интегрирование аппаратных и программных средств МКС. Наличие неизбежных ошибок в программе и необходимость экспериментальной обработки взаимодействия программы с реальным объектом в реальном времени требует применения специальных методов и средств отладки. На этапе комплексной отладки обычно используются лабораторные источники питания. Часть внешних источников сигналов может моделироваться.
После выполнения этапа комплексной отладки аппаратных и программных средств отлаженная программа заносится с помощью программатора в энергонезависимую память МК, и прототипная МКС может быть испытана в рабочих условиях с подключением полного набора внешних устройств (датчиков сигналов, объектов управления, пульта оператора для управления и контроля), а также питания от штатного источника. В процессе опытной эксплуатации в рабочих условиях выявляются ошибки, не обнаруженные на этапе отладки, определяется реакция системы на возможные непредвиденные ситуации.
Рис. 1. Основные этапы разработки микроконтроллерной системы
Если после испытания МКС в рабочих условиях она выполняет все необходимые функции, обеспечивает все характеристики и требования, предъявляемые к ней в техническом задании (ТЗ), то производится окончательная разработка технической документации на аппаратные средства и программное обеспечение. Далее изготавливаются опытные образцы МКС, которые сдаются в эксплуатацию, а затем и в серийное производство.
Разработка и автономная отладка аппаратных средств МКС
Этап разработки аппаратных средств (АС) может быть выполнен традиционными методами, с помощью которых проектируется и моделируется электрическая схема, разрабатывается печатная плата или несколько плат, после чего выполняется монтаж и отладка макета. Однако во многих случаях можно обеспечить значительное сокращение сроков и повышение качества разработки АС путем использования «полуфабрикатов» или готовых изделий, выпускаемых рядом производителей. Этот класс средств разработки получил название плат развития. Условно их можно разделить на следующие типы: системные комплекты – наборы размещенных на плате аппаратных средств, достаточных для реализации несложных устройств; отладочные платы и системы; целевые платы – программно-аппаратные комплексы, ориентированные на использование после отладки в качестве прототипной МКС.
Эти средства могут использоваться для следующих целей: тестирование и отладка программного обеспечения устройств на основе реальных образцов микроконтроллеров; комплексная отладка макета МКС, используемого затем в качестве образца для реализации прототипной системы; сборка и отладка прототипной или целевой МКС, в состав которого входят платы развития в качестве базовых модулей.
Практически все типы плат развития содержат в своем составе порты для подключения управляющего персонального компьютера. Ряд типов отладочных и целевых плат имеют также отдельное поле для макетирования пользователем дополнительных устройств с помощью проводного монтажа.
Если состав средств, имеющихся на плате развития, достаточен для реализации проектируемой МКС, то ее разработка сводится к созданию программного обеспечения и выполнению комплексной отладки МКС. Если имеющихся средств недостаточно, то они проектируются и размещаются на дополнительной плате, подключаемой к разъему на плате развития с помощью кабеля. Так реализуется прототип разрабатываемой МКС, на котором можно выполнить комплексную отладку программных и аппаратных средств, а в ряде случаев и провести проверку функционирования в рабочих условиях. После этого нетрудно разработать рабочий вариант МКС, объединив на одной плате используемые модули прототипной системы.
На этапе автономной отладки АС основными инструментами разработчика являются традиционные измерительные приборы – мультиметры, логические пробники, осциллографы, а также логические анализаторы, которые обладают широкими возможностями контроля состояния различных узлов МКС в заданные моменты времени.
Разработка и отладка программного обеспечения
Этап разработки программного обеспечения (ПО) для МКС является очень ответственным и трудоемким. По некоторым данным затраты на разработку ПО в 3-10 раз превышают затраты на приобретение и изготовление аппаратных средств.
При программировании МКС чаще всего используются язык Ассемблер или язык Си. Машинно-ориентированный (низкого уровня) язык Ассемблер применяется в случаях, когда имеются жесткие ограничения на объем требуемой памяти или на время выполнения программных модулей. Такие случаи являются достаточно типичными для МКС, поэтому Ассемблеры являются одним из основных средств создания ПО для МКС. В тех случаях, когда указанные ограничения не очень жесткие, для создания ПО используются языки высокого уровня (обычно Си).
В процессе разработки и отладки ПО используют следующие программные средства: ассемблеры, компиляторы; симуляторы.
Симуляторы (Simulators) – это программно-логические модели микроконтроллеров, используемые при отладке программ. Обычно они входят в состав отладчиков.
Отладчики (Debuggers) являются основным инструментом разработчика ПО, без которого практически невозможно получит работоспособные объектные модули рабочей программы. Отладчик реализует различные режимы выполнения транслируемой программы, позволяет производить просмотр и коррекцию регистров и ячеек памяти и т.д. В настоящее время все эти программные средства обычно используются совместно в составе интегрированной среды (оболочки) разработки IDE (Integrated Development Environment). Примером может служить интегрированная среда разработки MPLAB IDE, выпускаемой фирмой Microchip. Она имеет в своем составе менеджер проектов, текстовый редактор, ассемблер и симулятор, допускает подключение компиляторов языков высокого уровня типа Паскаль или Си.
Методы и средства совместной отладки аппаратных и программных средств
Этап совместной отладки аппаратных и программ в реальном масштабе времени является самым трудоемким и требует использования инструментальных средств отладки. В настоящее время такими средствами являются:
· внутрисхемные эмуляторы;
· внутрисхемные отладчики;
· отладочные мониторы;
· платы развития;
· эмуляторы ПЗУ;
· JTAG-эмуляторы.
Внутрисхемный эмулятор (ВСЭ) – это программно-аппаратное средство, способное заменить эмулируемый (отлаживаемый) МК в разрабатываемой МКС. Это наиболее мощное и универсальное отладочное средство, работающее под управлением персонального компьютера, упрощает очень трудоемкий процесс отладки и делает его удобным и наглядным для разработчика.
Стыковка ВСЭ с МКС производится при помощи кабеля со специальной эмуляционной головкой, которая вставляется вместо МК в отлаживаемую систему. Основа ВСЭ – это эмуляционная микросхема от фирмы-производителя микроконтроллеров. Она представляет собой такой же МК, для отладки которого используется, но имеет дополнительные возможности, а главное, выводы для доступа к внутренней памяти, периферийным модулям и служебным регистрам. Кроме эмуляционной микросхемы в состав ВСЭ входят интерфейс связи с персональным компьютером, память для хранения отлаживаемой программы, отладочной информации и точек останова. Также необходимо ПО для персонального компьютера, под управлением которого работает ВСЭ.
Достоинства ВСЭ очевидны – это быстрый и легкий доступ ко всем внутренним ресурсам эмулируемого МК, высокая скорость обновления отлаживаемой программы, поскольку она записывается не в программную память МК, а в ОЗУ, которое подменяет память программ.
Но у ВСЭ также есть и ряд недостатков: большая сложность и стоимость; ВСЭ не может использоваться в качестве внутрисхемного программатора для микроконтроллеров.
Внутрисхемный отладчик (In-Circuit Debugger – ICD), так же как и эмулятор, служит для внутрисхемной отладки МКУ, но принцип работы у него иной. Отладка осуществляется на штатном серийном микроконтроллере, при этом отлаживаемая программа записывается во Flash-память МК. Для того, чтобы функционировал режим внутрисхемной отладки, в серийные образцы микроконтроллеров встраивают специальный отладочный механизм. Для отладки этот механизм включается, а при обычной работе микроконтроллера в составе МКС он выключается с помощью конфигурационного слова МК.
Отладочный монитор – это специальная программа, загружаемая в память отлаживаемой МКС. Она вынуждает МК выполнять кроме основной программы управления еще и отладочные функции: загрузку кодов программы пользователя в свободную от монитора память; установку точек останова; запуск и останов загруженной программы в реальном времени; проход программы пользователя по шагам; просмотр, редактирование содержимого памяти и управляющих регистров.
Достоинством этого подхода являются очень малые дополнительные затраты при сохранении возможности вести отладку в реальном времени. Кроме того, отладочные мониторы используют тот же МК, который входит в состав разрабатываемой МКС.
Главным недостатком является отвлечение ресурсов МК на отладочные и связные с компьютером функции: монитор занимает некоторый объем памяти, задействованы прерывания, последовательный порт, часто и таймер.
Платы развития являются своеобразными конструкторами для макетирования МКС. Их очень удобно использовать для разработки и отладки аппаратных средств МКС. Однако их также можно использовать и для совместной отладки аппаратных и программных средств разрабатываемых МКС.
Возможности по отладке, предоставляемые комплектом «плата развития плюс монитор», безусловно, не столь универсальны, как возможности внутрисхемного эмулятора. Кроме того, некоторая часть ресурсов МК в процессе отладки отбирается для работы монитора. Тем не менее, наличие готового набора программно-аппаратных средств, позволяющих без потери времени приступить к монтажу и отладке МКС, во многих случаях являются решающим фактором. Особенно если учесть, что стоимость такого комплекта намного меньше, чем стоимость внутрисхемного эмулятора.
Эмуляторы ПЗУ используются при отладке МКС, рабочая программа которых размещается во внешнем ПЗУ. Эмулятор ПЗУ содержит ОЗУ, которое подключается к МК вместо штатного ПЗУ и работает под управлением присоединенного к эмулятору внешнего компьютера. Это устройство позволяет пользователю избежать многократных циклов перепрограммирования ПЗУ в процессе отладки ПО.
Таким образом, эмуляторы ПЗУ могут выполнить значительную часть функций внутрисхемных эмуляторов. При этом их реализация оказывается намного проще и дешевле, так как они не эмулируют сам МК, который в процессе отладки продолжает работать в составе МКС. Однако, основной недостаток эмулятора ПЗУ – возможность использования только для МК, которые могут обращаться к внешней памяти программ, сильно сужает их область применения.
JTAG-эмуляторы. JTAG – это стандартный интерфейс, применяемый для тестирования электронных компонентов и устройств. Исторически он появился как название специальной группы разработчиков, созданной по инициативе фирмы Texas Instruments для выработки стандарта на производство тестопригодных БИС (Joint Test Action Group – JTAG).
JTAG-интерфейс оказался прекрасным инструментом не только для задач тестирования БИС, но и для решения широкого круга других задач. В частности, возможности JTAG-интерфейса позволили применить его для внутрисхемного программирования и отладки микроконтроллеров, что используется в изделиях ряда производителей электронных компонентов. Отлаживаемый МК и эмулятор соединяются через интерфейс JTAG посредством специально выделенных на МК выводах. Такое подключение дает возможность отлаживать МКС в той конфигурации и с тем МК, с которым она будет работать. Это снимает как вопросы быстродействия эмулятора, так и вопросы изменения электрических параметров при его подключении. JTAG-эмулятор не оказывает на работу программы никакого влияния. Она выполняется на полной скорости работы МК без каких-либо задержек и ограничений. При использовании технологии JTAG происходит переход от эмуляции МК внешним компьютером к непосредственному контролю над ним при выполнении программы. JTAG-эмулятор может не только контролировать и управлять процессорным ядром МК, но для него доступны также периферийные модули и память, причем независимо от того, размещены они на кристалле МК или вне его.
JTAG-эмуляторы являются очень эффективными, удобными и мощными средствами отладки МКУ, однако они могут применяться только в том случае, если МК имеет встроенный JTAG-интерфейс.