0
\$\begingroup\$

I'm using the PIC 18F4550 to write to an LCD 16x4. I used MikroC Pro for PIC to write the code and the Proteus to simulate. I'm using the library Lcd and Lcd_Constants already present on the MikroC Pro for PIC. I'm just modifying a pre existed code that was originally designed for a 20x4 LCD, but I didn't find any declaration about the type of the LCD (16x4 or 20x4 ) in the code. As a example I tried to wrote the following messages:

  Lcd_Chr(1,1,'F');
  Lcd_Chr_Cp ('I');
  Lcd_Chr_Cp ('R');
  Lcd_Chr_Cp ('S');
  Lcd_Chr_Cp ('T');
  Lcd_Chr_Cp (' ');
  Lcd_Chr_Cp ('L');
  Lcd_Chr_Cp ('I');
  Lcd_Chr_Cp ('N');
  Lcd_Chr_Cp ('E');

  Lcd_Chr(2,2,'S');
  Lcd_Chr_Cp ('E');
  Lcd_Chr_Cp ('C');
  Lcd_Chr_Cp ('O');
  Lcd_Chr_Cp ('N');
  Lcd_Chr_Cp ('D');
  Lcd_Chr_Cp (' ');
  Lcd_Chr_Cp ('L');
  Lcd_Chr_Cp ('I');
  Lcd_Chr_Cp ('N');
  Lcd_Chr_Cp ('E');


  Lcd_Chr(3,2,'T');
  Lcd_Chr_Cp ('H');
  Lcd_Chr_Cp ('I');
  Lcd_Chr_Cp ('R');
  Lcd_Chr_Cp ('D');
  Lcd_Chr_Cp (' ');
  Lcd_Chr_Cp ('L');
  Lcd_Chr_Cp ('I);
  Lcd_Chr_Cp ('N');
  Lcd_Chr_Cp ('E');

  Lcd_Chr(4,2,'F');
  Lcd_Chr_Cp ('O');
  Lcd_Chr_Cp ('U');
  Lcd_Chr_Cp ('R');
  Lcd_Chr_Cp ('T');
  Lcd_Chr_Cp ('H');
  Lcd_Chr_Cp (' ');
  Lcd_Chr_Cp ('L');
  Lcd_Chr_Cp ('I');
  Lcd_Chr_Cp ('N');
  Lcd_Chr_Cp ('E');

But, in the simulation, appeared the third and fourth lines shifted by 6 columns positions. So, does someone know why it is happening ? Below is a print of a part of the schematics and simulation:

enter image description here

[EDITED]

I programmed a device here and the same happened. I think that, probably, the problem is on the library.

I did the following modification of th code above:

  Lcd_Out(1, 1, "First Line");
  Lcd_Out(2, 2, "second Line");
  Lcd_Out(3, -2, "Third Line");
  Lcd_Out(4, -2, "Fourth Line");

It worked. Is not a elegant way, but worked. I needed to shift the column number negatively.

\$\endgroup\$
  • 1
    \$\begingroup\$ Either your Led_Chr() function is not setting the cursor position correctly, or your simulation is not simulating the behaviour of the display correctly. That's about all that can be determined from what you've given us. \$\endgroup\$ – Finbarr Apr 25 at 12:34
  • \$\begingroup\$ Yes, strangely when I restarted everything, it worked correctly, without me changing anything at all. \$\endgroup\$ – Daniel Apr 25 at 12:43
  • 1
    \$\begingroup\$ Are you correctly initialising the display in your code? \$\endgroup\$ – Finbarr Apr 25 at 12:44
  • \$\begingroup\$ Yes, it makes a initialization \$\endgroup\$ – Daniel Apr 25 at 12:47
  • 2
    \$\begingroup\$ Restart it a few more times and see if it keeps working? \$\endgroup\$ – Finbarr Apr 25 at 12:48
6
\$\begingroup\$

Not having the source of those libraries I can't tell you how to fix it, but I can help you understand the problem so you may be able to sort it out yourself.

Here's a memory map for a typical 16x4 LCD display (Displaytech 164A series):

enter image description here ...and here's the map for a typical 20x4 (Displaytech 204A series):

enter image description here

As you can see, the third and fourth lines both start 4 locations further up in the display memory. Using code designed for this 20 column display to drive the 16 column display will work fine for the first two lines but place the third and fourth lines four spaces to the right - similar to the problem you're seeing, but the particular displays you use probably have slightly different display memory maps.

The cursor position you specify as row and column is converted by the driver code into the memory address that is passed to the display (i.e. it's not done by the display itself) so the library has to know how to carry out the mapping. It'll either be done by configuration settings somewhere or hardcoded into the driver routines themselves.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.