general HCI layer

[TorstenRobitzki]

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]

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]

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]

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]

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]

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]

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]

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]

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

[TorstenRobitzki]

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