Antamur - dead reckoning

jst пишет:

цитата:

Полезная статейка со ссылками на SDK: http://habrahabr.ru/post/125214/

Сохраню-ка пока не совсем не испортилась. ~~Жаль картинок уже нет~~ Картинки работают!
Скрытый текст

Модуль Bluetooth HC-04 на чипе BC417143B компании CSR

DIY или Сделай Сам

Компания CSR (Cambridge Silicon Radio) выпускает специальные чипы для устройств BlueTooth. Чипы судя по всему довольно недорогие, потому что господа китайцы предлагают миниатюрные (размером несколько больше симкарты) платки Bluetooth HC-04 на основе чипа BC417143B (семейство BlueCore4, см. [1]), которые в России можно купить всего лишь за 6.6 доллара (через dealextreme.com, см. [2] и [3]).

По умолчанию в память FLASH платки HC-04 записано ПО, которое позволяет связать по радио Bluetooth любой наладонник (или телефон, ноутбук и т. п.) со встраиваемой системой на основе микроконтроллера (робот, плата Arduino, любое устройство на микроконтроллере, имеющее TTL-порт UART RS-232). С помощью пакета CSR CASIRA BLUELAB SDK (в котором есть рабочие примеры программ Bluetooth) можно самому перепрограммировать модуль HC-04 и создавать свои собственные устройства Bluetooth. Программатор и полноценный аппаратный отладчик для модуля можно легко сделать самому, подключается к компьютеру он через порт LPT (см. [4]). В предлагаемой статье краткое описание инструментария разработки для чипов семейства BlueCore компании CSR, которое можно использовать для быстрого начала написания своих программ для модуля HC-04.

Подробно описывать технические характеристики модуля HC-04 не буду, так как все можно узнать по ссылкам с сайта dealextreme [2]. Напишу только о самом интересном. На борту у модуля стоит чип памяти на 1 мегабайт. Там записано управляющее firmware и все настройки (подробнее далее). На внешние 34 контакта модуля выведены:
— аппаратный UART, сигналы TXD, RXD, CTS и RTS.
— последовательный порт PCM (для цифрового ввода/вывода звука).
— два аналоговых входа/выхода AIO.
— ножка сброса RESET (её можно никуда не подключать).
— вход напряжения питания +3.3 вольта, ток потребления максимум 35 мА.
— интерфейс USB.
— интерфейс SPI, через который прошивается firmware и происходит отладка.
— 12 цифровых порта ввода/вывода PIO.

После подачи питания на модуль (3.3 вольта, максимум 35 мА) его можно обнаружить как беспроводное Bluetooth-устройство с профилем последовательного COM-порта. Т. е. на вашем наладоннике (телефоне, ноутбуке и проч.) появится последовательный порт, через который можно напрямую обмениваться данными через TTL-сигналы TX и RX стандартного порта RS-232. Firmware HC-04 позволяет AT-командами менять скорость передачи данных в широких пределах (от 1200 до 1382400 бод), причем изменения настройки скорости энергонезависимы, и сохраняются между выключениями питания. Таким образом, благодаря своим малым размерам и низкой цене (в России можно купить за $6.6) модуль HC-04 уже интересен как удобное готовое устройство для беспроводной связи.

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

Инструментарий для разработки

Программатор придется делать самому, так как в России его купить невозможно, никто не продает. Радостно, что схема совсем простая, нет проблем собрать самому. Программатор представляет собой простейший интерфейс LPT SPI.

Через этот нехитрый программатор можно слить всю память FLASH модуля HC-04 в двоичные файлы (с помощью утилиты BlueFlash), посмотреть и отредактировать настройки модуля и программы (с помощью утилиты PSTool). Писать программы firmware и отлаживать (с помощью того же LPT SPI) можно в среде разработки xIDE. Имеются многочисленные примеры исходного кода различных устройств Bluetooth, необходимая документация на английском языке. Все эти возможности открываются на операционной системе Windows, если установить CSR CASIRA BLUELAB SDK (инсталляционный пакет занимает примерно 55 мегабайт, после установки занимает 310 мегабайт).

Примеры позволяют создавать устройства Bluetooth роли A (что-то типа мастера Bluetooth, которые сами находят устройства Bluetooth и подключаются к ним. Устройство роли A найти поиском беспроводных устройств невозможно) и роли B (slave устройства Bluetooth, которые можно найти поиском беспроводных устройств). С помощью примеров из CSR CASIRA BLUELAB SDK можно организовать обмен данными между двумя модулями HC-04, в этом случае одно должно реализовать роль A, а другое роль B (штатное firmware, которое записано в HC-04 на заводе, этого делать не позволяет, в нем реализована только роль B).

Хранилище настроек, Persistent Store

В память модуля HC-04 вместе с firmware записано множество различных параметров (такие, как адрес Bluetooth, имя устройства, выходная мощность передатчика и проч.), так называемых ключей. Это не просто особенность именно модуля HC-04, так принято в архитектуре BlueCore при программировании приложений. Все ключи могут быть просмотрены утилитой PSTool, при необходимости изменены (если Вы, конечно, понимаете, что делаете) и сохранены в файл *.psr, имеющий удобный текстовый формат. Дамп ключей делается довольно долго (у меня процесс занимал около 2 минут), при этом работа firmware не останавливается. Все ключи, хранящиеся в чипе, разделены по уровням хранения. Уровни привязаны к месту хранения настроек (FLASH, RAM, ROM), а также по времени создания (Implementation, Factory). Ключи каких уровней отображать, выбирают в меню Store (All (TIFR), Implementation Only (I), ROM Only ®, RAM Only (T), Factory Only (F), Not RAM (IFR)). Если один и тот же ключ одновременно определен на разных уровнях и с разными значениями, и выбрано показывать все уровни (All (TIFR)), то будет показано значение ключа, сохраненного на самом верхнем уровне. Значения ключей по умолчанию сохранены в ROM, самый низкий уровень. Ключи времени выполнения сохраняются на самом высоком уровне, Transient (RAM). Несколько уровней сразу обозначаются аббревиатурами из первых букв уровней, например IFR, TIFR. Подробнее об уровнях Persistent Store написано в документе blab-ug-008Pb_PSTool_User_Guide.pdf.

Библиотеки BlueCore и SDK компании CSR

В проектах примеров xIDE все тонкости скрыты далеко от глаз пользователя в библиотеках. Библиотеки делятся на 3 класса:
• Foundation Libraries
• Support Libraries
• Profile Libraries
Foundation Libraries — основной функционал, низкоуровневая работа с аппаратурой. Поставляется только в бинарном виде, без исходного кода. Заголовочный файл для использования функций Foundation библиотеки — csr.h.

Support Libraries — обеспечивают поддержку соединений (RFCOMM, L2CAP и SCO). Заголовочные файлы, и файлы исходного кода находятся в папке C:\BlueLab\src\lib.

Profile Libraries — относятся к профилям BlueTooth. Профили – это что-то типа предназначения устройства Bluetooth (например, последовательный порт, аудиоустройство, источник и приемник файлов, интерфейс USB и т. д.). Заголовочные файлы, и файлы исходного кода находятся в папке C:\BlueLab\src\lib.

В чипе BlueCore имеется много разных интерфейсов, источников и приемников данных (Kalimba, PCM, SCO, RFCOMM, L2CAP, UART, Host, USB, HID, Region, File, Audio Notes), которые с помощью библиотек могут достаточно просто соединяться друг стругом и обмениваться данными через потоки (streams). Некоторые источники и приемники данных (Kalimba) относятся к ядрам BlueCore, имеющим на борту DSP. Чип BC417143B, установленный на платке HC-04, относится к семейству BlueCore4 и DSP у него нет. Подробности см. в документе CS-110275-UGP1_Implementing_Streams_in_BlueLab.pdf.

Для того, чтобы начать использовать библиотеку, нужно подключить директивой #include нужный .h файл и добавить в настройки проекта имя нужной библиотеки Project Properties -> Configuration Properties -> Build System -> Libraries — в поле ввода через запятую указаны имена нужных библиотек (без расширения файла). Библитеки можно пересобрать (процесс довольно долгий!) путем запуска ярлычков BlueLab 41 -> Rebuild -> VM libraries и DSP libraries.

Краткое описание xIDE и простейшего приложения

Проекты устройств BlueTooth, которые может найти хост через поиск, имеют суффикс _b (например spp_dev_b). Проекты, которые сами работают как хост, т. е. могут подключить к себе другие устройства BlueTooth, имеют суффикс _a (например spp_dev_a). Устройства с суффиксом _a нельзя найти хостом через поиск BlueTooth устройств.

Чтобы запустить проект через xIDE, нужно зайти в папку проекта (все проекты демонстрационных примеров находятся в папке C:\BlueLab41\apps\examples) и двойным щелчком запустить файл *.xiw (здесь хранятся настройки Workspace, настройки проекта хранятся в файле *.xip). Автоматически запустится среда разработки xIDE, в которой можно просматривать исходный код проекта и запустить код на компиляцию и отладку. При запуске отладки через LPT SPI автоматически считывается тип чипа, и проект компилируется под него. После компиляции программа автоматически заливается во внешнюю FLASH-память, подключенную к процессору CSR (напомню, что для модулей BlueTooth HC-04 это процессор BC417143B-IQN-E4 (BlueCore4-External device)), и программа запускается на выполнение. После останова отладки, если выключить и снова включить питание, то чип окажется перезаписанным новой скомпилированной программой, которая запустится и начнет работу. Грузится обычный проект а память чипа около минуты (а что Вы хотели от порта LPT?).

Можно самому с нуля написать для HC-04 простейшее приложение, мигающее светодиодом. Для этого нужно запустить xIDE, выбрать Project -> New..., указать тип проекта Bluelab –> Blank VM Project, ввести любое имя проекта (например MyFirstBluelab), выбрать папку для месторасположения проекта (все сделано по аналогии, как в Visual Studio) и нажать OK. Затем нужно создать файл модуля main.c, и ввести туда текст:

#include <message.h>
#include <pio.h>

#define LED_1 (1<<1)

typedef struct
{
TaskData task;
uint16 change;
} ToggleTask;

static void MyHandler (Task t, MessageId id, Message payload)
{
uint16 change = ((ToggleTask *) t)-> change;
PioSet(change, PioGet() ^ change);
MessageSendLater (t, 0, 0, 500);
}

static ToggleTask toggle = { { MyHandler }, LED_1 };

int main (void)
{
PioSetDir (LED_1, ~0);
MessageSend(&toggle.task, 0, 0);
MessageLoop();
return 0;
}
Коротко описание листинга (подробности см. в файле CS-110344-UGP2_WritingBlueCoreApplication.pdf):
— в блоке include подключаются заголовки для поддержки сообщений и портов ввода/вывода.
— оператор define задает ножку светодиода, которой будем управлять.
— структура ToggleTask задает тип для хранилища данных задачи приложения toggle.
— подпрограмма MyHandler – обработчик сообщения, который выполняет управление светодиодом. Алгоритм очень простой. Из переданной структуры задачи t считывается значение параметра change. Там находится маска светодиода LED_1, и параметр change здесь применен просто как демонстрация хранения и передачи данных запущенной задачи. Вызовы процедур PioSet и PioGet обеспечивают установку светодиода в противоположное состояние (если он был выключен, то включается, и наоборот), значение переменной change используется как маска. Процедура MessageSendLater отправляет новое сообщение задаче t через 500 мс.
— декларация статической переменной toggle выделяет память под переменную структуры ToggleTask и присваивает значения её полям task и change.
— в коде процедуры main PioSetDir настраивает PIO1 (LED_1) как выход.
— MessageSend отправляет первоначальное сообщение, которое получит обработчик MyHandler.
— вызов процедуры MessageLoop запускает доставку сообщений между задачами. В MessageLoop выполнение зацикливается, и до оператора return 0 управление никогда не доходит.

Теперь если нажать F7, то проект скомпилируется. Если нажать F5, то программа автоматически зальется в память чипа и запустится на выполнение (при условии, что у Вас подключены модуль LPT SPI и к нему подключен модуль HC-04), и светодиод на ножке PIO1 начнет мигать с частотой 1 Гц. При этом доступна полноценная отладка – по шагам, с точками останова, с просмотром переменных, памяти и регистров процессора. Точки останова ставятся в коде как обычно, щелчком мыши слева от текста кода (появляется коричневый кружок напротив строки, где задана точка останова) – также, как в Visual Studio. Подробнее про отладку можно прочитать в документе CS-101500-UGP5_BlueLab xIDEuser guide.pdf.

Общая структура приложения BlueLab

Приложение firmware основывается на задачах (task). Каждая задача выполняет определенную, возложенную на неё функцию. Все задачи выполняются как отдельные логические потоки, которые не блокируют друг друга. Планировщик задач не вытесняющий (not preemptive), поэтому важно, чтобы все обработчики сообщений выполнялись до завершения, и не зацикливались навсегда, иначе работа остальных задач нарушится. Задачи обмениваются друг с другом информацией через сообщения (message). Во все задачи, которые создает приложение, входит также особая задача верхнего уровня, так называемая задача приложения (application task). Эта задача отвечает на сообщения и управляет общим поведением приложения. Сложные приложения могут содержать несколько application task.

Сообщения (messages) создаются и передаются в следующей форме:
Task t, MessageId id, Message payload

Task t указывает на получателя сообщения, это указатель на принимающую задачу, например &AppTask.
MessageId id идентифицирует сообщение. Принята следующая система нумерации сообщений:
— сообщение, которое задача отправляет сама себе, начинается с 0x00.
— системные сообщения начинаются с 0x8000.
— сообщения, отправленные задаче отдельной библиотекой профиля, начинается с базы 0x7000, и соощения библиотеки SPP начинаются с 0x6f00.

Message payload — полезная нагрузка (данные), передаваемая в сообщении. Иногда в сообщении нет полезной нагрузки, когда достаточно только идентификатора сообщения. В этом случае Message payload равна NULL.

Имеется набор функций для упрощения отправки сообщений, см. message.h и соответствующую документацию. Обработчик сообщений для каждой задачи должен обработать все адресованные ему сообщения. Обычной практикой разработчика является разработка кода обработки сообщений, которые принимает задача приложения (application task). Не нужно писать обработчики для задач профиля (profile tasks) и задач поддержки (support tasks), инициализированных из библиотек BlueLab или SDK. Обработчики этих задач уже встроены в библиотеки и выбираются после вызова соответствующей функции Init. Приложение application task должно обработать сообщения, поступившие из библиотек, которые оно инициализировало. Таблица системных сообщений приведена в файле CS-110344-UGP2_WritingBlueCoreApplication.pdf, Appendix A System Messages. Таблица баз (первый байт значения ID сообщения) сообщений библиотек приведена в том же файле, Appendix B Library Message Bases. Во время отладки через дебаггер (LPT SPI или USB SPI) сообщения появляются в окне Output, закладка Messages.

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

Можно выводить отладочные сообщения из кода программы оператором printf. В этом случае в окне Output открывается закладка Print Channel 0, и туда впечатывается вывод printf. Вывод printf работает в реальном времени во время работы firmware через дебаггер на LPT SPI. В реальном приложении все операторы printf должны быть убраны, иначе приложение без отладчика повиснет и не будет работать (из-за переполнения стека). Для удаления отладочного вывода применяют специальный токен времени компиляции DEBUG_PRINT_ENABLED и операторы условной компиляции #ifdef.
#define DEBUG_PRINT_ENABLED 1 //разрешение вывода printf

DEBUG_PRINT_ENABLED можно также определить в свойствах проекта, Build System -> Define symbols. Пример использования DEBUG_PRINT_ENABLED имеется в проектах примеров приложений C:\BlueLab41\apps\examples\.

Есть несколько проблем, с которыми пришлось столкнуться при экспериментировании с xIDE. Если программа в чип прошивается, но отладка запускаться не хочет с ошибкой «The app file read from disk appears to be invalid.», то это может произойти, когда до папки проекта сложный путь, имеющий в составе пробелы и/или русские буквы. Например, Ваш проект размещается в папке c:\Documents and Settings\User\Admin\Мои документы\LEDFlashing\. Поменяйте размещение проекта на более простое, например c:\temp\LEDFlashing, и отладчик запустится нормально. С русификацией у xIDE есть определенные проблемы — текст, сохраненный в коде на русском языке, при повторном открытии отображается с кракозябрами, поэтому писать комментарии на русском языке в коде не получится. Иногда сильно мешает компиляции антивирус Касперского (процесс проходит очень медленно). Целесообразно настроить исключение проверки объектов на путь C:\BlueLab41\tools\*.exe. Настройки вступят в силу почему-то только после перезагрузки Windows.

Словарик

HCI Host Controller Interface
LC Link Controller
xIDE среда программирования для процессоров BlueCore от компании CSR
VM Virtual Machine — насколько я понял, это выполнение функций процессора хоста на встроенном RISC-микропроцессоре. Есть Classic VM, и есть Native VM, различающиеся архитектурой и скоростью выполнения. См. CS-122636-AN-1classicvsNative.pdf.
VM API программный интерфейс приложений, не относящийся к DSP.
BlueCore название линейки чипов Bluetooth компании CSR. В платке HC-04 применяется чип BlueCore4.
payload полезная нагрузка. В контексте передачи сообщений — данные, переданные в сообщении.
application task задача приложения — обязательный элемент любой программы firmware BlueCore.
preemptive, pre-emptive в данном контексте вытесняющая многозадачность. Для каждой задачи выделяется лимитирванный промежуток времени выполнения, что гарантирует невозможность блокировки выполнения всех задач, если одна из задач заблокируется (например, войдет в бесконечный цикл).
not preemptive в данном контексте означает многозадачность, когда задачи выполняются друг за другом, и каждая задача выполняется по порядку от начала до конца. В этом случае блокировка в одной задаче может остановить выполнение всех задач. Именно такой сценарий выполнения задач используется в библиотеках BlueCore и SDK компании CSR.
L2CAP Logical Link Control and Adaptation Protocol
Persistent Store хранилище данных установок в виде записей (ключей)
TIFR Transient (RAM), Implementation, Factory, ROM — места размещения Persistent Store, означающие все возможные варианты размещения. Ключи, установленные во время производства изделия, находятся в областях Factory и Implementation, ключи, которые образуются при работе изделия, размещаются в Transient (RAM).
IFR Implementation, Factory, ROM — места размещения Persistent Store, не использующие RAM.
BCSP BlueCore Serial Protocol — протокол, через который общаются с чипом BlueCore все средства отладки (на физическом уровне это происходит через интерфейс SPI чипа BlueCore).
Kalimba DSP — в некоторых чипах BlueCore (BlueCore3 и BlueCore5) имеется DSP. К сожалению, в процессоре BC417143B модуля HC-04 отсутствует DSP. Для работы с Kalimba DSP имеются специальное API и соответствующая библиотека.

Ссылки

1. Общее описание чипа BlueCore4-External device на сайте компании CSR.
2. Модуль Bluetooth HC-04 на сайте Dealextreme.
3. Как покупать на dealextreme.
4. Описание программатора и отладчика LPT SPI, ссылки на документацию, пакет CSR CASIRA BLUELAB SDK, прошивки программного обеспечения модуля HC-04.
5. Исходный код проекта xIDE для модуля HC-04, мигающего светодиодом на порте PIO1.