search

TorstenRobitzki / bluetoe

C++ Framework to build Bluetooth LE Server (GATT)
MIT License
138 stars 29 forks source link

general HCI layer #29

Open TorstenRobitzki opened 6 years ago

TorstenRobitzki commented 6 years ago

Connecting HCI over a generalized transport (USB, SPI, UART...) to a bluetoe::server<> instance.

We can start this on a separated branch. Separating the transport will help in making the part of the library testable. I would suggest to add new folders named hci to the ./bluetoe and ./tests folder.

I don't think that reusing bluetoe::link_layer::link_layer would make sense, when we are implementing L2CAP over HCI.

kaofishy commented 6 years ago

Yeah I've come to the same conclusion. I'm trying to see if there's anything from the existing link layer that we can re-use but even things like white lists seem difficult to decouple at first glance.

kaofishy commented 6 years ago

Hey @TorstenRobitzki ,

I've mocked up this prototype to generate HCI command packets. I've taken into account your comment about endianness. Let me know what you think.

Tony

TorstenRobitzki commented 6 years ago

Yes, I don't think that reusing from the link_layer makes sense. At least not if you are not going to base the implementation on the scheduled_radio hardware abstraction. Most of the BLE link layer is already implemented in a HCI. I would base L2CAP onto HCI and then pass the L2CAP stuff to the GATT, SM and Signaling Chanel (link in link_layer::handle_l2cap).

TorstenRobitzki commented 6 years ago

Well, I mostly looked at the calling side in main(). Looks good to me. I think, if you use functions instead of struct, you could even deduct the buffer size from call.

I would give it a goo. If you think this results in readable, maintainable software structure, I would try it out.

kaofishy commented 6 years ago

Oh right, totally forgot I could try deducing the size of the buffer if it is known at compile time lol

I'm using structs because templates on functions don't have partial specialization on non-type parameters apparently.

TorstenRobitzki commented 5 years ago

I've started a new branch (HCI_2) to sketch, how an HCI binding could look like. We have a link_layer implementation that is based on a schedule_radio implementation and we would now add a second link_layer implementation, that used HCI.

One thing to factor out, would be the transport. The Bluetooth SIG documents UART and USB. An additional thing to factor out, could be the protocol handling error. If one is sure, that there can not be any bit errors on the transport and that the BLE controller is free of errors, one could then simple do no error handling at all.

TorstenRobitzki commented 5 years ago

An interesting feature could be to be able to configure the link layer so that it provides support for only a limited number of HCI versions.

TorstenRobitzki commented 5 years ago

Zephire could be used to program a Nordic eval board as HCI controller that communicates via UART.

TorstenRobitzki commented 3 years ago

moved sketch to sci_3 branch as merge of master created tons of conflicts