Язык программирования Dbus и Bluez

Для проекта, который я делаю, мне нужно подключить свой Linux-ПК к устройству Bluetooth LE. Приложение, которое я разрабатываю, будет развернуто во встроенной системе ARM, когда оно будет завершено. Поиск документации в Интернете подсказывает, что предпочтительным языком программирования для таких приложений является Python. Все примеры Bluez/test написаны на Python, и существует довольно много источников информации о создании приложений BLE на Python. Не так много в C.

У нас с начальником возник спор о том, следует ли мне использовать Python или C. Один из его аргументов заключался в том, что при использовании Python для настройки соединений Bluetooth LE возникают неприемлемые накладные расходы, и что Bluetooth LE должен быть очень своевременным, чтобы функционировать должным образом. Мой аргумент заключался в том, что накладные расходы не будут иметь такого большого значения, поскольку не было ограничений по времени для соединений Bluetooth LE; Приложение найдет устройства, подключится к определенному и прочитает несколько атрибутов, которые сохранит в файл.

Мой вопрос; Есть ли причина предпочесть низкоуровневый подход C использованию высокоуровневой реализации Python для базового приложения, которое считывает сервисы GATT и их характеристики? Каковы будут последствия для встроенного устройства?


python c bluetooth-lowenergy dbus bluez
person Zimano    schedule 28.09.2015    source источник
comment
Либо слишком много возможных ответов, либо хорошие ответы будут слишком длинными для этого формата. Пожалуйста, добавьте детали, чтобы сузить набор ответов или выделить проблему, на которую можно ответить в нескольких абзацах.   -  person too honest for this site    schedule 28.09.2015
comment
Вопрос в следующем: по каким причинам следует предпочесть низкоуровневый подход C высокоуровневому подходу Python для базового приложения, учитывая аргумент временных ограничений. Пожалуйста, уточните, что я могу сделать, чтобы больше изолировать проблему.   -  person Zimano    schedule 28.09.2015

Ответы (2)


arrow_upward
3
arrow_downward

Это довольно открытый вопрос, так как при принятии этого решения необходимо учитывать множество факторов. Таким образом, лучший «ответ» может быть скорее попыткой сузить дискуссию:

Основываясь на вопросе, я делаю предположение, что система, на которую вы ориентируетесь, имеет D-Bus и Python со всеми необходимыми зависимостями.

Я бы попытался сузить дискуссию, сначала решив, какой BlueZ API использовать. Если вы планируете использовать API-интерфейс D-Bus, а не API-интерфейс библиотеки C libbluetooth, то это уже связано с некоторыми накладными расходами, и я не думаю, что Python сам по себе будет основным фактором. Это, конечно, следует измерить/оценить, чтобы знать наверняка, но исключение Python при использовании D-Bus может быть преждевременной оптимизацией, не имеющей большого значения на практике.

Если API-интерфейс библиотеки C должен использоваться, чтобы избежать накладных расходов D-Bus, я думаю, что вы должны использовать C для клиента во всем.

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

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

person JoGr    schedule 30.09.2015
comment
Хорошие моменты. Хотя следует также отметить, что libbluetooth является внутренней библиотекой и официально не поддерживается. Если вы хотите использовать официальные API, то DBUS — единственный вариант. И последний раз, когда я проверял, libbluetooth не поддерживает gatt. Хотя есть неофициальные libgatts за пределами дерева bluez, которые извлекли компоненты bluez gatt. - person kaylum; 30.09.2015
comment
Спасибо за ваш ответ, я также думал о преждевременной оптимизации, и действительно, доказательство концепции обеих реализаций было бы очень подходящим решением. Однако у нас не так много времени. Я придерживаюсь C GDBus API вместо низкоуровневого HCI. После некоторых исследований я обнаружил, что он очень похож на Python DBus API в отношении настройки шины и всего такого. Вот где для меня была большая часть сложности; подключение к dbus, отправка/получение сообщений и еще много чего, но теперь, когда я действительно провел достаточно исследований, API C GDbus кажется хорошим способом! - person Zimano; 06.10.2015
comment
Я решил со своим начальником, что будет лучше, если я сначала создам реализацию DBus, а когда все пойдет достаточно хорошо, начну разработку с низкоуровневым API. Таким образом, результат будет в любом случае. Спасибо еще раз! - person Zimano; 06.10.2015
comment
Рад быть полезным. Однако имейте в виду комментарий, сделанный Аланом Ау. Если низкоуровневый C API libbluetooth не является рекомендуемым/поддерживаемым/официальным способом, вы можете выбрать потенциально хрупкий и сложный в обслуживании дизайн, выбрав этот путь. - person JoGr; 06.10.2015
comment
Я тоже беспокоился об этом. Они даже говорят на своем веб-сайте, что если вы используете низкоуровневый API, вас ждут большие проблемы. - person Zimano; 07.10.2015

arrow_upward
0
arrow_downward

Что еще нужно учитывать:

  1. последняя версия BlueZ (например, 5.36+), BLE должен работать нормально и был очень стабильным для меня - и не забудьте добавить «экспериментальный» при его сборке и «-E» в качестве служебного параметра для получения данных производителя (и других экспериментальных функций)

  2. Используя C API, я думаю, что ваш код должен быть GPL (хотя не уверен на 100%). Интерфейс DBus позволяет делать закрытый исходный код (если это для компании)

person LarsKnudsen    schedule 11.01.2016