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

Question

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

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

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

Answer 1

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

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

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

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

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

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

Answer 2

Что-то больше, чтобы рассмотреть:

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

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