好消息: vista系统下avr-isp编程器的usb驱动已经实现

machao

avr-isp是德国一AVR爱好者的作品.它使用M8实现了USB接口,实现了简单实用AVR的ISP编程功能.在AVR STUDIO中可以非常方便的配合使用.

我在本栏中曾推荐并给出了修改的设计方案,（http://www.ouravr.com/bbs/bbs_content.jsp?bbs_sn=871314&bbs_page_no=1&bbs_id=1003）（http://www.ouravr.com/bbs/bbs_content.jsp?bbs_sn=754361&bbs_page_no=1&bbs_id=1003），而且也做了近100个在学校实验室中使用.解决了使用笔记本电脑没有并行口的烦恼.

由于这是几年前的设计,其usb的驱动只能支持到XP.这对于使用VISTA的用户非常不方便.

看到使用VISTA系统的越来越多,AVR STUDIO,CVAVR等也已经可以在VISTA下运行,因此在VISTA下AVR-ISP的usb驱动就提到议事议程上了.

在PSoC-KIT和PSoC-ISSP完成后,我在网上找到了相关的东西,现在AVR-ISP可以在VISTA下使用了.

点击此处下载 ourdev_441315.rar(文件大小:12K) (原文件名:avr-isp_vista.rar)


=========================================================================================
至于为什么AVR-ISP在XP下的驱动不能直接在VISTA下使用,看下面简单的介绍.

更具体的技术问题见文件包中原作者的说明和他的网站。


Although the low-speed bulk transfer is not supported on the USB standard, it has been working fine on Windows 2000/XP. However, it seems Microsoft changed their policy and Windows Vista does not allow this mode any more.

"lowbulk.sys" is a tiny filter driver to enable this transfer. It resides between "usbser.sys" and the USB port driver, and it helps configuring bulk pipes for low-speed device when connected. It just passes through the packets between the layers at other times.

This patch works as follows:
        Step 1.  Configures the interrupt pipes instead of bulk pipes.
        Step 2.  Reforms the interrupt pipes to the bulk pipes after the endpoints were generated.

This driver is designed for AVR-CDC, and may not work properly on other "low-speed bulk" devices.
This driver works on Vista x32 only. Vista x64 does not accept unauthorized kernel-mode drivers.

zxq6

谢谢，不过暂时还没换到vista的打算。

lhyj7080

好东西！记号

yyccaa

就是说，usb标准中只有全速/高速设备才能有批量传送端点，而avrcdc的硬件必须依赖低速设备的时序来实现CDC类，而CDC类中的数据接口却又必须使用批量传送，所以实际上avrcdc是以不符合usb标准的方式在通信的。

以前的2k/xp的usb总线驱动没有按usb标准做这个限制，但vista之后，m$在总线驱动中加入了这个限制，因此作为低速设备的avrcdc的包含批量传送端口的配置，对usb总线驱动而言已经是不允许被选择的。

作者通过在CDC类驱动usbser.sys等和usb总线驱动之间加入了一个过滤驱动来解决这个问题。

看了下这个过滤驱动的代码，可以发现，实际上GET_DESCRIPTOR仍不受影响（总线驱动没在这一步就毙掉avrcdc发送的配置描述符，因为它不解释这个描述符，而是传到上一层驱动去处理），但在实际通过批量传送的管道传输数据时，总线驱动会对低速设备的这个因素进行限制。

当处理usbser.sys发出的URB_FUNCTION_SELECT_CONFIGURATION时，把USB_ENDPOINT_TYPE_BULK替换为USB_ENDPOINT_TYPE_INTERRUPT，
欺骗总线驱动，以中断传送方式与avrcdc的批量端点建立管道（因为中断传输和批量传输在通讯协议上非常相似）。

        //    replace bulk pipes to the interrupt
        ......
            if( *(ptr+1)==USB_ENDPOINT_DESCRIPTOR_TYPE ) {
                if( *(ptr+3)==USB_ENDPOINT_TYPE_BULK ) {
                    *(ptr+3)    = USB_ENDPOINT_TYPE_INTERRUPT;
                    ......
                    *(ptr+6)    = 10;
                    if(bulk_count<MAX_NUMBER_OF_ENDPOINTS)
                        bulk_addr[bulk_count++]    = *(ptr+2);
                }
                ......
            }
        }

把修改过的URB_FUNCTION_SELECT_CONFIGURATION发给总线驱动
    status = IoCallDriver (deviceExtension->NextLowerDriver, Irp);

IoCallDriver返回后，要修改总线驱动给出的管道的类型，从UsbdPipeTypeInterrupt改回UsbdPipeTypeBulk，
这或者是为了欺骗上层的usbser.sys CDC类驱动，或者是为了恢复到实际的通信方式（我觉得应该是前者的因素）：

                    //    retrieve the replaced endpoints
                    if( pipe_info!=NULL ) {
                        for( j=0; j<bulk_count; j++ ) {
                            if( pipe_info->EndpointAddress==bulk_addr[j] ) {
                                if(pipe_info->PipeHandle!=NULL) {
#ifdef USE_BULK
                                    UCHAR    *ph = (UCHAR *)pipe_info->PipeHandle;

                                    if( *(ph+7)==UsbdPipeTypeInterrupt ) {
                                        *(ph+7)     = UsbdPipeTypeBulk;
                                        *(ph+10)    = 0;
                                    }
#endif
                                    pipe_info->PipeType    = UsbdPipeTypeBulk;   
                                    pipe_info->Interval    = 0;   
                                }
                                break;
                            }
                        }
                        ......
                    }

这样，通过欺骗上下2层的驱动，以中断传输方式与avrcdc的批量端点建立了管道连接，之后的数据传输其实不必再这么修改了，
因为DDK中，中断传输和批量传输都是用同一个“函数”UsbBuildInterruptOrBulkTransferRequest和同一个宏_URB_BULK_OR_INTERRUPT_TRANSFER发出URB请求的，并不作区分。

但有个问题我没搞明白，为什么作者在获取配置描述阶段时，把Communication Class通信类接口描述符和Data Class数据类接口描述符位置交换了下，难道是vista下的usbser.sys和2k/xp下的接口描述符顺序刚好相反么？

            //    swap the Communication/Data interface class descripters
            ......
            for( ptr=buf,pend=ptr+len; ptr<pend; ptr+=*ptr ) {
                if( *(ptr+1)==USB_INTERFACE_DESCRIPTOR_TYPE ) {
                    if( *(ptr+5)==2 )            //    Communication Class
                        p0    = ptr;
                    else if( *(ptr+5)==10 )        //    Data Class
                        p1    = ptr;
                    if( p0!=NULL && p1!=NULL && p0<p1 ) {
                        memcpy( pdsc+(p0-buf), p1, len-(p1-buf) );    //把Data Class复制到前面
                        memcpy( pdsc+(len-(p1-p0)), p0, p1-p0 );      //把Communication Class复制到后面
                        ......
                    }
                }
            }

machao

哈哈，楼上看来对USB的了解已经非常深入了。我只是找到这个东西，测试确实能用，而且非常稳定。因此推荐大家使用，但没有深入研究过。回答不了你的问题。

phone

3楼不简单呀！

gzzhang

很厉害！牛人太多了！

snoopyzz

专门前来景仰3L...

zxwr7282

看了 牛人越多 越发现硬件变的没有技术含量了~~~ 以后的微电子应该是软件的天下了

watercat

就我的开发经验看，在Windows下开发与硬件直接相关的上位软件，根本是自讨苦吃，受虐

特别是USB设备驱动，在Linux下只需要文件操作函数就能完成的简单工作，拿到Windows下面就成了什么高精尖技术，非得对操作系统有多么多么深刻的了解才能稍微使用一二——而且作出来的程序包管不能跨系统版本通用……更别提跨平台了……

其实就我的经验看来，类似USB-ISP这类东西，与其花大力气折腾什么Windows系统下的OOXX，不如直接转到Linux，都是开源软件，上位机程序永远比内核态设备驱动更好写更容易移植的……

PS：我在Windows下写Driver的年头可能比许多应届毕业生用电脑的年头都久，所以不必说什么酸葡萄理论之类无聊话了

PPS:同一个USB设备，只要我的udev配置文件相关段落写法一致，则无论接在PC上、接在ARM上还是接在AVR32AP7上，甚至于接在PS3上，都是可以依靠完全相同的源码来使用的，同时，不管PC、ARM、AVR32AP7甚至PS3，都有完全一致的本机编译器可用，换句话说，若我在四种机型上使用同样的USB设备实现同样的功能，则我只需要在任何一个体系下编写程序，并把代码发到各个不同体系的机器上，然后不加修改的在各体系本机make一下就能直接运行了，这两点，目前的Windows是拍马拍到手烂掉也做不到的……

watercat

至于8楼的说法，我觉得，这恰好证明了：

Windows系统架构让嵌入式开发变得本末倒置

嵌入式开发者在Windows体系下，所作的大量工作不是分析用户需求和实现对应的硬件功能，而是要花费大把的时间用在把标准的硬件功能翻译成Windows能理解的“家规则”中间件上，然后再由这份“家规则”中间件，来实现原本标准的用户需求

打个比方说，在Windows下做硬件密集型嵌入式研发，不但是脱了裤子放那个某种气，而且脱了裤子以后还必须在消化道末端插根管子，连上一系列转换器反应器，最终出来的却仍然是跟原本那某种气气味相同容量相同化学成分相同的“另一种气”……

非常的纠结

12345678

仰视一下9，10楼

ba1731

仰视一大片

watercat

举几种嵌入式开发最常用的设备来做说明吧

首先是USB

我们要明确，对于主机USB HOST来说，硬件只负责区分端口编号，以及已挂载的设备传输ID，至于什么生产商ID、产品ID、固件版本等等，都只是软件做的事情

在Linux下，已挂载的USB设备就会很简单的在/dev/usbdev*系列目录中增加一到几个条目，一一对应到你的USB物理设备所支持的各个传输ID上，并且设置设备文件访问权限（在常见的Linux发行版中，通常是root:users的664权限，但可以通过udev配置文件简单的更改）

这样，对于所有USB设备来说，使用它们的应用程序只需要编写成为一个使用标准文件访问函数对这些/dev/usbdev*条目进行读写的用户态应用程序即可，并且只要这个应用程序所运行的用户环境包含在users权限组下，就可以保证实现所有功能，当然，具体到哪个驱动对应哪个［生产商ID、产品ID、固件版本］（甚至于有些简略化的设备没有全部完整的ID信息，或存在可变ID信息，也是可行的），这都是应用程序自行扫描的事情，并且一个稳固的应用程序也应该有对诸如［文件被删除］或［文件被重新生成］的情况的应对措施，以确保设备插拔时不会直接错误退出

而换到Windows下，就变成了：Windows要求每个USB设备，必须提供一组完整且固定的ID信息，然后Windows自行通过这些ID信息找寻系统中注册的应用程序（而且实际上这个注册的过程非常麻烦、并且各个Windows版本间这个注册过程的底层操作几乎都不一样），同时，这些应用程序在正常情况下，大多是操作系统版本特定的——固然，你可以通过所谓的WDM方式编写稍具通用性的程序，但一来，WDM的操作非常繁琐，二来，即使用了WDM，至少32位和64位系统间仍然没有多少二进制甚至源码移植的可能性

另外，Windows还有一整套非常繁琐耗时（并且也非常花钱）的、美其名曰［提升系统稳定性］的所谓驱动程序认证和签名体系，越是新版本的Windows，这个体系管得越宽——并且这个认证只管你的设备是否能在特定的硬件体系和特定的操作系统软件版本下的“正确运行”（TMD，这事儿用得着M$来管么？），如果想用其它的操作系统版本，不好意思，你再交一份钱，我们给你再测一次……至于其它硬件体系……Windows实际上支持其它的硬件体系么？又有几个非硬件平台原厂的开发者知道怎么写WinCE下的设备驱动呢？

而这样一来，最典型的就是出现了一群所谓的［Windows设备驱动专家］（说真的，按我之前的项目经验来说，我也绝对应该属于这个群体——虽然现在想来，这完全是一种耻辱），他们未必对硬件有多深刻的了解，但他们非常精通［如何写出让Windows认可的设备驱动程序］，于是所有底层硬件工程师和上位软件工程师，若然自己不想或没有时间成为这种专家，就必须把大把的时间和精力花费在和这些专家进行沟通上，至于这样沟通下来的结果，是让你的程序“正常稳定运转”，还是三天一蓝屏，那就只有天知道了……

或许M$甚至于Windows盲从者都有一千个理由来证明［Windows驱动程序架构本身是好的，只是USB设备驱动的问题］，但我就想说了

至少对于USB设备来说，是Windows这种，把所有设备强行纳入自己定义的、家规则下的所谓［驱动程序架构］、然后一股脑的丢在内核模式运行来的好呢？还是Linux这种，系统只作硬件接口映射，然后所有使用硬件的应用程序在非特权用户的安全上下文中，运行一个用户态的普通应用程序来得好呢？

反正，我只见过USB设备把Windows系统带蓝掉，却从来没见过把Linux带死掉的USB设备

然后说说串行口

做过Linux开发的人都知道，在Linux系统下用串口，只需要用 fp=fopen("/dev/ttySx", "rw") 打开串口，然后再用一条 ioctl 设置串口包括波特率、校验、数据位等一系列杂项配置（如果只使用串口的缺省配置，则连这一条都可以省略），就可以直接用包括 fread、 fwrite甚至于 fscanf、fprintf之类的函数进行访问了，用完后，一个fclose，了事儿

至于Windows呢？我就不说什么了，有兴趣的人可以在本论坛搜索一下“Windows VC 串口”

再说说并口

并口现在用到的地方不多了，不过，至少在嵌入式开发、特别是针对三星一系列ARM9器件的嵌入式开发中，说并口是不可或缺的或许有些过火，但说没并口就非常麻烦，那是绝对跑不了的

在Linux下，并口操作同样简单， fopen打开 /dev/parportx，然后，每条ioctl对应一条并口控制寄存器读写指令，直接可以在非特权用户态程序中控制并口每一根数据线

若想在Windows下做到同样的事情，不好意思，直接问Windows那是绝对没戏的，必须通过自编的设备驱动程序（通常是giveio或winio），把用户进程的IO端口映射开放，然后用户进程还要在运行时呼叫相关驱动，而且最重要的是，由于并口硬件映射的IO区域并不一定是固定的（特别是那些通过PCI插槽扩展出来的并口，IO区域有时都不在16位IO空间内），所以若想要程序访问无误，就必须对用户态应用程序开放整个IO空间——这不算安全漏洞、不稳定因素，什么算？

这也就算了，更可气的是，由于Windows本来就没有设计并口直接访问的功能（而且显然M$也没打算增加这个功能，因为对M$来说，用并口的机器都该淘汰了，大家应该跟着M$的步调升级硬件、跟着M$的步调设计软件才对），所以若你的机器根本没有串口，也没有插PCI卡的位置（最典型来说，笔记本电脑），则你就打消主意吧，想用并口，换台老式机器吧……至于老式笔记本会不会因为分量问题导致你出差时飞机行李超重，M$是不会介意更不会去管的……

其它的无数内容更不必说了

总而言之，或许在纯桌面应用环境下，Windows依赖其长期垄断地位建立的用户习惯，仍然在相当长的时间内是难以动摇的，但至少，对于涉及硬件密集型操作的嵌入式系统应用（包括大部分工业级应用）来说，Windows并不是一个好的选择，甚至可以直接说，在这些情况下，Windows其实是最差的选择方案……

twoperson

闹了半天就是加了个copyright啊

frozenstar

听了watercat一席话，俺也想玩linux了。。中windows毒不浅了。。

electrician

８楼，不要扯到什么微电子，微电子和电子是完全不同的两个东西．

machao

哈哈，可以看出watercat是软硬件方面的高手了。

我没有去研究WINDOWS，也知道您所说的问题。只是在WINGDOWS下做事情的人太多了，我只是提供一个解决的办法，让大家能在VISTA下使用USB-ISP下载程序。

fugeone

连马老师都说是高手，那不是高手是什么？

198879

我WIN7下都在用，VISTA也早就可以用了，去官方更新驱动即可

machao

麻烦楼上把支持USB-ISP的驱动帖上来，让大家省点力。

lxyppc

【13楼】 watercat
---------------------------
哎，真羡慕做工控的
消费电子类的是无论如何也避不开M$的
而且现在M$的驱动签名认证更加严格了
不得不投入精力去研究微软的那一套东西

McuPlayer

哈哈，水猫把WDM说得体无完肤
其实MS一直试图建立这种家规则，像多媒体领域的DirectShow播放器框架，其实跟WDM是一个思路，不过是Ring3而已。

super373

讨论的好激烈啊~~标记下

e5399014

老师你好
请问这个驱动win7可以装么...
怎么装啊~~~谢谢

hdiskone

前段时间用过win7，很不方便，一些常用的软件环境都不能用。就改回xp了。vista就不打算用了，先收下备用。

walshao

不晓得这个WEN7可以用不