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