【极海G32A1465汽车通用MCU评估板测评】“以为是把工兵铲，实际是柄倚天剑”

只看该作者 · 2024-12-15 14:18

本帖最后由 lihuasoft 于 2024-12-15 14:53 编辑

　　11月下旬，在21ic论坛活动专区，无意中看到了Geehy在做“G32A1465汽车通用MCU评估板测评”活动。一念之间，一扇门就打开了，一片崭新的天地就在面前。因G32A1XXX的部分资料需要在官网申请下载，使我有机会大致浏览了Geehy官网，惊叹极海公司网站的清晰、简洁，每一张图片、每一个文件、每一个链接，都为了实用，根本不存在为了美工效果而拼凑的虚头巴脑的内容。产品门类不多，但已足够丰富，APM32微控制器已经形成几大系列，而电机控制专用MCU、汽车通用MCU产品对我最具吸引力。
　　拿到G32A1465的数据手册、用户手册、SDK，离公布测评名单还有一些日子，我只是习惯性地跳到文档的CANFD外设等章节，简略了解。一是因为还不清楚自己能否入选，不想浪费了时间；二是固执地认为：“汽车通用MCU”，那不就是“车规级MCU”吗？重点看看CAN通信、LIN通信，别的也没什么新意了吧？就这样直到12月初，确定我已进入名单，于是用了一个晚上从头研读G32A1465的用户手册，心里惊呼：

　　——纳尼？！原来“汽车通用MCU”是超越“车规级MCU”一个维度的存在！特别是与ISO 26262安全规范有关的内容，一边读，一边让我明明白白地认识到了自己的无知浅薄。
　　——原以为这款MCU只是一把普普通通的“工兵铲”，没成想它竟是一柄内藏真经的“倚天剑”！

　　那时我已经后悔在申请板子时说自己“曾经做过轮式工程机械的研发”了，觉得非常不好意思——我用的MCU，在车辆应用方面，根本无法与G32A1465这种专业的汽车MCU相提并论。这还在其次（毕竟我搞的是非道路车辆），主要问题在于：我设计软硬件时，缺少安全意识，就连做个伪随机数，ECU之间互相验证一下，都没有想过。如此说来，我设计的ECU那基本上就是光着屁股上街......至于非法嵌入汽车总线系统内部的鬼，就更不敢想了。唉呀呀呀，不能说了，请原谅我们只是小小的个体户，而且前东家是个好老板。

　　所以，“测评”二字，真的不敢当，我觉得，就算一次学习经历吧，感谢Geehy+21ic论坛给的这次机会，使我这样一个小学生，有幸进入这片对我来说崭新的天地。期待以此为契机，持续了解极海的MCU，未来有能力把G32A1XXX、APM32M3514写入自己的简历，用Geehy的MCU去赚钱。

　　废话已经写了不少，接下来打算写一写这几个题目：
　　  ●  研读G32A1465手册、SDK的一些收获
　　  ●  点灯
　　  ●  CAN通信测试
　　  ●  CAN FD通信测试
　　  ●  结合某两种功能做个接近真实场景的实验
　　  ●  ......
　　下面，先呈上第一部分，后续的内容会利用下班时间，在占楼部分陆续完成。

　　（一）研究G32A1465手册、SDK的一些收获

　　1、G32A1465的用户手册写得真好，实用、易读，干货满满。篇幅最大的几个章节，应该是“安全相关、CFGTMR定时器、CAN”这几章，这也是这个MCU最重要的武器库。以CAN这一章为例，有近一百页，里面详细介绍了CAN外设在芯片内部的工作逻辑，比STM32的手册详细多了。SDK每个例程都有一个readme，文档写得相当规范，让人信服，虽然是英文表达，但丝毫不影响阅读理解。

　　2、我所见过的一些名为“某某32”的Cortex-M内核的MCU，内核自不必说，外设其实与STM32大同小异，因为寄存器逻辑都是差不多的。然而我发现G32A1465还是很不同的，就拿GPIO来说吧，它有一个“端口逻辑电平翻转寄存器”PLLOT (port logic level out toggle)，端口电平的翻转可以批量完成：

复制

void PINS_HW_GPIO_TogglePins(GPIO_T * const gpioBase, PINS_CHANNEL_TYPE_T pins)



{



    gpioBase->PLLOT.reg = pins;//可以同时翻转多个IO，只需一个赋值，交给硬件就完事了



}

　　可以同时翻转多个IO，只需一次寄存器赋值，交给硬件就完事了！用途......车用LED动态氛围灯？令人有无穷想像！

　　而STM32是这样：

复制

void HAL_GPIO_TogglePin(GPIO_TypeDef *GPIOx, uint16_t GPIO_Pin)



{



  if ((GPIOx->ODR & GPIO_Pin) != 0x00u) //需要先读出、做判断



  {



    GPIOx->BRR = (uint32_t)GPIO_Pin; //虽然看起来可以一次翻转多个IO，但实际受到极性一致的限制



  }



  else                                 //何况还必须软件做判断，这样效率就低了



  {



    GPIOx->BSRR = (uint32_t)GPIO_Pin;



  }



}

　　需要先读出、做判断。虽然看起来可以一次翻转多个IO，但实际受到极性一致的限制。何况还必须软件做判断，这样效率就低了。

　　G32A1465在寄存器级基因上做的这种改进，一定有令人兴奋的用途，这就需要嵌入式工程师的智慧了。应该不止这一个寄存器，手册还没看完，我只负责抛砖引玉。

　　3、像我这样的已经熟悉了STM32CubeMX自动生成初始化代码的，其实是被驯养，有了工具依赖。这样就会逐渐丢失了直接撸代码的血性。而且STM32的HAL库函数封装嵌套层数太多，代码跟踪学习让人望而生畏。
　　G32A1465的SDK库代码，却让人觉得层次清晰（某些特征挺像TI的SimpleLink库，但要比TI库清晰得多），让我这样的水平差一些的初级程序员感觉亲切，有了信心。

只看该作者 · 2024-12-15 14:20

本帖最后由 lihuasoft 于 2024-12-15 14:23 编辑

占楼
　　（二）点灯

只看该作者 · 2024-12-15 14:20

本帖最后由 lihuasoft 于 2024-12-15 18:16 编辑

　　（三）CAN通信测试

　　这层楼主要是做传统CAN的测试，CAN FD的测试会放在下一层楼。
　　但是在此有必要先说一说我的CAN通信工具。因我以前的项目只用到经典CAN，从来没有用过CAN FD，于是，得知自己入选名单后，斥“巨资”买了USB-CANFP工具，就是下图中的小小黑盒子（本人不建议你买这个）；而那个红色的东西，是我一直在用的USB-CAN（同样不推荐买这个，我了解它的缺点）。
　　于是，现在我有2个CAN分析仪了，那就把这总共3个CAN设备连起来：

　　G32A1465板子上已经焊接了120欧的匹配电阻，再把小黑盒自带的120欧电阻接上，那个红色的CAN分析仪接在中间，要把电阻拨到关闭位置。于是总线两端都有了匹配电阻，一条情绪平和的CAN总线就有了。实际上这么短的线，不接120欧电阻应该也是没问题的。
　　先做一个CAN通信测试吧，评估板发出协议帧，两个CAN分析仪都收到了：

　　为了人为地让帧数据显得复杂，我把数据搞成1-10个连续的bit作为一个数据元素，这可能就是“画蛇添足”的本意吧。下面是上述效果的发送代码：

复制

void Key1Handler(void)

{

                /* Send standard CAN frame */

                eightBytes_t eightBytes = {

                                .bit0                 = 0b1,

                                .bit1_2         = 0b10,

                                .bit3_5  = 0b111,

                                .bit6_9  = 0b1011,

                                .bit10_14 = 0b11000,

                                .bit15_20 = 0b100111,

                                .bit21_27 = 0b1001100,

                                .bit28_35 = 0x5A,

                                .bit36_44 = 0b100000110,

                                .bit45_54 = 0b1111111111,

                                .bit55_63 = 0b000000000

                };



                CAN_DATA_INFO_T txDataInfo = {

                                .msgIdType  = CAN_ID_STANDARD,  /* Standard CAN ID */

                                .dataLen    = sizeof(eightBytes_t),      /* Payload size */

                                .fdEnable   = false,

                                .isRemote   = false

                };

                CAN_SendNonBlocking(CAN0_INSTANCE, TX_MB, &txDataInfo, TX_CAN_MESSAGE_ID_1, (uint8_t *)&eightBytes);

}

　　还简单地做了报文负载测试，两个分析仪马力全开，同时以最短的时间间隔持续向总线上发送报文，G32A1465评估板全部接收成功。我觉得G32A1465用在汽车总线通信和工业即时通信场景，一定能够胜任。

只看该作者 · 2024-12-15 14:20

本帖最后由 lihuasoft 于 2024-12-15 16:56 编辑

　　（四）CAN FD通信测试

　　CAN FD是在数据负荷区提高速率，加大了数据负荷能力。以前了解过，但没用过，在此只做一个实验。在使用时需要注意比特率有两个，都要设置正确，否则会报错的。
　　为了掩饰自己小白的真实身份，特意用了一个充电机的协议帧，显得自己好像很懂的样子（名为BCS，扩展帧ID为0x1811FEFE）：

　　实验代码直接用 SDK\Examples\G32A1465\CAN\CAN_FdFrames 这个例程稍做修改如下：

void Key1Handler(void)
{
BCS_t BCS = {
.BCS_C_Vol = 470, //充电电压测量值
.BCS_C_Cur = 1190, //充电电流测量值
.BCS_B_VMax = 425, //最高单体动力蓄电池电压
.BCS_B_VMGroup = 3, //单体蓄电池组号
.BCS_SOC = 90, //当前荷电百分比
.BCS_E_Tim = 18 //估计剩余充电时长
};
CAN_DATA_INFO_T txDataInfo = {
.msgIdType  = CAN_ID_EXTENDED,  /* 扩展帧ID */
.dataLen = sizeof(BCS),    /* 数据长度 */
.fdEnable = true,          /* Enable CAN FD */
.fdPadding  = 0x00,                /* Use 0x00 for FD padding */
.brsEnable  = true,                /* Enable bitrate switch */
.isRemote = false
};
CAN_SendNonBlocking(CAN0_INSTANCE, TX_MB, &txDataInfo, 0x1811FEFE, (uint8_t *)&BCS);
}

　　编译下载固件到G32A1465评估板，按下Key1，CANFD分析仪收到报文BCS这个报文（ID = 0x1811FEFE）:

只看该作者 · 2024-12-15 14:20

本帖最后由 lihuasoft 于 2024-12-15 14:25 编辑

占楼
　　（五）结合某两种功能做个接近真实场景的实验

只看该作者 · 2024-12-15 14:20

占楼

只看该作者 · 2024-12-15 14:21

本帖最后由 lihuasoft 于 2024-12-15 18:18 编辑

（因本人见识有限，以上内容观点修辞有不当之处，敬请谅解）

1万 · 2024-12-16 09:31

尼姑用倚天剑

【极海G32A1465汽车通用MCU评估板测评】“以为是把工兵铲，实际是柄倚天剑”

技术新星奖章