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?
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.