瓶颈：人力与资源不足

手头工作堆得越多，说明效率越低。好容易将书稿交出去了，和电子工业出版社的事情算是可以告一段落了。手头却有其他事情，而且遭遇到不少瓶颈。

1. SPI驱动：CC1101 + STM32/LPC824的工程，涉及到朋友委托以及ESL升级项目。原来打算验证一下mbed驱动，然后直接构建MAC和高层应用，现在看来CC1101的SPI驱动还不过关，无论是单独读写、批量读写，错误状态都很难归纳，不知是否和RDYmosi引脚有关。解决方案是采用逻辑分析仪去抓总线状态。
2. BLE/UART：无论是CC1101/LoRa/智能门锁，最终和手机本地连接的就是BLE，但是目前无论是Nordic SDK还是mbed Kit，都有问题。解决方案是采用最新的SDK和mbed去再次尝试。
3. ECDHE: WiFi连接云端，需要解决AES密钥生成的问题，目前ECDHE在Python中已经验证过了，但是时间较长，纯Python代码单次计算7秒。解决方案是在GCC x86/GCC-ARM-embedded中做验证。实在速度不行，可以采用ECC加速IC，或使用RFID轻量级的双向认证。
4. LoRa固件：虽然提供了Ping-Pong固件，但是实际能够做设计的，应该是ALOHA固件和LoRaWAN固件，此外还需要提供SCPI固件做网络监控测试。

发现还都是与通讯连接技术相关的问题，属于自己的本职工作。

更新

CC1101的SPI驱动有别于SX1278/MFRC522之类的器件，其内部寄存器还分为配置寄存器（可读写），状态寄存器（只读）和命令选通（Command Strobe）。SPI还分为单字节读取和脉冲式读取，最要命的是状态寄存器和命令选通共享同一地址，是通过脉冲标志位来区分。换而言之，脉冲位也是高位地址。所以，状态寄存器必须采用脉冲读取方式才是正确的。测试下来，CC1101配置寄存器可以正常读写，支持单字节和脉冲读取；状态寄存器支持脉冲读取；命令选通支持单字节方式。这或许就是困扰我这些天的原因之一。