Alright, so what does this thing actually do?
It is a USB-CDC compliant serial port. That is, you plug it into USB, and you get old-school serial communications out the other side at 5V for 1, and 0V for 0. It also includes support for RTS/CTS & DSR/DTR signalling. Perhaps the best analogy, is this program does the same job as the widely used FTDI USB/Serial chips.
Perhaps the biggest difference between this chip and FTDI's chips however, is FTDI uses proprietary drivers while this project supports the USB standard CDC device. This allows it to work with the drivers available for Windows/Linux and Macintosh. In my testing, no "inf" files or drivers need to be manually installed. (Though, I've read that this may be different on systems running Windows 8 or newer)
So, is this program 1KB? It's slightly smaller in fact!
Reviewing the end of 1kcdc.lst we see the following:
"Program Memory Words Used: 509"
This means 509 16-bit words are used for the entire ROM image. Weighing in at a total 1018 bytes. Just 6 bytes to spare if we include the config registers at address 0x300000.
I guess the final question question remains. What is this project missing?
Currently it does not support the following:
- BREAK signal detection/generation
- Parity modes/parity failure detection
- More than 1 stop bit
- 5,6,7, or 16 bits of data
- Ring signal
- Framing error detection
- Buffer overrun detection
This means, aside from BREAK support, that this module only supports serial format 8N1, at baud rates from 183 through 2,000,000.
The PIC serial interface only supports 8 or 9 bit serial. Supporting anything else would require serial transmit/receive in firmware. This would have serious performance implications and I'm not really interested in doing the work to support it.
However, with the 8 to 9 bit serial support, either parity or extra stop bits could be supported. The total number of bits including parity and stop bits would have to equal 8 or 9, but supporting parity is something I've explored as I've seen it used in the field.
And a final shortcoming of the setup, is the way I hacked the baud rate generator. It produces standard baud rates just fine, however some baud rates will not result in the optimal divider. Error in these cases will be quite low, in less than a 10th of a bit per byte sent, but it's a kludge I'd leave out if not for the space constraints.