蓝牙通信

http://www.eefocus.com/majianhui/blog/09-12/182434_16fbb.html

一个牛叉人的blog

最近做一个蓝牙通信的项目,搞软件的最怕的就是和硬件沾边哪怕一点点都觉得很迷茫!

做这个项目时遇到了一个问题

就是当手机和蓝牙模块建立连接后,用的是长连接模式,就是持续保持连接.手机这边作为客户端发起请求,蓝牙模块作为server相应并返回数据.

问题是如果client这边发送数据给server但是serve出于某种原因没有返回数据,而client并不知道server没有返回数据,仍执行read,就会阻塞.死到server写进数据,这样是不行的,怎么能解决这个呢,找了好长时间都没找到,不知道android里蓝牙这部分能不能用nio呢?这方面也没有找到,希望做过的高手们能指导下!!!!!!

目前用csr的bc04，bc04是从eeprom里读取pskey的，现在疑惑的是

1.通过bcsp用bcccmd修改pskey后存储到eeprom里吗？

2.如果pskey设置错误会不会影响bcsp的初始化呢？及三次握手

现在出现的现象是有时候pskey设置成功貌似存储到eeprom里，但是有时候就不行。

如果pskey里时钟设置错误貌似bcsp初始化就不正确，发送第一次握手的数据包后，有时根本候收不到蓝牙芯片返回的数据包，有时候收到的就是不争气的包甚至头尾都不是c0很奇怪！！！！！！！！！！！！！！！！！！！！！！！！！！！！

----转的

——对于蓝牙的无线接入过程控制器主要分为Standby与Connection两大状态。在这两大状态下又分为传呼（Page）、传呼扫描（PageScan）、询呼（Inquiry）、与询呼扫描（InquiryScan）四大子状态；另外，传呼下有主机响应（MasterResponse）子状志，传呼扫描下有服务机响应（SlaveResponse）子状态，询呼扫描下有询呼响应（InquiryResponse）子状态。如图1所示，蓝牙组件可离开Standby状态而进入Page、PageScan、Inquiry或Inquiry_Scan状态，然后在进入Connection状态。在一蓝牙Piconet中，Master运用Page或Inquiry与Slave建立连接的链路。若Master不知欲连接的Slave组件地址，便开始Inquiry程序来寻找Piconet中的Slave组件地址与其时钟；但若Master己知欲连接的Slave组件地址，则开启Page程序来寻找其它的Slave。

——在以下各节中将说明无线接入的程序，连接模式与接入控制。

二、接入（Access）程序

——在开始建立一连接的无线链路时，Master需要知道Slave的蓝牙组件地址。因此当Master蓝牙组件在Inquiry状态时，它运用Inquiry信息指示哪些蓝牙组件需要响应Inquiry，并收集所有响应Slave的蓝牙组件地址与时钟，在Inquiry状态的Master蓝牙组件继续在不同的FH频率传送Inquiry信息以寻找其它的Slave蓝牙组件。

——而一旦被发现的Slave蓝牙组件则规则性的进入InquiryScan状态以响应Inquiry信息。而其接收机则运用一匹配相关器（MatchingCorrelator）来搜寻Inquiry接入码（AccessCode）。此搜寻时间将持续至16个FH频率的范围。若某一激活的（Wake-Up）Slave蓝牙组件可辨识Inquiry信息，它则进入InquiryResponse状态。在Standby状态时的蓝牙组件可利用其所有的资源来搜寻其它InquiryAccessCode；而在Connection状态时的蓝牙组件则可将其现有的资料链路连接处于省能模式以便来搜寻其它InquiryAccessCode。以上的InquiryScan程序可能会被预留的SCO时段所中断。

——在已知欲连接Slave的DeviceAccessCode（DAC）时，Master则开启Page程序来寻找此Slave。在Page程序中，Master重复的用不同的FH频率来传送Slave的DAC以尝试连接（请参见图2）。Page程序的步骤如下。

——先以Slave的DAC来决定Page信号的FH频率序列。

——Master以预估的Slave时钟来预测Slave的Wake-Up时间与FH频率。

——在每一传送时段，Master顺序地发射两个不同的频率。

——在每一接续的接收时段，Slave的接收机，依据PageScan使用的跳频频率，顺序的侦测两个相对应的接收频率。

——Page程序可能会被预留的SCO时段所中断。当Slave组件成功的接收了Master的Page信息，Master与Slave便展开一例行的响应来互换信息。而Master与Slave间成功的连接，在于使用由蓝牙组件地址（BD_ADDR）导出的同一频率接入码与同一FH频率，且Master与Slave的时钟需同步。

——以下描述响应状态各程序中的步骤。

——1.SlaveResponse状态：

——（1）Slave在接到来自Master的DAC后，则以PageResponse所用的FH频率响应此DAC作为确认。

——（2）在传送响应信息后，Slave的接收机即开启并等待来自Master的FH同步（FHS）封包。

——（3）若Slave正确的接到此FHS封包，Slave便以PageResponse所用的FH频率传回其DAC以作为确认。

——（4）Slave可自此FHS封包的内容来得知Slave时钟与Master时钟的差异。

——（5）Slave在修正此时钟差异后，即可进入Connection状态。

——（6）若Slave在进入Connection状态前，上述建立连接的步骤失败的话，则Slave回到PageScan状态。

——在进入Connection状态后，由Master先传送一个POLL封包。若Slave未成功的接到此POLL封包，Master与Slave便分别各自回到Page与PageScan的状态。

——2.MasterResponse状态

——（1）Master在接到Slave传回的响应信息后，即固定其现有的时钟，并且将其输入至PageFH频率选取方案中。

——（2）Master运用此选取的PageFH频率来传送FHS封包。此FHS封包含有所有建构频道接入码所需的信息。

——（3）在Master传送FHS封包后，即等待Slave的确认。

——（4）若没有收到Slave的确认，Master将以更新的时钟再送FHS封包。

——（5）若收到Slave的确认，Master则进入Connection状态，并且运用BD_ADDR来与Slave交换使用的FH序列。

——（6）在进入Connection状态后，Master开始传送一个POLL封包。

三、Connection模式

——在Connection状态中，Slave组件可停留在Active、Sniff、Hold、与Park4个模式。以下分别说明之。

——1.Active模式

——（1）ActiveSlave侦测Master传向Slave的时段上有无封包。

——（2）为了保持Master与Slave间的同步，即使无信息需要传输，Master亦需要周期性的传送封包至Slave。

——（3）若ActiveSlave未被Master寻址，它可睡眠至下一个新的Master传向Slave的时段。

——（4）ActiveSlave可导出Master预定传向Slave的时段数目。

——2.Sniff模式

——（1）在此省能模式中，为了节省能源，Slave可减少侦测（Master传向Slave时段）活动的任务时间（DutyCycle）。

——（2）Master可经由链路管理（LM）协议发出一Sniff指令。此Sniff指令包含Sniff的长度与开始时钟差异。

——（3）若Slave正使用ACL链路连接，则Slave组件必须侦测每一Master传向Slave的时段。

——3.Hoid模式

——（1）使用ACL链路的Slave可被置于Hold模式。

——（2）在此Hold模式下运作的Slave仍保有其ActiveMember组件地址（AM_ADDR）。

——（3）在此模式下，Slave不提供ACL链路服务，但仍提供SCO链路服务。

——（4）因此释放出的能量可让Slave进行PagingInquiring或加入另一Piconet。

——4.Park模式

——（1）在Park模式运作的Slave仍与Master保持同步。

——（2）在此模式下，Slave已放弃其AM_ADDR，而接受一ParkMember组件地址（PM_ADDR）与一AccessRequest组件地址（AR_ADDR）。

——（3）在一Piconet中Park的Save将在规则性的时段后醒来活动以便再与Master保持同步。

——（4）Park的Slave规则性的后醒来活动，将查询Master使用的引导（Beacon）频道中是否有广播信息。

——上述的Park模式下的Beacon频道是由一个周期性传输的Beacon时段或一列周期性传输且等距的Beacon时段所构成，如图3所示。而其周期与时段数等参数则由Master经LM协议指令传至Park模式下的Slave。Beacon频道有下列的目的：经Beacon频道，Master可传输Slave与其同步所需的封包；Beacon频道可载送改变Beacon时段参数所需的信息；Beacon频道可载送Master的广播信息；Master可利用Beacon频道来重新激活Park模式下的Slave。

四、媒介接入控制（MAC）

——目前的蓝牙标准使用Master控制的TDDPolling方案来完成MAC。在ACL链路连接中，当某一Slave组件被在前一Master-to-Slave时段上的封包头端中之AM_ADDR所寻址时，则此Slave可在接续的出Slave-to-Master时段上传输信息。而Slave组件的SCO链路连接中，若在前一Master-to-Slave时段上的封包头端中之AM_ADDR并非指定另一Slave，则此Slave可在预留的Slave-to-Master时段上传输信息。而上述预留的SCO链路时段之建立则是透过各LM层中之协议指令来协商完成。

——在Park模式下的Slave组件，若在前一Master-to-Slave时段上接到Master广播封包指示，此Slave则可在Beacon接入视窗（AccessWindow）上送出接入要求信息，以要求恢复活动，其中信息的传输则占Slave-to-Master的一半时段（请参见图4与图5）。若有需要，在Beacon接入视窗上的时段也可用作Piconet中其它讯息的传输，如图6中的SCO链路信息。上述的Slave接入要求讯息中包含Master的DAC。

——由以上的说明，可知Master可藉送出LM协议中的恢复活动指令来重新激活Park模式下的Slave组件。

五、结论与未来的研究方向

——蓝牙目前的系统规格标准中，只定义了Master控制的Polling无线接入（WirelessAccess）协议，以作为基频芯片的接入控制方案。由上述的说明中可知，此Polling协议自频道资源的使用与管理效益上仍有待改进。如何研发更有效益的MAC方案与Scheduling方法，且在封包的递送路径方面可结合IP连网来发展随意的（ad-hoc）递送协议（RoutingProtocol）。而针对多媒体通信需求，新的蓝牙技术亦可依据服务品质（QoS）不同的要求来提供Bandwidth-on-Demand。