Программные продукты и системы

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

Целью появления Bluetooth было создание дешевого протокола беспроводного обмена данными, поддерживаемого маломощными передатчиками и доступного по всему миру. Эти протоколы обеспечивают надежную передачу данных и речи в радиусе примерно 10 метров.

Максимально допустимая скорость обмена между двумя BT-устройствами составляет 721 Кбит/с, или три речевых канала. Bluetooth обеспечивает как соединение точка-точка, так и режим сетевого обмена. В одной BT-сети может одновременно находиться до 8 активных узлов и до 256 неактивных. Возможно взаимодействие между BT-сетями, когда одно устройство является элементом двух сетей.

Существуют два вида BT-каналов:

-         асинхронный (ACL) – нет резервирования слотов времени, в любой момент master может начать обмен с любым из slaves и в любой последовательности;

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

На нижнем уровне стека протоколов Bluetooth находятся так называемые базовые протоколы, над которыми располагаются «адаптированные». Поскольку BT является открытым стандартом, различные производители могут реализовывать свои собственные или общие пользовательские протоколы.

Общий подход к отладке Bluetooth-подсистем

С точки зрения отладки большинство компонентов Bluetooth представляют собой черные ящики, их внутренняя организация либо полностью недоступна для изучения, либо ее исследование сопряжено с неоправданными затратами ресурсов. Достаточно прозрачными являются прикладные интерфейсы, поскольку они разрабатываются для конкретного приложения или группы приложений, а также аппаратно-зависимый драйвер внешнего канала, соединяющего CPU и микросхему BT.

Стек протоколов и логика работы самого чипа обычно скрыты от разработчика, производящего отладку. К сожалению, в отличие от большинства других протоколов, BT практически недоступен для мониторинга на уровне конечного выхода. Если при проводном соединении отслеживание потока данных является тривиальной задачей, то “прослушивание” радиоканала с динамическим выбором частоты требует специального оборудования, которым не всегда обладают даже крупные компании.

Начальная стадия отладки: сбор информации об ошибках

Традиционными методами сбора информации об ошибках являются: ведение различных протоколов, анализ данных отладочной печати, а также получение представления о маршрутах выполнения программы при ее запуске под отладчиком. В случае встроенных приложений, использующих BT, эффективность последнего метода оказывается весьма невысокой. Необходимость достаточно точно выдерживать временные интервалы между системными событиями, обилие возможных маршрутов и наличие помех в канале часто делают использование отладчика нецелесообразным. Альтернативные способы получения информации о программе обычно оказываются более надежными и эффективными.

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

BT-стек может изменять порядок прохождения данных и влиять на временные характеристики обмена. Иными словами, вызов функций прикладного интерфейса в некотором порядке не может гарантировать, что соответствующие BT-пакеты будут сформированы и переданы во внешний канал в том же порядке. Тем более, нельзя быть уверенным в том, что в том же порядке будут получены ответы от микросхемы BT. Последняя проблема решается включением в протокол идентификаторов каждого пакета, что в соответствии с [1] реализуется в стеке протоколов.

Отдельный вопрос, какие именно события необходимо протоколировать. Естественно, для детального анализа ошибочной ситуации полезно иметь максимум возможной информации о поведении системы. Однако протокол, содержащий слишком большой объем избыточных данных, становится очень трудно читаемым. Его сложно фильтровать – отделять события, имеющие отношение к исследуемой проблеме, от посторонних данных.

Проблема чрезмерного объема получаемой информации решается двумя способами.

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

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

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

2. Фильтрация данных в отлаживаемом приложении. Этот метод позволяет избавиться от избыточной информации до того, как она покинет целевую систему. Реализуется вспомогательным программным модулем, через который выводятся отладочные данные. При этом осуществляется отбор сообщений по заранее настроенным критериям, а вывод части данных блокируется.

Отладка драйвера внешнего канала

Теоретически отладка драйвера внешнего канала не имеет прямого отношения к BT-системам, поскольку для соединения CPU с BT-чипом обычно используется многофункциональный интерфейс, такой как UART или SPI. Детальное модульное тестирование этого канала должно служить гарантией отсутствия проблем при соединении с микросхемой Bluetooth.

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

Общего метода отладки драйвера внешнего канала не существует. Можно предложить ряд рекомендаций, призванных упростить этот процесс.

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

2. Анализ отношений событий. Большое значение имеет оперативное соотнесение переданных пакетов с соответствующими ответами и квитанциями. Это позволяет эффективно выявлять случаи потери или повреждения пакетов на линии, а также дает определенное представление о структуре потока BT-данных. Анализ отношений событий особенно важен в случае стохастических, трудновоспроизводимых ошибок, поскольку формирует структурированное описание контекста ошибочной ситуации.

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

Особенно важно поведение буферов непосредственно вблизи момента возникновения ошибки. Их постепенная и равномерная загрузка вплоть до переполнения является признаком того, что канал «заткнут» в результате аппаратной (а чаще программной) ошибки при приеме/передаче данных. Если буфер стабильно загружен, следует обратить внимание на производительность BT-стека: она может оказаться недостаточной при чтении данных или избыточной при их записи. Возможным способом решения данной проблемы является коррекция приоритетов входящих в реализацию стека задач относительно других процессов в системе. Другие подходы требуют вмешательства в код самих протоколов.

Не следует пытаться решать проблему переполнения буферов только путем увеличения их размера. Если буфер переполнен, проблема, возможно, кроется в модулях, обращающихся к BT-стеку.

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

Отладка внешних интерфейсов

Иногда между реализацией BT-стека и приложением организуется еще один уровень модулей. Это делается для организации удобного прикладного интерфейса, сокрытия специфики реализации нижнего уровня, для расширения возможностей, предоставляемых пользователю. Модули включают в себя обработку неких стандартно обрабатываемых событий, для которых можно исключить влияние пользователя, что позволяет уменьшить вероятность внесения дополнительных ошибок на этапе интеграции BT в прикладную систему. Число событий, информацию о которых получает приложение, можно свести к необходимому минимуму. Другой причиной появления дополнительного уровня модулей может служить необходимость обеспечения многопользовательского доступа к интерфейсам BT-стека. Таким образом, реализация BT-подсистемы может состоять из двух уровней: собственно BT-стека и дополнительных интерфейсных модулей.

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

Переход на целевую платформу обычно приводит к появлению целого ряда новых проблем, и не следует рассчитывать, что код, успешно отлаженный на ПК, начнет безошибочно работать в составе приложения. Нелегко найти правильный момент для этого перехода. С одной стороны, необходимо учитывать, что каждый цикл компиляции, сборки и запуска системы будет занимать на порядок больше времени, чем на ПК, и что отладочный стенд обычно является ресурсом, разделяемым большой командой программистов. Однако, с другой стороны, приложение должно работать не на ПК, а на целевой платформе. Поэтому часто при нахождении проблем имеет смысл воспроизвести ошибку на ПК. Если это получилось, можно сосредоточиться на отладке интерфейсов «усеченной» системы и лишь впоследствии вернуться к тестированию на целевом оборудовании. В противном случае, велика вероятность того, что встретившаяся ошибка носит индуцированный характер.

Отладка индуцированных ошибок

Индуцированные, или наведенные ошибки – еще одна категория проблем, возникающих при отладке Bluetooth-приложений. К ней относятся ошибки, возникающие в других частях приложения при внедрении BT-подсистемы. Эти проблемы достаточно трудно идентифицировать, поскольку они имеют разную природу и характер проявления. Кроме того, возникновение сбоев в подобных случаях сильно зависит от случайных факторов, например, физических адресов программных модулей, назначаемых при связывании компоновщиком. В результате проблема может оставаться латентной в течение длительного времени и проявляться без видимых причин в достаточно неожиданных ситуациях.

Большинство индуцированных ошибок можно отнести к одной из следующих групп.

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

·         Переполнение стеков задач. Проблема переполнения стеков в многозадачных приложениях для встроенных систем общеизвестна. Множество модулей используют синхронные интерфейсы, и их функции выполняются в рамках стека вызывающего процесса, на что последний, как правило, не рассчитан. Для BT типичным примером модуля, использующего синхронный интерфейс, является драйвер внешнего канала.

·         Перегрузка процессора. BT-подсистема достаточно критична к процессорному времени – ответ от удаленного BT-устройства должен быть получен в пределах определенного временного интервала, а после некоторого числа переповторов BT-соединение разрывается. Кроме того, потребляемые ресурсы сильно зависят от потока данных, имеющего нерегулярный характер.

Наилучший способ избежать большинства индуцированных ошибок – четкое соблюдение процедур интеграции BT-подсистемы. Целесообразно придерживаться ряда простых правил, сильно упрощающих локализацию наведенных проблем.

1.       Интеграцию BT-модулей следует производить отдельно от других частей приложения.

2.       По окончании процесса интеграции необходим полный цикл тестирования BT.

3.       При обнаружении ошибок следует убедиться, что они отсутствовали в предыдущей версии BT-подсистемы.

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

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

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

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

Обобщенные рекомендации по отладке

Начинать интеграцию подсистемы Bluetooth имеет смысл лишь после подробного тестирования остальной части приложения. Разработчики, осуществляющие интеграцию и отладку BT-подсистемы должны обладать базовыми знаниями реализации стека протоколов, а также имеющихся в ней проблем и ошибок. Значительную помощь может оказать взаимодействие  (если это возможно) с командой программистов, реализовывавшей BT-стек.

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

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

Список литературы

1.        Specification of the Bluetooth System. Core. Version 1.1. February 2001.

2.        Specification of the Bluetooth System. Profiles. Version 1.1. February 2001.