Uploading the firmware
If you are familiar with Atmel programming you probably know what you are doing. The Makefile in lcd2usb/firmware/Makefile assumes, that you are using a simple STK200 compatible printer port adapter.
Connect the assembled device (no display required yet) via USB to the PC. It will not be detected yet, since it doesn't contain the firmware. Connect it via the download cable and the programming adapter to the linux pc with installed uisp tool and type "make fuse; make flash-nodep" to upload the firmware.
If the Makefile doesn't work for you you can also flash the device manually using avrdude and the aforementioned STK200 compatible printer port adapter with the following parameters:
avrdude -c stk200 -p atmega8 -U lfuse:w:0x9f:m -U hfuse:w:0xc9:m -U flash:w:firmware-avrusb.hex
To manually upload the firmware using the usbasp just use the follwing command:
avrdude -c usbasp -p atmega8 -U lfuse:w:0x9f:m -U hfuse:w:0xc9:m -U flash:w:firmware-avrusb.hex
If your are familiar with a different AVR programming system you can of course use that one as well. But you'll probably have to do some minor adjustments in the Makefile.
For simplicity reasons, the LCD2USB interface only uses USB control messages. More efficient and faster bulk transfers are only available to high speed devices. A USB control message for a low speed device consists of exactly 8 Bytes. The first byte indicates the control type and has to be set to a fixed value for vendor specific commands like the LCD2USB is using for its own purposes (non vendor specific commands are e.g. used to request the device name and id etc). The remaining seven bytes are the request type (1 byte), a value (2 bytes), an index (2 bytes) and a length field (2 bytes) for data being transmitted with the control transfer. The LCD2USB protocol does not send extra data, thus the last two bytes should be 0 for compatibility reasons. The remaining four bytes (two bytes value and two bytes index) are left for the data transfer. These are used to transmit up to four data bytes per transfer. Four HD44780 command bytes or four HD44780 data bytes can thus be transferred during one USB transaction.
Details for the request byte
Bit 7 6 5 4 3 2 1 0 Name C C C T T R L L
The target id has different meaning for the different requests. For command and data transfers it is a two bit bitmap indicating which of the two possible controllers supported by the LCD2USB interface is addressed. Both controllers may be addressed at the same time (e.g. to setup user defined characters).
For set and get operations the target id specifies the value to set or get. Currently supported values are:
set 0 - set brightness set 1 - set contrast get 0 - get firmware version (msb = major version, lsb = minor version) get 1 - get button bitmap get 2 - get detected controllers
See the testapp source code delivered with the LCD2USB firmware archive for further details.
The LCD2USB interface was originally developed for use with lcd4linux. In the meantime LCD Smartie and LCDProc have been extended to support the LCD2USB as well. The LCD2USB software archives contain a little demo application that can be used as a basis for further LCD2USB ports. Currently Linux, MacOS X and Windows are supported by this application.
Using LCD2USB under Windows
Harald Körfgen wrote a LCD Smartie plugin for LCD2USB finally allowing the LCD2USB to be used under Windows as well. Here's what he writes about his plugin:
LCD2USB-smartie.zip contains all the necessary source files requried to compile the driver with Microsoft ® Windows Server® 2003 R2 Platform SDK, Microsoft Visual C++ 2005 Express Edition and LibUsb-Win32. LCD2USB.DLL is the resulting file.
In order to use the driver libusb-win32 has also to be installed and the LCD2USB.DLL has to be placed in the "displays" directory of LCD Smartie and it will be auto-detected and automatically be used. He has only tested his driver with a 20x4 display yet, so feedback is welcome.
Problem: The device seems to work fine, it is detected correctly by Linux, but i get various error messages when accessing it from the test application.
Problem: The device is not properly detected. Linux reports an error like "device not accepting address" in the system log but the LCD displays the init message (LCD2USB VXX.XX).
Problem: The device is not properly detected. Linux reports an an error like "device descriptor read/all, error -71" in the system log.
Inside a huge PCB factory: https://www.youtube.com/watch?v=_XCznQFV-Mw