LCD1602+908JL16

[popup]

Hi,all

I need to port LCD1602 to 908JL16CPE.

For we don't have many pins on JL16CPE, I need to configure LCD1602 as 4bit dataline,2 lines display,5*7 dot character.

I followed AN2940 "LCD Driver for the HC08/HCS08 Family" but it didn't work.

It appears not well initialized or I don't know any other possibilities.

Afer power on, the first line of LCD1602 displays all black blocks. and no chars displayed.

I assume this is the result of insufficient initialization,is it right? or what?

If anyone would provide me a tested LCD1602 subroutine example for HC908mcu, that will be great thanks.

Regard,

popup

[bigmac]

Hello popup,

Initialising the display for a 4-bit interface mode can be a little tricky.  One thing I would check is that the time delay after sending each command is adequate.  If this is bus rate dependent, you might need to adjust.

In addition to AN2940, there is also AN1774 and AN1775.  The code associated with these application notes is in assembly, for devices other than the HC908, and therefore not particularly useful to you.  However, they do give a more detailed description of the steps required for the display initialisation process, including the time delays necessary.

Regards,

Mac

[popup]

Hi, mac

I agree with that, the time delay should be carefully checked.

In fact, I usually use the TIM module to generate a exact time, but never use a software delay subrutine for this. It's somewhat because of I don't know how long a delay subrutine really lasts.

I know that I should calculate the cpu cycles and the delay time=cycles/Fbus, but how can I "see" how many cycles for a delay rutine in "C"?

for instance,the following rutines were written in C for avr atmega8 uc under 8M OSC.

If I want to use such similar rutines, how can I "see" the cycles and adjust the times of loops,so after that I can rewrite it to 908mcu?

Code:

for AVR atmega8cpu clock ：8M-----------------------------------------------------------------------*/#include "delay.h"void delay_1us(void)                 //1us delay  {   asm("nop");  }void delay_nus(unsigned int n)       //N us delay  {   unsigned int i=0;   for (i=0;i<n;i++)   delay_1us();  }  void delay_1ms(void)                 //1ms delay  {   unsigned int i;   for (i=0;i<1140;i++);  }  void delay_nms(unsigned int n)       //N ms delay  {   unsigned int i=0;   for (i=0;i<n;i++)   delay_1ms();  }

 
 Regards,

popup

[peg]

Hi popup,

Quickest way is probably to run the code in the true time simulator and watch the cycle counter, then calculate the delay from there.

[popup]

Hi, peg

In most cases I use In-circuit debugging, I have not  found a register named cycles or such similiarity.

If it is only in full chip simulation, do you mean that I set a breakpoint before calling of the delay subrutine and record the CPU cycles counter as C1, and set another breakpoint right after finishing calling this delay subrutine, then record the counter as C2. So C2-C1=cycles of the delay rutine?

Regard,

popup 

[peg]

Hi popup,

In CW debugger or simulator (just a different mode of the same thing) the register window has a "CPU Cycles:" display. This does not exist on the device but is simulated in the programme. You can use the cycles x command in the command window to set it. (e.g. cycles 0 will reset it) then you either run to a breakpoint or step through all of your delay routine. Now multiply the cycles counter by the period and Whalaa!

[eckhard]

Hello,

ist no problem to delay longer than nedded in the initilisation phase. So try a long delay.
Another way is to call the ROM routine delnus, should be at $FD35, to delay a defined number ob microseconds.
After initialisation you can check the Busy Flag if you have the R/W pin connected.
Try to use Delays that are longer than needed and if it works make the delay shorter until you get errors.


Eckhard

[popup]

Hi, eckhard

Thanks a lot for help.

I noticed that this project is target to 908JK8. Does JL16 have a ROM-resident delay routine? I checked JL16 datasheet and didn't find any.

I will try to force every delay operation longer then expect period. It's a good idea!!!

Anyway, do you know how to count the cycles from the .lst file?

Regards,

popup

[bigmac]

Hello popup,

Whether you use the timer, or count cycles, to generate a delay, the actual delay will still be dependent on the bus frequency, which might differ from that assumed for the application note.

The DELNUS routine probably does exist for the JL16, but I cannot find any documentation that lists its address.

Another quite simple way of generating relatively short delays, using the timer, is to -

1. Read the high byte of the timer counter register.
2. Increase the value by the amount of the delay required - this is then used as a reference value.
3. Within a tight loop, wait for the high byte of the timer counter to exceed the reference value.
4. When the condition is met, exit the loop.

The timing resolution will be 1/256 the timer overflow period (assuming default TMOD value of $FFFF), or 256 timer clock cycles.  In this case, the maximum delay cannot exceed the timer overflow period.  Note that, for the HC908 TIM module, after reading the high byte of the counter, you will also need a dummy read of the low byte to clear a read latch.  The timer must be running, but no interrupt is required.

Regards,

Mac

[eckhard]

Hello,

when I had to delay by hand I did it this way :

void delayt() {


_asm("\
lda #30 \n\
__dhbl:deca \n\
nop \n\
bne __dhbl \n\
");
}

so you have to count only the cycles of this few assembler statements.

Eckhard

[bigmac]

Hello,

For those interested, the following code is that associated with the ROM based DELNUS sub-routine.  It is simple enough to place within your own code, if required (when you don't know the address of the ROM version).

* NAME: _DELNUS
* PURPOSE: Delay N us

* ENTRY CONDITIONS:
* X = Delay(us) / 12
* ACC = CPUbus(MHz) * 4 (= oscillator frequency)

* SIZE: 10 BYTES
* STACK USED (INCLUDING CALL): 3 bytes

* REMARKS:
* fop >= 1 MHz, minimum delay = 12 us (+5 cycles)

************************************************************

_DELNUS:  DECA          ; 1 cycle
NXTX:     PSHA          ; 2
          DECA          ; 1
          DECA          ; 1
          DBNZA  *      ; 3 Execute ACC-3 times
          PULA          ; 2
          DBNZX  NXTX   ; 3 Loop X times - X*(3*(ACC-3)+ 9)
          RTS           ; 4
          ; Total delay = X*(3*ACC-9+9)+ 5 + Call
          ;             = 3*X*ACC + 5 + Call

The interesting point about the routine is its ability to allow for different bus rates by simply setting the value in ACC - and this consumes a total of only 10 bytes.  The maximum possible delay is a little over 3 ms.

Regards,
Mac

Message Edited by bigmac on 2007-05-12 01:08 PM

[popup]

Hi, bigmac

I use the tim module to generate exact delay for most applications.

I will try to use the method you suggest.

But how did you know there is such ROM-residents routines outside of the datasheet? Maybe I need a list of that so I can use that in further design.

Regard,

popup

[peg]

Hi popup,

The ROM resident routines are described in AN1831. They exist for flash programming but of course can be used for anything you like.

[popup]

Hi, all

Thanks a lot for all of you! With your help, I have successfully initialised and displayed chars on the LCD1602.

Again, many thanks to you all.

Regards,

popup

[bigmac]

Hello popup,

Perhaps you could tell us how the original problem was caused, and what you needed to do to fix it.

Regards,

Mac

[eckhard]

Hello,

maybe this could helt you a little bit.

http://www.eckhard-gosch.de/download/ZwobLCD.zip

Eckhard

[peg]

Hi again popup,

I am looking at a returned product right now with exactly this symptom.

All the dots on in the top row is what you get if you simply power up one of these modules and don't talk to it. So you are correct in assuming that you are not initialising it correctly.

I obviously have some working code here but for 8-bit access and in assembler, you probably want C?