BTM02E08蓝牙模块.docx
《BTM02E08蓝牙模块.docx》由会员分享，可在线阅读，更多相关《BTM02E08蓝牙模块.docx（46页珍藏版）》请在冰豆网上搜索。
BTM02E08蓝牙模块
第一部分BTM02E-08蓝牙模块
一、模块的基本参数
1、特性
支持蓝牙协议1.1、1.2
输出功率等级为class2
支持USB1.1和UART串口
低电压供电2.7V~3.6V
标准供电电压3.3V
内置8MbitFLASH存储器
尺寸：
mm
2、描述
采用CSR公司的蓝牙芯片作为核心芯片，并配以8MbitFLASH存储器，SPI接口，UART接口，USB接口，PCM音频接口，16MHz晶振，带通滤波器，天线匹配电路等。
并不是所有的应用都适合嵌入式应用，因为应用程序和固件栈必需共享片上RAM，以RFCOMM为基础的应用可用的RAM大概为几百字节。
应用代码必需控制在32K字以内。
二、BlueCore2-External蓝牙芯片工作原理
1、关键特性
片外8Mbit的存储器可以灵活的用于系统解决方案。
片上32Kbit的RAM用来实现蓝牙无线传输中数据交换的缓冲
4M波特率的异步串行接口
片上可运行多种协议栈：
标准HCI协议栈，全部内嵌的RFCOMM协议栈等
96Ball-VFBGA封装
2、管脚使用
USB接口不用时应接地
所有IO管脚被配置成输入时，复位后将变成弱下拉
不用的AIO（可编程模拟IO）管脚不使用时应该悬空
3、内部功能模块
USB：
用来与其他数字设备的通用接口，BlueCore02扮演外围设备角色，来回应主机的请求
SPI（异步串行接口）：
用来与其它数字设备的接口，SPI口可以用来调试软件和烧写外部FLASH存储器
UART：
与其他设备通信的通用同步串口
可编程IO：
共有15个可编程管脚（12个数字的和3个模拟的），有运行在片上的固件来控制
4、CSR软件栈
CSR为BlueCore2提供了片上运行的固件（Firmware），片上运行的协议栈仍需HCI的支持
1）HCIStack
该Firmware提供了一组特性及支持相应特性的HCI
在标准蓝牙协议上做了扩展：
●支持蓝牙串口协议——BCSP，一种以UART为物理层，可靠的特有协议（可选）
●提供了额外的50个系列HCI指令
●可以访问可编程IO端口
●访问蓝牙时钟
●访问固件上的随机数产生器
●动态配置UART（波特率，校验，数据位）
●无线传输使能：
一个简单的命令，与一个专门的物理开关有关，确定radio是否可以传输数据
●可以读取芯片外部管脚上的电压，可以运行在VM或主机上来电池的监测
●提供一组BCCMD命令，来访问片上的“persiststore”，该数据库存储了器件的蓝牙地址，器件class，radio配置，USB/DFU常数等（DeviceFirmwareUpgrade）
●UART上break命令的应用：
用于重启，开机进入低功耗，唤醒主机
●提供一组“radiotest”或者BIST指令，直接控制片上的radio
●虚拟机。
固件提供虚拟机环境，来运行应用代码。
虚拟机需要BlueLab和内嵌协议RFCOMM（或者L2CAP，SDP），运行在VM上的协议可以完成通过可编程IO点亮LED的简单工作
2）BlueCoreRFCOMMStack软件栈（将以Firmware的形式转载到片上）
直到RFCOMM层的协议都运行在片上
●与主机接口：
RS232，RFCOMM协议（如何建立无线串口连接？
）
●服务发现协议
3）虚拟机栈
●所有代码都在片上运行，代码在固件旁边运行（代码与固件并行运行）
●用户可以呼叫固件完成各种操作
●用户的应用代码与堆栈是分开的，防止对堆栈造成影响，可以随时修改应用代码
4）面向应用的应用软件的编写
当更高层的蓝牙协议栈像固件一样在片上运行时，底层将会通过片上运行的一个UART的驱动程序提供L2CAP，RFCOMM，SDP的API给高层
5、片外存储器
提供了8M位的存储空间，字长为16位。
用来存储代码和配置数据
6、UART接口
●信号机制。
UART接口为与其他串口器件提供了一种简单的机制。
采用RS232协议电平为0V~VDD_PADS（IO电路的电压），要求额外的电平转换芯片。
四种信号中，RX和TX用来传输数据，RTS和CTS可以用来做流控（低电平有效），采用CMOS工艺。
UART的波特率等参数设置有软件来完成。
●复位。
UART接口可以发送一BREAK信号复位BlueCore芯片，即RX信号线被置低的时间超过在PS中的Key：
PSKEY_HOST_IO_UART_RESET_TIMEOUT设定的值，可以用来主机复位系统。
同样道理，芯片也可以发送一BREAK信号来唤醒主机。
●波特率。
可以通过公式计算结果设置任意波特率，也可以设置标准波特率。
PSKEY_UART_BAUD_RATE（0X204）
7、SPI（串行外围设备接口）
BlueCore使用有16位数据位和16位地址位的SPI，当处理器运行时或被终止时将会通过SPI交换数据
●指令周期。
芯片为从设备，从SPI_MOSI接受命令，从SPI_MISO发送数据
SPI复位后，CSB必需置低。
写入时，MOSI上的数据在时钟的上升沿写入BlueCore。
读出时，在CLK的下降沿读出。
CSB变高时结束。
●写入过程。
线串行写入8位的命令字（写指令为00000010），接着是16位地址，然后16位的数据写入该地址中。
芯片内地址自动加1，接下来的数据将连续的存储于FLASH中。
●读出过程。
同上，先写入读命令字C[15:
0]（00000011），然后写入读地址A[15:
0]，在MISO上将输出16位的校验字T[15:
0]，跟着输出16位数据D[15:
0]。
校验字包括写入的命令字[7:
0]，和读出数据对应的地址[15:
8]，可以有效克服读出错误地址的内容。
读过程地址自动加1.
8、PIO
可由片上运行的应用程序或者HCI来访问。
●PIO[0]/RXEN。
复用端。
由PSKEY的PSKEY_TX/RX_PIO_CONTROL（0x209）来决定，可以用来作为radio前端的传输开关。
●PIO[2]/USB_PULL_UP
（1）。
复用端。
UART中，可用来做PIO。
USB中，用来做上拉。
外部RAM应用中，用来做片选。
●PIO[3]/USB_WAKE_UP。
USB中，由PSKEY中的PSKEY_USB_PIO_WAKEUP（0x2cf）
●PIO[4]/USB_ON
（1）。
●PIO[5]/USB_DETACH
（1）
●PIO[6]/CLK_REQ。
由PSKey中的PSKEY_CLOCK_REQUEST_ENABLE（0x246）决定。
芯片处于深度睡眠时，管脚可以接低，当有一个时钟请求时接高，时钟必须有4ms的上升沿。
9、USB
芯片包括一全速的USB接口（12Mbits/s），能够直接驱动USB电缆而无需USB收发芯片。
USB的数据线D+和D-连接到USB内部的USBＩＯ缓冲器中，因此输出阻抗较低。
为了与ＵＳＢ电缆的特性阻抗相匹配，在Ｄ＋和Ｄ－上必须串联电阻。
ＵＳＢ协议规定ＵＳＢ数据线输出的最小高电平为２.８Ｖ，为满足此要求，VDD_USB供电端至少为３.１Ｖ
自供电模式。
电路将由自己的供电系统供电，而不是来自于ＵＳＢ电缆的ＶＢＵＳ（５Ｖ），这种模式ＶＢＵＳ只会提供很小的电流（小于０.５ｍＡ）。
要求ＶＢＵＳ要经过一电阻网络分压，以便于当ＶＢＵＳ变高时（连接到了ＰＣ）ＢｌｕｅＣｏｒｅ可以检测到。
USB_ON端可以由任一PIO来充当，但是必需在PSKEY_USB_PIO_VBUS中注明所选的PIO号
Detach和Wake_up信号
BlueCore可以提供两个额外的信号给主机：
USB_DETACH和USBWAKE_UP。
这两个而外的信号在USB电缆和协议中是不存在的，但是在嵌入式系统应用中却非常有用，因为嵌入式应用中实际的USB电缆是不可见的（直接用PCB布线相连），所以不知道什么时候USB电缆应该建立连接。
Usb_detach：
置高时将会使USB_D+和USB_D-变为高组态，相当于断开总线连接。
置低时将恢复连接，并等待主机恢复。
USB_WAKE_UP：
用来唤醒主机。
只有USB_DETACH有效时才有意义，置为高电平时用来唤醒主机，以重新开始传输数据。
它是用来替换软件中USBWAKE_UP消息的，当断开连接时不能使用。
三、外部Flash存储器
蓝牙的配置参数被存储到Flash的PS区，可以通过程序包里的PSTool工具来对其进行操作。
四、RS232电平转换芯片
为主机与BlueCore的3.3V逻辑电平提供接口
五、复位电路
高电平复位。
上电时，复位管脚将置高。
可以确保电压稳定在3.3V之前芯片处于复位状态。
否则，当电压从1.8V降至1.6V时，芯片将尝试着从外部存储器获得指令，而此时Flash（针对3.3V供电的Flash）的供电可能没有准备好，Flash将返回错误的指令给BlueCore，这将会导致固件的配置失败。
（电压升至1.6V以上时芯片开始工作，而3.3V还未达到，Flash还不能正常工作）
当使用1.8VFlash时，复位电路可以取消，把复位管脚直接接地，因为Flash和BlueCore将同时达到1.8V电平（3.3V和1.8V可能不会同时达到）
（根据CSR公司提供的模块资料，在复位管脚处模块已经通过一10K的下拉电阻接地。
根据复位要求，应尽量延长复位时间，以确保电源供电稳定。
应接一大点电容）
平时可以直接接地也可以通过一个1K电阻，要保证接地可靠。
六、开关
开关的反跳在软件中实现。
七、PIO
不用的IO管脚可以悬空，因为在IC内部有弱下拉电阻。
在模块中，未用的AIO通过一100nF电容接地。
八、LED
可以由芯片的管脚直接驱动
九、PCB
SPI应留出相应的监测点，以便在卡过程中编程，校准，和查询芯片。
一十、数据速率
最大数据传输速率受到rs232电平转换速率限制，比特率的设置在PSKEY中。
要根据所使用的RS232转换器的实际速率来设置PS_KEY中的速率值。
十一、低功耗
节点应用。
电缆替代例子的底层固件层中不能应用深度睡眠模式。
MAX3243和MAX3228当没有有效的RS232信号时会自动进入低功耗模式关闭器件。
将FORCEON（232转换芯片的引脚）与3.3V相连可以关闭低功耗特性（此处加入跳线使该引脚可以接到0V提供选择）。
当将引脚FORCEOFF接3.3V时，将会使能自动低功耗模式。
在RS232芯片输入端没有有效数据输入时232芯片将会被关闭进入低功耗模式。
（将FORCE_OFF接3.3VCC使能自动低功耗模式，而通过控制FORCEON的高低来最终确定是否真正的使用低功耗模式）。
232芯片输出的信号INVALID像BlueCore指明是否有有效信号，从而可以唤醒BlueCore。
INVALID为高电平时表明输入端输入了有效数据。
INVALID连接到了IO7，向BlueCore提供一个高电平来唤醒BlueCore。
如果一个PIO被设置为输入，输入的低电平必须是一个有效地低电平，RS232芯片输出的INVALID信号有可能不是一个有效地低电平，所以当没有有效信号输入时，RS232芯片的输出端变为高组态，需要加入下拉电阻，以确保PIO7输入为低电平，是芯片进入睡眠状态（PIO中有弱下拉）。
为能使PIO能产生中断，需将其设置为输入并合理设置PSKEY_DEEP_SLEEP_PIO_WEEK，如果使用VM可以使用VmDeepSleepEnable
（1）来设置（VM应支持对PS的修改）。
十二、软件栈
LM（LinkManager），LC（LinkController），L2CAP，SDP和RFCOMM将以二进制文件的形式提供（是固件），Connectionmanagerlibrary和串口应用以C代码的形式提供，在BlueLab中编译通过后，在VM中运行（VM基于的是解释机制，编译一条执行一条？
）。
1、将要下载的固件编译成二进制文件并下载到Flash中，通过SPI下载。
2、设置PS，通过PSTool
十三、配对过程
1、RS232上电
2、如果已经配对，它将自动尝试建立连接，应用里存储了配对的设备地址。
3、如果上述过程失败，或者没有地址入口，从设备将会被动地等待连接请求，而主设备将会寻找从设备。
一旦连接成功的建立，另一方的地址将会存入PS。
第二部分BlueLab软件编程
从功能上可以把文件库大致分为：
操作系统、驱动程序、用户接口API、蓝牙协议栈、连接管理库和一些具体的应用程序。
理解Tasks,Timers,Schedulers
在一个蓝牙系统中，有很多工作需要维护，连接管理的消息需要处理，输入数据必须处理，输出的数据必需发送到基带管理器上，如果要通过主机控制器与主机交互还必须编址等，所以处理器要分出不同的时间来处理不同的任务（即多线程）。
每一个任务有他自己的调用堆栈，自己的IO队列，都可以从处理器得到回应。
有一个任务用来协调其他任务，叫做核心任务（kenel），也被看成调度（Schedulers）。
BlueCore系统采取轮询的运行方式，处理器轮流运行任务（而非抢占式）。
当任务阻塞时，调度停止运行该任务（当一个任务调用一个用于等待事件发生的系统调用时，任务将进入阻塞状态）。
所以当一个任务永远不被阻塞时，其他的任务将永远不会有机会运行。
遇到上面的情况，如果你的应用程序不能够被阻塞，就需要关掉整个蓝牙功能，但是在蓝牙堆栈里有很多实时性的操作要求运行，所以不能够这样做。
为了解决这个问题，BlueCore提供了一种环境叫做VM，来保护堆栈的正常运行，而不会受到占用大量时间的应用程序的影响。
调度并不是直接调用应用程序，而是调用虚拟机，然后通过虚拟机解释器的解释，虚拟机可以执行很多操作。
这样应用代码如果是一个无限循环虚拟机仍旧可以运行应用程序中预置的指令，所以无限循环不会无限运行下去。
虚拟机调度
片上的调度器在给其他待处理过程分配处理时间之前仅允许处理有限的虚拟机命令。
这意味着不能够指望运行在虚拟机上的应用程序能快速的作出反应。
一个无限的while循环会阻止芯片进入休眠状态而增加功耗。
而且虚拟机并不会一直运行该循环，而是会在运行一段时间以后转而去处理蓝牙协议栈和应用程序的其他任务。
（虚拟机调度是由scheduler实现的，调度程序的代码可见，虚拟机则只提供了接口函数）
for（;;）
{
uint16del=sched1（）;//有事件发生处理事件，没有事件发生返回
VmWait（del）;//应用程序运行在虚拟机上，调用此函数时，虚拟机进入等待状态，上面运行的所用程序都将被阻塞
//从而使蓝牙堆栈上的实时性较强的操作的以进行，而不受应用程序的影响
}
使用bluelab库
Bluelab提供了各种库，库里提供了支持basicC的函数。
当连接时，所有目标文件都会被用到，而且缺少的符号将从库中导入。
每一个符号都是从最开始的库（按照命令指定的顺序）获得的。
也就是说应用程序的makefile必需位于库前重写。
Scheduler依赖于message和timer库。
一些应用程序要求scheduler，但是并不一定这两个库东需要。
这种情况可以用这两个库的简化版来代替，将会占用更少的代码和数据空间。
应用程序框架、连接管理器、调度器、Timer、BlueStack、I2C、消息库和服务发现库需要被解释执行，而剩余的库将按原有模式运行，不必经过VM的解释器。
库分为三种：
1）基本库。
提供支持运行和调试C代码的功能。
2）CSR库。
3）应用程序库。
提供对运行在BlueCore上的应用程序的支持。
这些库的源代码在src/lib中。
可以通过在当前目录下输入makeinstall命令来重建和安装。
这就可以使库代码的调试可以像应用程序代码调试那样进行源码级的调试。
BlueCore上运行的程序
为了在片上运行最终的应用程序，必须将它和一个完整的蓝牙协议栈合并在一起。
开发工具包预带了固件映像，它允许芯片运行底层的蓝牙协议栈。
图中显示了一个应用程序映像与缺省的Casira映像的不同。
应用程序映像有额外的协议栈层：
L2CAP，RFCOMM和SDP。
这些是支持串行端口规范所需的协议栈层，也用于支持基于串行端口规范的简单规范。
这些协议栈层是由Mwzoe编写的，统称为BlueStack。
在BlueLab层之上，用一个连接管理器来处理RFCOMM连接的管理。
BlueLab中带有连接管理器程序库，使连接管理更加方便，但也不是非用他不可，可以自己别写连接管理器程序。
在应用程序顶层是VM。
VM使得连接管理器、库和应用程序软件运行在受保护的内存空间中，应用程序软件被编译成虚拟机执行代码。
当代码运行时，虚拟机检查每条指令是否有非法的内存管访问行为。
通过这种方式，VM确保了应用程序软件不会干扰蓝牙协议栈的正常运行。
在调试器下运行程序时，必须将RFCOMM载入到芯片中，芯片才能驱动无线电。
可是此时的应用程序是运行在PC机上的调试器下，所以也就不可能将应用程序的映像加载到芯片中。
解决办法是向芯片中下载一个空的映像——这是一个包含虚拟机的固件映像，但是不包含有效的应用程序。
主蓝牙协议栈的运行总是优先进行并连续不可间断，直到有多余的处理带宽VM才被调用。
BlueStack协议栈基于消息驱动，层与层之间使用消息传递方法，应用程序调度执行消息不为空的任务。
事件驱动中的事件包括BlueStack事件、PIO事件、RFCOMM源端及目的端事件等。
所有事件的处理以及消息队列中的消息处理均由调度程序来执行。
调度程序由高层应用程序启动，而个事件及消息处理分布在各软件层中。
在2.1版本以后，可以向片上加载应用程序，当连接到调试器时，片上应用程序将自动关闭。
应用程序库
为运行在BlueCore上的应用程序提供了支持。
这些库的源码位于src/lib目录下
连接管理器
连接管理器处理蓝牙协议栈中RFCOMM层以下所有的层。
如果没有连接管理器，则需要建立ACL链路，为RFCOMM配置链路，建立并配置L2CAP链路，最后才能建立RFCOMM链路。
使用连接管理器，只需一个调用就可以让所需的所有层完成配置。
大多数发送数据的应用程序都愿意使用RFCOMM连接，但是对于那些需要从更底层级别进入的程序，BlueLab连接管理器除了允许他们发送RFCOMM包以外，还允许他们发送L2CAP包。
L2CAP是蓝牙协议栈中应用程序可以将数据送往的最低级别，因为蓝牙链路中所有的用户数据都必须作为L2CAP包发送。
数据包是通过连接来发送的么让每个连接必需指向某个对等的设备，所以很自然，在发送任何数据包之前，连接管理器必须与对等设备配对。
在mssage.h中，任务/消息标识符0视为连接管理器保留的，而标识符1是为应用程序框架保留的。
其实际效果是，无论程序何时向连接管理器发送消息，他都是向消息队列0发送，而从消息管理器返回的消息总是返回到消息队列1。
不管消息的内容是控制信息还是数据包，这个关于消息队列数字的规则不变。
连接管理器的消息都在cm_rfcomm.h中声明。
连接管理器本身在CM_RFCOMM库libcm_rfcom.a中实现。
初始化并打开连接管理器
组成BlueStack和应用蓝牙协议的库必需包含进系统中。
所以这些库将自动启动以确保协议栈的正常运行。
而连接管理器不是蓝牙协议栈的组成部分，是可选的独立库，所以他不会自动启动。
如果想使用连接管理器，必需通过一些调用初始化并打开连接管理器。
首先，通过发送CM_INIT_REQ消息来初始化连接管理器。
如果连接管理器成功注册了BlueStack，它将返回CM_INIT_CFM消息。
这些消息仅仅是启动连接管理器的运行，所以两个消息都没有任何参数。
连接管理器运行以后，需要将应用程序的相关信息告诉连接管理器。
BlueCore经常将设备等级（classofdeviceCoD）设置成混杂型。
这可能并不适用于当前应用。
例如耳机应用程序，要把CoD中MajorDeviceClass设置为Audio，并使耳机规范适应次要设备。
这样正确的设置就很重要，因为CoD作为查询的回复被发送出去，然后被其他发现设备的应用程序利用，这时包含CoD的查询回复很有可能被该查询设备所屏蔽。
所以，如果CoD不能很好的反应应用程序所具有的功能，其他的应用程序很可能甚至不会向使用者报告这个设备的存在。
还需要让连接管理器知道要用到的服务列表，来描述应用程序中所提供的服务。
这项工作处理完以后，连接管理器将会专注于处理关于这些服务的询问，而不用应用程序进行额外的干预。
应用程序在CM_OPEN_CFM（这个消息已经不推荐使用，详见/docs/cm_rfcomm）中向连接管理器传递CoD和服务记录信息。
typedefstruct
{
uint8*serviceRecord;/*pointertoservicerecord*/
uint16sizeServiceRecord;
uint32classOfDevice;
}CM_SERVICE_REGISTER_REQ_T;
serviceRecord参数是指向一个动态分配的内存的指针，这个内存用于描述应用程序服务的服务记录。
服务记录必须包含一个RFCOMM信道（channell）的空入口，供应用程序的服务使用。
换句话说，UUID（universaluniqueidentifier）是由后面的三个UNIT型数来确定的。
信道会由连接管理器进行填写。
sizeServiceRecord参数是serviceRecord完整的大小，classOfDevice参数指明了设备的种类，用来回复别的设备针对本设备的查询操作。
在BlueLab28中classOfDevice参数已不适用，仅赋给值0，取而代之的是由CM_WRITE_COD_REQ消息来注册CoD信息。
这种变化是由于当用户放送多个CM_SERVICE_REGISTER_REQ消息来注册多个服务时，如果提供了不同的CoD信息，当其他设备查询时本地连接管理器将不知道回复哪个CoD信息，所以有一个单独的消息注册CoD信息。
在打开连接管理器以后，可以把应用程序提到这种状态，但是也可以继续进行操作使用安全管理等特性（SecurityManager）。
可以告诉安全管理器信任的设备，安全管理器将会把关于这些设备的信息存放在新人设备数据库中（TrustedDevicedatabase）。
在数据库中登记的信任设备将可以不经过应用程序的授权与本地设备进行连接并执行操作（已经授权无需再授权了，但是否还需授权并不是自动完成，而是有应用程序来实现的）。
要使用安全管理器（SM），应用程序可以发送CM_ADD_SM_DEVICE_REQ消息，消息中要包含将往SM中添加的可信任设备的详细信息。
typedefstruct
{
BD_ADDR_Taddr;
uint8link_key[SIZE_LINK_KEY];
bool_ttrust;
}CM_ADD_SM_DEVICE_REQ_T;
Addr参数是将要添加进SM中的设备的地址。
Link_key参数同时给出了设备的连接关键字（linkkey），trust参数如果为TRUE这名设备被信任，FALSE为不信任。
如果这一阶段没有连接关键字，将不得不跳过这一步骤。
稍后可以通过配对来获得连接关键字，然后调用SM。
除处理消息之外，还需要启动timer系统和
升级会员 