Для примера, возьму ту же Lab4. Есть светодиод и характеристика его включающая. Добавим условие, что при разрыве соединения он должен выключаться. Есть кнопка и характеристика передающая notification при изменении её (кнопки) состояния. И при разрыве соединения очищать переменную хранящую статус включены нотификации или нет (странно, что в лабе этот момент пропущен, но это не принципиально - для лабы). Ну и не хотелось бы держать всё в одном файле app.c или собирать туда все вызовы и уж тем более все процессы выполняемые по разрыву соединения собирать в одном app.c под одним case sl_bt_evt_connection_closed_id:, если их можно держать в отдельных файлах и не валить всё в одну кучу.
И я так понял, что этим идеалогия SSv5 отличается от SSv4. Ведь в SSv4 у меня в app.c нужно было держать строчки для OTA DFU: Спойлер
Код:
case gecko_evt_gatt_server_user_write_request_id:
if (evt->data.evt_gatt_server_user_write_request.characteristic == gattdb_ota_control) { /* Set flag to enter to OTA mode */ boot_to_dfu = 1; /* Send response to Write Request */ gecko_cmd_gatt_server_send_user_write_response( evt->data.evt_gatt_server_user_write_request.connection, gattdb_ota_control, bg_err_success);
/* Close connection to enter to DFU OTA mode */ gecko_cmd_le_connection_close( evt->data.evt_gatt_server_user_write_request.connection); } break;
В то время как в SSv5 в этом уже нет необходимости - они есть, но в другом файле и в моём они не мешаются под ногами.
т.е. цель получить ветки case sl_bt_evt_connection_close_id: в разных файлах app.c, led.c, button.c, а не заниматься экспортом переменных и функций.
Но, я понял, что если я не могу использовать встроенные механизмы, то могу уже сам организовать это - я прозрел.
Наконец-то Вам удалось донести до меня свою цель. Конечно, это дело вкуса - держать все BT events в одном месте или распылить их по разным местам. В конце концов, у BT не так много events, чтобы возникла путаница с помещением всего, что к ним относится, в один файл.
Сегодня мне подсказали на силлабовском форуме как переделать проекты с SDK 3.1.0 на 3.1.1. Нужно просто нажать кнопку Force Generation после открытия slcp файла (в его закладке Overview). Компиляция потом происходит без проблем. И действительно, Ваш проект лаба, что выкладывали выше заработал под SDK 3.1.1 без изменений.
Такссс, вчерась пришла ссылка на следующий лаб, чтобы "Familiarize yourself с нею". И.. снова, когда должна произойти нотификация - отваливается по таймауту. Я еще буду разбираться... но, может кто подтвердит, что это личная проблема или нет. Возможно проблема в том, что SDK у меня 3.1.1. предыдущую 3.1.0 - я снял галочку в SdK manager-е и она исчезла.
p.s. Это уже становится не смешно.Теперь ситуация прямо противоположная. На плате BGM220P (BRD4314A) работает, а на "кошерной" Thunderboard (BRD4184A) - нет. Ивент наступает, фунция sl_bt_gatt_server_send_notification() возвращает SL_STATUS_OK, но соединение отваливается по таймауту.
Ссылка на следующий лаб? Это какой? Мой следующий вебинар будет во вторник, но я пока ничего не получил к нему. Из предыдущего поста неясно в чём конкретно проблема и про какую галочку идёт речь. Или это только мне непонятно, что проблема по-прежнему с кнопками или ещё с чем-то, например LDMA? Если что-то не работает даже на "кошерной" плате, я-бы дождался вебинара и посмотрел будет-ли работать у других. Там-же и вопрос можно будет задать. А пока без лабов я на него не отвечу. Если дадите ссылку на новый лаб, можно и через ЛС, посмотрю на выходных.
Про себя скажу, что никогда не имел проблем с посылкой нотификаций и вообще с Bluetooth стеком на любой плате. Может это потому, что я никогда не использовал "драйвера" Simple LED и Simple Button, a всегда обходился функциями EMLIB настройки портов (это 1 строчка кода на пин) и прерываний от GPIO (это 3 строчки кода средствами EMLIB). Для себя я выделяю 3 следующих уровня (абстракции) конфигурирования периферии, в частности GPIO: Низший уровень: прямая манипуляция и установка битов регистров конфигурации; Средний уровень: использование библиотечных API из EMLIB; Высший уровень: использование "драйверов". Уровень "абстракции" повышается снизу вверх и одновременно падает уровень универсальности и гибкости. Если для каких-то драйверов (например, I2C) использование их имеет смысл, то для GPIO никакого смысла в них я не вижу. "Драйверов" GPIO не было в SSv4, они появились только в SSv5, и, видимо, что-то в них накосячено. Тем более, что стабильный и отработанный EMLIB-овский подход к GPIO из SSv4 работает и в концепции SSv5. Мне вообще трудно представить, что разработчики будут использовать драйвера GPIO и вообще кажется, что они только для "ардуинщиков" или демонстрации на вебинарах, чтобы быстро и не вникать в детали и неважно какая будет эффективность.
Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.
Я думал, что это письмо уже всем участникам вторничного вебинара разослано.
Цитата:
We're looking forward to seeing you on Tuesday, February 16th, at our next workshop: Optimal Power Using ADC With LDMA Using Configurator Tool.
Be sure to complete the checklist below before the workshop:
Install necessary software outlined in our pre-work instructions Familiarize yourself with the lab Submit any questions you have in advance
Is this the first time you’re using your Thunderboard Kit? We recommend you watch this Getting Started Lab.
И чтобы подготовиться я просто выполнил то, что там написано. И как обычно, что-то не пошло. При этом, это не мой код! Для диагностики добавил Simple LED, чтобы видеть, что код побывал там, где я его ожидаю, и что функция вернула результат без ошибки.
Я еще помучаюсь, выясняя, кто тормозит BT стек, ивент или посылка нотификации...
p.s. результат "исследования". Пробовал разные комбинации пока не "упростил" программу до минимума. Т.е по факту возникновения события просто меняется состояние светодиода и ничего более:
Код:
case sl_bt_evt_system_external_signal_id: sl_led_toggle(&sl_led_led0); // External signal triggered from LDMA interrupt if(evt->data.evt_system_external_signal.extsignals & LE_MONITOR_SIGNAL) {
// Get the average uint16_t data_mV = le_voltage_monitor_get_average_mv();
// Start the next measurements le_voltage_monitor_start_next(); } break;
Так вот после первого toggle соединение через некоторое время отваливается (EFR Connect сообщает State:Disconnected. Status:8), но светодиод продолжает мигать с периодом в несколько секунд - т.е. события продолжают идти. Попробовал убрать "перезапуск" - закомментирвал строчку le_voltage_monitor_start_next(); - отваливает всё-равно. Если в прерывании void LDMA_IRQHandler(void) (в файле le_voltage_monitor.c) убрать функцию sl_bt_external_signal(LE_MONITOR_SIGNAL);, соединение остаётся - не теряется.
Мне не хочется так говорить, но явно, что это ошибка в SDK.
Про галочку... СпойлерКогда я получил плату Thunderboard и начал с создания нового проекта для него, SS мне выдал по умолчанию SDK 3.1.0. Для того, чтобы каждый раз ручками не переключаться на SDK 3.1.1, я пошел в SDK manager и снял вот в этом столбце "галочку". И теперь, в этом списке нет 3.1.0 и я не знаю как его туда вернуть, чтобы попробовать.ай, нет, я всё наврал... У меня 2 workplace и оказывается я это сделал на другом, и снял галочку не с 3.1.0 (его нигде больше нет), а с 3.0.0.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Да, похоже Вы правы - это bug. Проверил на "кошерной" плате и поведение такое-же как у Вас. Решил проблему путём отсылки нотификаций в обработчике LDMA_IRQHandler (файл le_voltage_monitor.c) вместо посылки внешнего сигнала стеку (см. под спойлером, там ещё нужно будет добавить #include "gatt_db.h"). Тогда всё работает стабильно. Т.е. bug в обработке внешних сигналов в SDK3.x, что подтверждается Вашими экспериментами. Примечательно, что в старом SDK2.x под SSv4 внешний сигнал отрабатывался стеком стабильно и без проблем, хотя я его на всех чипах не проверял. Спойлер
// Notify connected user sl_bt_gatt_server_send_notification(connection_handle, gattdb_avg_voltage_data, sizeof(volt_buf), (uint8_t *)&volt_buf); // Start the next measurements le_voltage_monitor_start_next(); }
Поверю Вашему опыту с модулем BGM220. Проверил сейчас проект с оригинальным кодом на Wireless Starter Kit Mainboard с установленной на нём платой BRD4182A (т.е. на точно таком-же hardware как в лабе). На этой плате стоит другой чип EFR32MG22 вместо BG22, и на ней все работает как надо, не отваливаясь. Сейчас напишу обо всём этом своему контакту в Silabs, и если ничего не произойдёт, будет что спросить на семинаре во вторник. Кстати, емайл про лаб я всё ещё не получил, так что спасибо за ссылку.
Спасибо, что подтвердили, а то уж начинаю думать, что даже по инструкции ничего сделать не могу. Зато тут появилась очередная мысль. Сколько я теперь понимаю, все функции, которые должны что-то передавать, я могу вызывать практически из любого места и только приём отлавливать в функции sl_bt_on_event()?
Я тут еще вычитал... По поводу параметра характеристики. Вот если взять эту же характеристику avg_voltage_data. В этой лабораторной она имеет тип USER. Но про тип user я вычитал что пользователь сам должен вне стека выделить для неё место и сам делать ответы на запрос чтения. Если же определить как HEX или UTF-8, то стек сам будет обслуживать запросы на чтение. Вот тут попробовал, но странно, что не обслуживает посылку нотификаций. Пришлось сделать такой код, после изменения значения характеристики делаю отдельно посылку нотификации:
СпойлерВ gatt_db тип характеристики объявлен как HEX размером 2 байта и еще включено Read характеристики (опционально).
// Set flag to indicate sampling finished startedSampling = false; le_voltage_monitor_start_next();
}
Ну это из разряда "хотелось бы". А вот что не так - так это то, что где-то, что-то протекает. Работать - работает, но через некоторое время отвал по таймауту. Попробовал ваш вариант - работает значительно дольше, но тоже через какое-то время отваливается.
Так что, наверное, надо ждать, когда всё начнёт работать стабильнее.
Да, правильно понимаете - передачу можно организовать из любого места, и лишь вопросы, связанные с приёмом, из bt_on_event. Также правильно понимаете и про тип USER. Нотификации по изменению характеристики и не должны посылаться стеком автоматически, согласно спецификации SIG, так что код пользователя в этом случае необходим. Для отсылки нoтификаций может быть масса причин, в соответствии с логикой работы устройства, поэтому и принятие решения об их отсылке переложили на пользователя.
Я тут попытался поправить изначальный код для TB BG22 платы путём изменения дефолтных параметров соединения. Короче, попробуйте модифицировать connection_opened хендлер так:
Здесь TB2 запрашивает клиента об изменении параметров соединения и установки ненулевой latency (дефолтное знечение параметров соединения клиентом может задавать слишком маленький период и нулевую latency). У меня стало работать стабильно минут 10 без разрыва соединения, больше не проверял. Интересно, как будет у Вас.
Вчера я доложил о проблемах с кодом моему контакту с фирмы - он сразу ответил и обещал проверить и отписаться в течении недели. Но он человек занятой, работает с кучей клиентов, так что посмотрим. Если ничего не изменится до вебинара - задам вопрос там. Думаю, там и без меня люди такой вопрос зададут как только обнаружат отвал.
Ваш код под характеристику типа HEX сейчас посмотрю и напишу отдельно. Посмотрел и не понял зачем пишите новое значение характеристики в BT Database? В свойствах этой характеристики не разрешено её чтение клиентом, а разрешены лишь нотификации. Значение характеристики все-равно хранится вне BT DB. Вы пишите, что "пришлось сделать такой код" и я не понял почему пришлось. Что, без записи в DB что-то работало не так? Короче, опишите проблему более детально и/или чего хотите добиться.
По поводу нотификаций и "пришлось". Ну вы уже объяснили, что спецификация такова, а не так как я её себе представлял. Я предполагал, что есть характеристика и её значение. И если я её значение меняю командой sl_bt_gatt_server_write_attribute_value, то она уже читаться должна как новое значение. Ну а если я хочу послать нотификацию... где мне взять это значение? Пока я не нашел функции посылающей нотификацию со значением, которое прописано в характеристике. Выходит даже наоборот, командой write_attribute_value, я записываю одно значение, а нотификацию могу послать с другим значением. Или послать нотификацию с новым значением, но не записывая это значение в характеристику. Это всё валидные операции?
Ser60 писал(а):
Я тут попытался поправить изначальный код для TB BG22 платы путём изменения дефолтных параметров соединения. Короче, попробуйте модифицировать connection_opened хендлер так:
У меня с этими параметрами соединение происходит явно медленнее чем обычно и не получаю ни одной нотификации, а снова разрыв соединения по таймауту.
При посылке нотификаций, значение их берётся не непосредственно из стека, а из внешней переменной. Поэтому все Ваши перечисленные операции валидные. Если характеристика типа HEX и посылаются её нотификации, следует предварительно прочитать её значение из BT DB во внешнюю переменную, а потом послать её по нотификации. В случае обсуждаемого приложения предварительно читать характеристику не имеет смысла, поскольку её значение всё-равно хранится во внешней переменной и нотификации посылаются как только будет получено очередное её значение. К тому-же чтение характеристики в профиле Лаба не разрешено клиентам (мастеру, однако, всегда разрешены запись и чтение любой характеристики).
Представьте ситуацию когда характеристика типа HEX, например, температура, измеряется каждую минуту и её значение записывается в BT DB. Если разрешено её чтение клиетом, то оно будет отрабатываться стеком автоматически и клиент получит возможность читать текущую температуру из DB в любое время. Теперь представим, что хотим посылать нотификацию клиенту только если температура повысится выше порога. Вот тогда и следует посылать нотификацию, причём необязательно нотификацию температуры. Это может быть нотификация другой характеристики, например, с командой на включение кондиционера. Короче, операции чтения и записи характеристик инициируются клиентами, а операции индикации и нотификации - сервером, и сервер решает какие именно данные посылать.
Я связываюсь с BT сервером с помощью Cypress донгла. Да, с новыми значениями интервала соединения чтение клиентом BT DB сервера медленнее. Попробуйте поиграть с параметрами. В моём случае все стабильно работало (опять-же по крайней мере 10 минут) со следующими значениями:
Для ускорения чтения клиентом характеристик сервера лучше эту строчку вставить перед началом производства измерений, т.е. перед строкой
Код:
le_voltage_monitor_start_next();
в обработчие события sl_bt_evt_gatt_server_characteristic_status_id. Уточню: я эксперементирую с оригинальным кодом из Лаба, добавив в него лишь одну строчку выше. Плата - Thunderboard BG22. На других не пробовал. Если у Вас соединение разрывается сразу, может ваш клиент не воспринимает изменение сервером временных параметров соединения, хотя мне это и странно представить.
Да, в оригинальом коде работает и я не дождался отсоединения.
А предыдущее сообщение о разрыве соединения было в коде, где не посылается ивент, а посылка нотификации происходила в прерывании LDMA. И вот это самое печальное. Т.е. для работы нужны бубны с танцами. Или информация, что не так, как это проконтролировать и как избежать.
Полностью согласен, что детальное описание как всё работает было-бы полезно. Однако, думаю это будет неподъёмный толмуд, который сложно поддерживать актуальным из-за частых переделок системы, и который большинство пользователей наверняка не будет читать в пользу простоты задания вопросов на форуме. Если-бы на них сотрудники фирмы ещё всегда отвечали и с разумной задержкой...
Тем не менее, что мне с самого начала не нравилось в оригинальном коде - это длиннющий LDMA_IRQHandler. Я ввёл переменную dmaFlag, инициализированную в 0, и устанавливаемую в 1 в LDMA_IRQHandler и перенёс весь код из этого хендлера в app_process_action в файле app.c (см. под спойлером), где отсылка нотификации производится без посылки сигнала о внешнем событии стеку. Туда-же перевёл сам хендлер. Всё опять стало работать. Видимо, есть какая-то связь между приоритетами прерываний периферии и пробуждением стека. Спойлер
Да, SDK не виновата - обвинения снимаю :-). Вчера у меня возникли аналогичные предположения, но я начал подозревать функцию le_voltage_monitor_start_next(), которую вставил в обработчик. Оказалось, что проблема гораздо раньше. Я повторил ваш вариант в еще более близком к изначальному коду - просто всё содержимое обработчка прерывания поместил в app_process_action() (ну кроме очистки самого прерывания), оставив посылку sl_bt_external_signal(LE_MONITOR_SIGNAL); - всё так же работает.
Ну послушаем, что нам сейчас расскажут на вебинаре.
Xa! Я всё время тестировал оригинальный код со CySmart и их донглом в качестве клиента. Сегодня во время вебинара попробовал приложение EFR32. Оказалось, оригинальный код для TB BG22 платы работает стабильно с моим смартфоном (Samsung Galaxy S8) и разрыва соединения не происходит, так что у меня не было причины задать соответствующий вопрос. Считаю, что обсуждать донглы других фирм на силлабовском семинаре неуместно. Однако, на семинаре не рекомендовали вызывать команды BT стека из обработчика прерываний, а рекомендовали либо посылать внешний сигнал стеку, либо из кода пользователя, как в последнем случае.
Но на вебинаре тоже был как минимум один человек, который пожаловался на разрыв соединения. И ведущий не смог ничего сказать, только спросил сразу разрывает или нет. Тогда получается, что клиент может задать такие параметры соединения (и сервер их принимает), что этого времени уже не хватает на то, чтобы успело обработаться всё, что наворочено в прерывании. Смартфон задаёт одни параметры, а планшет другие? Этот момент прояснился - надо писать коротко.
Да, вполне может быть, что смартфон задаёт одни временные параметры соединения, а планшет другие. Это зависит от версии ОС, и также от аппаратной начинки. Например, известно, что iOS устройства медленнее, чем Android в плане поддерживаемых периодов соединения. Например, минимально возможный период 7.5мс, рагламентируемый SIG, может оказаться слишком быстрым для многих iPhonе-ов и для них не рекомендуется опускаться ниже 20мс. Поэтому надёжнее всегда вставлять в сервер код посылки запроса клиенту перейти на кастомный connection interval с его дефолтного функцией connection_set_parameters. Не факт, что любой клиент примет эти параметры, особенно если он их не может поддерживать, но если может, то примет почти наверняка (я не встречал обратного). Не знаю в скорости-ли дело или в чём-то ещё и почему такая разница в соединении с нашими устройствами.
Можно ли меня куда направить в сторону, как определить нужный сервис. В статье было про использование handle. Но, если я хочу сделать "совместимое" с другим устройством своё устройство, как обеспечить их "совпадение"? Тем более в конфигураторе такого поля нет и задать его не могу. Где-то вычитал про UUID. Но с ними тоже не всё ясно. Есть 16-битные adopted и есть еще какие-то очень длинные.
Вот, если я хочу сделать устройство имеющее характеристику аналогичную показанной на картинке с Handle = 0х0012. Какова должна быть последовательность действий? Создать характеристику с UUID 0xFFE1 ? И какими функциями я могу добыть хэндл для соединения клиента затем с этой характеристикой?
UUID сервисов и характерстик бывают либо 16-битные, либо 128-битные. 16-битные UUID следует использовать лишь для утверждённых SIG аттрибутов. Handles аттрибутов профиля определяются конфигуратором профиля автоматически в порядке расположения их в профиле и должны быть без пропусков. Профиль показанный на картинке можно создать в конфигураторе, используя в точности такие-же аттрибуты с хендлами выше 0х0012, здесь не вижу проблем. Иначе возможности разместить характеристику в точности с данным handle не вижу, да это и не нужно. Стандартные SIG UUID аттрибутов профиля станут доступны в конфигураторе профиля нажатием на кнопку +. Для кастомных аттрибутов UUID всегда длинные и формируются конфигуратором автоматически. В сети имеются генераторы кастомных UUID, но для SS это не нужно. Здесь под аттрибутом я понимаю сервис/характеристику/дескриптор.
Для определения в программе клиента handle для определённой характеристики сервера, при условии, что известен её UUID, используйте API sl_bt_gatt_discover_characteristics_by_uuid(). При обнаружении её в профиле сервера на стороне клиента генерируется событие, в переданной стеком структуре которого будет поле с handle характеристики на строне сервера. Если этого недостаточно, см. другие API GATT клиента.
Спасибо за подсказку. Сейчас делаю клиента, а потом буду делать сервер (по-новой, старый был в SSv4). Оказалось, что для characteristic discovery необходимо знать хэндл сервиса. Правда, в программе CySmart его подсмотреть не удалось. Не нашел, где это можно увидеть. Да и донгл, что-то не хотел ни с чем соединяться. Программу CySmart переинсталлировал - не помогло. Помогла только перепрошивка фирмвари донгла. Была 1.0.0.53, стала 1.0.0.54 - тогда только удалось соединиться. Пока разбирался с этим CySmart, в своей клиентской программе сделал просмотр сервисов сервера и получение хэндла. В качестве сервера выступал модуль HM-11. Выяснил, что требуемый UUID сервиса 0xFFE0 и получил хэндл 0x0010FFFF. Вот отладочный вывод:
Правда, когда оживил CySmart там нашел что хэндл сервиса всего 0x0010. Но в хидерах SDK это поле имеет тип uint32_t:
Код:
PACKSTRUCT( struct sl_bt_evt_gatt_service_s { uint8_t connection;/**< Connection handle */ uint32_t service;/**< GATT service handle */ uint8array uuid;/**< Service UUID in little endian format */ })
Так что может и хорошо, что сам получал хэндл, а не подсматривал в другой программе.
Сам поиск делал аналогично поиску устройства из статьи: посылаю запрос и сравниваю полученные массивы с заданными UUID. вот как это выглядит - это модуль сериального порта для связи с HM-11 (и совместимыми модулями):
Спойлер
Код:
/* * serial.c * * Created on: 18 февр. 2021 г. * Author: wl */ #include "sl_bluetooth.h" #include "gatt_db.h" #include "app.h" #include "sl_app_assert.h" #include "sl_iostream_uart.h" #include "sl_iostream_init_usart_instances.h" #include "printf.h"
static uint8_t connection_handler, respLen,*respData; static uint16_t char_handle = 0xFFFF, handle, gatt_result; static uint32_t service_handle; unsigned int ii, char_handle_defined=0, service_discovered=0; static uint8_t service_UUID[]={0xe0, 0xff}, characteristic_UUID[]={0xe1, 0xff}; unsigned int gatt_procedure_in_progress = 0;
// ---------- // This event indicates that a connection was closed. case sl_bt_evt_connection_closed_id: char_handle_defined=0; service_discovered=0; char_handle = 0xFFFF; break;
sl_app_assert( len == sent_len,"not_sent %04x bytes, len - sent_len"); sent_len = len = 0; // read up to 20 characters from local buffer while(len < 20){ if (SL_STATUS_OK == sl_iostream_getchar(sl_iostream_vcom_handle,&c)){ data[len++]= c; } else { break; } } if (service_discovered){ if(len > 0){ sc = sl_bt_gatt_write_characteristic_value_without_response(connection_handler, char_handle, len, data,&sent_len); } } else { sent_len = len; sl_iostream_write(sl_iostream_vcom_handle, data, len); } }
Тут я сделал "разделение" вызова sl_bt_on_event() из app.c . Т.е. этот вызов проходится и через app.c , и через serial.c. В app.c только процедуры соединения устройства (пароль, бондинг итп), а в serial - только обслуживание сервиса передачи данных. И, подумал, что можно было бы сделать еще файлы для других сервисов. Но....
Сейчас "график" работы выглядит так: Произошло соединение- sl_bt_evt_connection_opened_id: делаем запрос на поиск сервиса по UUID . нашли сервис sl_bt_evt_gatt_service_id: узнали хэндл, делаем запрос на поиск характеристики по UUID нашли характеристику sl_bt_evt_gatt_characteristic_id: всё, включаем нотификацию и работаем пока не разъединимся.
Да вот проблема в том, что за раз можно делать только один gatt-запрос. Т.е. пока я по факту соединения запрашиваю один UUID сервис - всё хорошо, но второй-то запрос обломится. И вот как принято эти запросы разделять/сериализировать? Флагами? Я тут уже попытался ввести флаг gatt_procedure_in_progress, который пока нигде не принимаю во внимание. Но ведь проблема в том, что событие соединения с сервером sl_bt_evt_connection_opened_id больше в этой жизни не повторится. Делать ивенты? Но их всего 32 - маловато будет.
Как это не удалось посмотреть handles в CySmart? Нужно соединиться с сервером и нажать на Discover All Attributes. Вся поднаготная сервера будет представлена как на ладони, вклячая handles и UUIDs. Спойлер У Вас, наверное, старая версия донгла(?) Вот параметры моего (модель CY5677 CYSMART 256K): Спойлер Флагов скорее не 32, а 2^32, т.к. флаг - это не отдельный бит, а всё слово.
Цитата:
И вот как принято эти запросы разделять/сериализировать?
В программе клиента формируется событие когда придёт ответ сервера на запрос. Дождитесь его и потом посылайте следующий. Или я неправильно понял вопрос?
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 47
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
