RAK411/RAK439 spi转wifi模块调试

等了好几天终于等到了这个模块，官方只提供了stm32f4的例程，却没有f103的例程，应该很多人都是在用f103吧。根据f4的代码修改到f103上。开始测试时由于没开uart功能，于是把printf函数屏蔽掉，然后发现miso和mosi连接反了，之后测试初始化正常。然后测试主函数程序，开始是这个样子的，勉强能用，但有时候会不响应数据。

if(Send_RecieveDataFlag==RAK_TRUE)
{			 
  Send_RecieveDataFlag=RAK_FALSE;
  rak_send_data(0,0,uCmdRspFrame.recvFrame.socket_flag, 20,test);					
}
  delay_ms(5);
		
  while(!(GPIO_ReadInputDataBit(SPIx_INT_GPIO_PORT,SPIx_INT_PIN)));
  if(rak_checkPktIrq() == RAK_TRUE)
  {
     rak_read_packet(&uCmdRspFrame);
     rak_clearPktIrq();
     Send_RecieveDataFlag=RAK_TRUE;	
    } 

后来发现在接收函数里设断点，然后运行就正常了。于是最后在里面加了100ms的延时。

  LED2(1);
  rak_send_data(0,0,uCmdRspFrame.recvFrame.socket_flag, 20,test);
  LED2(0);
  delay_ms(5);
  if(rak_checkPktIrq() == RAK_TRUE)
  {
     rak_read_packet(&uCmdRspFrame);
     delay_ms(100);
     rak_clearPktIrq();
   } 

之后测试运行速度，上面程序中的LED2为引脚输出，测试rak_send_data函数的运行时间。不测不知道，一测吓一跳。总线频率为72MHZ，然后下面为spi分频系数与实际运行时间。

spi分频系数     实际运行时间

2                         不工作

4                         5.2ms

8                         5.6ms

16                       6.4ms

32                       8.8ms

64                       14ms

上面的时间为发送20个字节数据的时间，这个时间简直太长了吧。然后spi使用4分频，发送多字节数据的运行时间

字节数目       实际运行时间

20                 5.2ms

200              5.4ms

1000           5.2ms

后经查找，发现每次发送的数据大小均为0x588，追根起来发现SendFrame这个结构体里定义的buffer为1400，导致每次发送都会发送这么大的数据，后将该结构体改小到200，时间在1.36ms左右，继续改小到20，时间在960us左右。

RAK411的spi通信速率最高可达2Mb/s，即2*10^6bit/s，1秒可以传输2*10^6/8=250000字节，根据前面采集的数据，传输0x588=1416个字节，大约耗时5.2ms，1秒可传输272307字节，与理论速度差不多。

再整理一下CAN的知识，波特率250Kb/s时，传输每个位耗时4us，一帧扩展帧大约131位，大约耗时524us。标准帧大约111位，耗时444us；1ms最多传输2帧。波特率为500Kb/s时，传输每个位耗时2us，传输一帧扩展帧耗时262us，传输一帧标准帧耗时222us；1ms最多传输4帧。

后记：又测试了RAK439，使用的是无os的例程，传输数据时经常会出现死机的情况，使用TCP&UDP测试工具，发送512个字节数据时，其速度最高在266000B/S。RAK411的速度在98042B/S。RAK439传输20字节数据的时间如下：

SPI分频数                      20字节传输时间

2         376us

4                                     400us

8                                     480us

基本是1ms一个周期，1ms内只能发送一次。

RAK439虽然比RAK411传输速度快一些，但感觉也不是太快，而且经常会死机，会进一些while循环死掉。不稳定！看来又得换方案了