AVR32 NGW100 Driving an STN LCD Module

I’ve had a few controllerless QVGA (320×240) mono LCD modules lying around for a while looking for some use.  These are fairly easy to get going with a low-end microcontroller using an external controller IC like the SED1335, but that’s another story.  I’d been thinking about doing some sort of integrated home automation project, and since this would need a user interface and I happened to have an NGW100 going spare, getting one of these displays to run on the AP7000’s integrated LCD controller seemed like a nice idea.

The NGW100 only has a 16-bit interface to its already relatively slow DRAM, so driving a high-res colour LCD from it leads to a fairly obvious slowdown.  For this application a mono display would be adequate, and easier to drive, requiring only a 4-bit data bus, the 3 clocks and a GPIO to power up the drivers.  The LCDC has no problem driving an STN panel, although I had to deviate from the datasheet in one area to get it to work – more on that later.

The particular panel (a Samsung UG32F05) requires a 5 V logic supply, but also calls for around -20 V for the LCD drive.  In the prototype this was generated using a nasty buck-boost converter thrown together from a 555 timer and a MOSFET, but this is not recommended (use a real switch-mode controller)!  The 5 V was derived with a linear regulator connected to the NGW100’s 2-pin power header, and the signal lines from the LCDC were connected up directly (D0-D3 straight through, PCLK to XSCL/CL2, HSYNC to LP/CL1 and VSYNC to DIN/FLM).  Because powering an STN display without the proper clocks applied can cause damage the module provides a /DISPOFF connection, which was driven from a spare GPIO on the NGW100.  Normally this would be connected to the LCDC’s PWR output, but this is shared with the SD card detect input on the NGW, and the application would be using this.  The pinout of the module goes like this:

To get the display working from Linux (I started from a vanilla 2.6.28.1 kernel) I created a copy of the evklcd10x.c board support module, added it to Kconfig and modified it to suit the parameters of the new LCD.  The fb_videomode structure was set up as follows:

• refresh = 75
• xres = 320, yres = 240
• pixclock = KHZ2PICOS(1500)
• left_margin = 1, right_margin = 1
• upper_margin = 0, lower_margin = 0
• hsync_len = 2, vsync_len = 1
• sync = FB_SYNC_HOR_HIGH_ACT | FB_SYNC_VERT_HIGH_ACT
• vmode = FB_VMODE_NONINTERLACED

This gives a refresh rate of around 75 Hz, although this is mis-reported by fbset.  The settings in the fb_monspecs structure are not that critical (it seems).  I set the frequency ranges based on the quoted timing data for the display.  More important is the atmel_lcdfb_info data, which was set up like this:

• default_bpp =1
• default_dmacon = ATMEL_LCDC_DMAEN | ATMEL_LCDC_DMA2DEN
• default_lcdcon2 = ATMEL_LCDC_DISTYPE_STNMONO | ATMEL_LCDC_SCANMOD_SINGLE | ATMEL_LCDC_IFWIDTH_4 | ATMEL_LCDC_INVVD_INVERTED
• guard_time = 2
• default_monspecs = fb_monspecs_structure
• atmel_lcdfb_power_control = lcd_power_control_function

The power control callback function is called by the driver after the controller has been set up and the timing signals are valid.  This is used to control the GPIO pin connected to the /DISPOFF input of the panel.  It is trivial, and along with an updated initialisation function it looks like this:

#define LCD_nDISPOFF    GPIO_PIN_PE(7)

static void lcd_power_control_function(int on)
{
printk(KERN_INFO “Turning LCD power %s\n”,on ? “on”:”off”);
gpio_set_value(LCD_nDISPOFF,on);
}

static int __init lcd_board_init(void)
{
at32_add_device_lcdc(0, &lcd_board_lcdc_data,
fbmem_start, fbmem_size,
/* IO port mask */
ATMEL_LCDC(PE, DATA0)  | ATMEL_LCDC(PE, DATA1)  |
ATMEL_LCDC(PE, DATA2)  | ATMEL_LCDC(PE, DATA3)    |
ATMEL_LCDC(PE, MODE) |
ATMEL_LCDC_CONTROL);
at32_select_gpio(LCD_nDISPOFF,AT32_GPIOF_OUTPUT); /* LCD /DISPOFF */
return 0;
}

That should be it.  However, it turned out that the AP7000 was generating 1/4 the number of clocks per line that it should have been even considering the 4-bit interface (20 clocks instead of 80).  Although I established this fact prior to connecting the module, visually this results in a display of vertical stripes.  In the datasheet it states that for STN mono mode, HOZVAL (found in the LCDFRMCFG register) is equal to (number of horizontal pixels / interface width) – 1.  The Linux driver calculates HOZVAL based on the display type, but does it by the book and chooses a value of 79 (320/4-1).  It was found that going against the datasheet and setting HOZVAL=319 solved the problem.  This was implemented by patching atmel_lcdfb.c so that hozval_linesz = info->var.xres (around line 577).  Please feel free to point out where I have screwed up here, or if this is indeed a mistake in the databook!

Once the board boots you can use fbset -depth 4 to switch to 16 shade greyscale mode.  The photo above shows the Qt text editor demo running in this mode.  Certain shades of grey exhibit a slight flicker, but for an STN display the image is pretty reasonable.