Well...Saturday morning...8:00 a.m. phone rings...it is Corey "let's hook up one of our pluto boards to the LCD module 2 lines x 16 characters, with backlight that we bought from the fpga4fun online shop." (i had actually answered the tv-remote first-try since it was so early on a weekend day). he arrived shortly thereafter...
fired up quartus, assign led, clk, RxD and TxD to their appropriate pins (7, 91, 77, 78) so they wouldn't get picked by the Fitter, put in Jean's example code and hit compile. Excellent! compiles fine...let's see where it put the outputs. Only a few wound up on pins that were brought out on the pluto board so we decided that since the design wasn't too space consuming we'd assign the pins by hand. we picked:
LCD_RS on pin 6
LCD_E on pin 15
LCD_RW on pin 21
LCD_DataBus[7] on pin 45
LCD_DataBus[6] on pin 55
LCD_DataBus[5] on pin 56
LCD_DataBus[4] on pin 61
LCD_DataBus[3] on pin 65
LCD_DataBus[2] on pin 69
LCD_DataBus[1] on pin 70
LCD_DataBus[0] on pin 71
compiled fine...the fitter had no problem using the pins we had selected.
now we needed to decide how we were going to hook up the wires to the pluto board. we decided that we would use two double row female header for the two double rows on the board and male headers for the two single rows in between them. we soldered them on long pin down so the two single rows could be plugged directly into a protoboard and with a bit of tape under the chip the double row header tails would not go in. now we had access to all the pluto pins. the two single row pins via the protoboard. (one hole still was usable on each side) and by sticking wires directly into the female headers we had soldered on the board on the double rows.
a double row female header on the lcd display and we were ready to hook it up! well...almost... what are the pinouts?? well, the lcd says that it is a 162C1YMY or something like that...google quickly told us that we were going to be out of luck finding the datasheet. well after a bit of searching we came up with a data sheet for a 162C0 which sounded close enough to use. so we got that and another appnote from Emerging Display Technologies Corporation that gave some programming specifics.
using that datasheet we managed to find the pinout of the lcd to be:
Vss (GND) on pin 1
Vdd (+5V) on pin 2
Vo (LCD Contrast) on pin 3
RS on pin 4
R/Wbar on pin 5
E on pin 6
[DB0:7] on pins 7 - 14
it also said that we could control the backlight via pins 15 and 16 which were on the other end of the board and didn't seem to do anything. The board seems backlit all the time.
The appnote gave us a wiring plan for the LCD contrast on pin 3 and using the variable resistor that we bought from the shop we got that working with no problem.
now for some time, i had been wondering about how serial com was going to work with the pluto. i had noticed that when i ran the config program the board configures fine until i closed the program...and that it didn't seem to configure the device at all if i let the program close the com port.
this would be a problem (sorta chicken and egg) 'cause i knew we wouldn't be able to open the com port if the configuration program had it open and stopping the configuration program seemed to unconfigure the pluto.
well...it seems that either my computer (an hp laptop) or the operating system (windows XP home) causes its TxD pin (RxD to the Pluto) to go high when it is not in use and that is exactly how you unconfigure the pluto...make that pin high and hold it for a few milliseconds.
we came to the conclusion that we'd have to use a second com port... didn't like that idea. we'd have to do the level shift thing and anyway, that pc doesn't have a second com port.
sent off an e-mail to jean and he replied (wow! he replied!! and fast!)
he said that he'd seen this before and did we have another pc and/or operating system. (and he also mentioned that using a second com port would be an option)
i happen to have a windows 98 machine and so we put the rbf file on it and tried the configure...worked fine AND it didn't put the TxD line high when it was not in use! (our digital scope really helps with stuff like this)
now all we needed to do was compile the 'C' code that jean had written and we'd be done! compiled fine...we configured the pluto...hit run on the 'C' program....didn't work!
somewhere i remembered jean saying something about rs232 being inverted. so i looked around and saw an example where he said that you might need to invert RxD (on the pluto).
so we changed one line in the quartus file.
async_receiver deserialer(.clk(clk), .RxD(RxD), .RxD_data_ready(RxD_data_ready), .RxD_data(RxD_data));
became:
async_receiver deserialer(.clk(clk), .RxD(~RxD), .RxD_data_ready(RxD_data_ready), .RxD_data(RxD_data));
compile, configure, run....
