MCU是Microcontroller Unit（微控制器单元）的缩写，它是一种集成了中央处理器（CPU）、存储器（ROM、RAM）、输入/输出端口（I/O）、定时器（Timer）、串行通信接口（UART、SPI、I2C等）和其他外围设备控制器的单个芯片。MCU通常用于嵌入式系统中，用于控制各种电子设备和系统。
由于其集成度高、体积小、功耗低以及成本相对较低等特点，MCU被广泛应用于各种嵌入式系统中，例如智能家居设备、医疗设备、汽车电子系统、工业自动化等。MCU的选择通常基于应用的需求，如处理性能、功耗、外设接口等因素。
近日，西人马公司再次推出自研芯片，CU0801A。
CU0801A是基于RISC-V架构的32位高性能低功耗通用微控制器。RISC-V处理器适用于低能耗、小面积的嵌入式应用，具有简单的动态分支预测、指令预取缓冲区和本地内存等多种高效微架构特点。
CU0801A提供高达256KB的嵌入式Flash 存储器用作程序/ 数据存储，高达96KB 的嵌入式SRAM 存储器用作系统操作和应用程序运用，具有多种外设，如14 bit SAR ADC、I2C、UART、SPI、IWDT、RTC等。
芯片因应用而生。CU0801A专为智能传感器应用、PLC、电源监控、报警系统、手持式设备、数据记录应用、马达控制和PC外围设备等多种工业、消费类应用场景，适合传感器、工业控制、电源监控等微小信号采集的应用场景。举例如下：
之前西人马发布的CU0102B芯片采用0.18um CMOS BCD工艺制造，该款芯片与压电传感器如压电加速度计、压力以及MEMS压电麦克风等一起集成使用，即可以生产出稳定可靠的IEPE传感器。继4月发布CU0102B，短短两个月后，西人马再次发布自研芯片，印证了西人马强劲的技术实力。
作为一家IDM经营的芯片公司，西人马立足MEMS、SoC和CPU芯片和传感器的设计、制造、封装和测试等全链条能力，借助国产化、数字化的大趋势，向上夯筑端侧安全、边缘计算和云端平台，在消费驱动、产业驱动、政策驱动的新数字基建中与生态伙伴携手实现共同价值，为全球数字经济发展提供核心柔性引擎。
西人马公司在研发能力、设备投入、工艺改良方面有独特的优势，研发了一系列小而美、小而精、小而强的产品。公司以自主研发的MEMS、ASIC、MCU智能芯片，对传感器和数据采集器进行赋能，使普通传感器变成了智能传感器，普通数采变成了智能数采，并以智能硬件为基础，开发了应用于智能边缘计算的操作系统，智能云行业解决方案，形成了“端-边-管-云-用”的一体化解决方案。公司从芯片设计、制造、封装和测试等多环节实现自主创新、自主可控。
西人马公司分别在北京、上海、深圳、西安、厦门、泉州和法国、美国设有分公司，其中核心研发人员硕博士占比90%以上，芯片团队来自于世界500强芯片企业，如三星、台积电等等。西人马已通过行业最高质量管理认证-AS9100D航天航空标准及ISO17025质量认证体系。
此次发布的MCU芯片，仍由西人马公司北京研究院研发而成。北京研究院的团队成员均来自于世界五百强企业和国内外一流院校，团队拥有芯片设计、软硬件开发、视觉感知等领域的经验。未来，北京研究院还将继续发布一系列MCU芯片。
来源：西人马FATRI
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
声明：本处所说的菜单是用在128*64这种小屏幕的菜单，例如下面这种，不是彩屏上的GUI。
作为一个底层驱动工程师，驱动写完了，是要写硬件测试程序的。这个测试程序，一般给测试部/硬件工程师用来测试硬件， 也会给工厂产线测试准成品。
开始的人偷懒，不想一秒就直接上，所有菜单都这样做，一层套一层
void test_main(void)
{
while(1)
{
get_key(&key);
switch(key)
{
case 1:
test_key();
break;
case 2:
test_lcd();
break;
....
}
}
}当菜单越来越多，就开始纠结了，这样写维护不便，看起来也不美，还浪费程序空间。
作为一个天天看《编程之美》的码农，决定改变现状。酷狗百度一番，找到了两个参考：《基于二叉树的多层的液晶菜单界面设计》 《基于节点编号的通用树状菜单设计方法与实现.pdf》 按照他们的设计方法，鼓捣了一个版本，能用，挺好，但是也纠结。因为他们用了树这种数据结构。对于程序运行来说，非常好，效率高。但是对于我来说，菜单代码是一次性的，但是菜单内容，却是会经常改的。让我用人脑去维护一个包含几十个上百个菜单的树，不容易。
想来想去，这些菜单到底有什么不好？对于我来说，为什么不好用？得出下面结论：
1、管得太宽 菜单，你就管菜单切换就行了，到了最低一层，也就是实际的测试功能，就不要管了。菜单切换是类似的，实际测试都是不同的。比如在菜单中，按键1，是进入第一个菜单。但是在测试中，按键1，功能都不一样。如果菜单连这个也要管，相同动作功能太多，无法进行统一抽象，就很难模块化。
2、出发点不一样。上面说到的菜单，出发点都是如何设计一个好的菜单数据结构，让程序快速，高效运行。我想要的却是一个容易维护的菜单结构，至于菜单的代码有多乱多纠结，没关系， 而且，几百上千个菜单，就算用轮询的方法，也不过几百us吧，没关系。
根据需求，我重新设计了一个菜单结构体
/**
* @brief 菜单对象
*/
typedef struct _strMenu
{
MenuLel l; ///<菜单等级
char cha[MENU_LANG_BUF_SIZE]; ///中文
char eng[MENU_LANG_BUF_SIZE]; ///英文
MenuType type; ///菜单类型
s32 (*fun)(void); ///测试函数
} MENU;是的，就这么简单，每一个菜单都是这个结构体 用这个结构体填充一个列表，就是我们的菜单了
const MENU EMenuListTest[]=
{
MENU_L_0,//菜单等级
"测试程序",//中文
"test", //英文
MENU_TYPE_LIST,//菜单类型
NULL,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_1,//菜单等级
"LCD",//中文
"LCD", //英文
MENU_TYPE_LIST,//菜单类型
NULL,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_2,//菜单等级
"VSPI OLED",//中文
"VSPI OLED", //英文
MENU_TYPE_FUN,//菜单类型
test_oled,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_2,//菜单等级
"I2C OLED",//中文
"I2C OLED", //英文
MENU_TYPE_FUN,//菜单类型
test_i2coled,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_1,//菜单等级
"声音",//中文
"sound", //英文
MENU_TYPE_LIST,//菜单类型
NULL,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_2,//菜单等级
"蜂鸣器",//中文
"buzzer", //英文
MENU_TYPE_FUN,//菜单类型
test_test,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_2,//菜单等级
"DAC音乐",//中文
"DAC music", //英文
MENU_TYPE_FUN,//菜单类型
test_test,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_2,//菜单等级
"收音",//中文
"FM", //英文
MENU_TYPE_FUN,//菜单类型
test_test,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_1,//菜单等级
"触摸屏",//中文
"tp", //英文
MENU_TYPE_LIST,//菜单类型
NULL,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_2,//菜单等级
"校准",//中文
"calibrate", //英文
MENU_TYPE_FUN,//菜单类型
test_cal,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_2,//菜单等级
"测试",//中文
"test", //英文
MENU_TYPE_FUN,//菜单类型
test_tp,//菜单函数，功能菜单才会执行，有子菜单的不会执行
MENU_L_1,//菜单等级
"按键",//中文
"KEY", //英文
MENU_TYPE_FUN,//菜单类型
test_key,//菜单函数，功能菜单才会执行，有子菜单的不会执行
/*最后的菜单是结束菜单，无意义*/
MENU_L_0,//菜单等级
"END",//中文
"END", //英文
MENU_TYPE_NULL,//菜单类型
NULL,//菜单函数，功能菜单才会执行，有子菜单的不会执行
};这个菜单列表有什么特点和要求呢？
1、需要一个根节点和结束节点 。
2、子节点必须跟父节点，类似下面结构。
-----------------------------------------------
根节点
第1个1级菜单
第1个子菜单
第2个子菜单
第3个子菜单
第2个1级菜单
第1个子菜单
第1个孙菜单
第2个孙菜单
第2个子菜单
第3个子菜单
第3个1级菜单
第4个1级菜单
第5个1级菜单
结束节点
------------------------------------------------第2个1级菜单有3个子菜单，子菜单是2级菜单，其中第1个子菜单下面又有2个孙菜单（3级菜单）。
维护菜单，就是维护这个列表，添加删除修改，非常容易。那菜单程序怎么样呢？管他呢。定义好菜单后，通过下面函数运行菜单，
emenu_run(WJQTestLcd, (MENU *)&WJQTestList[0], sizeof(WJQTestList)/sizeof(MENU), FONT_SONGTI_1616, 2);
-第1个参数是在哪个LCD上显示菜单， -第2个是菜单列表， -第3个是菜单长度， -第4个四字体， -第5则是行间距
注意：运行这个菜单需要有rtos，因为菜单代码是while(1)的，陷进去就不出来了。需要有其他线程(TASK)维护系统，例如按键扫描。
代码托管在github：https://github.com/wujique/stm32f407/tree/sw_arch
相关文件：emenu.c、emenu.h、emenu_test.c
当前代码：
1、实现了双列菜单，用数字键选择进入下一层。每页最多显示8个菜单（4*4键盘用1-8键）
2、实现了单列菜单，通过上下翻查看菜单，确认键进入菜单。3 天顶菜单未实现，谁有兴趣可以加上。
3、基于LCD驱动架构，这个简易菜单自适应于多种LCD。
效果如下：
显示效果
128*64 OLED
128*128 tft lcd
320*240 tft lcd
总结
类似菜单在我开发的产品上已经推广使用。经测试，可以明显减少测试程序代码量，节省程序空间。并且易于修改和维护。
来源：嵌入式云IOT技术圈
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
在开发过程中轻松更换 MCU 而无硬件代价，支持 Microchip、TI、NXP、STMicro 等主流 MCU
MikroElektronika (MIKROE)作为一家通过提供基于成熟标准的创新式硬软件产品来大幅缩短开发时间的嵌入式解决方案的公司 ， 今天推出 SiBRAIN，即一种用于附加开发板的标准，以便于在配备 SiBRAIN 插孔的开发板上简单安装及更换微控制器 (MCU)。SiBRAIN 可使嵌入式设计人员能够在原型系统中尝试不同的 MCU，而不必投资昂贵的硬件或费力学习新的工具。SiBRAIN 卡目前可支持包括 Microchip、STMicroelectronics、NXP 和 Texas Instruments 在内的主要厂商的 MCU，其他厂商的MCU很快也将跟进。
MIKROE 首席执行官 Nebojsa Matic 表示：“由于没有标准化，每一个不同的微控制器都有一套特定的操作说明，需要学习新的工具，购买新的开发板和授权，并采用新的工艺。SiBRAIN 卡和插孔标准改变了游戏规则，可节省数月的开发时间和资金，并提供巨大的设计灵活性。”
SiBRAIN 使用同样的“即插即用”概念，支持 MIKROE 的Click board产品系列。SiBRAIN 附加板视 MCU 的型号、引脚数以及所需外部元件的数量而异。每个板都是一个独立的单元，允许开发系统在逻辑层面运行，而不必满足众多不同 MCU 的特定需求。设计师因而可以自由选择 MCU，而无需考虑引脚数量或引脚兼容性。最重要的是，这种方法使设计人员能够在开发阶段轻松更换 SiBRAIN MCU 卡，而无需任何额外的硬件。
每张 SiBRAIN 卡配备两个高速 168 针的夹层接头（一个公头和一个母头），并带有标准 SiBRAIN 插孔插头。这种卡可以轻松安装在任何带有 SiBRAIN 插孔的开发板上，而且智能设计消除了方向和位置出错的可能性。MIKROE 已提供超过 100 张涵盖STM32、PIC32、TIVA、 MSP432、Kinetis 等常见 MCU 的 SiBRAIN 板，而且每周都会增加新卡。
如需更多信息，请访问 https://www.mikroe.com/mcu-cards/8th-generation。
关于 MikroElektronika
MikroElektronika (MIKROE) 致力于通过使用工业标准的硬件和软件解决方案来改变嵌入式电子行业。2011 年，该公司发明了 mikroBUS 开发插座标准和使用该标准的紧凑型 Click 板，极大地缩短了开发时间。现在，该公司推出了第 1000 款 Click 板，十倍于竞争对手，且 mikroBUS 标准已被微芯科技、瑞萨和东芝等领先公司纳入其开发板。此外，MIKROE 是全球覆盖最多品种编译器的供应商，并且提供开发环境、开发板、智能显示器和程序调试器等等。
Azure RTOS组件已集成到Renesas RA灵活配置软件包及Renesas Synergy 软件平台中，也可通过Renesas RX智能配置器轻松获取
全球半导体解决方案供应商瑞萨电子集团(TSE：6723）今日宣布，使用所有瑞萨电子主流32位MCU进行产品设计的客户现在可以使用Microsoft Azure Real-Time Operating System (RTOS)嵌入式开发套件，包括其强大的Azure IoT中间件。最近发布的用于瑞萨电子RA MCU的灵活软件包(FSP)3.0版和用于Synergy MCU的Synergy Software Package(SSP)2.0版集成了Azure RTOS并可开箱即用。瑞萨电子通过e2 studio集成开发环境为RX MCU提供Azure RTOS提供支持。
Microsoft Azure RTOS包括Azure RTOS ThreadX，这是一种专为深度嵌入式应用程序设计的先进实时操作系统，可提供包括实时多线程、线程间通信和同步以及内存管理等众多功能。同时， Azure RTOS ThreadX还可提供包括picokernel架构、抢占式调度阈值设定、事件链和丰富的系统服务集等高级功能。
瑞萨电子物联网及基础设施事业本部高级副总裁Roger Wendelken表示：“我们与微软的合作达到了一个重要的里程碑，很高兴客户能够在我们的32位MCU上使用该领先RTOS平台。我们的软硬件集成方案努力确保客户可以通过访问预先集成的项目模板和智能配置器来实现无缝开发体验。这种集成方案还使用了瑞萨安全加密引擎的独特功能，实现了非常稳固的安全基础。”
微软Azure IoT事业部集团副总裁Sam George表示：“赋能开发人员是组织解锁创新和加速价值实现的最有效方式之一。Azure RTOS与瑞萨电子FSP/SSP的集成体现了双方的雄心壮志——该合作将瑞萨电子的领先开发经验与Azure IoT平台安全、可扩展和开放的边缘到云端的物联网功能相结合。现在是基于瑞萨32位MCU构建产品的最佳时机。”
除了Azure RTOS ThreadX，使用RA、RX和Synergy的开发者还可以访问以下中间件协议栈：
瑞萨电子将于2021年晚些时候发布云开发平台，为开发人员搭建可安全连接并利用Azure IoT强大功能的完整框架。这些云平台具有开箱即用的多种不同连接选项，包括蓝牙、蜂窝、超宽带和Wi-Fi 6/6e。这些Azure认证的套件将通过Azure设备目录提供。了解瑞萨和微软高管就此次重要合作的看法，请访问：https://aka.ms/MicrosoftAzureRTOS/Renesas/MCU/Release。
关于瑞萨灵活配置软件包
易于使用的灵活配置软件包(FSP)包括一流的HAL驱动程序，支持瑞萨电子基于32位Arm®Cortex®-M处理器的高性能RA MCU。FSP使用GUI来简化并显著加速开发过程，同时还使客户能够轻松地从原先8/16位MCU设计过渡到RA MCU。了解FSP开发人员的Azure RTOS使用体验，请访问：https://aka.ms/MicrosoftAzureRTOS/RenesasFSP/Video。
关于瑞萨Synergy Software Package
Synergy Software Package(SSP)是一个紧密集成、优化且经认证的软件套件，可根据最终产品的复杂性进行扩展并简化复杂的系统级服务。SSP组件由瑞萨高度集成、优化、测试、归档和维护。分层架构使开发人员能够使用应用程序框架的通用API或根据需要直接连接到设备驱动程序层来编写他们的应用程序。
关于瑞萨电子集团
瑞萨电子集团 (TSE: 6723) ，提供专业可信的创新嵌入式设计和完整的半导体解决方案，旨在通过使用其产品的数十亿联网智能设备改善人们的工作和生活方式。作为全球微控制器、模拟、电源和SoC产品供应商，瑞萨电子为汽车、工业、家居、基础设施及物联网等各种应用提供综合解决方案，期待与您携手共创无限未来。更多信息，敬请访问renesas.com。
2021年全球半导体行业集体缺“芯”，一度导致芯片成为“2021年度最佳理财产品”，部分MCU的价格从10元不到，涨到现在的200元左右，涨幅近30倍，涨价速度堪比“一线城市房价”。
在这个全球芯片缺货涨价的特殊时期下，ZLG致远电子为解决客户缺芯问题以及帮助客户度过难关，推出极具性价比的Cat.1核心板解决方案。
ZLG致远电子推出的Cat.1智能网联核心板，采用Cortex-A5内核，主频高达500MHz，内部集成了“Cat.1+BLE+WiFi”，采用嵌入式开发方式，支持eclipse开发环境；全资源Open，预留了USB、UART、SPI、I2C等外围接口，具有电话、短信、语音等功能。广泛适用于IoT领域，如云支付设备、工业监测、移动医疗、BMS监测等。
选择Cat.1核心板的理由
1. 性能
由上表可知，Cat.1核心板从处理器性能到存储空间都远超常用32位MCU，而且Cat.1核心板还集成了常用的无线功能，包含Cat.1、蓝牙、WiFi，综合性能遥遥领先。
2. 成本
3. 货期
4.服务
ZLG致远电子为用户提供成熟的软硬件参考资料和在线技术服务支持，帮助用户快速实现产品的上市。
Cat.1核心板应用案例-充电桩
Cat.1核心板方案优势：
ZC1-EV-Board评估板
为了方便用户快速开发，ZLG致远电子推出基于Cat.1核心板的ZC1-EV-Board评估板，该评估板将接口、天线、电源等直接引出，用户开箱即可使用。
来源：ZLG致远电子
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
近年来，随着工艺与IP的逐渐成熟，32位的MCU增长迅速，风头之劲乃至16位的MCU基本上被跳过了。现在说嵌入式MCU，要么就是8位，要么就是32位，16位的MCU产品型号屈指可数。
那么，8位MCU的情形又如何？很多嵌入式工程师都有一些误解，下面来简单分析一下。
一、8位MCU正在被淘汰
这是最常见的误解，先说事实，根据最新的Gartner的市场报告，8位的市场营收额和增长额跟32位的相比都仅仅差几个百分点。考虑到8位的单个芯片比32位芯片要便宜很多的事实，8位的出货量其实远高于32位的。
打个直观的比方，现在我们有了高铁，是不是所有传统的普快、特快火车都要立即淘汰呢？显然事实并非如此，至于原因就太多了。现实情况就是，8位 MCU曾经的应用领域并不能立即用32位的MCU直接替代。
二、8位处理器缺乏创新
不少人会认为既然现在市场的宠儿是32位的MCU，厂商们是不是都没有投入研发资源在8位产品上了。这么想的人可能一想到8位的MCU，脑海中会浮现40DIP的“经典8051”的形象。
事实上，芯片厂商们并没有停止创新。比如，CIP-51内核因为采用了一个时钟周期等同于一个指令周期的设计，瞬间将同频率的8051性能提高了12倍。国内的一些半导体厂商也有基于8051或其他8位内核的创新。
三、8位处理器难以使用C/C++语言编程
如果你了解Arduino的设计原理，这个误解就不攻自破。当然坦白讲，8位的MCU使用高级语言编程确实比32位的MCU要困难些。主要障碍就是内存地址的不统一。比如，8051内核的内存地址就分为CODE、data、sfr、idata和xdata。如果涉及到banking就更复杂了。8位的PIC还有硬件Stack这样更加“非主流”的设计，但是这些障碍都可以通过工具的优化来缓解。
四、8位处理器专为简单应用而生
这个观点倒是有几分真实，但是嵌入式应用本身就是简单应用居多。嵌入式系统应用的本身特点决定了8位依然有很多用武之地。外设和编译器的进化将慢慢拓展8位处理器的应用范畴。
五、8位处理器不能胜任IoT应用需求
IoT应用不是一个单独的应用，而是一个复合应用。智能手表、智能音箱、主控制器、网关这种当然需要复杂的处理器来实现。但是IoT应用还包含大量的传感器节点、执行节点和转换节点。这种节点用低功耗的8位处理器来实现更加适合。
六、8位处理器响应慢
这个就是完全的误解了。典型的嵌入式应用中，响应速度主要跟中断响应和唤醒延迟相关。8位处理器有天然的优势（地址转换工作量小、IP单元实现门数少），至少不输于32位的处理器。
七、8位处理器的能效低于32位处理器
曾经看过ARM公司的权威工程师写的一本书，书中观点是32位处理器的能效比高于8位的MCU，理由是32位处理器能快速处理完任务，休眠时间的比例更大。但是，这个结论包含一个假设，就是任务有一定复杂度。
如果任务本身非常简单，唤醒过程的功耗也很大，那么这个假设不成立。针对不同应用场景，不能简单说8位、32位哪个能效比更高。至少非常简单的应用中，8位的能效比要高。如果再加上单独响应，无需CPU干预的一些任务，8位的能效比甚至能高出很多。
八、相同价格的32位处理器功能远强于8位处理器
这个也有一定程度的可信度，但是不要忘记有相当大的一部分应用使用8位的MCU就已足够在这种情况下，非要购买平均价格高一点的32位MCU，成本就会上升。对于很多基本上标准化了的嵌入式产品来说，8位MCU还是具有一定的成本优势的。
九、8位处理器设计的应用不能适应未来变化
这是个思维角度问题，作为嵌入式程序员，更应该考虑当前的任务。不管是什么类型的MCU，如果产品形态变化了或者需求本身变化了，就要重新设计。未来谁都看不清，何必考虑那么多没有实际意义的前瞻。
十、8位处理器开发工作更繁重且没有升级路径
32位处理器的处理更加以软件为中心，可以做更多的代码复用。而8位处理器更多地利用硬件外设来完成任务。综合而言，没有绝对的差别。
只要是嵌入式处理器，升级路径都不大明确。如果你采用既有8位，又有32位的产品的厂家，你会发现很多外设都很相似。考虑到现在图形化配置外设的趋势，升级路径逐渐变得不那么重要，反正都是图形化或者脚本化来生成基础驱动代码。
来源：AI电堂
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
今天就来分享一个基于FreeRTOS的micro（微型）ROS。
一、关于ROS
ROS：Robot Operating System,，即机器人操作系统。
和普通OS不一样的是，ROS主要是针对机器人，是基于操作系统之上，提供一系列程序库和工具以帮助软件开发者创建机器人应用软件。它提供了硬件抽象、设备驱动、库函数、可视化、消息传递和软件包管理等诸多功能。ROS遵守BSD开源许可协议。
ROS设计者将ROS表述为“ROS = Plumbing + Tools + Capabilities + Ecosystem”，即ROS是通讯机制、工具软件包、机器人高层技能以及机器人生态系统的集合体。
二、micro-ROS
本文说的micro-ROS，是基于ROS2进行优化的一套轻量级ROS系统，它提供了完全部署的ROS 2生态系统的大多数吸引人的工具和功能，并具有入式和低资源设备的卓越能力，可以运行在MCU硬件平台。
传统上，即使机器人包含许多ROS，ROS仍停留在微控制器边界。它们通常通过串行协议与旧版ROS中的ROS-serial之类的工具集成在一起。
在微控制器中拥有所有ROS2的功能和相同的API会不是很好吗？这正是micro-ROS提供的-机器人系统嵌入式部分内部的ROS开发生态系统。micro-ROS允许开发人员在硬件级别附近运行ROS 2节点。这使所有硬件外设都可用于该应用程序，从而使其能够直接与SPI或I²C等低级总线进行交互，以与传感器和执行器接口。
微型ROS是一组分层的库，它们可以直接重用ROS 2的库，也可以使其适应资源受限设备的功能和需求。具体来说，如果我们转向ROS 2体系结构，则由微型ROS维护的层是ROS客户端库（RCL）和ROS中间件接口（RMW）。同样，RCLCPP是RCL之上的C ++抽象层，即使大多数与RCL直接接口，它也可以被微型ROS应用程序组件使用。该层在RCLC中提供了相对于ROS 2的附加功能，RCLC是用C99编写的库，其中专门设计和开发了与RCLCPP提供的功能类似的功能，例如便利功能或执行程序，以适合微控制器。
通常，ROS是基于 Linux系统之上的运行的一套系统，而本文这套微型ROS基于FreeROS运行。
这使micro-ROS在硬件和软件级别上都能与大多数嵌入式平台兼容。
但是，最终构成micro-ROS体系结构的是RMW实现，该实现基于称为Micro XRCE-DDS的中间件库。Micro XRCE-DDS是由对象管理组（OMG）定义和维护的DDS-XRCE（用于极端资源受限环境的DDS）协议的C / C ++实现。
顾名思义，DDS-XRCE是一种有线协议，允许引入以数据为中心的发布者-订阅者DDS模型进入嵌入式世界。DDS-XRCE依赖于客户端-服务器体系结构，其中客户端是用C99编写的轻量级实体，可在低资源设备中运行，而代理（C ++ 11应用程序）则充当客户端与DDS世界之间的桥梁。DDS-XRCE协议负责在这两个实体之间传递请求和消息。相应地，该代理能够通过标准DDS有线协议与DDS全局数据空间进行通信。在DDS世界中，代理通过与其他DDS参与者进行通信来代表客户。该通信由客户端代理，能够通过所有标准DDS实体与DDS进行交互的模拟DDS应用程序进行协调。代理将客户端的状态保存在其内存中，这样，即使代理断开连接，代理也可以存活。代理与客户端之间的通信遵循请求-响应模式，即双向并基于操作和响应。
三、为什么选择FreeRTOS？
由于它们的轻巧性，XRCE-DDS客户端库和microROS都易于在实时操作系统之上运行，这使它们能够满足其典型目标应用程序所提出的对时间要求严格的要求，其中涉及的任务包括要求时限或确定性响应。
具体来说，FreeRTOS已成为micro-ROS项目支持的首批RTOS之一，因此已集成到其软件堆栈中。这允许重用FreeRTOS社区和合作伙伴提供的所有工具和实现。由于微型ROS软件堆栈是模块化的，因此期望并期望交换软件实体。
FreeRTOS是开发micro ROS和Micro XRCE-DDS应用程序的理想选择。首先，它为许多不同的体系结构和开发工具提供了一个独立的解决方案，它以非常清晰和透明的方式编写，并且拥有非常庞大的用户群，从而确保了大量FreeRTOS用户将能够将其应用程序与微型ROS应用程序集成。而且，它是众所周知的高度可靠的RTOS。至关重要的是，FreeRTOS具有最小的ROM，RAM和处理开销。通常，RTOS内核二进制映像的大小在6K到12K字节之间。由于要与RTOS进行资源竞争，因此，当要最小化MCU上的微型ROS应用程序的内存占用量时，这些内存是理想的选择。
在下文中，我们将讨论FreeRTOS提供的几种功能，以及微型ROS如何利用它们来获利，以优化其堆栈中组成的不同库的所需功能。
四、任务和计划程序
FreeRTOS提供了一组最少的任务实体，这些实体与调度程序的使用一起，为在应用程序中实现确定性提供了必要的工具。微型ROS客户端库（RCL，RCLC和RCLCPP）访问RTOS的资源，以控制调度和电源管理机制，从而为开发人员提供了优化应用程序的可能性。
FreeRTOS提供的任务有两种：标准任务和空闲任务。前者由用户创建，可以视为RTOS上的应用程序。至关重要的是，将微型ROS应用程序集成到RTOS中作为具有给定优先级的此类任务之一。空闲任务另一方面，优先级较低的任务只有在没有其他任务在运行时才进入运行模式。由于microROS主要针对低功耗和IoT设备，因此这些空闲任务和相关的空闲挂钩非常适合在MCU中启用深度睡眠状态。由于将无状态XRCE-DDS客户端实现为micro-ROS中间件，因此这些深度睡眠状态可能是内存易失的，也就是说，由于面向连接的中间件有线协议，可以使用没有RAM持久性的深度睡眠模式。
使用FreeRTOS调度程序，micro-ROS能够管理其主要任务以及负责传输层的任务的优先级。通常，负责网络堆栈或串行接口的任务必须优先于micro-ROS应用程序。
五、内存管理
FreeRTOS提供的最令人期望的功能（对于微型ROS开发人员和用户而言非常有趣）是堆栈管理和静态堆栈创建能力。在处理micro-ROS的任务创建时，通常，堆栈分配是关键的设计决策。FreeRTOS允许进行细粒度的堆栈大小管理，这又使程序员可以知道在程序执行期间正在使用多少堆栈内存，或例如确定堆栈内存分配是否存在于静态或动态内存中，从而确定帮助正确使用MCU的内存，这是嵌入式系统中的宝贵资源。至关重要的是，可以为微ROS提供繁重的堆栈使用方任务，并为其分配静态分配的堆栈，从而防止将来出现堆和其他任务初始化问题。
在这方面，值得一提的是，这些内存管理工具为基准化微型ROS和XRCE-DDS的内存占用量提供了理想的框架。具体而言，已进行了彻底的堆栈消耗分析，以评估XRCE-DDS客户端内存消耗。堆栈是程序员在运行应用程序之前未知的内存块。为了对其进行度量，可以使用FreeRTOS uxTaskGetStackHighWaterMark（）函数，该函数返回在执行过程中XRCE-DDS任务堆栈达到最大值时未使用的堆栈量。通过将此值减去总堆栈，可以得到XRCE-DDS应用程序使用的堆栈峰值。用这种方法获得的结果汇总在此处发布的报告中。
我们还注意到，由于FreeRTOS中使用了可插拔的动态内存管理方法，因此micro-ROS能够完成所需的用于管理内存的接口。通过这种方式，已经使用heap_4作为参考实现了诸如calloc（）或realloc（）之类的函数。这些功能在馈入micro-ROS内存管理API之前已被包装，以便分析动态内存消耗。
与静态内存情况类似，FreeRTOS的可交换动态内存管理方法使在嵌入式系统中执行动态内存配置文件分析特别容易。的确，尽管在其他RTOS中，动态（取消）分配功能隐藏在RTOS或标准库的深处，但在FreeRTOS中，它们暴露给用户并易于定制，因此简化了处理和控制动态内存使用的过程。
六、传输资源
与客户端支持库访问FreeRTOS的特定原语和功能（例如调度机制）的方式相同，中间件实现Micro XRCE-DDS要求访问RTOS的传输和时间资源以使其正常运行。关于IP传输，在FreeRTOS的特定情况下，Micro XRCE-DDS使用在此RTOS上实现lwIP的附件。lwIP（轻型IP）是为嵌入式系统设计的，广泛使用的开源TCP / IP堆栈，旨在减少资源使用，同时仍提供完整的TCP堆栈。这使得lwIP的使用特别适用于以micro-ROS为目标的嵌入式系统和资源受限的环境。
除了TCP / IP堆栈，lwIP还有其他几个重要部分，例如网络接口，操作系统仿真层，缓冲区和内存管理部分。操作系统仿真层和网络接口允许将网络堆栈移植到操作系统中，因为它提供了lwIP代码和操作系统内核之间的通用接口。
FreeRTOS与lwIP 的集成是从头开始设计的，具有标准且熟悉的接口（伯克利套接字），并且具有线程安全性，旨在使其尽可能易于使用。而且，它可以将缓冲区管理保留在可移植层中。
请注意，XRCE-DDS客户端还支持FreeRTOS + TCP网络堆栈。FreeRTOS + TCP是用于TCP / IP堆栈协议支持的官方FreeRTOS扩展库。
还努力使FreeRTOS + TCP与micro-ROS兼容。这包括对TCP和UDP连接的支持，它们依靠FreeRTOS + TCP API来实现micro XRCE-DDS Client API所要求的抽象层，以便能够使用这些协议与代理进行通信。
此外，还存在使用FreeRTOS的时间测量功能的可能性，从而使XRCE-DDS库能够执行基于时间的任务，从而使用户看不到实现。
七、Posix扩展
允许将FreeRTOS无缝和盈利地集成到micro-ROS中的另一个显着原因是POSIX扩展的可用性。便携式操作系统接口（POSIX）是IEEE计算机协会为维护操作系统之间的兼容性而指定的一系列标准。FreeRTOS Labs提供的FreeRTOS + POSIX层实现了POSIX API的子集。
确实，尽管micro-ROS中间件具有较低的POSIX依赖关系（只是clock_gettime（）函数），但整个micro-ROS堆栈具有与功能和类型定义相关的更高依赖关系。另外，由于微型ROS项目的基本原理之一是移植或重用Linux（主要是POSIX兼容操作系统）中本机编码的ROS 2的代码，因此使用了某种程度上可与Linux兼容的RTOS。POSIX显然是有益的，因为代码的移植工作量很小。
为此，使用了sleep（）和usleep（）之类的函数。micro-ROS的POSIX类型定义依赖项依赖于FreeRTOS内核中未定义的某些结构，例如struct timeval或struct timespec。还需要诸如type.h，signal.h或unistd.h之类的文件来定义一些标准的类型定义和结构。
对于errno.h，尽管在FreeRTOS + POSIX层中未实现，但出于编译目的，micro-ROS必须包括一些不可用的定义。
通过使用FreeRTOS + FAT库，应在micro-ROS堆栈中重构这些定义，以使FreeRTOS + POSIX具有完全的兼容性。这样，可以完全支持依赖文件系统支持的高级micro-ROS功能，例如日志记录机制。
八、教程
如何在FreeRTOS上使用Olimex STM32-E407评估板创建和运行第一个微型ROS应用程序：
https://micro-ros.github.io/docs/tutorials/core/first_application_rtos/f...
（公号不支持外部链接，请复制链接到浏览器打开）
九、最后
总而言之，FreeRTOS提供了运行Micro-ROS应用程序的轻量且理想的RTOS，因为它提供了广泛的所需功能，实际上构成Micro-ROS堆栈的所有模块化层都在不同级别上使用了这些功能。
随着micro-ROS和FreeRTOS的用户群迅速扩展并且引人注目的用例激增，预计在不久的将来，micro-ROS与FreeRTOS和FreeRTOS + 提供的库进一步集成。
其中，对FreeRTOS + FAT库的利用显得尤为可取，以便添加一个虚拟文件系统组件，该组件允许像在完全部署的ROS 2生态系统中一样可视化和管理日志记录操作。
还设想了专用部分中所述的内存管理工具的进一步利用，以扩展XRCE-DDS客户端的内存配置文件，从而为micro-ROS客户端提供类似的分析。
micro-ROS项目计划的另一个未来行动是采用FreeRTOS的认证版本SafeRTOS。
最后但并非最不重要的一点是，似乎值得一提的是FreeRTOS与micro-ROS典型目标应用相关的硬件集成的两个非常成功的案例，即功能强大的Crazyflie 2.1无人机和ESP32 MCU的硬件。实际上，Crazyflie软件可以利用FreeRTOS的几种工具和功能来获利。微ROS应用与FreeRTOS的有关此MAV工作的演示的例子可以理解这里。至于与FreeRTOS本机集成并提供现成的Wi-Fi天线和蓝牙功能的第二种硬件，则已经在该系统上进行了最新的micro ROS端口。
更多内容，请参看：
https://micro-ros.github.io/
来源 | strongerHuang
原作者：Francesca Finocchiaro
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
Jacob Beningo
在这篇文章中，我们将详细探讨如何让微控制器进入睡眠状态并看看到底能够节省多少能耗。
低功耗模式实验
探索低功耗模式的最佳方法是选择一个微控制器并以各种低功耗模式实际运行该处理器。本文中，我决定翻出积尘已久的NXP Kinetis-L Freedom电路板，我曾经不仅用它进行过实验，而且还应用于许多产品、应用和课程。无论对错，我决定不仅要测量微控制器的能耗，还要测量整个开发板的能耗。MCU通常是电路板上的耗能大户之一，但测量整个系统的电流经常提醒我它并不是电路板上唯一的耗电器件。微控制器的优化长路迢迢，但其实它并不是唯一需要优化能耗的器件。
从基线测量开始
每当我努力优化一个产品的能耗时，我首先会从基线能量测量开始。通常我会通过分析几秒或几分钟内设备的电流消耗来了解应该从哪里开始。在我的开发板实验中，将Kinetis-L置于运行模式，无睡眠模式，所有外设均运行并设置电路板定期切换LED。通过采用IAR嵌入式工作台的I-Jet调试器以及I-Scope，我可以为该电路板配置一个简单基线，即LED关闭时电流消耗大约为16.9mA，LED打开时大约为18.0mA，如图1所示。显然，从哪里开始进行测量很重要，否则分析结果可能明显偏离。
采用等待模式和深度睡眠模式优化能耗 节省能耗最快的方法是执行等待或深度睡眠模式。研究Kinetis-L处理器的数据表可以得出，等待模式的能耗在3伏电压下的电流介于3.7和5.0mA之间。在此模式下，CPU和外设时钟被禁用，而闪存处于休眠模式，此时允许处理器在中断时间范围内(12-15个时钟周期)仍然可以被唤醒。等待模式易于实现，设置进入等待模式的代码如下所示：
void Sleep_Wait(void){SCB_SCR &=~ SCB_SCR_SLEEPDEEP_MASK;asm(“WFI”);}只需这两行代码，开发板的电流消耗就从18.0mA降至15.9mA。电流消耗减少了11.6%! 如果电路板由680mA电池供电，则该设备的电池寿命将从37.8小时变为42.8小时!两行代码就可以将电池寿命延长五小时! 这些高级电源模式的好处在于我们可以轻松地再向前迈一步。我们可以使用以下代码将处理器置于深度睡眠等待模式，而不仅仅是等待模式：
void Sleep_Deep(void){SCB_SCR |= SCB_SCR_SLEEPDEEP_MASK;asm(“WFI”);}我们所做的仅仅是调整了SCB_SCR寄存器中的一位，就已经将最初的18mA电流消耗减少为14.8mA。电流消耗减少了17.8%!同样，假设电路板由680mA电池供电，电池寿命现在已经从37.8小时增长为46小时!只需几行代码就可以节省大量能耗，而这只是冰山一角! 利用Stop模式和VLLS模式实现微安级电流消耗 采用停止模式可以禁用内核和系统时钟，这有可能将MCU电流消耗再进一步降低两毫安。你会发现，功耗模式越低，实现它所需的代码就越多，而唤醒系统恢复工作的代码就越复杂。令Kinetis-L进入停止模式的代码如下所示：
void Sleep_Stop(void){volatile unsigned int dummyread = 0;SMC_PMCTRL &=~ SMC_PMCTRL_STOPM_MASK;SMC_PMCTRL |= SMC_PMCTRL_STOPM(0);dummyread = SMC_PMCTRL;Sleep_Deep();}请注意，停止模式通过电源管理控制寄存器控制，一旦状态被设置，就会调用Sleep_Deep函数来完成电源模式的设置并执行WFI。
到目前为止，我们一直在谈论1~2mA的MCU能耗。现代微控制器将提供仅消耗微安甚至毫微安的电源模式!Kinetis-L处理器于2013年左右首次亮相，其超低漏电停止(VLLS)模式仅耗能135至496微安!初始化此电源模式的代码如下所示：
void Sleep_VLLS1(void){volatile unsigned int dummyread = 0;SMC_PMCTRL &=~ SMC_PMCTRL_STOPM_MASK;SMC_PMCTRL |= SMC_PMCTRL_STOPM(0x4);SMC_VLLSTRL = SMC_VLLSCTRL_LLSM(1);dummyread = VLLS_CTRL;Sleep_Deep();}讲到这里，你会发现微控制器已经几乎不消耗任何能量了!
低功耗模式对唤醒延迟的影响
正如我们目前所看到的那样，将处理器设置为越来越低的电源模式是节省能源的好方法，但这是需要付出代价的。处理器的能量状态越低，唤醒处理器恢复工作所需的时间就越长。例如，如果我使用标准停止模式，则处理器被唤醒并再次开始执行代码需要2μs加上中断延迟，这还可以接受。但是，如果在Kinetis-L上设置了其中一种VLLS模式，将需要启动处理器的唤醒延迟再加上额外的53到115微秒!有些应用可能无法接受这种状况。图2显示了Kinetis-L从低功耗模式到运行状态的各种转换。
结论
Arm微控制器都具有标准的低功耗模式，但每个芯片厂商都会定制开发人员可用的更多低功耗模式。正如我们所看到的，芯片供应商通常会提供几种容易实现的模式，对唤醒延迟的影响最小。他们还会提供几种超低功耗模式，几乎可以关闭处理器并且仅消耗几百微安或更少能量!开发人员通常需要在能耗和系统被唤醒需要的时长以及响应事件的速度之间进行权衡。而权衡一定是基于应用的，所以不要指望能够在每个产品和应用上都执行最低功耗模式。
来源：电子工程专辑
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
作者：Kevin Koestler
Omdia 预计，低功耗无线微控制器 (MCU) 的出货量将在未来四年内翻一番，达到 40 亿件以上。MCU 大量上市将为无线连接带来比以往更多的机会，并越来越多地用于各种应用和技术中，包括低功耗 Bluetooth ®、Zigbee®、Thread、Matter、Sub-1GHz、Wi-SUN 和 Amazon Sidewalk。通过16 款全新的无线连接器件，我们可帮助您创新、扩展和加速无线连接的部署，不受连接对象或连接方式的影响。
灵活支持不同无线连接设计
设计过程的第一步是选择无线 MCU，即选择 MCU 平台和无线电，以及从众多通信协议中选择一项合适的协议。业内不仅有多种协议可选，而且每种协议都具有多种特性和上百种选项，所有这些都会让您不知所措。随着要求的提高或终端产品的增加，更新设备和软件来紧跟无线领域的发展趋势变得不再简单。因此，应选择一款既适用于第一代产品又适用于未来产品的无线 MCU。
着眼于未来的设计可提供升级或扩展产品的灵活性，同时可重复使用现有投资，充分缩短设计周期并优化产品成本。更低功耗、更小尺寸、集成和新协议特性等全新的技术功能正在增加无线应用的数量。资产跟踪器、消费类可穿戴设备和远距离安防系统等产品都需要 MCU 平台提供各种不同的功能。
实现多协议系统
无线连接设计需要在不同类型的终端设备之间实现无缝通信。例如，在大型公寓楼的安防系统中，使用多个无线设备协同工作以保护居民。如果您正在设计具有简单传感器和复杂网关的完整系统解决方案（如图 1 所示），您需要一系列无线 MCU 来满足设计中的各种内存、功率和成本要求。
公寓楼的第一层安防措施是在每个公寓入口安装智能电子锁。多协议电子锁可使用 Sub-1GHz 作为远距离通信协议，并使用低功耗蓝牙进行配置，通过中央安全网关对每个公寓进行统一控制和监控。在这一层，必须考虑内存大小，尤其是在设计多协议应用时。
SimpleLink™ 多协议 CC1352P7 无线 MCU 非常适合同时应用 Sub-1GHz 和低功耗蓝牙协议的场景，具有 704kB 的闪存和集成功率放大器，可扩大范围以覆盖大型楼宇。未来升级电子锁应用时可能需要额外的内存，用于实现无线固件更新或最新协议规范所支持的功能，例如用于增加覆盖范围的低功耗蓝牙的编码物理层。
我们来看看另一个应用示例：图 2 所示的供暖、通风和空调 (HVAC) 系统。同样，不同类型的终端设备需要相互通信。考虑到在系统中采用恒温器，并通过添加远距离温度传感器来增强其效果，便于用户按房间监控和自定义温度。
对于恒温器网关，SimpleLink 多协议 CC2652P 或 CC1352P 无线 MCU 通过动态多协议管理器支持使用并发协议，同时具有 352kB 的闪存和 88kB 的安全随机存取存储器，可支持 Sub-1GHz、Zigbee 或低功耗蓝牙堆栈。为了降低温度传感器的成本，TI 设计了 SimpleLink 单协议 CC2651R 及CC1311R 无线 MCU 用于注重成本的应用。
恒温器和温度传感器在内存、尺寸和价格等特性方面具有不同的复杂性和要求，这证实了为什么选择价位合适、具有合适功能的无线 MCU 至关重要。它为初始设计过程和未来创新提供了自由。CC2562R、C2652P 和 CC2651P 具有预认证的系统级封装选项，可缩短上市时间。此外，无线 MCU 之间的软件兼容性对于优化投资和跨多代产品或库存单位的重复使用至关重要。
节省设计时间和投资成本
表 1 包含16 款全新无线 MCU（2021 年全年发布）的更多详细信息。如您所见，您可以选择闪存从 352kB 至最高 704kB的Sub-1GHz 或 2.4GHz 的产品，同时保持相同的封装尺寸和应用程序编程接口。
适应未来需求的可拓展性
选择无线 MCU 时，您不仅要为当前设计选择平台和无线电，还要为将来的设计做准备。通过16 款全新的无线连接器件，TI品类丰富的产品系列涵盖了先进技术以及直观的开发工具和软件，可让您连接任何价位合适、具有合适功能的设备。
当您设计的解决方案需要满足不断变化的无线连接需求时，实现自由灵活至关重要。没有人是一座孤岛，您准备好与我们的互联世界一起前行了吗？
来源： 德州仪器
免责声明：本文为转载文章，转载此文目的在于传递更多信息，版权归原作者所有。本文所用视频、图片、文字如涉及作品版权问题，请联系小编进行处理（联系邮箱：cathy@eetrend.com）。
