"xpyttl" wrote in message
news
pin part, so that from the bigger part you can simply do a printf() to
communicate to your PC over serial. It relies on a Microcoft provided
serial emulation driver. If your requirements are more demaiding, then
you will need to really hit the books. Doing the USB software interface
isn't real trivial.

mmmm ... I can see I should have been more explicit there, and maybe caught
a couple of typos.

There are a number of USB classes with different capabilities. There is a
serial emulation class, which Microsoft provides a driver for. It appears
on Windows as a new serial port, and applications access it as if it were a
serial port.

All USB devices must offer up a manufacturer code and a device code whenever
they are first connected. The OS reads a .inf file to connect the
particular codes to a driver. MicroCHIP provides an .inf file with the
board that points to a MicroSOFT driver which does serial emulation.

When the 16-bit part wiggles it's USART, the PIC18F2550 catches that and
sends it out over USB to the PC in serial emulation mode. The application
on the 16 bit part must set up the baud rate for the USART, but beyond that,
normal C I/O can be used, although it is pretty fat for many applications.

The documentation for the board says in comes with a dsPIC33FJ12GP202 but
mine came with a PIC24FJ64GA002 -- more memory but no DSP engine. The board
has jumpers to accept any 28 pin, 16 bit part. I've been doing most of my
experimentation with a dsPIC30F012. The 30F parts are 5 volts, the others
3.3, and the 30Fs have a slightly different pinout. Jumpers deal with both,
as well as deciding whether the board wants to be powered from the USB or a
separate supply.

For a lower cost implementation, the 18F2550 and its cousins have plenty of
gas to do more work, and Microchip does provide sample code for the USB
serial interface, but I've always been a bit suspicious of Microchip sample
code ... often it isn't quite as solid as one would hope.

...