活动
从 2023-11-01 到 2023-11-30
2023-11-24
-
20:23 VE问题 #2588: x86 Android 从8GB改为64GB后，增加一个SD卡的现象
- 思路2
Grub分区的大小，调整下
因为分区原理比较低级，如果容量不对，可能会造成一些残余的空间。 -
- 思路1
TIAN:
应该是虚拟的sdcard挂载到data上了
有这个应该不影响吧
没有，反而会有问题
一些APP运行需要这个目录
-
- 因为这个SD卡的存在，系统会自动提示，请格式化这个分区，
实际这并不是SD卡，只是一个EMMC的分区, 被误认为SD卡.
如果格式化之后呢，这个系统的引导程序（GRUB）就被破坏了，这是很严重的事情。
客户认为很容易被误删除...
2023-11-13
-
- 这个驱动并不是为了解决问题，只是为了监控一下
测试场景是Android 通过ch9104发给window上的PC
50 条 0到49行 ============ 这样的数据
2023-11-11
-
- CH9104也不行，数据丢失比之前V1414更严重，
APK去掉NO_NONBLOCK就不丢失数据, 也能OK.
看起来两家都有一样的问题. 目前只只有CP2102是可以的.
2023-11-10
-
- 如果友商的方案没有问题，那是不是exar的驱动还是要完善，
比如解决或者实现 nonblock？ -
- CP2102, USB to Uart ，无此现象。测试OK
-
- 使用exar 参考板，
1 同样存在问题，丢失数据。 和主板上是一样的情况
2 公版参考版的 RS232芯片 全部NG , 使用TTL测试的。
2023-11-09
-
- 当前总结一下：
APK 数据量比较大, (连续发送49行数据)
用PC的串口终端看到，数据少了
APK可以通过延时，或者取消 nonblock的方式，解决这个问题
但客户不认可，
客户需要从驱动角度解决。
2023-11-07
-
- 电话聊一下吧，看看原因在哪？tx的处理流程是不需要加延时，如果按照你们的现象看，就是对方没处理完数据，让tx晚点发咯
-
- 方向3 驱动方面
这个在串口发数据的时候，让他们跟一下驱动的debug信息，找到准确的发送数据函数，在哪里判断是否发送完毕，发送完毕后加点延时。
-
- 方向2
Apk 在JNI 文件里, nonblock was removed.
这样也是可以解决问题的
2023-11-06
-
- 收到。
1 COM5 是CPU的， 是一个简易信号。其他COM 是USB to Serial的， 是全信号。
COM5这个是新的反馈，我们要搭配APK , 反复再测一下 . 这个要做线。
2 客户意思不是apk... -
- @锐宝PM洪丰 @锐宝ARM软件经理周锐箭
关于Serial data损失问题，COM5是正常，只是USB to Serial的才会有问题。
是不是要修改USB to Serial 驱动？
客户反馈一次传送很多data时候...
2023-11-03
-
- 目前需要有COM口 apk开发经验的工程师，对上述进行一个判定
-
- - Serial port test data丢失的问题 ,客户不认可
客户无法接受贵司评估的增加Delay命令（usleep）来解决的方案。因为控制Serial Port的program（app）不是客户的，而是下游的客户进行的。... -
- 目前对apk进行了一个delay控制，可以解决这个问题。
2023-11-02
-
- 洪总，mxl那边确认也没有你们上次要的文件（APK 的 JNI 文件，访问COM用的），我们还是想把问题看看能不能解决掉，能够按照这个去复现加打印信息我们看看吗？
我们提供加打印信息的驱动，看看是挂在哪？
2023-11-01
-
- 方案1：
给字符串fd 的 close 动作，
给这里加一个点延时, (500mS 1S 5S ) 但没有效果，
还是打印到18左右
导出 Atom