mirror of
https://github.com/bluekitchen/btstack.git
synced 2025-03-25 07:43:38 +00:00
docs: spelling fixes from eaec219ce0
This commit is contained in:
Matthias Ringwald
parent
5d5a5a9cd5
commit
f5aa8d7048
@ -1,6 +1,6 @@
|
||||
We already had two listings with the Bluetooth SIG, but no official BTstack v1.0 release. After the second listing, we decided that it's time for a major overhaul of the API - making it easier for new users.
|
||||
|
||||
In the following, we provide an overview of the changes and guidelines for updating an existing code base. At the end, we present a command line tool and as an alternative a Web service, that can simplify the migration to hte new v1.0 API.
|
||||
In the following, we provide an overview of the changes and guidelines for updating an existing code base. At the end, we present a command line tool and as an alternative a Web service, that can simplify the migration to the new v1.0 API.
|
||||
|
||||
# Changes
|
||||
|
||||
|
||||
@ -488,10 +488,10 @@ to the btstack_config.h and recompiling your application.
|
||||
|
||||
## Bluetooth Power Control {#sec:powerControl}
|
||||
|
||||
In most BTstack examples, the device is set to be discoverable and connectable. In this mode, even when there's no active connection, the Bluetooth Controller will periodicaly activate its receiver in order to listen for inquiries or connecting requests from another device.
|
||||
In most BTstack examples, the device is set to be discoverable and connectable. In this mode, even when there's no active connection, the Bluetooth Controller will periodically activate its receiver in order to listen for inquiries or connecting requests from another device.
|
||||
The ability to be discoverable requires more energy than the ability to be connected. Being discoverable also announces the device to anybody in the area. Therefore, it is a good idea to pause listening for inquiries when not needed. Other devices that have your Bluetooth address can still connect to your device.
|
||||
|
||||
To enable/disable discoverabilty, you can call:
|
||||
To enable/disable discoverability, you can call:
|
||||
|
||||
/**
|
||||
* @brief Allows to control if device is discoverable. OFF by default.
|
||||
@ -519,7 +519,7 @@ To enable/disable advertisements, you can call:
|
||||
*/
|
||||
void gap_advertisements_enable(int enabled);
|
||||
|
||||
If a Bluetooth Controller is neither discoverable nor conectable, it does not need to periodically turn on its radio and it only needs to respond to commands from the Host. In this case, the Bluetooth Controller is free to enter some kind of deep sleep where the power consumption is minimal.
|
||||
If a Bluetooth Controller is neither discoverable nor connectable, it does not need to periodically turn on its radio and it only needs to respond to commands from the Host. In this case, the Bluetooth Controller is free to enter some kind of deep sleep where the power consumption is minimal.
|
||||
|
||||
Finally, if that's not sufficient for your application, you could request BTstack to shutdown the Bluetooth Controller. For this, the "on" and "off" functions in the btstack_control_t struct must be implemented. To shutdown the Bluetooth Controller, you can call:
|
||||
|
||||
|
||||
@ -71,4 +71,3 @@ common options:
|
||||
more flexibility.
|
||||
|
||||
 {#fig:MTDaemon}
|
||||
|
||||
@ -140,15 +140,15 @@ callback for CTS interrupts.
|
||||
### H5
|
||||
|
||||
H5, makes use of the SLIP protocol to transmit a packet and can deal
|
||||
with packet loss and bit-errors by retranssion. Since it can recover
|
||||
with packet loss and bit-errors by retransmission. Since it can recover
|
||||
from packet loss, it's also possible for either side to enter sleep
|
||||
mode without loosing synchronization.
|
||||
|
||||
The use of hardware flow control in H5 is ooptional, however, since
|
||||
The use of hardware flow control in H5 is optional, however, since
|
||||
BTstack uses hardware flow control to avoid packet buffers, it's
|
||||
recommended to only use H5 with RTS/CTS as well.
|
||||
|
||||
For porting, the implementation follows the regular H4 procotol described above.
|
||||
For porting, the implementation follows the regular H4 protocol described above.
|
||||
|
||||
## Persistent Storage APIs {#sec:persistentStoragePorting}
|
||||
|
||||
|
||||
@ -239,7 +239,7 @@ shows how this is accomplished.
|
||||
### Providing a PANU service
|
||||
|
||||
To provide a PANU service, you need to provide a BNEP service with the
|
||||
service UUID, e.g. the PANU UUID, and a a maximal ethernet frame size,
|
||||
service UUID, e.g. the PANU UUID, and a maximal ethernet frame size,
|
||||
as explained in Section [on BNEP service](protocols/#sec:bnepServiceProtocols). Then, you need to
|
||||
create an SDP record for it and publish it with the SDP server by
|
||||
calling *sdp_register_service*. BTstack provides the
|
||||
|
||||
@ -326,7 +326,7 @@ The remainder of the API is similar to the one of L2CAP:
|
||||
## RFCOMM - Radio Frequency Communication Protocol
|
||||
|
||||
The Radio frequency communication (RFCOMM) protocol provides emulation
|
||||
of serial ports over the L2CAP protocol. and reassembly. It is the base
|
||||
of serial ports over the L2CAP protocol and reassembly. It is the base
|
||||
for the Serial Port Profile and other profiles used for
|
||||
telecommunication like Head-Set Profile, Hands-Free Profile, Object
|
||||
Exchange (OBEX) etc.
|
||||
@ -596,7 +596,7 @@ BTstack contains a complete SDP server and allows to register SDP
|
||||
records. An SDP record is a list of SDP Attribute *{ID, Value}* pairs
|
||||
that are stored in a Data Element Sequence (DES). The Attribute ID is a
|
||||
16-bit number, the value can be of other simple types like integers or
|
||||
strings or can itselff contain other DES.
|
||||
strings or can itself contain other DES.
|
||||
|
||||
To create an SDP record for an SPP service, you can call
|
||||
*spp_create_sdp_record* from with a pointer to a buffer to store the
|
||||
@ -797,7 +797,7 @@ Long Term Key (LTK) is generated based on the local keypair and the remote publi
|
||||
To facilitate the creation of such a keypairs and the calculation of the LTK,
|
||||
the Bluetooth Core V4.2 specification introduced appropriate commands for the Bluetooth controller.
|
||||
|
||||
As an alternative for controllers that don't provide these primitives, BTstack provides the relevant crytographic functions in software via the Apache 2.0 licensed [mbed TLS library](https://tls.mbed.org).
|
||||
As an alternative for controllers that don't provide these primitives, BTstack provides the relevant cryptographic functions in software via the Apache 2.0 licensed [mbed TLS library](https://tls.mbed.org).
|
||||
|
||||
There are two details to be aware about using LE Secure Connections:
|
||||
|
||||
@ -899,7 +899,7 @@ After the bonding process, *SM_EVENT_JUST_WORKS_CANCEL*, *SM_EVENT_PASSKEY_DISPL
|
||||
|
||||
### Keypress Notifications
|
||||
|
||||
As part of Bluetooth Core V4.2 specification, a device with a keyboard but no display can send keypress notifications to provide better user feedback. In BTstack, the *sm_keypress_notification()* function is used for sending notifcations. Notifications are received by BTstack via the *SM_EVENT_KEYPRESS_NOTIFICATION* event.
|
||||
As part of Bluetooth Core V4.2 specification, a device with a keyboard but no display can send keypress notifications to provide better user feedback. In BTstack, the *sm_keypress_notification()* function is used for sending notifications. Notifications are received by BTstack via the *SM_EVENT_KEYPRESS_NOTIFICATION* event.
|
||||
|
||||
### Cross-transport Key Derivation for LE Secure Connections
|
||||
|
||||
@ -910,7 +910,7 @@ To derive an LE LTK from a BR/EDR link key, the Bluetooth controller needs to su
|
||||
### Out-of-Band Data with LE Legacy Pairing
|
||||
|
||||
LE Legacy Pairing can be made secure by providing a way for both devices
|
||||
to aquire a pre-shared secret 16 byte key by some fancy method.
|
||||
to acquire a pre-shared secret 16 byte key by some fancy method.
|
||||
In most cases, this is not an option, especially since popular OS like iOS
|
||||
don’t provide a way to specify it. In some applications, where both
|
||||
sides of a Bluetooth link are developed together, this could provide a
|
||||
|
||||
@ -94,7 +94,7 @@ to [C:\mspgcc](). Add [C:\mspgcc\bin]() folder to the Windows Path in Environmen
|
||||
variable as explained [here](#sec:windowsPathQuickStart).
|
||||
|
||||
**Loading Firmware.** To load firmware files onto the MSP430 MCU for the
|
||||
MSP-EXP430F5438 Experimeneter board, you need a programmer like the
|
||||
MSP-EXP430F5438 Experimenter board, you need a programmer like the
|
||||
MSP430 MSP-FET430UIF debugger or something similar. The eZ430-RF2560 and
|
||||
MSP430F5529LP contain a basic debugger. Now, you can use one of
|
||||
following software tools:
|
||||
|
||||
@ -38,7 +38,7 @@
|
||||
/*
|
||||
* hci_transport.h
|
||||
*
|
||||
* HCI Transport API -- allows BT Daemon to use different transport protcols
|
||||
* HCI Transport API -- allows BTstack to use different transport interfaces
|
||||
*
|
||||
* Created by Matthias Ringwald on 4/29/09.
|
||||
*
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user