Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - hvilleneuve

Pages: [1]
1
OLEDs / Re: NHD-0420DZW-AY5 with scrambled display
« on: August 04, 2015, 04:50:55 PM »
The 300uS in the comment refers to the SETUP time, not the MAX EXECUTION TIME. These are two separate things.

The WaitReady function polls the STATUS bit to know when the LCD is ready to accept new commands.

2
OLEDs / Re: Precision about Vih in NHD-0420DZW-AY5 specifications
« on: August 04, 2015, 04:48:27 PM »
Yes,
I can read too. In fact, this is the EXACT information I talked about in my first post.

This is still confusing. Why then do you state in page 1 then that the trailing 5 of the part number indicates "+5V power"?

3
OLEDs / Re: Precision about Vih in NHD-0420DZW-AY5 specifications
« on: August 04, 2015, 07:43:27 AM »
Hi,
it is also stated that VDD can be from 3.0 to 5.3V. But since the part number is ending with a "5", and in the cover page of the datasheet it is written "+5V power supply", can we power it from +3.3V? The specifications are very confusing.

It seems to imply that there is a part number specifically for +3V devices...

4
OLEDs / Precision about Vih in NHD-0420DZW-AY5 specifications
« on: July 31, 2015, 02:12:19 PM »
Hi,
in the specifications for NHD-0420DZW-AY5, it is stated that Vih (min) = 0.9VDD.

If we are powering the LCD from VDD=+5V, it means that Vih should be higher than +4.5V, which is extremely high.

It seems to be an error. Can you confirm the minimum Vih when VDD=+5V

5
OLEDs / Re: NHD-0420DZW-AY5 with scrambled display
« on: July 31, 2015, 10:13:55 AM »


/* LCD commands */
#define CHARLCD_CMD_CLEAR   0x01
#define CHARLCD_CMD_HOME    0x02
#define CHARLCD_CMD_ENTRY   0x04
#define CHARLCD_CMD_DISPLAY 0x08
#define CHARLCD_CMD_FS      0x20  /* function set */
#define CHARLCD_CMD_ADDR_DD 0x80
#define CHARLCD_CMD_ADDR_CG 0x40

/* Bit fields */
#define CHARLCD_CMD_FS_D8  (1<<4) /* 8bit display */
#define CHARLCD_CMD_FS_2L  (1<<3) /* two lines */
#define CHARLCD_CMD_FS_5x8 (0<<2) /* 5x8 font */
#define LCD_DISPLAY_ON     (1<<2)
#define LCD_DISPLAY_OFF    (0<<2)
#define LCD_CURSOR_ON      (1<<1)
#define LCD_CURSOR_OFF     (0<<1)

#define LCD_FONT_ENG_JAP      (0x00)
#define LCD_FONT_WEST_EUROPE1 (0x01)
#define LCD_FONT_ENG_RUSSIAN  (0x02)
#define LCD_FONT_WEST_EUROPE2 (0x03)

#define CHARLCD_STAT_BUSY  0x80

/* Maximum execution time is for the CLEAR DISPLAY command. */
#define MAX_EXECUTION_TIME_MS 2

void WriteLCD(qint8 controls, qint8 data)
{
    LCD_device_->WriteI2Cint((quint16)(data * 256 + controls));
    /*
     * No need to introduce delay here: the maximum setup time between
     * any commands is 250nS, and the previous command takes around 300uS
     * to execute.
     */
}

void WriteCommand(qint8 command)
{
    WaitReady();
    WriteLCD(0x00, command); /* RS=0, R/W=0, E=0 */
    WriteLCD(ENABLE_LCD, command); /* E=1 */
    WriteLCD(0x00, command); /* E=0 */

}

void WriteData(qint8 data)
{
    WaitReady();
    WriteLCD(DATA_SELECT, data); /* RS=1, R/W=0 */
    WriteLCD(DATA_SELECT | ENABLE_LCD, data); /* RS=1, R/W=0, E=1 */
    WriteLCD(DATA_SELECT, data); /* E=0 */
}

qint8 ReadLCDStatus()
{
    uint8_t returned_value[2];

    returned_value[0] = 0;
    returned_value[1] = 0;

    WriteLCD(READ_nWRITE, LCD_DATA_BUS_INPUT); /* RS=0, R/W=1, E=0 */
    WriteLCD(ENABLE_LCD | READ_nWRITE, LCD_DATA_BUS_INPUT);
    LCD_device_->ReadI2C(returned_value, sizeof(returned_value));
    WriteLCD(READ_nWRITE, LCD_DATA_BUS_INPUT); /* RS=0, R/W=1, E=0 */

    return returned_value[1];
}

void lcd_init(void)
{
    uint8_t v;

    /* Initial state: RS=0, R/W=0, E=0, data bus is input */
    WriteLCD(0x00, LCD_DATA_BUS_INPUT);

    /*
     * Make sure to configure 8-bit interface first.
     * Send the command 3 times, to take into account the fact that the LCD
     * could be in 4 bit mode, and not in sync.
     */
    v = CHARLCD_CMD_FS |   /* Function set */
        CHARLCD_CMD_FS_D8; /* 8-bit interface */
    WriteCommand(v);
    WriteCommand(v);
    WriteCommand(v);

    v = CHARLCD_CMD_FS |     /* Function set */
        CHARLCD_CMD_FS_D8 |  /* 8-bit interface */
        CHARLCD_CMD_FS_2L |  /* 2 lines mode */
        CHARLCD_CMD_FS_5x8 | /* 5x8 font */
        LCD_FONT_WEST_EUROPE1;
    WriteCommand(v);

    /* From this point on, the BUSY flag and address counters can be read. */
    busy_flag_valid = true;

    /* Turn display OFF. */
    WriteCommand(CHARLCD_CMD_DISPLAY | LCD_DISPLAY_OFF);

    /* Clear display */
    WriteCommand(CHARLCD_CMD_CLEAR);

    /* Entry mode set */
    WriteCommand(CHARLCD_CMD_ENTRY | LCD_MODE_INCREMENT);

    /* Return home. */
    WriteCommand(CHARLCD_CMD_HOME);

    /* Turn display ON. */
    WriteCommand(CHARLCD_CMD_DISPLAY | LCD_DISPLAY_ON);
}

6
OLEDs / Re: NHD-0420DZW-AY5 with scrambled display
« on: July 31, 2015, 07:33:56 AM »
Hi,
we are using the parallel interface, 6800 mode (default).

In our case, the timing is not on the margin, far from it. For example, the specifications requires a minimum pulse width of 250nS for the enable signal, we are at 350uS.

7
OLEDs / NHD-0420DZW-AY5 with scrambled display
« on: July 30, 2015, 02:32:59 PM »
Hi,
We are using a NHD-0420DZW-AY5. The display works fine, but after a few hours/days of operation, we sometimes observe that the the display is full of strange symbols. Those symbols are not part of the listed characters in any of the ROM character tables in the datasheet. Even if we restart the software and reinitialize the LCD, we cannot recover from this condition. The only solution seems to remove and then reapply the +5V supply.



If we reinitialize the CGRAM data, it doesnt change anything either.

During our initialization sequence, we always write 10 characters and check after each of them that the auto-incremented address reported by the LCD is valid. This test passes with success during this scrambled mode. So the LCD is responding correctly to the HOST commands, but it seems that its character table is somewhat invalid.

The timing has been verified on an oscilloscope, and all signals are well within the specified ranges.

We have seen this behavior in at least three of our products, so this has not happened on a single LCD.

Any idea?

Pages: [1]