本帖最后由 freebsder 于 2016-8-2 03:01 编辑
分两部分，一部分是环境，一部分是能耗。
本人之前是不太喜欢使用STM32的MCU。由于我个人的关系，经常在windows，linux，osx之间切换使用，一份代码维护几个工程觉不太方便很麻烦，加之ST的生态建设更多的依附于低价策略之下的爱好者推广，引以为豪的库封装也被初学者神话之后慢慢掩盖了其他MCU厂都有类似甚至更优秀的情况，因此总对STM32有向往奈何不想折腾。
最近慢慢的发现ST也开始布局更完整的用户环境，很欣喜，这样的改变值得花一些经历折腾一下。
另外，这小板子很简单，主要就是一个板载仿真器，一颗引出兼容arduinomini引脚的L432，前面dcexpert有写，想看详细分析的可以去看看：
传送门。
先说环境，有三个可以说说的东西。一个是AC6 这款IDE， 一个是jlink-ob开始支持大部分NUCLEO和DISCOVERY评估板，一个是mbed，下面慢慢聊，想到哪里写到哪里。顺带提一嘴，T某I的CCSv6开始支持三种OS了，详细信息请自行查找。
AC6的前身是一款eclipse的插件，全名叫“Open STM32 Tools”,不久之前正式和eclipse打包在一起组成了面向STM32 系列MCU的IDE。同时支持windows，linux和osx。项目地址往这边看
http://www.openstm32.org/HomePage 。升级更新还蛮快，基本隔2，3天update一下都有小版本更新。这款IDE应该是ST自己生态的一个起点。
启动画面看起来比较淡然，比较符合我的感官，不过，紫色，让人有一些娘炮的不稳重感，呃，还有一朵长得像蝴蝶的菊花。
原生的AC6依赖openocd这款在线调试代理。然而openocd的速度和stlink-v2的速度，哥哥我确实不太喜欢，用起来不仅慢还很麻烦。好消息是4月份的时候segger推出了STM32的jlink ob firmware，详情往这里看
https://www.segger.com/jlink-st-link.html，现在的固件基本可以覆盖大部分NUCLEO和DISCOVERY。建议AC6做更新的时候可以直接把JLINK插件集成进去好了，省得一会被墙一会被404。
AC6的具体安装和JLINK OB firmware更新操作，更多的是按照说明看着提示来，这里便不再详细啰嗦下去。
试试新建一个工程。
芯片选择之后AC6会自动提示要使用哪个库，最新的器件已经都切换到HAL，不支持比较老旧的StdPeriph。确定之后就等待下载完成吧，下载包自动解压之后放到用户个人目录中下次新建该芯片的项目就不用再等待了。呃，话说快了，有一种情况，HAL库有官方更新的时候AC6还是要你选择新下载。
HAL库支持很好，三方和附加库也比较齐全。熟悉的朋友拿着就可以上手了。要例子可以去firmware包里面找SW4STM32工程，导入到AC6即可。Eclipse不多介绍，喜欢的人不喜欢的人都有道理。
我们导入一个例子吧，STM32Cube_FW_L4_V1.5.1/Projects/STM32L432KC-Nucleo/Applications/FreeRTOS/FreeRTOS_ThreadCreation/SW4STM32/STM32L432KC_NUCLEO这个。
调试的时候在GDB SEGGER J-LINK DEBUGGER中新建一个调试配置，芯片型号填入STM32L432KC就可以用上高大快上屌的jlink了。有兴趣的可以在设备管理器里面找到虚拟串口，另外推荐可以试试segger的RTT功能，据说比serial和swo都快，还带缓存、日志等功能。
截止到成文的时候，存活的、没有存活的常见MCU厂基本都推出了基于Eclipse的支持三OS的IDE，当然这里的MCU说的是ARM MCU，其他大量非ARM系列的开发仍然只有单OS可选。例外的是atmel这只已卖身妾基于virtual studio做了自己的IDE，然并卵，没有带来更多的优势，令人匪夷所思。
虽然查看寄存器这种功能还不如IAR，KEIL，但是垃圾的IDE完全可以消灭更值钱的灵感（AC6可以支持SVD文件的寄存器定义，不过暂时我还用不到，没有深入折腾）。
mbed是一个挺好的东西，介绍的人很多，这边只是提一下。STM32的HAL库当然是很贴切STM32MCU的，虽然这个库功能也比较残缺很多地方搞得比自己写更复杂。比较着来看，mbed建立在更高逻辑层面的“库”之上，如果把HAL库比作linux kernel api的话，mbed应该是posix api了。
mbed是用C++封装的，抽象程度很高，如果当做struct的扩展来用即便不需要多少C++知识也可以用的比较顺畅。很多MCU特定的功能肯定没法用了，毕竟抽象程度越高个性化程度也就越低。中小型项目的选型中，mbed是个很不错的起点，包括常用的I2C，SPI，IO，Interrupt，Timer，Ticker，Analog，CAN，Serial，如果加入RTOS支持的话，还有Mutex，Thread，Queue等基础设施可以顺手拈来。但是，重点是，这些基础设施的功能还是弱小得，作为项目或测试的一个起点很不错。本人的某个项目中已经在使用mbed作为基础平台和测试平台，拿测试来说，往常需要个把小时写的测试用例，mbed只写了不到十分钟。
再扯能耗
L432终于可以和MSP432站在一个起点考量：内核都是cortexm4，都是自家低功耗系列中比较新的器件，关键是名字里都有432。虽然主频，功能单元，功耗模型各不相同，站在能耗比的角度来看各有千秋。不表MSP单说L432。
通常认为功能与功耗是一对矛盾，并存起来要么选鱼要么选熊掌。因此big.LITTLE架构弄个异构的快慢处理器来寻求平衡。就MCU来说，单纯要更强功能应该是cortexm7系列主打的目标市场，单纯要更低功耗应该是cortexm0系列擅长的领域。能达到手册号称的cortexm4从功能，性能，功耗方面确实是一个难得的平衡。
低功耗应用一般被看做用于传感，被动监测等领域。目前市面上的传感器一般要么是数字式要么是模拟式。针对数字式传感器L432配备的i2c，spi接口几乎覆盖了大部分数字传感器接口，如果放入到控制和工业环境中，CAN接口提供基础数据通讯能力，低功耗UART也经常用于短距数据通讯。Dsp在这种场景中为数据的处理提供更高级别的计算支持。模拟传感器的数据利用L432的低功耗12位带硬件过采样ADC，最高可达到16bit，功耗低至200ua/msps。更进一步，2，4，8，16倍的可调增益运放对微弱信号有了一个基本配置，处理范围内的信号应该可以节省一些外围器件的要求。如果换做外围器件搭建动态增益可调的需求，仍然需要下一些功夫，当然，这些参数相对来说都比较基本，如果要更精细的信号调理，还是得自己动手了。阈值监测的应用放在模拟比较器COMP身上没有什么更合适了。
从芯片的功能配置上看得出L432针对应用场景的各种预先考量。给出的配置虽然大部分功能都可以在常见的MCU上取得，然而具体针对到低功耗这一目标应用场景，这些功能就显得再合适不过。再加上面向工业领域和通用领域的通讯功能，搭建一个传感器数据网络节点的方案可以节约不少外围成本。
通过单芯片求得功能、性能、计算、功耗的平衡，这样的设计我个人持肯定态度，比某厂家试图在一个MCU里面搞两个核简单的多。两个核意味着同步、通讯、调试等各种复杂问题，浮躁的社会是不太认可高复杂度的东西参与竞争的。
芯片特色中没有强调功能模块之间低功耗模式合作的能力，core在休眠的时候由功能部件（之间）自动完成某一些处理、计算、然后有条件的唤醒core进一步处理，类似某一些芯片的梦游、状态机（虽然名字不一样，实际上可以认为类似）等功能间协同能力。需要说明的是由于时间关系，本人并没有很具体的翻阅每一页手册的说明，只在浏览的基础上大概得出的印象，可能不准确，但是L432的数据和芯片手册都没有把这个拿出来作为卖点，那么以上情况成立的可能性是很大的。
之前看过ST的6轴传感器，里面的实现使用状态机把功能性、定制型暴露给用户。技术上说在L432（或L系列）中添加类似状态机协调core休眠时的各低功耗功能部件，对ST来说应该不是难事吧。
ST切入低功耗MCU领域并不是较早的，甚至可以说发力是较晚的，感觉后发优势并没有体现出来。低功耗MCU从最初的执行期休眠期功耗，到部分低功耗器件，到更精细的休眠功耗，到整体功能部件的低功耗加强，再到内核低功耗的加强（比如CortexM4核），然后到功能部件之间低功耗模式的自主协同数据处理，每一步的发展或许ST仍然需要不断的积累才能给大家带来更大的惊喜。
总体 来看ST越来越加强自主生态的建设，积极参与并融入到共建生态的建设，L432这颗器件在能耗方面取得难得平衡的同时提供大量可以应用在低功耗场景中的功能部件，如果各种数据手册中涉及的参数相对比较保守不夸张的话，这颗芯片作为低功耗应用和产品的首要考虑对象是值得花一些时间做进一步评估的。
提升卡
变色卡
千斤顶
1/9 
京公网安备 11010802033920号
Copyright © 2005-2024 EEWORLD.com.cn, Inc. All rights reserved
