<<---------------明天成了3天后。继续总结

*****************************************
USB Video Class调试小结（续）
*****************************************

4. 按这个框架，重写JPEG到USB的发送程序。运行新程序，能够看到连续正确的JPEG数据包了，PC端摄像机 程序也后反应，但是黑屏，没图像。 BusHound抓到的数据包，到JPEG流一段，前2个是空白，这个好处理，编码好JPEG后先填满USB的两个BUF，再启动_SetEPTxStatus(, EP_TX_VALID)，这样收到的JPEG流，看头看尾都是完整的，但是就是黑屏。
 反复折腾都没有改进，无聊之下去翻看JPEG的编码，对照JPEG文件，已经能找到的BusHound抓包例子。乱调整一下，把省略了的APP0段加上，突然发现有图像出来了！他NN的熊。 
 JPEG Encoder是自己写的，为了节省Bytes，有些可选段没加上。回头一想也好理解，单个JPEG，APP0段是可选的，没有它也能显示；视频流模式，USB Video Class设备把数据流丢给DirectX  Render，后者要从每帧图像中找APP0段中的JFIF标记，或者，在数据流出错后，新的帧到来时，找到JFIF标记就丢给JPEG解码器。没有JFIF标记，初始化错，或者中间数据流出错，DirectX Render就直接罢工！显示黑屏。这个APP0段说是可选，实际是必选才行！

当初屏幕捕捉的图像，虽然不成样子，毕竟门打开了：

5. 有了信心，但图像仍有错。 瞄准JPEG Encoder，原来只支持Mono、YUV422，增加YUV420支持，用这个数据 量小一些，但UVC图像没还是有错，看到的数据包又是正确的JPEG。 调整payload header，没有错，对照N个payload包，数据正确，USB发送调度没有错...
 翻多了程序，没有顿悟也有渐悟：USB是中断处理中读数据，JPEG编码在主程序中执行，同时读写一片SDRAM，存在中断保护的问题! USB从SDRAM读出payload数据包时，引用错误的全局变量，随机地读到保存正在编码的JPEG区块了。
 对SDRAM的读取用的是分页机制，有多个寻址变量而不是简单的UInt32地址。底层函数设计时只考虑主线程中读的方式，中断时应对这些全局变量压栈保护。按这个修改，OK，稳定的图像出来了!

6. 整理和优化程序，框架是全新的，这个工作必须做。排除一些小Bug，偶而还会发现图像右下角会出现几个 错块，后来证明都是SDRAM缓冲读取的保护问题。 移植MT9M111 CMOS Sensor上来，这个是1280x1024的摄像头，用隔点取样法，从1280x1024图中编码320x240, 320x256, 640x480，测试都OK，基本的版本算是通过了。

（blog编辑时老是丢数据，浪费时间，明天再补充）