Регистрация конфигурации запуска

Перед разработкой отладчика необходимо зарегистрировать новый тип программ, которые подлежат запуску. Для этого в Eclipse используется концепция “тип конфигурации запуска”, для его описания используется интерфейс ILaunchConfiguration. Экземпляры типа конфигурации запуска, то есть собственно конфигурации запуска, содержат наборы именованных атрибутов, которые могут хранить значения данных, специфичных для данного вида запуска.

Для каждого типа конфигурации запуска существуют также разные режимы, в которых этот запуск может быть осуществлен. Платформа содержит предустановленные следующие режимы:

1) запуск на автономную работу;

2) отладка;

3) профилирование программы.

Имеется возможность как использовать существующие режимы запуска для определенных типов конфигураций, так и создавать новые. Модули, которым необходимо зарегистрировать свои типы конфигураций запусков, регистрируют класс, реализующий интерфейс ILaunchConfigurationDelegate. Этот класс знает, как запустить указанную программу по заданному типу конфигурации и режиму запуска. Как только программа оказалась запущенной, создается объект с интерфейсом ILaunch, предназначенный для представления сессии запуска. Данный объект хранит такую информацию, как запущенные процессы и задачи, информация о сессии отладки, месте исполнения в исходном коде. Объекту ILaunch также доступна информация о конфигурации, с помощью которой был произведен сам запуск (рисунок).

Рисунок 2.8 – Схема запуска пользовательской программы

Пользователь может задать свои параметры конфигурации запуска, которые могут быть сохранены в файле.

Модель отладки

Ключевым моментом создания отладчика в среде Eclipse выступает разработка его модели, интерфейсы для которой в платформе уже предопределены; их схема представлена на рисунке 2.9.

Рисунок 2.9 – Диаграмма модели интерфейсов платформы отладки Eclipse

Модель отладки, представленная на рисунке, включает всевозможные виды артефактов отладки. Все артефакты должны реализовывать интерфейс IDebugElement (в дополнением к их непосредственным интерфейсам). Модель отладки включает следующие интерфейсы для артефактов отладки, приведенные в таблице 2.4.

Таблица 2.4 – Интерфейсы подсистемы отладки

Существует два важных замечания, которые должны быть учтены при проектировании модели отладки.

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

- Действия, совершенные пользователем через графический интерфейс, например, команда “выполнить шаг отладки”, должны быть неблокирующими вызовами (асинхронными). То есть команда пользователя “выполнить шаг отладки” не должна ждать, пока шаг выполнится в виртуальной машине, в противном случае при длительном выполнении шага машиной поток графического интерфейса Eclipse может зависнуть. Корректная (неблокирующая) схема взаимодействие изображена на рисунке 2.10.

Рисунок 2.10 – Неблокирующая схема взаимодействия модели отладки и виртуальной машины

Виртуальная машина

Существует два способа исполнения пользовательской программы:

1) прямая интерпретация;

2) трансляция с отложенной интерпретацией.

Для рассматриваемой интегрированной среды разработки приемлемым является второй подход, поскольку:

1) программу на языке С невозможно разбить на независимые команды, которые можно было бы интерпретировать; во время отладки требуется исполнение всей программы;

2) процесс интерпретации может производиться много раз после единожды выполненной трансляции.

В качестве виртуальной машины, исполняющей программу, выбрана lua [46], которая исполняет программу на скомпилированном в байт-код скриптовом языке Lua. Выбор именно данной виртуальной машины обусловлен следующими соображениями:

1) виртуальная машина lua кросплатформенна: работает на Windows и UNIX-подобных операционных системах;

2) виртуальная машина высоко оптимизирована, что обеспечивает ее высокую скорость работы;

3) имеется API для использования языка Java (инструмент LuaJava [47]), который является основным языком реализации разрабатываемой системы;

4) виртуальная машина поддерживает кооперативную многопоточность пользовательских программ;

5) лицензия lua подходит как для учебного использования, так и для коммерческого.

Язык Lua является динамически типизированным языком, т. е. на этом языке тип имеют не сами переменные, а их значения, поэтому в языке отсутствуют определения типов. Для интеграции виртуальной машины lua с языком Java возможно использование библиотеки LuaJava, позволяющей скриптам на языке Lua манипулировать Java-объектами (в том числе вызывать их методы).

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

Моделирование

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

На данный момент на рынке средств моделирования микроконтроллеров существуют в основном два типа систем:

1) отдельное приложение-симулятор позволяет смоделировать работу бинарного образа программы;

2) симулятор встроен в интегрированную среду разработки.

Ключевым недостатком первого рода программ (к таким относится, например, популярный цифровой симулятор Proteus [48]) является отсутствие возможностей интегрированной среды разработки, что не позволяет отлаживать программу на исходном языке (отладка программы, скомпилированной в машинный код в таком симуляторе возможна, но не имеет большого смысла).

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

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

Не нашли, что искали? Воспользуйтесь поиском по сайту: