Xiaofan Chen wrote: > Thanks for the information. Then it must be using a custom driver. > Do you use the Microchip supplied driver (Written for Microchip > Technology, Inc. by Walter Oney, author of the famous book > 'Programming the Microsoft Windows Driver Model') or write your own? We created our own driver, although we started with one of the Microsoft examples supplied with the DDK. My intent was not to just create a firmware/software solution for the USBProg, but to use the USBProg as a test platform for a complete USB PIC solution that could be applied to a variety of products. I wanted to have a well tested and field proven solution we could provide to customers. This was actually the main motivation behind the USBProg. Having another programmer to sell was a secondary advantage. The serial port is a simple, low cost, and very effective way for a host to communicate with a small embedded project. It enables small low cost or one off projects. Unfortunately the serial port is going away, at least for unsophisticated end users. USB is also cheap, simple for the end user, and even simpler than RS-232 for end device hardware. The only drawback is considerable software complexity at both ends. USB can do a lot of things, but if all you need is a basic bi-directional stream of bytes, it looks like a large investment just to get to what you had already with RS-232. There are ways to sortof get this from USB without too much work, but they are more kludges around USB than embracing the new technology and thereby getting the most from it. The most common one seems to be making your device HID class. That means you can use the standard HID driver built into the operating system, but has its drawbacks. HID isn't really meant to provide a bi-directional stream of bytes that can come close to replacing a 115.2Kbaud RS-232 connection. I wanted something that was designed from the ground up that best utilizes USB to provide a bi-directional stream of bytes that could be applied to many arbitrary microcontroller projects. We therefore created our own PIC USB firmware, and a host driver that worked with it and added the few niceties required to make a USB device "just work" for the end user. I plan on making this firmware/software available for free for personal and internal use, and charge a $3000 one time license per VID/PID combination for commercial use. I don't have the exact figures here, but all the USB firmware uses up around 7% of the 18F2550's program memory in the USBProg if I remember right. The firmware was carefully written in assembler and uses the 18F USB hardware to its fullest capability. It's not just a hack to get something working. It is broken into two executable modules USB and USB0. USB provides a simple get-byte and put-byte interface to each endpoint. The data types, buffer sizes, and which endpoints are enabled are defined in a include file, and the USB module automatically configures itself at assembly time accordingly. A put-byte or get-byte routine is created and exported for each enabled endpoint as appropriate. Under the hood it uses the ping-pong hardware double buffering feature with software triple buffering. In other words, one buffer can be getting sent, the next queued to be sent when the host requests it, with the application filling a third. The same works in reverse for receiving. USB isn't just a bi-directional stream of bytes, so a few additional details need to be exported to applications so they can make full use of USB if they wish. These mostly have to do with buffer management, like flush, hold, and determining whether the PUT or GET routines can accept or provide a byte now (just like the TXIF and RCIF flags for UARTs). The USB module also exports software interfaces for these kind of control functions. The USB0 module handles the endpoint 0 communication. In our model, endpoint 0 is owned by our software and firmware, and the application has complete ownership of the other endpoints. This makes private communication between our firmware and the driver over endpoint 0 possible while still being totally transparent to the application at both ends. This is one of the things that falls out naturally from USB which is not something you could easily do with RS-232. The USB0 module also has a include file where all the static enumeration data is defined in a easy to edit form, and the USB0 module configures itself accordingly at assembly time. For most applications, implementers would only have to adjust table entries defined in this include file and everything else is automatically taken care of by the "enumeration magic" in the USB0 module code. There are however a few issues that make USB inherently different from RS-232 that need to be addressed at a higher level. For RS-232 the end user had to be aware of what port a device was connected to, and then specify this to applications that used the device. There is no equivalent port number that a end user can easily find, and there could be many devices of the same type connected to the USB. A different way of identifying devices was needed. In our system, a unique name is stored in nonvolatile memory of each device. The end user specifies this name, and does not need to know the USB connection details. But how do you get the name to the host without dictating some part of the communications protocol the application must use? This is where private communication over endpoint 0 between the firmware and the driver come in. As part of the enumeration process, our driver inquires the device unique name string. This is saved in the driver, and can be inquired by application code at any time without new USB communication needed. General purpose host software can enumerate all the devices of the particular type and get their unique names. For example, the program PICPRG_LIST enumerates all USBProgs plugged into the USB and shows their names. All the other PIC programmer programs take the optional -N command line option to identify the particular programmer to use. The default is the first USB programmer if there is one, else serial port 1. This is to make it easy when you only have a single USBProg on your USB and therefore there is no ambiguity. Reverting to serial port 1 is to be backwards compatible with the existing programmers. The program PIC_CTRL allows setting a programmer name with its -SETNAME option. I'm not sure exactly when all this will be made available on the web site for anyone to use. I'd prefer only supplying the Windows driver in binary for free use, but don't know yet how to allow that to be configured for a VID/PID combination and a GUID automatically assigned. For now we are working directly with commercial customers who will get complete source code as part of their license. ******************************************************************** Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products (978) 742-9014. Gold level PIC consultants since 2000. -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist