Author Topic: LCD Display  (Read 18374 times)

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
LCD Display
« on: January 07, 2008, 04:50:59 PM »
Hi ,
 We're trying to run a HDM20416H LCD display, which is 4 lines*20 chars. I #defined
SUPPORT_LCD and the LCD works in the Simulator. When I run it in the real board
I get part of the "Hi uTasker !"  msg displayed. It looks like the timing may be off or we're writing to the wrong display memory for this chip. I tried adding redundant writes in
CLOCK_EN_HIGH and LCD_DRIVE_DATA to stretch out the timing but it still didn't work.
The registers and bit masks for this LCD look the same as the one uTasker is setup to use.

 I want to debug this using CW 6.3 light, but it doesn't break on any code in LCD.C.
I notice that when you have the source code displayed in the right hand pane, in the
left hand column of the source code there are dash lines where you would click on to set a break point. After setting the break point a red ball would appear. Some source file have dashed lines where the red ball is displayed and you can set breakpoints in these files, unfortunatley they do not show up in LCD.C. Anyone have any idea why this happens ?

 Thanks,
 John
 

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: LCD Display
« Reply #1 on: January 07, 2008, 05:53:27 PM »
Hi John

Did you also consult the following?
http://www.utasker.com/forum/index.php?topic=93.0

Are you operating your display in 4 or 8 bit mode. In 4 bit mode the timing between the two 4 bit read/writes can be critical (as detailed in the link).

I wonder whether the additional writes you have added are being compiled in or perhaps optimised away by CW (if it does turn out to be a speed issue). Try reducing the CW optimisation level to see whether there is a difference and whether it then allows break points to be set in LCD.c. I think that you will find that the hardware accesses in this module cause CW to generate code which doesn't easily match up to the C.code so setting break points can be very tricky. It may be best to try setting a break point in the task body and then viewing in 'interleaved' or 'assembly' display mode to get a feeling for the code. If you can then identify the assembler code belonging to the C code you are interested in, setting break points in assember should always work. Without optimisation there are generally no such problems but CW debugging with highest optimisation is a bit of a challenge...

Regards

Mark

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: LCD Display
« Reply #2 on: January 07, 2008, 06:12:11 PM »
Mark, we have read the post for the LCD display. It pretty much describes what we have to do. We are using 4 bit mode. I have found that in order to be able to break on a line in a C source file you must ensure that the debug dot is displayed in the left hand Project pane for that file. This column is checked for most C files. Clicking on the column toggles the flag. I have disabled optimization so I can step through the code.

 I'll let you know my results ...

 Thanks,
 John

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: LCD Display
« Reply #3 on: January 07, 2008, 08:28:17 PM »
Hi John

I just checked the LCD code in the M5223X SP5 and have seen that there are some improvements (tested in another project) which are not available in that code.

I will send you the version and hope that you can then confirm that it solves any problems you may still have - it use used in 4-bit mode. The M5223X SP6 should be ready shortly so that it is generally included.

Regards

Mark

Changes in my developmemnt version which are not in the SP5:

   09.10.2007 Add configurable delay to ensure two back to back writes are not too fast in 4 bit mode {1}
   10.10.2007 Correct nibble adjustment in 4-bit read                    {2}
   12.10.2007 T_INIT_WAIT modified to 5ms rather than 1 tick Ticks of greater will default to 1 tick) {3}


Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: LCD Display
« Reply #4 on: January 08, 2008, 08:49:11 PM »
Mark, I got the SP5 code to work by delaying 35us
at the end of _fnWriteDisplay(), which writes out each 4 bit nibble . I am able to write to all 4 lines of the 20416H LCD. I also started the LCD task with a 50ms delay to ensure power up initialization of the LCD, which the spec says is 10ms. Not sure if this was needed though.

 Thanks for the help ....
 John

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: LCD Display
« Reply #5 on: January 08, 2008, 09:21:04 PM »
Hi John

That is good news.

Adding the start delay to the LCD task is a good idea - in fact I thought it already had one but it didn't (I have added 10ms to my reference project). [Note that if the TICK rate is higher (such as 50ms) it will round up - never down so this is safe].

You should find that the display and LCD simulator do behave exactly the  same - the simulator doesn't check timing issues so your solution was correct - you should find that the next SP will also have the correct delay (I believe it is only the the first write which needs it since it is the specificiation between the first and second nibble write which is critical).

Regards

Mark

PS I now have a graphic LCD simulator simulator in operation (64 x 128 for example with a user definable font set and the ability to position small bit maps and scroll etc.). There is a little more work to do - I am testing it on an STR91XF but it is not processor specific - and then I will try to integrate it into the project. A small graphic display is handy since it allows also proportional fonts (other than things like Courier with fixed widths and spacings plus different font sizes plus of course a bit of graphical stuff).

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: LCD Display
« Reply #6 on: January 09, 2008, 08:24:23 PM »
Mark, I changed the LCD task start delay to 10ms and
now place the 40us delay in fnWriteDisplay() before writting the
first nibble and it works. When compiling with full optimization
I had to add the pragma in the delay function. I found you do
a simalar hard delay loop in other code and borrowed
the timming parameter, 556 iterations=1us

 The code also works with a NHD-0420DZ LCD with backlight

 Thanks,
 John


void DelayUS(int aUS) {
#pragma global_optimizer off

int   ulDelay;

   for (ulDelay=556*aUS; ulDelay >0; ulDelay--);
}
« Last Edit: January 09, 2008, 09:10:34 PM by johnr »

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: LCD Display
« Reply #7 on: January 15, 2008, 02:02:09 AM »
Hi John

I just realised that the LCD task in the demo project is started by the application task. The application task is delayed by 100ms so the LCD task in fact doesn't need any delay of its own.

Regards

Mark

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: LCD Display
« Reply #8 on: January 15, 2008, 06:00:28 PM »
Mark, I noticed when I have LCD support that LED1 doesn't blink anymore
because the WDOG doesn't run. When I disable LCD support the WDOG runs

 John

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: LCD Display
« Reply #9 on: January 15, 2008, 07:56:25 PM »
John

That doesn't sound right at all. I have several projects with LCD and I have never seen this effect.
Is the system TICK otherwise operating or is it just the watchdog task which is effected?

Regards

Mark

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: LCD Display
« Reply #10 on: January 15, 2008, 11:05:19 PM »
Mark, with the LCD enabled ,the fnLCD() never breaks in the debugger ,which call fnRetriggerWdog(). LED3 does blink though. What can I break on to determine the timer is
working ?

 Thanks,
 John

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: LCD Display
« Reply #11 on: January 15, 2008, 11:59:38 PM »
John

If you have the RTC demo active it will blink LED3 at 1s interval (after about 1 minute). This is an RTC interrupt so doesn't mean that the scheduler is actually operating. If the LCD display is otherwise operating I expect that the scheduler and TICK is in fact OK but maybe the watchdog task has been corrupted (or its timer).

The TICK source is static __interrupt__ void _RealTimeInterrupt(void) in M5223x.c.

If you don't disable the watchdog you should get a reset after 2s if the watchdog timer is really no longer working. Can it be that you have moved ports around and disabled teh LED output in the process?

Regards

Mark

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: LCD Display
« Reply #12 on: January 16, 2008, 04:14:00 PM »
Mark,
 When I  changed

#ifdef SUPPORT_LCD
 { "LCD",       fnLCD,          MEDIUM_QUE,  (DELAY_LIMIT)(NO_DELAY_RESERVE_MONO), 0, UTASKER_STOP},  //
#endif

to

#ifdef SUPPORT_LCD
 { "LCD",       fnLCD,          MEDIUM_QUE,  (DELAY_LIMIT)(.01 * SEC), 0, UTASKER_STOP},  //
#endif

 the WDOG task stopped running. Changing it back to no startup delay
fixed the problem. I didn't notice any other problems, but I was only doing some web and serial port testing.

 Thanks,
 John

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3234
    • View Profile
    • uTasker
Re: LCD Display
« Reply #13 on: January 16, 2008, 04:19:29 PM »
John

Since the LCD is started from the delayed application task you can leave it like this.

I will look into the potential problem and get back when I know more.

Regards

Mark

Offline johnr

  • Jr. Member
  • **
  • Posts: 91
    • View Profile
Re: LCD Display
« Reply #14 on: January 17, 2008, 05:56:42 PM »
Mark, after applying the SP5 fix to uTasker.c, I noticed when I set

#ifdef SUPPORT_LCD
 { "LCD",       fnLCD,          MEDIUM_QUE,  (DELAY_LIMIT)(.01 * SEC), 0, UTASKER_STOP},  //
#endif

that the LCD and APPLICATION tasks only run once. The WDOG runs
continuously. After removing the startup delay to LCD everything runs OK

Thanks,
John