哇酷®开发者社区(WhyCan® Forum)

速率要求是多少？WinUSB设备也是免驱的，USB FS下使用批量传输时速率大概9.6Mbps；比HID大概的传输速率400kbps高不少了。

哪里超出显示范围？有些终端输出是不会自动换行的

libiconv将多种编码合一个so文件里面，所以文件比较大。glibc的gconv的编码文件是各自分开的，想要什么编码就添加什么文件，无需重新编译源码方便剪裁。比如GBK.so大小才100多KB

100-strip_charsets.patch 那个补丁应该就是嫌无用编码太多进行裁剪的，刚好将GBK给裁了。

rt device都是基于hal实现的，什么叫不完整？是有些驱动要在RTOS里才好实现。

你用STM32这类单片机搞UI,那些UI资源大小都是数MB大小，如果指望UI有个小改动就去烧录芯片，用SWD去烧录一样不好整。

如果确认是编译器优化的缘故，就要修改编译优化选项改为 -O0  并添加调试选项 -g

可能是断点处的代码被编译器优化了。另外纠正一下，这叫调试，不叫仿真；那些什么什么Link的是调试器，不是仿真器。

将非标准USB设备做成WinUSB设备就好了，可以用系统自带的驱动，干嘛非得自己写驱动。

正常来说不同控制间是相互独立的，相互占用不同的内存地址空间。你这种情况可以等效为接入几个独立的CSI传感器，即4组数据线和时钟线一对一相连即可。
至于V4L驱动，我认为无需修改驱动，就让系统认为是接入了4个摄像头，只要在应用上将4个摄像头抓取的4张图片合成一张图片即可。

实际来说Linux即使打了实时补丁依然不能算作实时系统，而是通用系统，它设计之初注重的是吞吐量处理。
个人觉得，你测0数据长度帧率并不能体现它的吞吐量处理能力，而是实时控制的时延指标；应该测64字节长度的数据帧率才是迎合它的设计初衷。

不懂电子的小白，何时靠AI就能做出合格的电路板？

WCH-LinkW是用CH32系列无线MCU实现的无线调试器，单个使用时支持有线调试，两个配对后支持无线调试。

网上有卖，单个20、两个38，性价比高。

ubuntu何在？

往另一方面想，待遇越高被裁的概率也越高；升到一定程度后，工作压力也会跟待遇成正比（无论是否是通过副业来提高）。待遇主要在于选择。

灵活变通吧，比如先将uboot烧录好，后面想怎么折腾都可以

rtos启动速度200ms应该是非XIP启动的耗时，不过这个XIP启动我也没有深究。
D13x的SDK是全公开的，在这里： https://gitee.com/artinchip/luban-lite

MPU最好选支持XIP启动的。
匠芯创的D13x、D12x是类似MPU的MCU，480MHz、支持XIP启动、集成DDR内存、带图像处理器；

操作系统的IO操作都是有缓存的，缓存在系统内核里。如果想要IO操作即时生效，就要调用flush接口；或者在open的时候添加flag指明不使用缓存。

背光是用PWM调控亮度的吧？是PWM的频率太低了。如果将亮度设成100%就不再闪烁，那就是这个问题。

问了原厂，CH32M030C8已经量产了。
极简的电路方案还有点诱惑的，不过我的电机驱动算法有浮点运算，上这芯片的话得改成整形运算才行，晚点再研究了。

无源晶振工作于闭环反馈电路，两个主控的震荡电路就是两个闭环电路，合不了一起。

哪部分代码？model和view-model都是模型，都是业务代码，当然是手写的。
Zig这边的模型都是Zig结构体，而非AWTK的tk_object_t对象；这里的“封装”是将view-model结构体转换为tk_object_t对象，封装手段是泛型反射；可以理解为Zig的view-model在编译时转换成了tk_object_t对象。

在MVVM框架下，model是纯数据模型、view-mode封装了model并添加UI所需的属性和命令用于跟view交互。
而awtk-mvvm其实没有model而只有view-model，而view-model的实现方式是使用代码生成工具将C的结构体转换为tk_object_t对象。

有硬件I2C肯定首先硬件的啦，迫不得已才会用软件实现，软件I2C搞得再好其CPU占用都会比硬件的高

声明式UI框架依赖编程语言的泛型和反射特性，目前要在C类似级别的语言上有享有泛型反射，Zig是个不错的选择，虽然它还没达到1.0版本。
Rust可能是另一个选择，但它是C++级别的，复杂度偏高了；调用C也比Zig麻烦好多；故不选Rust。

不同芯片厂家的gpio的配置不是完全相同的，我没用过全志的MPU，找了下示例，全志的GPIO端口C的2、3脚似乎是这样配置的：

sda-gpios = <&pio 2 2 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;
scl-gpios = <&pio 2 3 (GPIO_ACTIVE_HIGH|GPIO_OPEN_DRAIN)>;

@dukelec
磁编码器方案在于性价比，而使用带光电编码器的闭环步进也很常见了。

但是就论最极端工况工作温度125℃下误差1度，此时跑FOC虽然不理想，但也是可以跑得动的。
如果实际工况真有125℃，肯定不会上磁编码器而上光电编码器了。所以磁编码器的实现应用误差肯定是比规格书的极限误差小。

TMC的无感FOC方案是电流闭环的改进。现在的步进驱动方案基本都是恒流驱动了，所以做电流闭环是自然而然的事，但电流闭环驱动下依然会有失步风险。所以TMC的无感FOC方案主要是减小无位置传感器时的失步风险，其实应用依然是低速下的位置控制场景。

源码目录的文档：Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
或在线内核文档：https://www.kernel.org/doc/Documentation/devicetree/bindings/i2c/i2c-gpio.txt

MCU开发我一般用串口调试，只有在项目初期才会用调试器做单步调试。搞个串口命令解析器，串口收发加上缓存这样串口调试基本就不会影响程序执行时序，也是很方便的。

再进一步，就可以将底层收发进行抽象封装，让命令解析器支持实体串口、SDI虚拟串口等。

阻止编译器对部分代码进行优化即可，实现方式有两种：

一、对变量添加 volatile 关键字后该变量即不会被优化掉；
二、用#pragma GCC optimize 预处理指令指示部分代码的优化等级，如：

#pragma GCC push_options
#pragma GCC optimize("O0")
 // 强制指明O0优化的代码区域
#pragma GCC pop_options

今天调力矩闭环步进电机驱动软件时，不知哪里改得不对，电机突然狂转，转速飙到3000rpm。
这或许就是你所说的弱磁控制吧，只是后面在正常情况下怎么都复现不了这个转速，有点耐人寻味。
这个驱动器所用的驱动芯片是DRV8870之类的斩波恒流驱动芯片，并用磁编码器实现位置闭环。

手上有根CH340芯片的USB转RS232串口线，发现在Linux下可正常使用，但在Window10、11下不能正常打开，九成是仿冒芯片了。
估计市面上还有仿冒芯片做成的USB串口线流通，大家需要注意。

仿冒芯片，确实可恶。pin对pin研发芯片不犯法，但这个仿冒芯片通过逆向抄图还共用人家的系统驱动，导致因兼容性而使用户无法正常使用，真的非常可恶。

只有图片为非压缩的bmp之类格式，且像素格式跟framebuffer的一致才不需要解码；否则纯CPU解码会非常耗时

是的，flush只是确保没有缓存了，但最后一个字节可能还没发送完成。所以至多还要延时10个bit的传输时长。

还有一个方法就是RS485芯片的DE和RE引脚分开控制，让发送的同时使能RE并开启串口接收，当接收到的数据长度跟发送的一致时，表示发送已经完成。
这样做还有一个额外的功能，发送的同时接收，如果接收到数据跟发送的不一致，就表示发送有问题。

芯片支持RS-485硬件自动控制收发方向，即串口支持RS485模式。用硬件RS485-DE引脚不是更方便简单？

没明白电压跟检查工作有什么关系。身高1米8的老板就检查不了身高3米的员工是否正常工作？

你是疑惑两者身高不匹配？办法有两种：
1. 检查工作的时候用分压电阻将员工身体弯下来到1米8即可
2. 直接将员工的身高压缩到1米8来工作，现在很多正常身高是3米3的员工即使身高压缩到1米8依然可以正常工作

内存条有问题或接触不良

知识储备太低了，问题都问不清楚，搞毕业设计不要急功近利，多看LVGL文档或教程就可以解决

U11内部有一个由VOUT指向VIN的二极管，而VSUPPLY为0V时MOS管栅极悬空，此时MOS管应该处于导通状态。
另外不知道MOS管是什么型号，其内也有可能有体二极管由电池指向VSUPPLY。

DE是什么信号？I8080接口本身并没有垂直同步信号，只有个别LCD屏才会有这个额外的垂直同步信号输出，I8080接口显示屏通常叫这个信号为“TE”

电路极其简单，引脚使用非常极限。LED驱动电流300mA以上

@liyucai
粗略来说，应该是这根天线使原线路的阻抗变大，等效于添加了串联电阻。

先编译内置的工程，再来整自定义电路板吧。

现在的新手提问，普遍都是给出的信息少得可怜，一般人都懒得鸟

TF卡前一两个扇区需要存储分区表，扇区大小通常为4096Byte，所以TF卡前8KiB空间是预留给分区表用的。

将hostname写到/etc/hostname文件里

肯定是老方案啦，用这么多引脚的Flash芯片，不然PCB板可以更小。PCB板也是要成本的

原厂那边人没有用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没有安装。