Virtual 2x16 Character LCD

Rayman

Here's something that may not be very useful, but I did anyway in support of another project...

But, if you want to develop Prop code for a 2x16 LCD but don't have one for some reason?

Anyway, I modified the attached LCD driver to also send the data out on serial port.
The Windows Program (I'll try to attach) takes the data and shows virtual LCD.
It's not 100%, but does do everything this demo does.

Program just squeezed under the 2M upload limit !

Francis Bauer

I just downloaded the files and it appears to be working fine. I do get character smearing during the text scrolling update though, so you do see two of the same characters briefly as the scrolling text is updated.
Even so, pretty cool to be able to simulate an LCD on the PC over a serial connection. Thanks for the code.

Rayman

Thanks for testing!
I could add display buffering to the code to make it look better when updating.
Right now, there's a lot of screen flicker...

Rayman

I think I've decided to write my own driver for these 2x16 character LCD displays...
Going to copy mostly from OBEX but add a couple things...

There are a few good ones in OBEX already, but I don't see one that lets you create your own characters using the CG RAM. I think they all are written for the HD44780 driver and not the ST7066U like the Newhaven display that I have. But, I think they both work exactly the same.
Looks like both are used in other modes besides 2x16, such as 4x20, 2x40, 1x12. I shouldn't take much work to adapt this code to one of these other modes...

Some of the OBEX drivers read the Busy flag but none read data from the CG or DD RAM. It's not clear how useful reading from RAM would be in practice though... Does give you storage that would survive a Prop reset but not a power cycle.

Actually, I see that my application has the R/Wn pin grounded... Saves a pin, but only writes are allowed to display. I'm thinking about whether to change that or not...

The display driver is a bit more complex that I initially though and the datasheet isn't totally clear.
But, I think I've decided these things for now (until proven wrong):

1. The cursor position is the same as AC (address counter).
2. There is a hidden (not readable) register that controls the display shift. You can incrementally shift the display, but you cannot read the amount of accumulated shift or set the shift value. All you can do is reset the shift to zero with clear or return home instructions...
3. The datasheet specifies minimum wait times for each type of instruction. So, reading the busy flag isn't required if you just wait this time.
4. 8-bit mode is nicer, but looks like a waste of pins given that the Prop can transmit 4-bit data much faster than the display can process it.

AwesomeCronk

Rayman, did you write this simulation code for Windows? If so, then I would love to know where you learned to do so!

Rayman

I thought no one would ever ask! Now, I can monologue...

I taught myself how to program in C++ years ago.
Well, really MFC, which is something like C++ made easier, but for Windows only...

I started with Visual Basic though. I think VB is much better now that when I learned it.

Edit: Actually, I started with QBasic and then VBDOS, both of which aren't used today...

These days, seems a lot of people have moved from MFC to C#.
But, if you know how to do native code, seems crazy to switch to managed code to me...