请教有无关于KBOOT 1.1.0 HID升级过慢的解决方案？
如标题所述，目前打算直接使用KBOOT 1.1.0，HID模式。但粗测了一下，升级速度实在是看不下去，太慢了（数据包过短），我都怀疑这货是不是USB。
目前对于HID类没接触过，所以想请教一下大家，是否有提速的方法，怎么实施？
如果没法提速的话，那我想，这释放出来的KBOOT HID，只能算是实验室的产品
如果是为了免去编写PC端的驱动的话，那么我想CDC-ACM虚拟串口，也可完成，而且跟操作串口无两样，这速度才能真正体现USB的优势。 自己顶一下，呼叫 FSL 的 FAE 专家们~~~ 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掉数据的发送" 这样一个目的
The data phase is aborted if the Generic Response packet prior to the start of the data
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 于 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倍的提速，而这样的时间，才是可以接受的。
至此，此问题就算结案了，我写下这些，希望对大家能有所帮助~ 有个小问题，请教一下楼主，这个kboot的升级用的USB是UART还是OpenSDA啊？ 我的有块FRDM-KL25Z的板子，上面有个USB好像直接接到芯片引脚，还有一个openSDAd的USB，楼主说的USB是不是直接接到Kl25芯片引脚的那个USB啊？ 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升级。 security 发表于 2015-8-11 21:18
frdm kl25z我不清楚，我手上的板子是frdm k22f，我想应该差不多，板子上有2个usb，一个是opensda，调试用 ...
这里的“kboot的usb hid升级”是下载应用程序吧？ terrymty 发表于 2015-8-12 08:53
这里的“kboot的usb hid升级”是下载应用程序吧？
是的，KBOOT就是用来下载应用程序，或称为所谓的升级固件，只是下载的传输媒介有多种，例如UART、USB-HID。
页:
[1]