【国民技术N32项目移植】汇总一下我踩过的那些坑

国民技术与电子发烧友联合举办的N32 MCU移植挑战赛，从10月份开始报名，到现在已经持续好几个月了，现在马上就接近最后交作品的日期了，我也要赶在DDL之前完成作品提交。

在正式提交作品之前，我先跟大家汇总一下，聊聊本次大赛，我踩过的一些坑。

1 写在前面

在梳理我的踩坑之前，我补充说明一下，我这边的基本情况：

我的项目名称是：基于N32G4FR和小度音响的智能家庭中枢控制系统。本项目主要使用N32G4FR作为端侧的核心控制器，外加一个传感器器件、控制器件，实现与云端互通；同时集成对接小度智能音响，实现通过语音调度和控制家庭环境是智能设备。这里的智能设备包含有智能灯、智能空调、温湿度传感器等等。

在参加这次国民技术大赛之前，我曾基于国民技术的N32G457参加过另一次比赛，当时很荣幸得了个第一名，详见：【N32G457】基于N32G457和RT-Thread全新打造的私有化定制家用式智能告警系统（2022年国民技术MCU&RT-Thread设计大赛第一名作品）

所以基于那次比赛的认知，我对国民技术N32还是印象比较深的，对这次参赛也充满信心。

可是，过于信任还是不行的，果不其然，该踩的坑还是踩了。

2 踩过的坑

下面简单聊一聊这次踩的几个坑，不多，就暂时罗列8个吧！

2.1 开发环境的大坑

我是一开始就想着基于RT-Thread来开发的，而RT-Thread官方的仓库推荐开发N32G4FR有IAR/MDK开发环境，也有gcc的编译环境。

我本人是不习惯使用IAR和MDK环境的，于是首选env+scons开发，一开始赶紧拉代码整编译，最后编译是编译出来了，但是烧录进去没有log，跑不起来？

我还一度怀疑是不是烧录有问题？或者我的串口有问题？

最后我想，要不我妥协下，使用MDK开发吧。结果芯片的package又没有，FTP服务器都登录不了，真的是走投无路了。

后面一想，N32系列不是好几款芯片吗？应该都是兼容的吧？

我想起我之前还留有N32G457的bin文件，直接烧录进去，果然，嘿，有log输出，这让我看到了希望。

之前我开发N32G457是用RT-Thread Studio开发环境的，于是我直接就搭了一套N32G457的开发环境，就基于RT-Thread Studio来玩。

后面得到了验证，这个方案是可行的。所以我就直接沿用这个方案，把我的应用代码挪过来调试了。

就是RT-Thread Studio有些慢，后面有提到，后面还是要多多摸索别的开发环境。

2.2 下载固件还是一样坑

官方提供的下载是 Nations MCU Download Tool V1.2.2

这玩意你要是第一次使用，分分钟把你搞崩溃，动不动这不行，那不行。

我这里给大家梳理一套，我使用比较丝滑的操作：

2.3 FTP资料的下载问题

官方给出的下载资料地址是一个FTP服务器 ftp://58.250.18.138

大家一定要注意，直接使用浏览器或者Windows的资源浏览器是很难打开的，别问我是怎么知道的。

推荐使用专门的FTP下载工具，比如 FlashFXP v5.4.3970 Prortable ，需要的可以联系我。

2.4 串口复用导致的引脚问题

我的项目中，计划使用UART4作为红外传感器的接入口，一开始我查了一份datasheet，发现它的引脚是：

然后找了另一份datasheet，看了它引脚是：

试了都不行，怎么都收不到数据，后面无奈之下，我想看到RT-Thread的适配代码，那里总会有写UART4适配时用的引脚吧。

于是找到了下面的代码：

以试验后果然是这个。

实践证明：代码才是最可靠的，其他文档都是仅供参考。

这也从侧面说明了，有些引脚复用配置的，存在多种可能性，一定要跟进自己的实际情况来连接。

还有一点，N32系列适配RT-Thread时，默认使用的V1版本的驱动框架，如果你的应用代码用了V2版本，记得修改一下，不然可能编译、运行会有问题。

2.5 paho-c MQTT 开源库订阅多个主题的问题

这个我不相信没有遇到类似的困扰，结果就是我搜了一圈，没有热给出一个合理的方法，貌似默认大家都懂怎么使用，还是怎么的？

难度大家玩MQTT都是只订阅一个主题吗？

到底怎么用，我都差点去问ChatGPT了，最后还是忍住了，先自己看看代码吧。毕竟都是开源的，于是我找到了相关的头文件代码：

struct MessageHandlers
{
    char *topicFilter;
    void (*callback)(MQTTClient *, MessageData *);
    enum QoS qos;
} messageHandlers[MAX_MESSAGE_HANDLERS]; /* Message handlers are indexed by subscription topic */

void (*defaultMessageHandler)(MQTTClient *, MessageData *);

它是通过messageHandlers数组来实现多个主题的存储的，而且这个MAX_MESSAGE_HANDLERS还是支持menuconfig的，默认值是1，这也是后面为何我用了这种方式订阅多个主题，结果还是不行，原因就是这个值默认值是1，你要支持多个主题，还得配置一下。
    
代码调用如下：
/* set subscribe table and event callback */
client.messageHandlers[0].topicFilter = rt_strdup(CFG_MQTT_TOPIC_AC_IN);
client.messageHandlers[0].callback = n32_mqtt_sub_callback;
client.messageHandlers[0].qos = QOS1;

client.messageHandlers[1].topicFilter = rt_strdup(CFG_MQTT_TOPIC_LED_IN);
client.messageHandlers[1].callback = n32_mqtt_sub_callback;
client.messageHandlers[1].qos = QOS1;    

通过多个下标来完成几个主题的订阅。很丝滑，但是不知道的，你死活也不知道怎么玩。

2.6 吐槽一下RT-Thread Studio的构建编译速度

这个速度真的是太喜人了。尤其是当你配置了一些选项，然后要重新保存生成配置项时，估计你看到那个进度条都快睡着了。

如果有充裕的时间，我一定会选择用scons编译环境，至少配置完一下子就可以编译，不用盯着个拼命发呆；而用scons的话，自定义流程也可以把握一下。

你以为的是使用RT-Thread Studio方便了你开发，其实很多时候它在无形中拖慢了你的开发。

2.7 硬件APP把人都整奔溃了

硬件APP的口号是：为硬件发声。

我觉得立意还是挺好的，就是我的体验比较差。

差的并不是浏览视频方面，而是导入本地视频到剪辑，再到最后成功发布的整个过程，体验真的太差了。

有以下几点待改善：

导入视频后，点击完成，然后合成视频，这个速度太慢了，我就一个3分钟左右的适配，给我十几二十分钟还没合成好；
好不容易合成100%了，结果给我提示err=-2 或 err=-28 之类的，然后就没了；你在点击完成，又给你冲0%开始合成一遍；又等。。。
就上面两个过程，我发现，每合成一个100%，你本地就存了一个副本，然后这个副本又没有啥用，就为了上传一个视频，不一会我的手机存储空间就没掉了1个G；
好不容易到了发布页面了，设置好封面，填好标题，点击发布，然后一下子整个也没调到一个推荐视频上？诶，我的视频呢？哪去了？去【我的】那里也看不到，我一度以为APP沙雕了；后面又重试一下，仔细留一下，才知道处于【发布】时，左上角有个0-100的进度圈圈，不仔细看压根看不到。是不是可以这么理解，我在上传我的视频的同时，可以看一下别人的视频解解压？
还有一点，如果你不认证的话，只能上传3分钟以内的视频；一开始我并不知道，傻里吧唧地录一个7分钟的视频，结果硬生生要切割成3个视频上传，然后手机APP还死活成功不了，最后还是用网页版成功了。

你说这样的操作体验，我估计是不敢再用了。