WhyCan Forum(哇酷开发者社区)

原厂那边人没有用zsh这种比较便利的shell，所以才搞了OneStep命令。并且原厂那边可能OneStep命令用得多，非OneStep命令用得少，所以容易出问题。
我用zsh，根本不需要OneStep命令就用得很便利了。另外，OneStep命令不支持zsh shell，我都懒得提了。

还是遵循官方的硬件指南吧：
- 高速信号（EMMC、SD卡、RMII、RGMII、USB、LVDS、MIPI、DVP） 避免跨越不同参考平面
- QSPI接口 SPI_MOSI、SPI_MISO、SPI_WP、SPI_HOLD、SPI_CLK、SPI_CMD需等长约束（长度差建议不超过20mil）
- USB_DP、USB_DM需等长约束（长度差建议不超过10mil），差分对90欧姆阻抗匹配
等等

特别是USB，换层太多，还没走差分线

这不是编译器的问题，而是MCU资源太少的问题。所以8051这种MCU逐渐被ARM、RISC-V这些32位MCU替代。

用低资源MCU做开发是种很悲催的体力活。
本人十多年前用过那种OTP ROM或者Mask ROM的非Flash(不能在线调试只能仿真调试)，没有C编译器只能写汇编、汇编之下还没有除法指令的8位MCU时深有体会。

建议不要找这种用低资源MCU的岗位。

rust太复杂了，在MCU上写rust跟写C++差不多；
MCU上一般是用静态内存分配，用不了rust内存管理的强项；
不能直接调用MCU厂商提供的固件C库，只能用开源社区的库，代码质量反而无法保证；

所以MCU上的rust生态不可能会壮大，最多业余玩-玩而已。

TI 的GPMC吗？跟PBUS是差不多的东西吧

JLink怎么可能是仿真器！？那是调试器。

仿真器是那种MCU的ROM不是Flash而是OTP或Mask。OTP只能烧录一次；Mask不能烧录，只能将程序做在芯片的光刻掩模上。开发时不能像Flash MCU那样在线调试，只能通过FPGA之类的可编程器件去模拟MCU内核指令即对MCU进行仿真调试。这个FPGA板子才叫仿真器，通常由MCU原厂制作并带个壳子。

我评估过D21 Linux SDK跑AWTK demo，发现开不开G2D其CPU占用跟帧率都差不多。而G2D需要占用非常多的内存，于是直接把G2D关了，跑一般UI应用也是很流畅的。所以一般来说，跑方方正正的绘图UI，不开G2D足够了。

至于AWTK这边G2D的性价比低，不知是AWTK上的图形加速有问题还是其它，就得而知了。

方法二改法不太妥当。新版本下，Env.get函数返回的是deque、group.get函数返回的是list，再者不能用加号来组合。最好按下述修改：将deque转为list

diff --git a/kernel/rt-thread/tools/building.py b/kernel/rt-thread/tools/building.py
index 24bcf5cc..cf329981 100644
--- a/kernel/rt-thread/tools/building.py
+++ b/kernel/rt-thread/tools/building.py
@@ -779,8 +779,8 @@ def DoBuilding(target, objects):
             CFLAGS = Env.get('CFLAGS', '') + group.get('LOCAL_CFLAGS', '')
             CCFLAGS = Env.get('CCFLAGS', '') + group.get('LOCAL_CCFLAGS', '')
             CXXFLAGS = Env.get('CXXFLAGS', '') + group.get('LOCAL_CXXFLAGS', '')
-            CPPPATH = Env.get('CPPPATH', ['']) + group.get('LOCAL_CPPPATH', [''])
-            CPPDEFINES = Env.get('CPPDEFINES', ['']) + group.get('LOCAL_CPPDEFINES', [''])
+            CPPPATH = list(Env.get('CPPPATH', [''])) + group.get('LOCAL_CPPPATH', [''])
+            CPPDEFINES = list(Env.get('CPPDEFINES', [''])) + group.get('LOCAL_CPPDEFINES', [''])
ASFLAGS = Env.get('ASFLAGS', '') + group.get('LOCAL_ASFLAGS', '')

for source in group['src']:

X宝上大把，带壳的也有

转速快了之后是不是出现丢步？可能是电机扭矩不够，可以提高电机的驱动电压或更换扭矩更大的电机。

启动时有错误："Failed to get mtd config"，应该是分区配置有问题

不知是谁带坏了风气，总想把调试器做低成本而不是做稳定，导致x宝上的调试器特别是DapLink普遍都不稳定。

也可以加入反向扭矩来实现刹车，控制反向扭矩的大小应该就可以控制刹车的柔和度

正在尝试将基于AWTK的UI软件从RTOS SDK切换到Linux SDK，发现Linux SDK 1.2.7版本的内置AWTK demo跑不起来。
然而之前因为git pull不能成功，只好删除之前的再重新git clone。然而想回滚到上一版才发现上一版的历史已经没有了，最近的只有1.2.3

这样管理git仓库屁用没有！还不如直接将各版本打包，公布其下载链接算了。

Linux SDK仓库的历史只剩4条了，明显是为了减小体积而手动删除的。根治体积太大的问题，还是应该按我上面的方法解决。

你买的是带显示屏的开发板吧。除非是单色lcd屏或串口屏产品，正经的彩色显示屏不会带PCB

@gpfrank
D21x UART的字符超时中断就是你说的idle中断

吐槽下LVGL，它的API这么多年了都稳定不下来，几乎每年增大一个大版本号。这看似是发展快速，实则是核心设计有问题，一直稳定不下来。

这种冷门芯片都是这鸟样。建议用串口屏，简单、实在。

@244141084
步进电机转速过了1000RPM没啥意义，此时扭矩太小，带不了载。若真有高转速需求，则不应该选步进电机。

弱磁控制用于高转速场合吧，步进电机跑不了高转速。提高步进电机驱动效率主要靠电流闭环或力矩闭环驱动方式。

我用AWTK有一两年了，只要在awtk.zlg.cn网站保持登录就会持续发放LIC。
不过我不怎么用AWStudio，实际项目都是手写UI描述文件XML，特别是用了MVVM的情形。即使是手写XML肯定也比LVGL好用，LVGL现在才开始搞UI描述文件。

如果对MVVM感兴趣，可以关注我这几天的研究成果，用zig写MVVM应用，利用zig的泛型/反射特性直接从Model构建出View-Model：
https://gitee.com/ufbycd/awtk-mvvm-zig-example

示波器 + 差分探头，调节示波器的扫描周期与以太网信号同步时就会看到眼图，眼图越干净说明信号质量越好。

既然怀疑编译器。那它啥版本？哪来的？换过编译器没有？

肯定要看启动日志啦

也可用python -m venv 为sdk单独创建一个的scons运行环境，不要将其它软件安装到这个环境即可。

目前来说比较好的手段是连接jtag调试器来调试，不然真不好找CPU异常出处。除非异常发生于系统启动阶段，此时可以打log调试。

建议官方将CmBacktrace移植到RISC-V，方便追踪程序崩溃位置。

了解下RT-Thread的这个宏INIT_APP_EXPORT，就知道了

RTOS使用systick溢出中断的分辨率是毫秒，其计数器VAL的分辨率小于微秒。两者结合可以得到微秒分辨率的计时

抓不住精髓，废话一堆，没啥鸟用。

一堆东西放在一起，你要分清本质区别，才不会乱！

接触不良，要么是线、要么是接口

找到问题了！D21x是64位机，C++的初始化函数表.init_array应该是8字节对齐的，而SDK的链接脚本里弄成4字节对齐了。
按以下patch将链接脚本里的改为8字节对齐即可：

diff --git a/bsp/artinchip/sys/d21x/link_script/gcc_aic.ld.S b/bsp/artinchip/sys/d21x/link_script/gcc_aic.ld.S
index 7600a467..561a79ed 100644
--- a/bsp/artinchip/sys/d21x/link_script/gcc_aic.ld.S
+++ b/bsp/artinchip/sys/d21x/link_script/gcc_aic.ld.S
@@ -149,7 +149,7 @@ SECTIONS
*(.rodata.*)
*(.srodata*)
*(.rodata.str1.4)
-  . = ALIGN(0x4) ;
+  . = ALIGN(0x8) ;
PROVIDE(__ctors_start__ = .);
KEEP (*(SORT(.init_array.*)))
KEEP (*(.init_array))

88脚、100脚、128脚封装的引脚间距分别为：0.4mm、0.4mm、0.35mm

其实就一个问题：烧录工具软件只支持Windows。可能是官方错认为大家都是在Windows下用虚拟机Linux做开发，实则在实体Linux下做开发的应该不在少数，MACOS也算类Linux环境。

RTOS SDK那边有Linux下的命令行烧录工具(upgcmd)，但不稳定，且不支持指定分区烧录。
Linux SDK那边还没怎么研究，似乎没有Linux烧录工具。不过Linux下如果板子有网口很少在开发时直接烧录，而是通过网络共享的方式应用新固件或App，但没看到有文档介绍。板子没网口的话，也只能通过烧录来验证调试。

本人的开发环境是实体ManjaroLinux，目前用RTOS SDK做开发，SDK依赖库都能装上、源码编译无问题，唯独要时常开个Windows虚拟机来做烧录，肯定是不便利的。

工业应用一般都要求实时控制，所以有不少MPU+MCU的多核异构芯片方案，期待匠芯能出这种方案。全志就算了，SDK都藏头躲尾的。

看了下linux sdk里的PWM驱动，跟rtos sdk一样只实现了经过多个固定频率的PWM周期后就关闭PWM的功能。但这实现不了step/dir接口的加减速控制呀，加减速控制需要每经过一个PWM周期就修改一次频率！

不过改下linux驱动还是可以实现的，目前在rtos sdk上就是改了驱动才能实现加减速控制。

也是个好消息，D21x在Linux下是可以实现步进电机的加减速控制的，只是要修改下驱动。单主控方案没问题。

AiBurn上不是已经显示固件的存储介质是MMC了么？这个还不算？

混音、降噪等操作作得不好反而会削弱声音的立体感，因为这些操作会影响音频信号的相位，如果左右或前后两边的信号相位差过大就不能产生声像定位，从而丢失立体感。

这就是为什么由单个全频喇叭组成的低价2.0音箱会比高价的分频音箱具有更好的立体感。分频器，无论是硬件式还是软件式都会影响音频相位。

你Linux用得少吧，哪个开源项目不都是这样，版本号：官网Release版本 > ArchLinux软件仓库版本 > Ubuntu软件仓储版本

ubuntu软件包一般都比较老旧，你在ubuntu上安装或编译最新版本很容易掉进依赖地狱。

另外，我看了下：官方最新版没有到3，最新的是2.1.3，ArchLinux这边是2.1.2；官方文档最新版是2.1.2

@ubuntu
是pty可以认为是pts，默认情况应该支持中文。可以做以下尝试：
- 确认远程机的/etc/locale.gen文件是否有en_US.UTF-8 跟 zh_CN.UTF-8
- 将locale改为zh_CN.UTF-8
- 检测本机中文字体中否正确安装

哦,如果LCD刷新模式选择为swap_ex mode就不会因为 局部text更新而触发整屏刷新。

进一步测试发现是贴图导致刷新缓慢：如果没有任何贴图UI是比较流畅的，但只要有一个哪怕是非常小的贴图，刷新耗时就会超过100ms

搞电子工程就是要假设一切皆有可能，不能有侥幸心理。

估计是波特率误差较大导致，要根据时钟参数计算波特率误差来选择合适的波特率。

T113没有GPU吧，所有没有wayland-egl， 这个是wayland众多后端中的一个。换一个后端即可，T113支持的wayland后端应该有：fbdev、DRM、X11

而wayland是gtk的后端之一，如果要用X11的话，不如直接配置gtk使用X11作为后端。

TF卡座封装只有单侧焊盘，没有SOP8双侧焊盘的牢固。

工业产品内置的TF卡，肯定不是主存储器，主要用来存储不太重要的内容。

@xdlkliang
不行呀，在读取过程中产生进位，即是高低两个寄存器都已经变化了呀，那么两个寄存器都要重新读取。

所以要用do while流程来或以下的if流程来处理：

	hi = csi_coret_get_valueh();
	lo = csi_coret_get_value();

	// 产生进位的时间间隔是很长的，不可能在短时间内产生两次进位
	if(hi != csi_coret_get_valueh()) {
		hi = csi_coret_get_valueh();
		lo = csi_coret_get_value();
	}

发现RTOS SDK里有这个API：aic_get_time_us，其实现就是读time寄存器，于是找到上面问题的原因了。

我用的芯片是D21x，其CSR寄存器time是64位的，所以此芯片应该没有timeh寄存器，只需读time寄存器即可。
那么，基本上只需两条指令就能获取分辨率为1us的时基，不错！

最后D21x上读取内核时基的函数如下，D13x等32位MCU就没那么便利了：要读取寄存器2次且需处理读取过程中的进位情况

static inline uint64_t _read_csr_time(void)
{
    uint64_t value;

    __asm__ __volatile__ ("csrr %0, time\n\t"
            : "=r" (value) :
            : "memory");

    return value;
}

PS：RTOS SDK里d13x、d12x等读取系统时基的函数 aic_get_ticks，没有处理读取过程中可能出现的进位情况（读取时低32位寄存器发生32位进位），是否是一个BUG？！

u64 aic_get_ticks(void)
{
    return (((u64)csi_coret_get_valueh() << 32U) | csi_coret_get_value());
}

另外一个值得注意的是rt-thread第三方包的代码质量很一般。

比如目前用到的Third-party packages里的beep和at24cxx的代码质量一般，使用前要优化下才能放心用。

luban-lite的驱动分了三层，从上到下分别是：rt-device、drv、hal。大部分情况rt-device驱动即能满足要求，但也可以配合使用drv或hal驱动，后者就是你所说的标准mcu。类似于STM32的HAL和LL驱动混用。

比如我就对pwm的drv驱动稍做修改以添加中断处理函数，从而实现STEP/DIR接口的步进电机的梯形加减速控制。原驱动已经比较完善，改动不大。

这就是我为什么D21x的片子依然跑RTOS而非Linux的原因，OS驱动完善的同时也可以当MCU用。

用nm工具看了下cpp源码编译生成的.o文件，C++运行环境似乎要以下这些符号，看来不好弄。

T _Z8cpp_testv
U _ZNSt8ios_base4InitC1Ev
U _ZNSt8ios_base4InitD1Ev
U _ZSt16__ostream_insertIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_PKS3_l
U _ZSt4cout
b _ZStL8__ioinit

更正一下，eclipse也可以使用上面所说的compile_commands.json文件，这其实是一个"Compilation Database"文件。配置方法如下图：
配置好了之后eclipse就能正确识别工程配置，并提供流畅的代码补全功能。

个人还是觉得eclispe比vs code好用点，目前vs code的git插件比eclipse的差太多了。

配置后展示

20kΩ电阻和100nF电容的RC常数是2毫秒，且导通阻抗RDS在VGS(th)附近的变化是剧烈的，这对导通积热的影响可以忽略吧。
驱动容性负载导通时的瞬时电流超过最大漏极电流，这个风险是否可以忽略？

提示出错的语句为f'{x}'语法，这是python3.6起才支持的语法，很可能反而是python3没有安装。

什么原因烧的？

目前SDK里有命令行下载工具：upgcmd，此工具也可以通过构建系统来调用（scons --aicupg）。但我在D21x上测试发现很不稳定，只下载成功过一次。

可以参见这里： https://whycan.com/t_10926.html#p98462

我在nand flash上试了下，插入一千条数据耗时80ms、插入一万条耗时500多ms。看来跑fs + sqlite还得是nand flash好点。

stu add 1000                                                                              
Insert 1000 record(s): 83ms, speed: 0ms/record

stu add 10000                                                                             
Insert 10000 record(s): 562ms, speed: 0ms/record

哦，我这是D21x，cpu主频高点

各种不同工具的出现是为了迎合不同的需求。比如，交通工具就有很多种。

然而如果一个没有汽车驾照不会开车的人，没有领会驾考的意义就去漫骂汽车驾驶复杂，只会贻笑大方。

是的，我也觉得有问题。

littlefs起初是为nor flash设计的，不过看到也有人用于nand flash，不知是否真能用于nand flash。
uffs专用于nand flash。
fatfs用于SD卡或U盘，将它作为内部文件系统就有点奇怪了。

其中littlefs和uffs都对意外断电做了优化，而fatfs意外断电很大概率会出错，所以并不适用于内部文件系统

个人认为差不多，三极管也是需要基极维持一定的电压才能形成电流。

是的，开关搞慢点，主要是减少电流冲击并提高EMI特性吧

进一步测试发现，只有选中FATFS格式下的auto calcuate image size选项才能成功，即不能实现一个可读写的分区。

即这SDK不能保存任何运行时数据，无法商用。

晶振频率小导致经PBP初始化后的DRAM频率变小而已，又不是运行不了程序。在PBP之后修改PLL设定即可，有啥问题？

全屏刷新要1秒多，太慢了吧，使用体验差

Xorg并不只使用opengl，它可以通过DRM来使用显卡的2D加速，sipeed流畅的原因应该是这个，它的DRM支持D1的G2D。

不是芯片或配置的问题，触摸板的分辨率是个物理参数。可以用tslib经校准后强行拉到别的分辨率，或从淘宝就可以搞到别的分辨率的板但外形尺寸不一定合适

对比通过wayland来使用GPU会怎样？

开发环境基于Eclipse或VS Code都没有啥问题，这是当前开源且功能丰富的工具的两大主流选择。问题是PlatformIO主要面向萌新，有点能力的老鸟用这个就很不搭调。

这问题其实跟MounRiver差不多，起初MounRiver为了迎合Keil/IAR开发者的口味，对Eclispe大肆裁减，企图将Ecipse改为Keil，这引起Eclipse开发者的不满。

于是就有非社区版和社区版之分，非社区版裁掉了很多Ecipse特色的实用功能就是个开源版的Keil，而社区版则没有功能裁减只是增加了WCH家的插件。

我个人认为，作为一个面向各种资历的开发者的工具，没必要为了迎合新人而降低工具的天花板，把新人的入门引导做好即可。

你这PWM这么久了还没搞定呀。试下在Uboot里将该PWM所处的引脚配置为输出并输出低电平，或者在Uboot里也配置为PWM但占空比设为0。

有点无语，你把ARM平台的库安装到X86系统？

器件数不超过10个才叫“没有过多的器件”，你这里器件多着了，随便一个退耦电容接触不良都会导致整个系统出问题。

汽车仪表屏一般用LVDS的吧

样板怎么能只做一片呢，要做两三片看问题是否有共性，才好判断是设计问题还是制板工艺问题。

因为upgcmd模式下的USB不是tty这种标准设备，而是自定义的USB设备。

upgcmd会根据VID和PID自动查找USB设备而无需-d选项，只有在接入了多个同类设备时才需要使用-d选项来区分。

笑死！连机器学习都没有概念的人在大谈特谈AI

32位80251？为什么不选RISC-V？后者无论性能、生态、受权、扩展都能秒前者！

C/C++的构建系统就这样，乐鑫SDK用的是常用的构建系统。那些只会使用Keil/IAR工具的人，其对C/C++构建的知识可以认为基本为零。
所以为会认为乐鑫的SDK恶心。

上面那个udev rules就是通过udev添加设备节点呀: SYMLINK+="aic0"
USB设备接入后就会自动在/dev目录下生成aci0节点。其实不一定要加这个节点，只要权限许可就可以访问了。

另外，建议多了解udev。

Linux里的文件权限管理比Windows严格，无论是tty还是USB设置都需要用户对其有访问权限，可以用udev rules修改设备文件的权限模式来获取访问权限。

参照上面SEGGER那个非常有问题的测试对比文章，我用Zig写了类似的测试源码，其中两个测试结果：

$ zig build size --release -Dtarget=arm-freestanding-gnueabi -Dcpu=cortex_m23
text    data     bss     dec     hex filename
28828      16       0   28844    70ac /home/chenss/workspace/zig/code_size/zig-out/bin/code_size

$ zig build size --release -Dtarget=riscv32-freestanding-gnueabi -Dcpu=sifive_e34
text    data     bss     dec     hex filename
31326     232       0   31558    7b46 /home/chenss/workspace/zig/code_size/zig-out/bin/code_size

跑了多个测试发现RISC-V跟ARM的代码密码其实差不多（Zig对RISC-V32的支持要弱于ARM32）
详情参见这里：https://gitee.com/ufbycd/code_size

现在绝大部分人做调试器的方向都是错的，都是想着做低成本，而不是把东西做好。

导致现在在淘宝上买的DapLink很多都不稳定，要买多个对比实测才知道好不好用。真TM的一言难进！

不过上述方法有个大问题，因为很多编译相关的宏没有设置，导致工程里的很多符号没有被eclipse识别，这样写代码时很多东西不能自动补全，极不方便。

另一方面，按理来说，重复执行 scons --target=eclipse_sdk 后eclipse应该可以自动更新工程，并且应该不会的编译问题才对。

另一种工程管理方法：用VS Code配合bear(https://github.com/rizsotto/Bear)工具就可以检索复杂工程，用法如下：

* 先安装好bear工具，ArchLinux系统可以直接安装：sudo pacman -S bear
* 配合bear构建工程来生成clang的检索文件compile_commands.json：bear -- scons -j16
* 然后使用VS Code打开工程的文件夹即可，此时所有编译时用到的文件内的符号都能自动补全
* 工程因menuconfig更新后，需要重新执行第2部的bear构建来更新检索文件

复习下C语言的基础吧。只有位于BSS段的全局变量才会被自动初始化为0，而且这个初始化不是语言本身实现的，而是执行main函数之前的启动代码执行的。

工具链做得不好，本质上是因为C/C++相较于rust、zig、go这些自带构建系统的语言来说其构建系统就是一坨屎。

问题是产品的周期是很长的，只要有不确定的风险存在，就很难保证在产品的整个周期内它不涨。

为什么首先联想到的不是Layout？硬件设计只有电路原型设计吗？

所以说搞AI的人不懂PCB，只会下棋。

EDA大厂已经在搞了，但立创就不好说。

将复位引脚保持在低电平让其保持复位状态，然后再连接SWD即可。

那是不行。我一般只要IO口足够时都会分开控制RD和DE引脚，预留冲突检测的可能性。

许可协议都不遵守的就是流氓，流氓还有什么好讲的！拒之于千里之外才是正道！

D13x内置的内存规格为：
        64Mb，16-bit位宽，最高频率 200MHz DDR
        32Mb， 8-bit位宽，最高频率 200MHz DDR
注意，内存是DDR时序的，一周期传输两次数据，而SDRAM一周期传输一次数据。我记得，STM32F7/H7也支持DDR RAM。

luban-lite是SDK的名称，兼容RT-Thread和FreeRTOS，也支持裸机开发。目前使用SDK需要了解Kconfig和scons(也就是RT-Thread那一套)。

如果镜像的文件系统是ext4之类有写入功能的格式，可以挂载SDK编译生成的镜像文件，然后就可以直接复制进去了。

嵌入式Linux在开发阶段通常网络引导的方式启动嵌入式系统：uboot通过tftp加载mtd分区内容到内存，再通过nfs挂载位于PC端的文件系统。

f1c100s如果不能在uboot启用以太网的话，可以在板子进入Linux系统后通过网络接收内核和设备树的mtd分区内容，然后用mtd工具直接写入mtd分区(flash)，然后重启。

哦，看来是我搞错了，P扩展是DSP+简单SIMD指令；V扩展是加强版的SIMD指令，RVV指的是V扩展，一般要高性能MPU才有。

从来没用过小日子的芯片，有用过的能否说说感受？

发表言论前为什么不查查Cortex-M85是不是也是双发射的呢？

官方给出Cortex-M85的指标是6.28 CoreMark/MHz。相比Cortex-M7，标量运算性能提升30%、向量运算性能提升400%

太粗心了吧，官网的文档中心里有讲SDK的获取方式。

检查USB转串口芯片是否支持CDC，不支持就要安装该芯片的VCP驱动。

如CH340G芯片只支持VCP驱动，那么就要安装CH341SER驱动。

板子上带的USB HUB