BGAPI ды BLE112

Калі вы вырашылі карыстацца BGAPI для кіравання модулем BLE112, перад вамі стаіць выбар рэжыму абмена. Трэба выбраць нумар модуля UART а таксама рэжым яго працы: з кіраваннем патокам альбо без. Дакументацыя не дае дакладнага апісання асаблівасцяў розных рэжымаў. Тут паспрабую сабраць тыя асаблівасці, што я знайшоў, калі наладжваў сувязь паміж гэтым модулем і мікракантролерам.


Вось такія наладкі я карыстаў, каб модуль меў малое спажыванне току і хутка кіраваўся па UART (частка файла hardware.xml):

<sleeposc enable="true" ppm="30" />
<sleep enable="true" max_mode="3" />
<wakeup_pin enable="true" pin="6" port="0" state="up" />
<host_wakeup_pin enable="true" pin="7" port="0" state="up" />
<usart alternate="1" baud="1000000" channel="0"
       endpoint="api" flow="false" mode="packet" />

Першыя два радкі даюць малое спажыванне току праз рэжымы сну. Трэці і чацвёрты задаюць сігналы, праз якія модуль і мікракантролер будзяць ада сну адзін аднаго, калі трэба абменьвацца інфармацыяй. Апошнія два радкі задаюць наладкі UART: хуткасць абмену, рэжым.

На хуткасці ў адзін мегабіт/с модуль не здольны перадаваць дадзеныя без перапынку:

Відавочна што хуткасць можна паменшыць прыкладна у тры разы (да 300 кілабіт/с).

Фармат пакета

Існуе два рэжымы: з кіраваннем патоку і без кіравання патокам (альбо пакетны рэжым). Асноўнае адрозненне пакетнага рэжыму: перад пакетам трэба слаць агульную даўжыню пакета. Функцыя можа выглядаць так:

void ble112_send (uint8 len1, uint8* data1,
                  uint16 len2, uint8* data2
                 )
{
    const unsigned char length = len1 + len2;
    write(handle, &length, 1);
    write(handle, data1, len1);
    write(handle, data2, len2);
}

Але адказ не будзе мець такога першага байта!

Здарэнні

Існуе тры розных віда пакетаў якія ходзяць паміж модулем і мікракантролерам: каманды, адказы і здарэнні.

Абмен выглядае так: мікракантролер шле каманды і атрымлівае адказы. Калі модулю трэба паведаміць мікракантролер, ён шле здарэнні. Каб выканаць некаторыя каманды модулю патрэбен час, таму ён адказвае адразу, а дадзеныя (ці пацверджанне выкананых дзеяў) дасылае пасля ў выглядзе здарэнняў.

Напрыклад, як працуе каманда раз'ядноўвання злучэння:

Зверху (першы радок) каманда, адказ на каманду (трэці радок) прыходзе адразу, а пацверджанне, что сувязь разарвана, амаль праз 90 мілісекундаў (таксама трэці радок).

Уключэнне модуля

Як працаваць з модулем зразумела. Але як дазнацца што модуль гатовы прымаць каманды? Гэта проста - па здарэнню "boot".

Вось так выглядае першапачатковая наладка модуля ў мяне:

Першым прыходзе здарэнне "boot" (залёнае). Далей мікракантролер выстаўляе сігнал WakeUp, каб модуль не пайшоў спаць і чакае здарэнне "port interrupt" (сіняе). Гэта здарэнне адбываецца кожны раз пры прабуджэнні модуля праз сігнал WakeUp. Пасля здарэння можна слаць каманду наладкі парта 1 (чырвоны). Гэта патрэбна, бо порт працуе як уваход і можа даваць значнае спажыванне току, калі ён боўтаецца ў паветры. І напрыканцы ўключаем рэжым advertise (жоўты), каб модуль змаглі знайсці і далучыцца.

Калі ў вас ёсць некалькі каманд паслаць у модуль, не абавязкова апускаць і зноўку выстаўляць сігнал WakeUp, тады не будзе дадатковага здарэння ад парта, што трошкі скароціць час абмену, а каманду можна слаць адразу пасля атрымання адказа на папярэднюю каманду.

Я спрабаваў не чакаць здарэння, а слаць каманду праз невялікі прамежак часу пасля выстаўлення сігнала WakeUp, але не атрымаў упэўненай працы модуля. Модуль адказваў не на ўсе каманды ды прыходзілі здарэнні, якіх павінна быць не было. Верагодна буфер для атрымання і адсылкі дадзеных па UART у модуля маленькі і не здольны апрацоўваць некалькі пакетаў адразу.

Колькі часу патрэбна на абмен

Вось так выглядае запіс аднаго атрыбута (памерам 20 байтаў) ў модуль:

На ўсю размову спатрэбіцца трошкі менш за 3 мілісекунды. Падчас гэтага часу модуль будзе спажываць амаль 8 мА, што дае дадатковыя 24 мкА да агульнага спажывання, пры запісы атрыбута адзін раз у секунду.