MAC协议的实现
MC13192 自带有4个定时器,每个定时器定时结束时产生一个中断,可以通过MC13192中断状态寄存器获知中断源,例如,当定时器1定时结束,则会产生一个中断, 此时的中断状态寄存器的第9位被置高,因此在中断服务程序中加入对定时器中断的处理,可以实现时槽的划分,并且根据当前的时槽数来决定数据的收发,可以实现MAC层协议所要求的功能。在本设计中,我们采用30ms作为一个超帧的长度。以网关为例,处理定时器中断的程序如下所示：
if(u16StatusContent & TIMER1_IRQ_MASK)
//中断类别为定时器1中断
{
time_slot++; //每次超时都将时槽加1
if(time_slot==16)
time_slot=0; //时槽数的合法数值为0-15
PLMEEnableMC13192Timer1(1875);
//每个时槽的长度为1.875ms
switch(time_slot)
{
case 0: LoadBaecon(&tx_pkt);//读取一个Baecon
MCPSDataRequest(&tx_pkt);//发送Baecon
break;
case 8:
MLMERXEnableRequest(&rx_pkt1,0);
//打开接收天线,并将数据保存到rx_pkt1
break;
case 9:
MLMERXEnableRequest(&rx_pkt2,0);
break;
case 10:
LoadPacket(&tx_pkt,0,1); //读取一个数据包
MCPSDataRequest(&tx_pkt);//发送数据
case 11:
LoadPacket(&tx_pkt,0,1); //读取一个数据包
MCPSDataRequest(&tx_pkt);//发送数据
//12-15时槽略
}}
手持设备的程序设计与网关设计大同小异,所不同的是,网关在每个超帧的开始自动发送Baecon,而手持设备则被动的接收Baecon,每次收到Baecon之后才打开定时器来划分时槽,而第15个时槽完毕后,手持设备需要打开接收天线以接收下一个超帧的Baecon。
MC13192与语音编解码器及网络设备的协同工作
因为MC13192支持的速率仅为250kbit/s,因此在网关与手持设备之间必须只能传输编码后的语音数据。在选择编解码方案之前,首先需要粗略估计一下带宽,由于极限速率为250Kbit/s,而由于协议所限,仅有一半时槽可供使用,即125Kbit/s,供两个设备上下行使用。这样,每个设备的单向极限速率仅为31.25kbit/s。而MC13192自身的切换时间为144us,而如
对于网关而言,需要记录每个手持设备的通话对象,它通过MC13192及802.15.4 MAC协议获得时槽中的数据,根据对应的时槽确定数据属于哪个手持设备。最后将收到的语音数据封装成RTP包发送到手持设备的目的地。对于从网络上收到的语音数据,则需要确定属于哪一个手持设备,再通过MC13192在特定的时槽发送出去,如图3所示。
对于手持设备则比较简单,它只需要在特定的时槽发送要编码后的数据,再在特定的时槽接收数据,如图4所示。
设计总结
该设计方案已经被用于本人参与的基于MC13192的ZigBee电话项目中。经过实际测试,在
参考文献：
1．Freescale, MC13192 Reference Manual.
2．IEEE Std 802.15.4-2003
3．李晶皎、王爱侠、张广渊, Coldfire系列32位微处理器与嵌入式Linux应用, 北京：北京航空航天大学出版社,2005.6