[REFERENCE]: BLE master/slave, GATT client/server, and data RX/TX basics
Jeff Rowberg
posted this on July 31,【CC254X_BLE】配对与绑定实验 - huanghai381的日志 -
电子工程世界-论坛
【CC254X_BLE】配对与绑定实验
热度 1已有 7321 次阅读 12:47
|个人分类:
是在基于协议栈的demo：SimpleBLEperipheral
添加了密码配对与绑定。在simplebleperipheral.c中定义状态变量和管理配对的回调函数声明//
Application
statesenum{&&BLE_STATE_IDLE,&&BLE_STATE_CONNECTED,};//
Application statestatic uint8 simpleBLEState = BLE_STATE_IDLE;//ghostyu
bondstatic uint8
gPairStatus=0;/*用来管理当前的状态，如果密码不正确，立即取消连接，0表示未配对，1表示已配对*/void
ProcessPasscodeCB(uint8 *deviceAddr,uint16 connectionHandle,uint8 uiInputs,uint8
uiOutputs );static void ProcessPairStateCB( uint16 connHandle, uint8 state,
uint8 status );//注册回调函数//要实现密码绑定，首先需要实现bongmgr的回调函数。// GAP
Bond Manager Callbacksstatic gapBondCBs_t simpleBLEPeripheral_BondMgrCBs
={&&ProcessPasscodeCB,&&&&&&&&&&&&&&&&&&&&&&//
密码回调&&ProcessPairStateCB&&&&&&&&&&&&&&&&&&&&&&//
绑定状态回调};在从机初始化函数void SimpleBLEPeripheral_Init( uint8 task_id
)中修改这一段中&&// Setup the GAP Bond Manager&&{&&&&uint32 passkey
= 0; // passkey "000000"&&&&//uint8 pairMode =
GAPBOND_PAIRING_MODE_WAIT_FOR_REQ;//除非其中一个配置成GAPBOND_PAIRING_MODE_INITIATE,
如果是central的话会发起pairing request, 如果是peripheral的话会发起slave security request,
//最终会导致central那端收到 GAP_SLAVE_REQUESTED_SECURITY_EVENT, 这个时候你看代码,
如果central也是出于GAPBOND_PAIRING_MODE_WAIT_FOR_REQ,//那么他还是会发起配对.//所以,
只要其中一个设置成GAPBOND_PAIRING_MODE_INITIATE, 两边就会配对,
如果都是GAPBOND_PAIRING_MODE_WAIT_FOR_REQ, 那么就没有配对过程.&&&&uint8 pairMode =
GAPBOND_PAIRING_MODE_INITIATE;//GAPBOND_PAIRING_MODE_INITIATE一方设置为初始化就可以实现连接&&&&uint8
mitm = TRUE;&&&&uint8 ioCap =
GAPBOND_IO_CAP_DISPLAY_ONLY;//只有显示设备&&&&uint8 bonding =
TRUE;&&&&//配置上述定义&&&&GAPBondMgr_SetParameter( GAPBOND_DEFAULT_PASSCODE,
sizeof ( uint32 ), &passkey );&&&&GAPBondMgr_SetParameter(
GAPBOND_PAIRING_MODE, sizeof ( uint8 ), &pairMode
);&&&&GAPBondMgr_SetParameter( GAPBOND_MITM_PROTECTION, sizeof ( uint8 ),
&mitm );&&&&GAPBondMgr_SetParameter( GAPBOND_IO_CAPABILITIES, sizeof (
uint8 ), &ioCap );&&&&GAPBondMgr_SetParameter( GAPBOND_BONDING_ENABLED,
sizeof ( uint8 ), &bonding
);&&}再来详细看看那两个回调函数的处理：//绑定过程中的密码管理回调函数static void
ProcessPasscodeCB(uint8 *deviceAddr,uint16 connectionHandle,uint8 uiInputs,uint8
uiOutputs ){&&uint32&&passcode=123456;&&uint8&&
str[7];&&//在这里可以设置存储，保存之前设定的密码，这样就可以动态修改配对密码了。&&// Create random
passcode&&LL_Rand( ((uint8 *) &passcode), sizeof( uint32
));&&passcode %= 1000000;&&//在lcd上显示当前的密码，这样手机端，根据此密码连接。&&//
Display passcode to user&&if ( uiOutputs != 0
)&&{&&&&HalLcdWriteString( "Passcode:",&&HAL_LCD_LINE_1
);&&&&HalLcdWriteString( (char *) _ltoa(passcode, str, 10),&&HAL_LCD_LINE_2
);&&}&&&&// Send passcode response&&GAPBondMgr_PasscodeRsp(
connectionHandle, SUCCESS, passcode
);}//绑定过程中的状态管理，在这里可以设置标志位，当密码不正确时不允许连接。static void
ProcessPairStateCB( uint16 connHandle, uint8 state, uint8 status ){&&if
( state == GAPBOND_PAIRING_STATE_STARTED
)/*主机发起连接，会进入开始绑定状态*/&&{&&&&HalLcdWriteString( "Pairing started",
HAL_LCD_LINE_1 );&&&&gPairStatus = 0;&&}&&else if ( state ==
GAPBOND_PAIRING_STATE_COMPLETE )/*当主机提交密码后，会进入完成*/&&{&&&&if ( status ==
SUCCESS )&&&&{&&&&&&HalLcdWriteString( "Pairing success", HAL_LCD_LINE_1
);/*密码正确*/&&&&&&gPairStatus =
1;&&&&}&&&&else&&&&{&&&&&&HalLcdWriteStringValue( "Pairing
fail", status, 10, HAL_LCD_LINE_1 );/*密码不正确，或者先前已经绑定*/&&&&&&if(status
==8){/*已绑定*/&&&&&&&&gPairStatus = 1;&&&&&&}else{&&&&&&&&gPairStatus
= 0;&&&&&&}&&&&}&&&&//判断配对结果，如果不正确立刻停止连接。&&&&if(simpleBLEState
== BLE_STATE_CONNECTED && gPairStatus
!=1){&&&&&&GAPRole_TerminateConnection();&&&&}&&}&&else if (
state == GAPBOND_PAIRING_STATE_BONDED )&&{&&&&if ( status == SUCCESS
)&&&&{&&&&&&HalLcdWriteString( "Bonding success", HAL_LCD_LINE_1
);&&&&}&&}}烧写程序后，用ios上的lightblue软件去找设备并尝试去连接，发现需要输入配对密码了，输入CC2540那边LCD上显示的密码，就可以完成配对下次重连时就不用再配对了！故意输错就会断开连接。
图片:xxx.jpg
作者的其他最新日志
评论 ( 个评论)
Powered byFrom Texas Instruments Wiki
This is the FAQ (Frequently Asked Questions) list of TI's BLE (Bluetooth Low Energy) solution.
BLE (Bluetooth Low Energy) is part of the
from Bluetooth SIG which defines the the classic Bluetooth legacy protocols, the Wi-Fi based Bluetooth high speed, and also the Bluetooth Lew Energy (BLE). The BLE is defined as subset of Bluetooth v4.0 aiming low power, low latency, and low throughput applications with completely different new protocol which is not compatible with the other legacy Bluetooth protocols.
The single-mode BLE device implements only the new BLE protocol while the dual-mode BLE device implementation is also integrated with the classic Bluetooth protocol.
Almost all CC2541 I/Os are available on jumper P1 and/or P10 on the SmartRF05 board:
I/O Mapping
If you are implementing the POWER_SAVING (using the 1 uA PM2 sleep) in your CC254x design, an accurate 32 kHz clock is needed for the sleep timer to maintain the connection timing required by BLE. If you are mains powered, for example, and do not need to use the POWER_SAVING feature, the timing is maintained with the 32 MHz crystal and no 32 kHz crystal is needed.
According to the Bluetooth 4.0 Core Specifications, a peer device with up to 500 PPM frequency deviation on its sleep clock must be accepted. When selecting a 32.768kHz crystal for a custom board, therefore, you may choose one with up to 500 PPM spread in the production around the expected value. In TI's BLE stacks, a default PPM value of 40 is used for peripheral- and 50 for central devices. If you select a more inaccurate crystal, this must be compensated in software. To compensate for sleep clock inaccuracy you can use the command HCI_EXT_SetSCACmd(&ppm_val&); which must be executed during initialization of the device. For central devices, this value is used internally for compensation and also converted to a BLE Spec-defined ordinal which tells peripheral devices how much drift they can expect. For peripheral devices this value is used directly, as the central/initiating device always transmits first in a connection event. Read more about this command in the Vendor Specific HCI Guide included in the TI BLE stack. The drawback of using a clock with a wider distribution is that the software compensation entails widening the RX-window. That is, the time the device spends listening before the 'real' beginning of a connection event in case either peer has drifted. This consumes more power.
Power measurements over time can be carried out on e.g. a CC2540 KeyFob by following the instructions in our Application Note .The application note includes details on how to modify the board, an example measurement and an Excel spreadsheet template for inputting measured data and automatically compute average power consumption.
These measurements were carried out with a CC2541 with a TPS62730 DC-DC step-down converter. Battery life is based on an ideal 230 mAh battery.
SimpleBLEPeripheral - Advertising
Time awake: 3.9 ms: 1.28 ms processing after Rx/Tx
Average current draw for event only: 8.6 mA
Average current draw with 1s interval: 0.035 mA / ~260 days continuously
SimpleBLEPeripheral - Empty connection event
Time awake: 3.0 ms: 1.3 ms processing after Rx/Tx
Average current draw for event only: 8.9 mA
Average current draw with 1s interval: 0.028 mA / ~327 days continuously
SimpleBLEPeripheral - Read request to KeyFob, 1 characteristic
Time awake: 5.7 ms: 3.9 ms processing after Rx/Tx
Average current draw for event only: 7.5 mA
Average current draw with 1s interval: 0.044 mA / ~208 days continuously
SimpleBLEPeripheral - Read response from KeyFob, 1 characteristic, 1 byte
Time awake: 2.8 ms: 1.3 ms processing after Rx/Tx
Average current draw for event only: 8.6 mA
Average current draw with 1s interval: 0.026 mA / ~352 days continuously
SimpleBLEPeripheral - Write request to KeyFob, 1 characteristic, 1 byte
Time awake: 5.9 ms: 4.1 ms processing after Rx/Tx
Average current draw for event only: 7.5 mA
Average current draw with 1s interval: 0.045 mA / ~200 days continuously
SimpleBLEPeripheral - Write response from KeyFob, 1 characteristic
Time awake: 3.1 ms: 1.4 ms processing after Rx/Tx
Average current draw for event only: 8.8 mA
Average current draw with 1s interval: 0.028 mA / ~327 days continuously
SimpleBLEPeripheral - Notification from KeyFob, 1 byte
Time awake: 3.2 ms: 1.4 ms processing after Rx/Tx
Average current draw for event only: 8.8 mA
Average current draw with 1s interval: 0.029 mA / ~316 days continuously
SimpleBLEPeripheral - Notification from KeyFob, 60 bytes looped
Time awake: 8.8 ms: 5.8 ms processing after Rx/Tx
Average current draw for event only: 7.89 mA
Average current draw with 1s interval: 0.071 mA / ~135 days continuously
Please refer: .
The BLE-Stack contains example code with HAL (Hardware Abstraction Layers) which can be used as the peripheral drivers. Since the CC254x shares the same peripherals as the CC253x (Zigbee SoC), example codes for CC253x peripherals should also apply to CC254x.
Others can be found as follows:
The BLE standard does not really define the maximum number of devices (see ), but using the BLE-Stack (starting from v1.1) the master shall support up to 3 simultaneous connections.
The following is taken from the Release Notes of BLE-Stack v1.1 and v1.2:
Version 1.2
Feb 13, 2012
- Multi-role and combo-role support has been enhanced. The BLE stack can now
support simultaneously advertising and/or scanning while in a connection as
either a master or a slave. This allows for a central device to perform
device discovery while in a connection. All previous rules for multiple
simultaneous connections as a central device still apply (see v1.1a release
notes below).
Version 1.1
July 13, 2011
Changes and Enhancements:
- The stack now supports up to 3 simultaneous connection as a central / master
device, with a few constraints:
- All connection intervals must be a multiple of the minimum connection
interval (i.e. the minimum connection interval is the greatest common
denominator of all connection intervals).
- The minimum connection interval allowed is 25ms when using more than
one connection.
- When more than one connection is active, only one data packet per
connection event will be allowed in each direction.
There's been a change in v1.3 of the stack to the max timeout for limited advertising, it's now 180 seconds instead of 30.72. This to follow Bluetooth spec addendum. See
for more information on how to change this.
With the Vendor Specific HCI command HCI_EXT_SetTxPowerCmd(). Allowed paramters:
HCI_EXT_TX_POWER_MINUS_23_DBM
HCI_EXT_TX_POWER_MINUS_6_DBM
HCI_EXT_TX_POWER_0_DBM
HCI_EXT_TX_POWER_4_DBM (CC2540 Only)
Sometimes you want to change the connection interval and slave latency from the peripheral side to conserve power, especially when connection to an iOS device.
To do this, you can call the function
bStatus_t GAPRole_SendUpdateParam( uint16 minConnInterval, uint16 maxConnInterval, uint16 latency, uint16 connTimeout, uint8 handleFailure )
which is defined and documented in peripheral.c and will send an L2CAP request for parameter update.
Alternatively, see example in simpleBLEperipheral.c, change #define DEFAULT_ENABLE_UPDATE_REQUEST to TRUE near the top and fiddle with the desired parameters. This will cause peripheral.c to issue an update request on the GAP_LINK_ESTABLISHED_EVENT of its gapRole_ProcessGAPMsg(). See simpleBLEperipheral's task init to see how this GAPRole data is communicated to peripheral.c.
Be sure to follow
when doing this, as there are limitations on acceptable parameters.
For BLE-Stack v.1.3, TI recommends to use IAR 8051 EWB 8.10.4 or 8.11.4. For downloading the specific IAR 8051 EWB please refer .
For a workaround for the SLEEP_CODE segment error, use this .
At the moment for BLE-Stack v1.3.x, the BLE-Stack can only be compiled using the
version 8.x. No other IDE is possible as part of BLE-Stack is released in binary library format which can only work with the IAR compiler.
We recommend using IAR 8.10.4, as that's what the library files have been compiled with and the stack has been tested with.
The answer varies depending on the stack configurations. To give some numbers, the following memory footprint is acquired from the current BLE-Stack examples (as is) compiled using IAR 8051 EWB v8.11.1:
Project Name
Memory Footprint
SimpleBLECentral-CC2540EM
118 379 bytes of CODE
29 bytes of DATA
memory (+ 81 absolute )
7 246 bytes of XDATA memory
194 bytes of IDATA memory
4 360 bytes of CONST memory
SimpleBLECentral-CC2541EM
121 188 bytes of CODE
29 bytes of DATA
memory (+ 81 absolute )
7 246 bytes of XDATA memory
194 bytes of IDATA memory
792 bytes of CONST memory
SimpleBLEObserver-CC2540EM
38 926 bytes of CODE
29 bytes of DATA
memory (+ 81 absolute )
3 272 bytes of XDATA memory
194 bytes of IDATA memory
3 847 bytes of CONST memory
SimpleBLEPeripheral-CC2541DK-MINI Keyfob
108 502 bytes of CODE
35 bytes of DATA
memory (+ 72 absolute )
6 270 bytes of XDATA memory
194 bytes of IDATA memory
4 145 bytes of CONST memory
SimpleBLEPeripheral-CC2540EM
110 648 bytes of CODE
35 bytes of DATA
memory (+ 72 absolute )
6 270 bytes of XDATA memory
194 bytes of IDATA memory
581 bytes of CONST memory
Heartrate-CC2540DK-MINI Keyfob Slave
108 110 bytes of CODE
35 bytes of DATA
memory (+ 74 absolute )
6 113 bytes of XDATA memory
194 bytes of IDATA memory
4 151 bytes of CONST memory蓝牙4.0 BLE
协议栈的研究 TI CC2540 CC2541 OSAL-海文库
全站搜索：
您现在的位置：&>&&>&工学
蓝牙4.0 BLE
协议栈的研究 TI CC2540 CC2541 OSAL
是一种支持短距离通讯的无线技术，主要工作在2.4GHz频带。至今分为五个版本1.1，1.2,2.0,3.0,4.0（4.1），现在市面上流行三种设备传统蓝牙（Bluetooth简称BR），低功耗蓝牙（bluetoothSmart即是Bluetooth Low Energy简称BLE，蓝牙4.0（BluetoothSmartReady即是BR+BLE））b
蓝牙4.0由传统蓝牙，高速蓝牙和蓝牙低功耗三种规范合成。其中常用的有两种模式（单模-&支持（BLE）和双模-&支持（BLE+BR））。我们用的CC2540是单模芯片。c
蓝牙4.0中的BLE（蓝牙低功耗Bluetooth Low Energy）定义了两个频段2.4Ghz（16个信道896/915MHz（896M一个信道915M十个信道），共27个信道。速度：支持1Mbps数据传输率下的超短数据包。所有连接都使用蓝牙2.1加入的减速呼吸模式（sniff
subrating）来达到超低工作循环跳频：蓝牙规范自适应跳频技术主控制：更加智能，可以休眠更长时间，只在需要执行动作的时候才唤醒。延迟：可在3ms内实现连接并设置数据传输。范围：提高调制指数，最大范围可到100m健壮性：所有数据包都经过24bitCRC校验。确保最大程度抵御干扰。安全：使用AES128 CCM加密算法进行数据包加密和认证。拓扑：每个数据包的每次接收都是用32位寻址，理论上可连接十亿台设备。针对一对一连接，并支持新型拓扑的一对多连接。d
蓝牙4.0总共40个信道，都分布在2.4GHz，其中0.12.39三个信道用来广播信息。e
蓝牙4.0的引起超低的功耗而备受瞩目。是3.0的升级版，较3.0更加省电，成本更低，3ms低延迟，超长有效连接距离，AES-128加密；
2.BLEa.蓝牙4.0规范中的一种，其中master最多有7个外设，低功耗，低延迟，低吞吐量。 b．六种设备状态待机状态（standby）：设备没有传输和发送数据，并且没有连接到任何设备广播状态（Advertiser）：周期性广播状态扫描状态（Scanner）：主动寻找正在广播的设备发起链接状态（Initiator）：主动向扫描设备发起连接。主设备（Master）:作为主设备连接到其他设备。从设备（Slave）：作为从设备连接到其他设备。五种工作状态准备（standby），广播（advertising），监听扫描（Scanning），发起连接（Initiating），已连接（Connected）四种设备类型Cnetral主机（常作为client端）：如手机，PCPeripheral从机（常作为Service端）：如心率计，血糖计Observer观察者：Broadcast广播者：连接过程：Peripheral开启广播--&Central扫描从机广播--&Peripheral接收到Central的扫描请求，Peripheral向Central发送扫描回应数据--&Central向Peripheral发起连接--&开始通信。c．BLE中的连接参数（ConnectionEvent==确认连接应答信号--&设备大多数情况下都在Sleep状态下，每个ConnectionEvent都由Master发起包，在由Slaver回复）参数1：Connection Interva--&l两个ConnectionEvent之间的空闲值，单位为1.25ms，最小7.5ms，最大4s。参数2：Slave Latency--&Slaver设备没有数据要发时，跳过一定数目的ConnectionEvent的值，Rang：0-499.参数3：Supervision Timeout--&超时时间，就是两个设备在连接的这段时间没有发生通讯而导致连接自动断开的值。Range（10ms-----32s）但是必须满足以下条件参数3&=参数1*（参数2+1）。d． 兼容性
BLE协议结构
a. 结构可分为三大层（控制层（controller）?（HCI、LL、PHY））协议层（Host）?（L2CAP、SM、ATT、GATT、GAP）应用层（App）?（GATT Profile和GAP Role/Security Profiles）b. 各层单元逻辑PHY ?物理层：主要是射频和电路部分LL ?链路控制层：通过计算器的设置来控制物理层HCI ?通讯层：向host和controller提供一个标准化接口，该层可以由软件api实现或者用硬件接口UART SPI USB 来控制L2CAP?逻辑链路控制和适配层：负责逻辑链路的连接以及事件的分发，位于基带协议之上。 L2CAP向上层提供面向连接的和无连接的数据服务。它的功能包括：协议的复用能力、分组的分割和重新组装以及数据组提取。L2CAP允许高层协议和应用发送和接受高达64Byte的数据分组SM?安全服务层：提供配对密匙的发放，实现安全链接和数据交换ATT?属性层：是BLE中一个很重要的一层，所有的数据都要经过这层，展示属性的称为服务器，与之配对的称为客户端。主机设备可以是服务器也可以是客户端规定了Client和Server两个角色，数据存在Service端，以Attribute形式存在，Client则以读或写的方式来对Server端数据进行操作GATT?定义使用ATT的服务框架GATT规定了配置文件（profile）结构。在BLE中所有的profile或者服务用到的数据块都称为“特性”characteristic，基于ATT层更加细化的根据性质把传输的数据分成特定的类并标上UUID（每类ATT也有一个独特的UUID） GAP?主要用于设备查找，连接建立，广播发送接收的一些控制APP层：Profile定义的是特定的一个使用环境，相同的也有个UUIDc. 名词解释Profile：可以理解成是一种规范，蓝牙组织规定了一系列的profile,如心率计，防丢器等。每个Profile中都会包含多个ServiceService：可以理解成一个服务，在ble从机中，通过多个服务（如电量信息服务，系统信息服务等），每个Service里面包含多个Characteristic特征值。Characteristic特征值才是bel的主体，（如：点量80%。会通过电量的Characteristic特征值存在从机的profile里，这样主机可以通过这个Characteristic来读取80%这个数据。）Characteristic：Characteristic特征值，主从机的通讯全是通过Characteristic来实现的，可以理解为一个标签，通过这个标签可以获取或者写入想要的内容UUID：统一识别码我们刚才提到的Service和Characteristic，都需要一个唯一的UUID来标识。
CC2540a． 芯片特性内部由一个51内核和基本外设构成，时钟频率可达32MHz，机器周期为一个时钟周期， 拥有内部阻容振荡器，8KBRAM，256KBFlash5通道DMA，1个16位，两个8位定时器，红外生成电路，32KHz有捕捉功能睡眠定时器数字信号强度指示器（RSSI），电池监视和温度感应器，8通道12位ADC，2个UART，USB 拥有SmartReadyBlueTooth两个模式，CC2541支持（BR和BLE模式）传输速率：低于100kbps
b． 引脚分配
c． 最小系统
d． OSAL系统
上一篇： 下一篇：
All rights reserved Powered by
copyright &copyright 。文档资料库内容来自网络，如有侵犯请联系客服。}