请教有无关于KBOOT 1.1.0 HID升级过慢的解决方案?

2020-02-11 10:18发布

如标题所述,目前打算直接使用KBOOT 1.1.0,HID模式。
但粗测了一下,升级速度实在是看不下去,太慢了(数据包过短),我都怀疑这货是不是USB。
目前对于HID类没接触过,所以想请教一下大家,是否有提速的方法,怎么实施?

如果没法提速的话,那我想,这释放出来的KBOOT HID,只能算是实验室的产品
如果是为了免去编写PC端的驱动的话,那么我想CDC-ACM虚拟串口,也可完成,而且跟操作串口无两样,这速度才能真正体现USB的优势。
友情提示: 此问题已得到解决,问题已经关闭,关闭后问题禁止继续编辑,回答。
该问题目前已经被作者或者管理员关闭, 无法添加新回复
8条回答
security
1楼-- · 2020-02-11 14:38
自己顶一下,呼叫 FSL 的 FAE 专家们~~~
Henjay724
2楼-- · 2020-02-11 19:28
Henjay724 发表于 2015-7-13 10:35
试试把kMinPacketBufferSize (在command_packet.h文件)、BL_MIN_PACKET_SIZE(在usb_descriptor.c文件里 ...

谢谢给出这么详细的帮助~
我后面会去从提高HID数据包的大小入手,能提高一点速度,是一点。
不过,单就修改这两个参数,我试验了下,没有起作用,数据包还是一样,估计PC端的也要调整,这就作为后面的一个优化方向,还是谢谢了~

经过这几天的45度角夜观星象,我发现,问题的根结在于:
1、HID数据包过短,导致分包过多
2、FSL的协议,PC端想要达到 "在数据阶段,能够根据device的反馈,判断是否应该abort掉数据的发送" 这样一个目的
  1. The data phase is aborted if the Generic Response packet prior to the start of the data
  2. phase does not have a status of kStatus_Success
复制代码
3、FSL提供的demo工具,很坑爹的在每一包数据包的发送前,都去进行这样的判断,而且超时时间是100ms
4、问题的关键是,正常情况下,压根就没有abort的情况,因此FSL的KinetisUpdater.exe,就这样,在每包数据发送前,白白等待了100ms
5、而正如第1点说的,HID的数据包的数量是较多的,每包都空等100ms,那么最终下来,时间必然是龟速
6、而FSL释放KBOOT 1.1.0时,没有测试覆盖全面,提供的测试数据只有2KB,这数据量看不出速度慢的问题。

解决方案:
1、提高HID的数据包大小,减少分包数量,但HID估计数据包提高不到哪里去(我没接触过HID,这里只是猜测),这作为备选方案
2、缩短这100ms的时间,这就要去调整源码,看看如何更好的实现。

目前我只是简单的将100ms,缩短为5ms,设置为5ms,是出于flash操作的保护考虑,对于小数据长度的flash的写入,这时间是足够的,而且5ms没收到数据的话,PC端HID的异步IO请求仍是pending的
如果真的abort请求的话,在下一包数据的发送前,会接收到此HID数据。

经过这样的简单5ms调整,重现编译dll库,原本升级61KB的数据,时间由
Successful generic response to command 'write-memory'
  - took 204.359 seconds
缩短为
Successful generic response to command 'write-memory'
  - took 19.024 seconds
security
3楼-- · 2020-02-12 00:57
本帖最后由 security 于 2015-7-14 11:26 编辑
Henjay724 发表于 2015-7-13 10:35
试试把kMinPacketBufferSize (在command_packet.h文件)、BL_MIN_PACKET_SIZE(在usb_descriptor.c文件里 ...


在device端调整这个size是OK的,是可以将HID的report数据包增大,从而减少分包数量。
至于昨天为什么验证失败,那是因为PC端并不是根据device来自动调整的,PC端也需要我们重新编译释放,昨天木有重新释放PC端的程序。
今天我将PC端的blfwkdll.dll重新编译释放,就OK了(PC端也直接依赖了command_packet.h的kMinPacketBufferSize定义,此时只需build动作)。

同时做如下调整:
1、HID的端点的中断interval,由10ms调整为1ms,缩短PC端HID的访问时间
2、撤销昨天的100ms调整为5ms的动作,还原为原有100ms
3、修改FSL的通信协议,调整为:在data phase阶段,每一包都有应答,一般情况应答success,当我们想abort传输时,应答abort
        这样,就不用每次都空等100ms(因为原先的协议,正常下不会发任何数据包)
        只要device处理完毕,就可以立即应答,这样PC端就可以立即响应应答,做出下一步的抉择,从而打通顺畅整个通信的脉络

经过这样的调整,发送升级61KB的数据,时间缩短至
Successful generic response to command 'write-memory'
  - took 8.553 seconds
我们可以看出,从原先龟速的 204.359 seconds,缩短至 8.553 seconds,是23倍的提速,而这样的时间,才是可以接受的。

至此,此问题就算结案了,我写下这些,希望对大家能有所帮助~
security
4楼-- · 2020-02-12 04:40
 精彩回答 2  元偷偷看……
terrymty
5楼-- · 2020-02-12 09:57
我的有块FRDM-KL25Z的板子,上面有个USB好像直接接到芯片引脚,还有一个openSDAd的USB,楼主说的USB是不是直接接到Kl25芯片引脚的那个USB啊?
terrymty
6楼-- · 2020-02-12 12:55
terrymty 发表于 2015-8-11 15:50
我的有块FRDM-KL25Z的板子,上面有个USB好像直接接到芯片引脚,还有一个openSDAd的USB,楼主说的USB是不是 ...

frdm kl25z我不清楚,我手上的板子是frdm k22f,我想应该差不多,板子上有2个usb,一个是opensda,调试用(cmsisdap,加虚拟串口,你在mcu中往uart打回显,opensda会转发,通过这个虚拟串口转发到pc),这个u口,同时也供电用;另外一个u口就是直连到mcu的usb口了,这个用在kboot的usb hid升级。

一周热门 更多>