Прерываемые инструкции. Сторожевые таймеры (Watchdog Timers)
В редких случаях некоторые макроинструкции должны быть прерываемыми. Это может быть случай, когда команда выполняется очень долго. Рассмотрим, например, инструкцию из памяти в память, которая перемещает большие объемы данных. В большинстве случаев, такая инструкция должна быть прерываемой, между блоками, чтобы уменьшить задержки при обработке прерываний. Однако, прерывание данной инструкции может вызвать проблемы целостности данных. В конечном итоге, это редкость, чтобы архитектура поддерживала прерываемые инструкции, ссылаясь на описанную проблему.
Таймеры наблюдения (контрольные таймеры, Watchdog Timers). Во многих компьютерных системах, ЦП и/или другие устройства оснащены регистром подсчета, который постепенно увеличивается. Далее, регистр должен быть очищен(сброшен) соответствующим кодом, используя отображенный памятью ввод-вывод, прежде, чем регистр переполнится и сгенерирует прерывание (исключение переполнения). Такой тип оборудования, называется (драйвер, устройство) таймер наблюдения ("сторожевой" таймер, контрольное реле времени, контрольный таймер). (WDT) (рис. 10.9).
Программное обеспечение посылает сигнал сброса через запрограммированный или отображаемый памятью ввод-вывод, для сброса таймера прежде, чем произойдет переполнение и сгенерируется исключение переполнения.
Таймеры наблюдения используются для обеспечения того, что определенные устройства обслуживаются равномерно (через регулярные промежутки времени) и что некоторые процессы выполняются в соответствии с их предписанием, и что ЦП продолжает функционировать. Сброс «сторожевого» таймера, часто шутливо упоминается как "поглаживание собаки" («petting the dog»).
Основы разработки встроенных систем. Типовая среда разработки с использованием кросс-платформы. Рисунок, пояснения.
Одной из характерных особенностей встроенных систем является методология кросс-платформенной разработки. Основные составляющие среды разработки: центральная система (хост-система), целевая система и разнообразные соединения между хост-системой и целевой системой, как показано на Рисунке 11.1.
Многие производители микросхем выпускают чипы со встроенной в микропроцессор схемой отладки, называемой отладкой на чипе – ОНЧ (On-Chip Debugging – OCD).
BDM (Background Debug Mode) и JTAG (Joint Test Action Group) являються двумя типами решений ОНЧ, которые позволяют осуществить прямой доступ к микропроцессору и контроль над ним и ресурсами системы без необходимости использования служб отладки на целевой системе или дорогих внутрисхемных
эмуляторов.
BDM – фоновый режим отладки. Он использует интерфейс отладки введённый компанией Motorola для своих микропроцессоров. Этот термин также указывает на подход метода отладки без кодировки (на выполняемой системе), предоставляемый решениям ОНЧ.
JTAG – объединённая группа тестирования, созданная производителями электроники для разработки нового и экономически эффективного способа тестирования. Результатом работы консорциума JTAG стал стандарт IEEE1149.1.
Основными инструментами разработки, предлагаемые хост-системой, являются кросс-компилятор, компоновщик и отладчик на уровне исходного кода. Целевая встроенная система должна предоставить динамический загрузчик, загрузчик для компоновщика, монитор, и отладчик. Между хост- и целевой системой могут присутствовать ряд соединений. Эти соединения используются для загрузки образов программ с хост-системы в целевую систему. Эти соединения также могут использоваться для передачи информации между отладчиком хост-системы и средством отладки на целевой системе.
Программы, включая системное программное обеспечение, операционную систему реального времени (ОС РВ), ядро, и код приложения должны быть разработаны в первую очередь, откомпилированы в объектный код и скомпонованы друг с другом в исполняемый образ. Программисты, пишущие приложения, выполняемые в той же среде, которая используется и для разработки, называемой «родной» разработкой, не беспокоятся о том, как исполняемый образ загружается в память и как управление на выполнение передается приложению. Разработчики же встроенных систем, использующие кросс-платформенный подход, должны понимать функционирование целевой системы, как сохранять образ программы на целевой встроенной системе, как и куда загружать образ программы при выполнении и как интерактивно, последовательно разрабатывать и отлаживать систему. Каждый из этих аспектов влияет на то, как разработан, скомпилирован и самое главное скомпонован код.