 All right, so I guess we could get started My name is Johan Hedberg. I work for Intel been working with the Zephyr Bluetooth support now for about one and a half years and In this presentation, I'll be going through what exactly it is about Bluetooth that Zephyr supports and what our plans are going ahead When we talk about Bluetooth in the context of Zephyr or IoT in general, it's for the most time Bluetooth low-energy technology that we are talking about Bluetooth low-energy is something that was introduced relatively recently when you think about how old Bluetooth is as a specification and technology came in 2010 and It has several different names that it's been called like BLE or Bluetooth smart But this one smart was a marketing name that the Bluetooth Sieg was using for it But I think the official term nowadays is Bluetooth low-energy technology. They've dropped the Bluetooth smart part Little energy uses the same 2.4 gigahertz Frequency as traditional Bluetooth slightly different Bit simpler radio modulation than the classic Bluetooth. It has Up to a hundred meters range. It has a bit lower bandwidth Then traditional Bluetooth where you can go up to three megabits per second. You get one megabit per second with Bluetooth I'll leave and Depending on your usage, you can get many years of battery life even with small coin cell batteries using Bluetooth low-energy the kinds of Devices that have Bluetooth low-energy are usually categorized based on do they support traditional Bluetooth classic or not So on your PCs or on your phones, you would have so-called dual mode Controllers which have the Bluetooth classic and Bluetooth le and then your small Sensors like low-power devices that would be so-called single mode devices that only support Bluetooth low energy and The low power consumption makes Bluetooth le the best choice a very good choice for IoT use cases So regarding Zephyr support for Bluetooth le it supports the very latest Bluetooth 4.2 standard The main focus as I explained has been on Bluetooth le and We have pretty much Like almost all of the features that are available. There are a couple of optional features that we are still working on Some highlights of functionality that we have we have support for L2Cop connection or the channels, which is a feature of the 4.1 Bluetooth specification Which is required to do for example IPv6 over Bluetooth le. We also have the Security update from Bluetooth 4.2 called le secure connections That we support We recently started implementing with the classic support as well So if somebody wants to create devices that support both le and Bluetooth classic another name for that by the ways VR EDR Stands for basic rate slash enhanced data rate The Zephyr Bluetooth stack uses Standard HCI separation between the host layer and the controller layer This is something that's been a standard interface on Bluetooth controllers for a long long time When the Bluetooth all the energy was introduced a very common scenario for Single mode controllers was that that they wouldn't necessarily have a HCI internally because if they have just a single core but we've decided to Whether it's it's a single core or multiple cores to have HCI is the standard because it gives ultimate flexibility on combining different host different controllers and And something which happened just Very recently this year is that we also received the layer below HCI the controller implementation Which basically gives you a Bluetooth firmware for your Bluetooth controllers? Or talk about that a bit more later regarding the architecture so We have For the host stack, I'll give more details about the controller later later. So the host stack at the lowest layer we have a Abstraction called an HCI driver which abstracts away the details that the HCI transport details to the controller so it can be a physical transport like you are at our spy or If you are running the controller on the same CPU, then it would be a virtual driver that you would have there The interface to the application side is on the generic access profile layer and the Gut layer actually don't have a bullet point for that, but you can see it here in the diagram so this the gap and gut are basically the main Interfaces when programming creating applications with Bluetooth Gap gives you the generic ways of Establishing connections discovering devices and so on and whereas gut is the main protocol or profile used for communicating with other devices The security manager protocol you can request that for connections. It's abbreviated here SMP and Then we also have the possibility of doing IPv6 over Bluetooth LE Which actually for the most part you would be using the IP stack interface for doing that The support when it comes to HCI is fairly complete and well tested when we did the development Of the stack in the early days. We were using a lot of our own Controllers funder laptops and this USB dongles. So we've had quite a lot of Different hardware references to verify that it works well against Pretty much all of the aspects of the stack is configurable depending on what your needs are so when you make a build you're not going to have anything unnecessary there consuming memory How we split this during runtime for the host stack So we have the HCI driver interface and we have simple APIs for getting data to and from the driver We This is kind of becoming obsolete with the unified kernel of Zephyr, but originally when we created we were targeting so that you could have a nano kernel only system And that means we use only fibers and nano kernel objects. This will now slowly start getting replaced by the unified kernel objects instead So we have a single received fiber for data coming from the controller For the most time When we get data from the controller that's in interrupt context So we just want to put it quickly to a received queue and then have the fiber actually process it So we don't take too much time in the interrupt context and the two kinds of data that we're getting then from there The RX fiber then either processes connection data or some as ACL data or then HCI events For sending data out from the device from the host to the controller We have two fibers one for HCI commands for configuring the controller for creating connections and and so on The controller exposes its own flow control for the commands, which is why we have a separate fiber for this so it the controller control tell us tells us how many HCI commands it's able to receive and We shouldn't be sending it more commands than that It will notify when it's ready to get the next command and so on and this is actually mapped to a semaphore in the command transmission fiber and For connections the controller also has a separate flow control for that and Because of that we have a separate fiber actually we have one fiber per connection for sending out data the main reason why we have one fiber per connection is that we can have multiple connections connections can come and go and If a connection gets disconnected we want to free up any Outgoing buffers that there are for that connection and if we had a single Q and a single fiber At least the current objects for those in the kernel They don't allow you to go inside the Q and remove items So the simplest way is to have just a single Q and a single fiber per connection This is not ideal and and it will probably fixed at some point. There's a new Poli pole-based API coming at some point this effort which allows you to wait on multiple different objects at the same time So we can then potentially shrink the Connection fibers into a single fiber it might even be possible then to combine the command HIC common fiber and Connection fiber into one It's not a huge amount of memory that we are wasting. I think currently the connection fiber Stack size is 256 bytes. So that's how much The overhead is per each new connection Regarding the data as it flows through the stack If anybody is familiar with Linux kernel networking, there's a concept there called socket buffers We have something analogous to it on the Zephyr side called network buffers The API is very similar to socket buffers. In fact, we've copied some of the terminology of the socket buffer Linux kernel socket buffer API and both the IP stack in Zephyr as well as the Bluetooth stack uses These network buffers natively everywhere where it goes so They provide easy APIs for encoding protocol data decoding protocol data Also depending on the indianess if you have a little indian protocol or big indian protocol It's very easy to get it from there to host indian or vice versa The network buffers provide the fragmentation support so you can have chains of buffers where the data is split into and By using these on in all the subsystems in all the layers we minimize the need to do copies of the data the network buffers are also compatible with the kernel objects of Zephyr and So you can use the the five force for example is effort to pass the network buffer and to read it then at the other end and As I mentioned, this is used basically everywhere where we need to have the data passed around so As I mentioned, it's possible to configure pretty much everything when it comes to the Bluetooth functionality When you start creating a product or an application the first thing you do is you look at what your requirements are and What exactly the features that you need are The first choice would be to look at how is your controller connected? Is it overspiced the way you are or do you maybe have a single? Core solution where the controller is running on the same core so you would have a virtual driver than for that and You would be looking at the features you need whether you need Which gut rolls you need? There's the peripheral role, which is typically used for sensor type devices and the central role which would be used for For example your phone connecting to other devices You can select all of the different security features What what you need we have a mode for doing the secure connections only for example if you want Absolute security not using the legacy security from previous booted versions, which has some vulnerabilities Bluetooth low energy has a concept called signing Where you don't need to encrypt the connection to another device, but you can sign the data This is not a much used feature at least what I've seen in the market But we have support for it and and you can disable it if you don't need it or enable it if you do need it You can specify the exact number of buffers for your needs How big the buffers need to be depending on the protocol that you're using for since Jeffer doesn't have dynamic memory allocation All of this need it's good to be able to specify all of this at build time because then you're not taking Any more space than your actual use cases require so you can specify the number of pair devices Each pair device takes a certain amount of memory because we need to store I think some two or three keys per device and some are some other piece of information so Depending on your needs you would set that to some value I think it defaults to one pair device and then you would increase that depending on how many devices your device needs to support The same thing with the connections, so do you want one connection if you're a simple Sensor beacon well actually beacon wouldn't have connections, but if you're simple sensor You would have just one connection, but if you want to have richer functionality, then you can increase the number of supported connections If you're beacon and don't need any connections at all we allow disabling all connection related functionality So you can build a really really small system that way That doesn't support connections, but you can still do basic Advertising and and scanning for advertising packets using LED and there's a whole bunch of debug options You can enable this per protocol basis in the Bluetooth stack to get the debug logs for what you need to debug Once you've selected the configuration that you want it's time to start actually writing the application I've given a sample here of a typical Peripheral peripheral style application exposing simple service or set of services so The first thing blue that application does it initializes the stack so we have a BT init API It can operate both in blocking and non-blocking mode, so you can give it an optional callback Which then gets called once the stack is finished initializing You would register the services that you want to expose so I don't let's say a temperature sensor so you would have a temperature service exposing that and Once you have the services registered you would make it possible for other devices to to discover you and to connect to you So in booted low energy speak, this is called advertising So you would do a connectable advertising to let others able to to be able to connect to you and As devices are connected you have some kind of sensor which is exporting some value in what to notify the changes very simple Notification API that you call to send out broadcasts of changes to that sensor and We have lots of different sample applications For different Bluetooth profiles available in this effort source tree under samples Bluetooth So that's a good source to start looking at when implementing Bluetooth applications So a bit more about the development When we started creating the stack for Zephyr our main development environment was simply QM on our Linux laptops and Something that made this very Fast and easy for us was the ability for to use the native controller on our laptops. So we are running running Linux and Blue Z provides a way to expose the h.i. Interface of the Controllers connected to it. So what we do is we simply Create the unique socket that QM connects to it creates a serial port internally and then we connect up one of this Effort you are drivers to that serial port The nice thing with this is that we can still see all the data going through h.i. on the Linux side And we can use the Linux tracing tools like BT mon or h.i. dump to decode the h.i. data and see what's going on and Of course you get the gdb access also with QM So once we have the initial support in place, of course, we want to make sure that this works on real devices and as we Transitioned to those more and more we've developed some Helpers to let you debug better. What's happening Bluetooth wise there? We have something called the monitor protocol Which is a binary protocol which interleaves the h.i. traffic as well as the normal logs from Zephyr and With a special kconfig option you enable it it transforms the The console you are from a text-based console into this binary protocol. It will install its own hooks So any place in the kernel that does printf or printk those will actually go through the encoding functions and get transformed into this binary protocol and then on the other side We have support with the Lucy BT mon tool for actually decoding this so you would give you would connect your Zephyr board With a serial cable or share out the USB to Your Linux laptop and you would run BT mon there you would give the tty device To be team on and you would then see interleaved all the h.i. traffic that happens as well as all the log messages that happen And that's a very nice way of Tracing what's happening on your Zephyr based board There's actually another talk after mine in this same room by Lewis von Denz He's going to talk more about the joint usage of bluesie and Zephyr and how they have benefited each other so on to the Controller implementation I mentioned earlier. So I find this a really happy nice thing because until before this year there was basically no Bluetooth open source Bluetooth firmware implementation available and The other open source Bluetooth stacks that they were they were from HCI upward but early this year the minute project released their implementation for Bluetooth controllers and slowly after It wasn't I think within a month or so after so it wasn't slowly Nordic semiconductor released their own implementation of the LA controller and So we basically now have two different options for open source firmware for Bluetooth controllers We've been working together with Nordic now for quite some time cleaning up the code making sure it adheres to the Zephyr Coding style that it takes the maximum benefit out of the infrastructure that we have in Zephyr of the different Objects that we have available there and interrupts and so on and it's going to be part of the next Zephyr release The layer the official layer that this actually implements is the LA link layer So that's the one which sits basically between the hardware and the HCI It's very capable the implementation. It's hooked up to K config So when you define things like number of connections that you want to have for the host stack the controller also makes use of the same config options and It will use exactly the amount of resources needed for that nothing extra. It's also very flexible that unlike many LA controllers out there that you can do Pretty much any combination of connected roles. You can have multiple slave connections. You can have multiple Central master role connections. You can have combinations of those I it's only limiting factors how much runtime memory you have and what exactly you said in K config that you need to have Since it's coming from Nordic the first radios that this supporting is their radios the nrf 52 and the nrf 51 But we are trying to create a radio health abstraction so you could have it run on other radios as well and I expect to see that happening now There have been a couple of companies. I've been talking to here at this conference For example that are interested in in porting this link layer onto their radios and then since You would have the host basically running on the same CPU. We're still using HCI between the host and the controller But there's no physical transport as such So we have the network buffers that are going from the controller to the host But from the host perspective, it doesn't really matter. Is it running on the same core or is it running on another core over some physical transport and Since we have all the flexibility of different features We also have the flexibility of configuring different kinds of combinations of host and controller functionality so depending on what your needs are you can make controller only build basically a HCI firmware build with Zephyr and You would have a very simple Application running which exposes which hooks on to the physical transport and exposes the HCI there. We already have a USB Sample actually so if you have a Zephyr device which has USB device support You can make that into a Bluetooth dongle that you can plug into your PC and use it like that We're very soon going to have UART Based sample and a spy based one also Then what we were using for a long time before the controller Contribution came along is the host only configuration and in this configuration you have an HCI driver Which hooks on to an actual physical transport like UART and then the controller itself is on a different core and you can Build both the host and the controller if you want the full stack on a single core as well Some more details and samples of where you would actually use these different kind of configurations Intel has the Arduino 101 board. It has a Nordic NR51 controller on it and it has a Quark SE on it So the natural thing to do is to run a controller only configuration on an NR51 have a simple HCI over UART application running there and then run the second instance of Zephyr on the Quark SE where you have the host on the configuration and Connecting to the second Zephyr running on the NR51 We now announced their carbon board at Linaro connect very recently It's very similar in this sense to Intel's Arduino 101 instead of Quark SE it has a Cortex-M4 and Instead of UART between these two cores it has pi, but otherwise they actually demoed the host only configuration running on the The Cortex-M4 and then the controller only on the NR51 and Then if you have just a single core you can of course run everything And enough memory for this also then you're gonna run everything on a single core Good example is the NR52 from Nordic, which is more capable than the NR51 and That's actually that's been used also for testing this new controller support from Nordic that we run both the host and the controller on a single board like that We've been focusing a lot on low energy, but There can be a need or want of companies to create dual mode solutions also I don't know smart headsets or something like that Or in general if you want support for legacy devices, which don't have any support for example There are very few cars car kits out there that have any support. So we've started Implementing support for Bluetooth classic as well Current status is that we have the generic access profile there and we have the basic low-level protocols in place like L2CUP and RFCON and there are a couple of higher level profiles that we are working on like As we profile and ATDP which are for audio streaming and also AVRCP which is for controlling the playback on a device So how does it look like then now on onward? After this conference it looks like Or I hope it it's gonna happen that we will be receiving more and more people joining in into the work to help out This is a list of some of the things that that we are working on and we welcome help one So we want to make sure that whenever there are new standards coming out that Zephyr supports them as well as possible So we are working on on Bluetooth 5, which is the next with the specification coming out on on Bluetooth mesh Which is also supposed to be come out soon one kind of challenge when it comes to an open source project and Upcoming standards Especially Bluetooth standards is that unfortunately, we cannot work in the open so the Bluetooth Sieg rule state that we cannot publish any information that isn't public through the Sieg yet, so What we can do is Until the moment that the specification goes public is that those companies that are interested to collaborate on these features Who have access who are Bluetooth Sieg members and have access to the standards we can create Private repositories and collaborate code on there and then once the specification goes public will immediately Pursuit to the public care it and then try to get it integrated there Another thing we want to be working on as I mentioned is supporting the controller support the li link layer to support as many radios as possible It will be an interesting test because How well we define the radio hardware abstraction layer because the nr 51 and the nr 52 are quite Similar and it's possible that they are very different looking radio interfaces for other radios It's possible that we need to do some extra abstractions there I've seen that some companies implement a lot of the link layer in hardware So you wouldn't need to run it in software and we may need to define some kind of standard link layer interface And then we can reuse at least the HG adaptation For different radios even though we don't reuse the full link layer implementation for them When we initially got the contribution for the link layer there was very little integration using the native objects that separate provides But it is getting better with I think the HL layer is already using net buff natively there on the link layer side But the further down we can push the buffer usage that the more efficient it will become because we don't need to copy data as it goes up or down the layers and There are some missing features. We still want to implement one is a link layer privacy, which basically pushes the Identity resolution of Devices using private random addresses down to the controller instead of the host needing to do it The main reason why we don't yet have it is that we just haven't had hardware that exposes this interface But we should be able to do it for example with the link layer Implementation is effort itself now To make sure it works and yeah All of these are areas where we welcome anybody interested to work on them to join the project as it's open The only exception as I mentioned are the not yet released standards where we need to simply You can contact me and we can arrange that we have some common repository to work on assuming that your company's a member of the Seagun has access to the specifications already and that's actually what I had so Welcome any questions if you have Yes Yes, which one which energy is it? Yeah, I've heard about it, but which controller has it? Okay, so it's an error 51 based. I think it should be possible the Intel Arduino 101 the nr 51 there it has 16 kilobytes of RAM and then we can at least fit the controller on the configuration there The narrow tells me that the current bill is about 13 kilobytes. So there's a little bit to go to add more stuff there If you want to run a minimal host the Carbon board from the narrow it has 32 kilobytes of RAM so there you'd for sure be able to run the full host and actually most of the Development kits I've seen from Nordic as well as there they have USB dongles which have the nr 51 Those are all 32 kilobyte RAM variants and I've seen there's a host running there on those So I would if it's the 32 Is it 16 Yeah, and you And you would set the number of connections probably to one and so on just to get rid of everything unnecessary Yeah Yeah, we would say basically you wouldn't have Much overhead at all and you add new connections Any other questions? All right. Well, I'll be around so if you have something just come and ask me