4

For a project I am doing I have to connect my Linux PC to a Bluetooth LE device. The application I design will be deployed on an ARM embedded system when it is complete. Searching for documentation online hints that the preferred programming language for these kind of applications is Python. All the Bluez /test examples are written in Python and there are quite a few sources of information regarding creating BLE applications in Python. Not so much in C.

My superior and I had an arguement about whether I should use Python or C. One of his arguments was that there was unacceptable overhead when using Python for setting up Bluetooth LE connections and that Bluetooth LE had to be very timely in order to function properly. My argument was that the overhead would not matter as much, since there were no time constraints regarding bluetooth LE connections; The application will find devices, connect to a specific one and read a few attributes, which it saves to a file.

My question is; is there any reason to prefer the low-level C approach over using a high-level Python implementation for a basic application that reads GATT services and their characteristics? What would the implications be for an embedded device?

Zimano
  • 1,870
  • 2
  • 23
  • 41
  • 1
    There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs. – too honest for this site Sep 28 '15 at 14:14
  • The issue is: What reasons are there to prefer a low-level C approach over a high-level Python approach for a basic application, keeping the time constraint argument in mind. Please elaborate on what I can do to isolate the issue more. – Zimano Sep 28 '15 at 14:16

2 Answers2

3

This is quite an open question as there are so many things to consider when making this decision. So the best "answer" might rather be an attempt to narrow down the discussion:

Based on the question, I'm making the assumption that the system you are targeting has D-Bus and Python available with all needed dependencies.

I'd try to narrow down the discussion by first deciding on what BlueZ API to use. If you are planning on using the D-Bus API rather than the libbluetooth C library API, then there is already some overhead introduced by that and I don't believe Python in itself would be the major factor. That should of course be measured/evaluated to know for sure, but ruling out Python while still using D-Bus might be a premature optimization without much impact in practice.

If the C library API is to be used in order to avoid D-Bus overhead then I think you should go with C for the client throughout.

If the "timely manner" factor is very important I believe you will eventually need to have ways to measure performance anyway. Then perhaps a proof of concept of both design options might be the best way to really decide.

If the timing constraints turn out to be a moot question in practice, other aspects should weigh in more, e.g. ease of development (documentation and examples available), testability, and so on.

JoGr
  • 1,457
  • 11
  • 22
  • 1
    Good points. Though it should also be pointed out the libbluetooth is an internal library and is not officially supported. If you want to go the official APIs then DBUS is the only option. And last time I checked, libbluetooth does not support gatt. Though there are unofficial libgatts outside the bluez tree which have extracted out the bluez gatt components. – kaylum Sep 30 '15 at 20:10
  • Thank you for your answer, I was also thinking about premature optimization and indeed a proof of concept of both implementations would be a very suited solution. However we don't have that much time. I am sticking with the C GDBus API, instead of the low level HCI one. After some research I found that it is very similar to the Python DBus API in regards to setting up the bus and all that. That's where most of the complexity was for me; getting on the dbus and sending/receiving messages and whatnot but now that I've actually done enough research, the C GDbus API seems to be a good way to go! – Zimano Oct 06 '15 at 07:37
  • I decided with my superior that it is best if I built the DBus implementation first, and when that goes well enough, start developing with the low level API. This way there will be a deliverable either way. Thanks again! – Zimano Oct 06 '15 at 07:46
  • 1
    Glad to be of assistance. Keep the comment made by Alan Au in mind though. If the low level C API of libbluetooth is not the recommended/supported/official way then you might take on a potentially fragile and maintenance heavy design by going that route. – JoGr Oct 06 '15 at 08:07
  • I was worried about that too. They even say on their website that if you're using the low-level API then "you're in for a lot of pain". – Zimano Oct 07 '15 at 07:15
0

Something more to consider:

  1. the latest BlueZ (eg. 5.36+), BLE should work fine and has been very stable for me - and remember to add "experimental" when building it and "-E" as a service parameter to get manufacturerData (and other experimental features)

  2. Using the C API, I think your code must be GPL (not 100% sure tho). The DBus interface allows you to make closed source code (if it's for a company)

LarsKnudsen
  • 112
  • 3