额，c/c++混用，这个是基础中的基础，在座的各位应该没人不知道吧，至于拿出来说么？

我说的arduino框架的极限，就是很简单的字面上的意思。arduino源于avr，本质上就是以avr的外设为蓝本，构造了一个虚拟的MCU，整合了各种常用外设的抽象。流行后有各种新的mcu架构被映射到了这个虚拟的MCU抽象上，同时也有大量的库基于它做了支持。因为解除了mcu arch和具体实现之间的耦合，它就可以很方便的实现n种mcu架构 x m种库应用的组合。这是它最大的价值，但这也是它的上限。说的更简单一点，arduino就是一个小而美的虚拟机。你当然可以享受这个虚拟机下生态带来的好处，但你当然也要面对这个虚拟机做出的取舍。

因为实际的硬件是如此的复杂，根本就不可能有一套统一的，又完全没损失的抽象来满足所有mcu arch x 所有的lib组合需求。比如arduino下你想要dma？只有samd架构下才有，你例子里的esp32就没有咯。比如dma资源冲突了咋办？arduino的dma抽象能帮你自动规划分配资源嘛？比如stm32/at32的adc2无法在dma2下使用，这种问题它的dma抽象能让你不关心细节闭着眼直接用嘛？
比如arduino有timer抽象嘛？能帮你自动分配timer资源么？有相当于stm32的timer这么复杂的设计嘛？为这样的timer设计写的库能无缝运行在各种mcu arch下嘛？
比如rp2040的PIO它能抽象一个么？能复刻到stm32，esp32，riscv上给个软件兼容实现，让我为rp2040/PIO开发的应用也能无缝跑在其他mcu上嘛？
答案当然都是没有，不仅仅是现在没有，未来也不可能有。它能做的就是把各种mcu arch最相似的那一小撮做抽象统一起来，任何差异化太大，有特色的东西都不可能有。这些就是你用了arduino后需要舍弃的东西。
当然，你也可以无限的给arduino做底层hack，把你要的特殊东西自己想办法port进arduino。那你就是放弃arduino最大的优势，当arduino不存在直接在hal库上开发。那这个时候就别再说什么arduino的生态优势了。

最后回到我的应用。首先我整个就基于canopen。我需要littlefs也是为了给canopen配上persistent。arduino上有canopen实现么？我这次用了at32，arduino现在有支持么？何况我下一版要基于rust重构，arduino ide支持rust么？
即使arduino有canopen支持，canopen本身就是要伴随着相当复杂的二次开发过程的。主要工作量也依然是canopen层面的工作，跟arduino又有啥关系？

所以我觉得我前面已经说的很清楚明白了，我并不关心你这个话题。在某个问题上用ai还是xx，效率谁高谁低根本就不重要。我在第一篇就说的很清楚：以前是有人开发库，构建生态，准备好各种各样的东西让你很方便的使用，让你不用重复造轮子。以后不需要了，ai可以按你的需求随时很轻松的捏一个完美适配你某个特定场景的轮子。这根本就不是谁好谁坏的问题，这是方法论上的巨大进步，是热兵器对冷兵器的代差，是降维打击。说的再简单一点，假设arduino真的做到了完美，任何需求都能满足，什么东西都是现成的，那我也会用ai在arduino下让它自己去编程。

最后，这个主题下我贴的所有代码，今天我都刷进去测试过了，gpt4写的代码在简单修正了编译问题之后，都是一次调试过的，它实现的逻辑毫无问题。不仅如此，它还帮我发现并修正一些我自己做的资源分配中的问题（比如这个dma2下不能用adc2）；因为我自己的错误提出的不合理的要求（比如我要求它写出所有的read/write函数，但它总是跳过了某些参数，后来发现是因为这些都是readonly的不能write）；以及一些因为我不知道某些细节而做出的低效设计（比如ds18b20是有唯一id的，通过一套扫描发现算法，可以一根总线驱动所有的ds18b20）；它还帮我debug过程进行了辅助，提出了很多建议（比如遇到问题我dump了一堆寄存器名和值，但我并不想去一个个查手册弄清楚什么寄存器什么值代表什么意思，直接让它结合问题现象给出分析建议）
这些统统不是什么用不用arduino层面的问题。未来已至，后面拥抱ai的，和排斥ai的，将是2个物种。这话说的有点严重，信不信随你。

【 在 Oriphia 的大作中提到: 】
: 在一个Arduino工程里，可以用Arduino自带的标准库wifi.h，也可以用ESP-IDF标准库的esp_wifi.h，区别是前者是CPP写的，后者是C写的。
: [upload=1][/upload]
: [upload=2][/upload]
: ...................
--
FROM 180.111.27.*