FEZ Panda II with HD44780 controlled LCD

Second test: displaying text on a 20×4 LCD controlled by a HD44780 compatible driver chip. As you can see, it’s working

After Eric VDB pointed me to Codeshare in a comment on a previous post, I couldn’t resist searching for something that could help me get started.

And I found something useful here. Although the example that came with it was targeted for a Gadgeteer Extender Module (which I don’t have), I had no problems getting it to work. I created an additional constructor that would accept pin numbers, like this:

SerialLCDDisplay lcd = new SerialLCDDisplay(
                     FEZ_Pin.Digital.Di21, // RS
                     FEZ_Pin.Digital.Di23, // ENABLE
                     FEZ_Pin.Digital.Di25, // DB4
                     FEZ_Pin.Digital.Di27, // DB5
                     FEZ_Pin.Digital.Di29, // DB6
                     FEZ_Pin.Digital.Di31); // DB7

It took me some time to figure that out, but within the hour I had the LCD running. I added an endless loop with an increasing counter and a delay of 1 second and let the sketch program run; at the time I took the picture it had been running for more than 4 hours.

One thing I noticed was that the LCD sometimes displayed garbage when the Panda was rebooted; after that everything worked OK, but startup looked a bit ugly. Maybe give the hardware connected to the Panda some more time to settle? I don’t know yet; we’ll see about that later. Another thing I need to have a look at is the fact that this SerialLCDDisplay class was apparently written for an LCD with 2 lines; cause line 0 (first line on the LCD) and 1 (second line on the LCD) were OK, but output destined for line 2 were shown on the first line of the LCD again – probably a minor issue.

And since I’ll have to change the class code for that anyway, I’ll also add 2 additional parameters with which I can set the number of rows and columns of the LCD – cause I have both 20×4 as well as 16×2 LCDs!

Oh, and I saw these automatically generated Debug messages appearing in the Debug output window in Visual Studio on my PC:

GC: 4msec 12132 bytes used, 52248 bytes available
Type 0F (STRING              ):     96 bytes
Type 11 (CLASS               ):   1596 bytes
Type 12 (VALUETYPE           ):     60 bytes
Type 13 (SZARRAY             ):    108 bytes
Type 15 (FREEBLOCK           ):  52248 bytes
Type 17 (ASSEMBLY            ):   7560 bytes
Type 18 (WEAKCLASS           ):     48 bytes
Type 19 (REFLECTION          ):     24 bytes
Type 1B (DELEGATE_HEAD       ):     72 bytes
Type 1D (OBJECT_TO_EVENT     ):    168 bytes
Type 1E (BINARY_BLOB_HEAD    ):    156 bytes
Type 1F (THREAD              ):    384 bytes
Type 20 (SUBTHREAD           ):     48 bytes
Type 21 (STACK_FRAME         ):    828 bytes
Type 27 (FINALIZER_HEAD      ):    168 bytes
Type 31 (IO_PORT             ):    252 bytes
Type 34 (APPDOMAIN_HEAD      ):     72 bytes
Type 36 (APPDOMAIN_ASSEMBLY  ):    492 bytes

This must be some diagnostic information from the GC process kicking in. 12 KB used? Woow… that’s 20%. But what’s the baseline of used memory, e.g. what does a program with an ‘empty’ main() use in terms of memory? Sounds like a good subject for another post..