【CC1352P测评】Sensor controller是个啥

cruelfox

【CC1352P测评】Sensor controller是个啥 [复制链接]

　　CC1352 内部包含了一个 Sensor Controller. 在介绍中只叙述了它是一个单独的低功耗处理器，配备了若干个外设，用于低功耗运行状态下的模拟采集、外部通信等工作。它自己能脱离主系统独立运行，当然功耗要比 M4 主 CPU 更低才合算。

　　不过，Sensor controller 并不是 ARM 核的，它是一个 16-bit CPU核，但它也不是 MSP430. 在 CC1352 参考手册中有对其核心寄存器和指令集的详细描述。看得出来，为了省电，这个 CPU 的功能并不强。
　　在总线连接上，Sensor controller 属于 AUX domain. 这是一个子系统，除了 CPU 之外还有一些单独的硬件设备，通过总线桥梁这些设备都可以被 M4 主 CPU 访问，但是反过来不可以。
　　Sensor controller 的指令和数据都是存放在一块 4kB 容量的 SRAM 里的。于是，它必须由主 CPU 去初始化，把代码装载到这个 SRAM 中才能工作。

　　Sensor controller 需要一个单独的开发工具：Sensor controller studio, 使用类似C语言的编程语言。安装这个软件以后，我随手试了一个LED blink的例子，没有找到 compile 菜单在哪里，结果是它飞快地自动就执行了编译。如果开发板连在电脑上，就可以连接板子然后运行，可以 debug 跟踪执行。而且，这个过程并不需要 CCS 参与。
　　我把板子再拔下来，发现原来 flash 里面的程序并没有受影响。这说明程序是直接被调试器写到 AUX domain 的 SRAM 里面的。那么，编译过程生成了什么？

 

　　在输出的目录下只有一些源文件，没有二进制文件。检查了一番，我发现这些文件是给主 CPU 的开发用的（不过不像有GCC支持的版本），应该是需要集成到应用的工程里面去。
　　在代码里面有这样的：

/// Firmware image to be uploaded to the AUX RAM
static const uint16_t pAuxRamImage[] = {
    /*0x0000*/ 0x140E, 0x0417, 0x140E, 0x0438, 0x140E, 0x0442, 0x140E, 0x045F, 0x140E, 0x0468, 0x140E, 0x0471, 0x140E, 0x047A, 0x8953, 0x9954, 
    /*0x0020*/ 0x8D29, 0xBEFD, 0x4553, 0x2554, 0xAEFE, 0x445C, 0xADB7, 0x745B, 0x545B, 0x7000, 0x7CA2, 0x68AB, 0x009F, 0x1431, 0x68AC, 0x00A0, 
    /*0x0040*/ 0x1431, 0x68AD, 0x00A1, 0x1431, 0x78A2, 0xF801, 0xFA01, 0xBEF2, 0x78A9, 0x68AB, 0xFD0E, 0x68AD, 0xED92, 0xFD06, 0x7CA9, 0x6440, 

　　也就是 Sensor controller studio 把编译结果写在这里了，由 C 程序自己去装入执行用的 SRAM. 这种方法也是不二之选，比如说，(1) 这个16-bit CPU的程序开发和ARM工具链没有任何关系，它也不能访问片上其它设备，不需要CC1352 SDK，开发环境是与主系统独立的。(2) Sensor controller的代码和主系统牵扯少，适合两边分别开发各自编译。(3) 若把 Sensor controller 看作是一个功能定制的硬件，开发应用程序的时候就不需要关心它的软件实现了。