linux 2.6下编译usb驱动和arm板进行数据通信(7) ubuntu, 处理器, linux, Intel, 通信

yuyang911220

但是和libusb-0.1.12一样,在
Intel处理器（DELL OptiPlex 330) 不支持AMD处理器（DELL OptiPlex 740)主板上ubuntu出现不稳定现象，在
AMD处理器（DELL OptiPlex 740) 不支持Intel处理器（DELL OptiPlex 330)主板上表现出色，
如果这样来看的话，只能说ubuntu在DELL OptiPlex 330主板usb驱动模块不稳定了，但是
在DELL OptiPlex 330上对u盘进行数据操作一切正常，具体不清楚到底是咋回事，唉！！！[注：很有可能DELL OptiPlex 330上usb数据传输速度太快，下面arm板上的驱动对于快速数据传输反应不过来，但是加入mdelay(10)进行10ms延时之后，仍然出现同样的问题，所以80％问题是ubuntu在DELL OptiPlex 330主板上不稳定！]



ps：可以肯定的是pc确实已经把通信数据发送下去了,在调用read的时候,一直不能等到设备返回应该返回的状态信息，协议上可能不存在丢包后数据重发机制，所以可能确实是因为pc下发的数据包丢失了，所以设备端因为没有收到数据,以及校验包完整性措施，进而，不能和tcp/ip数据传输那样有很好的容错能力，看来marvell设计的这个通信不成熟阿，
所以在协议设计上，对丢包处理、数据干扰后的校验重传机制等对任何产品来说不是必要的，而是必须的，所以文件切包之后进行包序号标记是很有意义的,可以参考成熟的tcp/ip数据传输、校验、重传等方式！[gliethttp_20080529]
ps：所以从这里来看,所谓的设备通信不稳定，就是在于设备对丢包和误码处理不完善，虽然bulk类型端口的通信能够保证数据传输正确性，但是不能保证因为线路干扰严重或者系统自身的问题超过bulk内定的重试次数之后引起的丢包现象！[gliethttp_20080529]




                                                                                                                               

应用程序：仅供参考 int usb_fd = 0; char * DeviceName = "/dev/gliethttp_flash0"; //#define USBDEBUG #ifdef USBDEBUG int    dbg_level = 1; #define usb_dbg(args...)    \     do {            \         printf(args);    \        }while(0) #else int    dbg_level = 0; #define usb_dbg(args...)    \     do {            \     }while(0) #endif void dbg_usbStatus(WTPSTATUS *WtpStatus) { #ifdef USBDEBUG     int i;     if (WtpStatus->DLEN > 0)     {     for (i=0; i< WtpStatus->DLEN; i++)         printf("data 0x%2x-----", WtpStatus->Data[i]);     }     printf ("\n");     printf ("CMD 0x%2x-----", WtpStatus->CMD);     printf ("SEQ 0x%2x-----", WtpStatus->SEQ);     printf ("CID 0x%2x-----", WtpStatus->CID);     printf ("Status 0x%2x----- ", WtpStatus->Status);     printf ("Flags 0x%2x-----", WtpStatus->Flags);     printf ("DLEN 0x%2x-----", WtpStatus->DLEN);     printf ("\n"); #endif }