Very timid beginning framework for BLE communication

[Anton Lundin]

On 19 April, 2017 - Linus Torvalds wrote:

> Dirk, Anton, (and possibly others who currently use RFCOMM),
> 
> would you mind taking a look at my "ble-prep" branch in
> 
>       https://github.com/torvalds/subsurface-for-dirk.git ble-prep
> 
> that I have *not* made into a pull request yet, because I don't
> actually have anything to test with.
> 
> It's really just three commits:
> 
>       custom serial: pass device_data_t to bluetooth operation function
>       Expand 'bluetooth_mode' from a boolean to an emun
>       Prepare to split the custom serial operations up by RFCOMM-vs-BLE
> 
> and each of them actually tries to be a total no-op at this time. But
> the intent is to make it possible for core/qtserialbluetooth.cpp to
> simply have a different set of operations for BLE devices where RFCOMM
> doesn't work.
> 
> My plan (which may or may not work) would actually be to turn the
> Suunto EON Steel into a user of the serial emulation code too, for the
> BLE case there - even though the native model for the EON Steel isn't
> really "serial" at all, but a packet format with command/reply on top
> of USB HID (and now on top of BLE GATT with the new firmware). But I
> think it should probably be possible to use the same serial
> abstraction to then write the BLE packets instead.
> 
> But that series of three commits doesn't do any of that. It just tries
> to do no-op prep on code that I don't actually know at all, which is
> why I'd like somebody else to take a look at it.
> 
> In particular, somebody should probably test that it still works with
> the RFCOMM model. I'm particularly worried about devices that can do
> *both* traditional bluetooth *and* BLE. Because right now it just says
> that if the device can do BLE, we'll pick the BLE model. Of course,
> right now that BLE model ends up falling back to the same old RFCOMM
> code (which would fail on a BLE-only device), so it should still work
> with a "RFCOMM *and* BLE" device, but whatever..
> 
> Comments?
> 
> And yes, if somebody who actually knows that code (I'm looking at you,
> Anton) actually knows the Qt bluetooth interfaces and would fill in
> the open/close/read/write cases for the GLE GATT case, that would be
> great. Because right now I have a device that can do BLE, but going
> from "USB HID" to "BLE GATT" is a fairly big step. For example, it's a
> packetized protocol, and the packet size has changed.
> 
> In contrast, somebody who has a Perdix and already knows it, may have
> a much simpler time with the protocol that is already just a serial
> stream and isn't really packetized (and the BLE GATT thing is just a
> transport for that).

I finally got around to take a look at this code. I don't really know
that much about the Qt bluetooth as I would like to do, and it was
actually Claudiu Olteanu who wrote that code as a part of his GSOC
project.

I did rewrite the custom serial layer, and thats rather what this
is about.


I did read the code, and it looked fine. The big question in my mind why
we should mix the two custom serial bluetooth layers at all? Why not
just implement them as two completely different "custom serial" layers?

As far as I've understood things, even the scan for devices are
completely different, so is the reason that Qt merges the two scan
results?

The only btle device I have access to talks classic bluetooth to, so I
haven't figured out a sane way to test this.


That said, I would have liked to see that device pop up as two in the
device list, so you can choose if you would like to talk rfcomm to it or
btle.
I haven't actually gotten around to test any btle communication against
it other than hcitool lecc, but I think it talks the exact same protocol
over the two transports.

If we exposed those two different transports to the user, thats a simple
way of handing differences in protocol, transport quality and giving the
user the option to workaround any bugs which they might encounter.


//Anton


-- 
Anton Lundin	+46702-161604