hitachi sp14q006-t, 4bit lcd without graph controller, good for vhdl - Page 1
Forum section: electronics / general

author: legacy
author_rank: Super Contributor
timestamp: July 06, 2016, 03:38:27 pm
content: yeah, hitachi sp14q006-t looks good for VHDL, ain't it?anyone has already developed a driver?anyone interested?and ...hereit is the datasheetyou just need a Vee of -20V5V is fine for the backlight LEDwhile signals of 3.3V are perfect for fpgaI guess this LCD is also fine for MC68EZ328 (including ADS-v2 boards)

author: Buriedcode
author_rank: Super Contributor
timestamp: July 06, 2016, 04:54:22 pm
content: Currently working on a 'generic' LCD controller for all the graphic displays I have without onboard SED1335's. But I'm doing it in verilogUsing SRAM for the frame buffer, but for development, using SDRAM with a controller that pretty much gives it a basic SRAM interface. They are quite forgiving in their drive requirements, but I'm adding extra configuration because I have some larger displays (640x480, 800x600) as well as colour-stn.I'll share what I have once I've tested it completely, but this could be a long way off. My hope is to have a fairly generic design, able to be put into FPGA's, or larger CPLD's, with SRAM connected - and very basic config comaands like the SED1335, along with scrolling, double buffering, and perhaps 'window mode' allowing one to partition the display into separate windows that can be moved around. It seems such graphic displays have been (righty) superseded by TFT's, so whilst I'm sure there are many verilog/VHDL examples of driving such displays - I really haven't found many on the web. I'm sure such glass will be seen as 'retro' fairly soon, so it'll make a comebackIf you already have a fairly fast MCU, I had some success with using an SPI port and a DMA, although it still required external memory

author: legacy
author_rank: Super Contributor
timestamp: July 06, 2016, 05:51:07 pm
content: which LCD do you have? I suppose you have Vee= -40V, and ... LVDS?

author: legacy
author_rank: Super Contributor
timestamp: July 06, 2016, 05:53:45 pm
content: oh, about extra features, GameDuino2 happens to have a very powerful GPU attached to the LCD and interface

author: bktemp
author_rank: Super Contributor
timestamp: July 06, 2016, 06:06:14 pm
content: 320x240=76800bits. It should fit into internal blockram, even for small FPGAs.If you don't need full screen bitmap images, you can even generate the image data while outputting the frame:http://www.fpga4fun.com/GraphicLCDpanel.htmlDriving passive LCDs is a bit different from driving TFT LCDs because there are 4 pixels per clock and all other timings signals are not synchronous to the pixel clock.Driving those displays is easy: You need to generate the timing and collect 4 pixels and output them in parallel. If you want grayscales you can apply dithering or FRC modulation to the grayscale data before generating the 1bit/pixel output.

author: Buriedcode
author_rank: Super Contributor
timestamp: July 06, 2016, 06:38:44 pm
content: yup pretty much, although I'm not adding graphics acceleration or anything like that - seems a bit silly for STN displays that have slow response times (handy for FRM though). You say that's easy for blockram, but then you're tied to using an FPGA large enough for two screens worth for double buffering = 320x240 x 2 = 150kbits. And that goes up if you want say, 4bbp. Whilst I'm using an old FPGA (cyclone II) having the memory external free's up resources for FIFO's pipelining reads and writes to the RAM interface, it also means the virtual screen can be much larger, say 1024x512 making scrolling menus easy. My goal was to keep it relatively small, and blind to any vendor specific things.I am not providing anything like a graphics accelerator, or even character ROM - right now its just refreshing the display, providing a basic 8/16/32-bit parallel interface to something with intelligence -, 8/16/32 bit micro's so the display just looks like a block of memory. The reason I haven't just hacked something together is because of variations in the interfaces that *some* displays have - like the planar EL display which conform losely to the spec, but have their own issues. That requires more options, like front/back porch, programmable framerate etc..Also, I wouldn't hold your breath, I'm not doing anything 'new' or high-tech - I'm just after driving up to 20 panels from one FPGA/CPU.I haven't used LVDS at all - cheaper and easier to purchase boards for that. And the highest (or is it lowest?) VEE I'll use is -28V for the dual scan 640x480's. Driving TFT's is much easier, just faster. Things start to get hairy when you have to deal with colour tables for CSTN, using FRM where each byte written to the display is RGBRGBRG etc..Apologies if it seems like I'm hijacking the thread! Its still all STN graphic displays with FPGA's

author: legacy
author_rank: Super Contributor
timestamp: July 06, 2016, 07:17:34 pm
content: Quote from: Buriedcode on July 06, 2016, 06:38:44 pmhow do you generate it?p.s.LVDS, for laptop LCDs, for sure, I was thinking you were using them *directly*everything with {1024x768 pixels and a thousand colors}@70Hzgenerates signals in term of 400-600Mhztherefore LVDS is a must (I know, I am reusing my PowerBook-G3's LCD)Quote from: Buriedcode on July 06, 2016, 06:38:44 pmnahh, no problem, dudeI have quoted gameduino2 because it can be interesting or useful if you need extra features(e.g. autonomous windows, sprites, etc)

author: legacy
author_rank: Super Contributor
timestamp: July 06, 2016, 07:25:22 pm
content: Quote from: bktemp on July 06, 2016, 06:06:14 pmumm, it's a bit confusing, ain't it? from the Hitachi datasheet, it seems 1bit of color LCD

author: bktemp
author_rank: Super Contributor
timestamp: July 06, 2016, 08:07:48 pm
content: Driving a passive LCD is quite easy if you know how a LCD works. Look at the numbers in each data bit: The first clock cycle transfers pixels 1-4, the next cycle 5-8. So you need 80 clocks to shift out 320 pixels.Depending on how you design the framebuffer (1bpp or more grayscales) I typically clock everything using a pixel clock. After 4 clock cycles a 4bit word is shifted out to the LCD.A passive LCD uses two shift registers: The column driver uses CL2 as a shift clock and CL1 as a latch clock. Each clock samples 4 bits in parallel.The row driver is a 1bit shift register with CL1 as the shift clock and FLM as the data input (there is no latch clock). To start a frame scan a sind 1 is shifted into the row driver. Since the row shift clock is connected to the column latch clock the column data is automatically synchronized with row driving.If FLM is set to high more than once per frame, multiple rows are active at the same time. You typically don't do that, but it is interessting to know and helps understanding how driving a LCD works.

author: bktemp
author_rank: Super Contributor
timestamp: July 06, 2016, 08:33:01 pm
content: Quote from: Buriedcode on July 06, 2016, 06:38:44 pmIf you need only a LCD driver without special features, I wouldn't use a FPGA, because there are so many cheap microcontrollers with buildin LCD controllers. My preferred solution for small passive LCDs and TFTs up to 480x320 is PIC24FJ128DA206: TQFP64, 96kBytes SRAM, a fast GPU (up to 96Mpixels/s drawing rate), up to 16 grayscales or up to 65536 colours and enough flash for drawing nice menus and other stuff.Larger dual scan LCDs (640x480) are a completely different story. Because they are obsolete no modern controller can drive them, so a FPGA/CPLD is the only solution (except for some ancient LCD controllers like S1D13506).One advantage of using a FPGA is, you don't need a full framebuffer unless you want to use it as a generic LCD controller because you can implement a character ROM and draw all characters while outputting the display data. You can even render lines and other primitives from coordinate data without a framebuffer.

author: Buriedcode
author_rank: Super Contributor
timestamp: July 06, 2016, 09:04:32 pm
content: Quote from: legacy on July 06, 2016, 07:25:22 pmColour STN which are passive - TFTs are active - generally you have one bit per subpixel. So, each pixel is 3-bits, but because the display has an 8-bit interface you have to send 320*3/8 = 120 writes per line.They are arranged as:R1-G1-B1-R2-G2-B2-R3-G3, B3-R4-G4-B4-R5-G5-B5-R6, G6-B6-R7-G7-B7-R8-G8-B8 So thats 3 bytes for 8 pixels.This is why there is a pipeline, because the memory either contains one byte per pixel, for 256 colours, or a nibble per pixel for 16 colours. So 4 or 8 bytes must be read to write 3 bytes to th display. For each frame each subpixel is either on or off - unlike active/TFT that can set the value for each pixels as it scans, so to generate colours you have to use FRM. This pretty much uses PWM for each subpixel. So say for 8bbp, in the format 2 red, 3 green, 3 blue - the red has 4 levels (including off) and the green/blue has 8. Over 8 frames the controller checks if each pixel should be on or off, depending on its value, and the current frame count.TFT's are just so much easier, the difference being you can write up to 24-bits per pixel, and with higher resolutions the bandwidth can be very high. They also have much better contrast, response time, and just look better. I can't say I like CSTN displays but I'm adding the facility to drive one so that the one display I do have is just so I learn more about FPGAs

author: legacy
author_rank: Super Contributor
timestamp: July 13, 2016, 03:34:35 pm
content: Quote from: bktemp on July 06, 2016, 08:07:48 pmis there a document, with signal-sequence and time diagram, which teaches about FLM when it needs to be set high more than once per frame?

author: bktemp
author_rank: Super Contributor
timestamp: July 13, 2016, 07:56:54 pm
content: I haven't seen any good appnotes about driving LCDs. Maybe because they are obsolete now.You can learn much about how driving LCD displays works by reading datasheets of the ics used. Here are some typical row (common) and column (segment) driver ics:ftp://ftp.epson.it/pub/electronics-de/assp/sed1700/sed1752.pdfftp://ftp.epson.it/pub/electronics-de/assp/sed1700/sed1753.pdfThe segment driver uses 8bit data instead of 4bit, but otherwise it could be one of the drivers used in many 320x240 4bit LCDs.There is no magic involved, they are simple shift registers + level shifters/output multiplexers.If you have a working code driving your LCD, you can start changing timing parameters to see how the LCDs reacts.

author: legacy
author_rank: Super Contributor
timestamp: July 13, 2016, 10:30:31 pm
content: Quote from: bktemp on July 13, 2016, 07:56:54 pmI am designing the interface circuit in vhdl, I have a few doubts about the timing

author: Buriedcode
author_rank: Super Contributor
timestamp: July 13, 2016, 11:59:30 pm
content: What doubts do you have? Generally there's three timing signals, CL2 which is the write clock, for your display that writes 4 bits to your display, at 320x240 resolution thats 320/4 = 80 writes, usually you set up data on the rising edge, and the display clocks it in on the falling edge. CL1 is the hsync, a signal pulse when the horizontal counter is at maximum, so the last write, the pixels clock has a falling edge when this is high. Lastly, FLM or Vsync, this should be high for the first line being written - it tells the display that the line you've just clocked in should be line 1.So for the timing, you just need two counters, X and Y. The hard part is grabbing data from a frame memory, possibly into a buffer so it reads a whole line into the buffer during the current line - meaning the memory is free to be written to most of the time. I'm currently trying to make a very basic 'hard wired' (no config registers) DMA to grab bytes from SDRAM to a FIFO.As suggested datasheets for LCD controllers are helpful, especially the sed1335.

author: Buriedcode
author_rank: Super Contributor
timestamp: July 14, 2016, 12:05:50 am
content: Quote from: legacy on July 06, 2016, 07:17:34 pmI had a bunch of small 'modules PCB's' I made many years ago when I started collecting/hoarding LCD's. Main one I use is just a max749, SMT, on a single sided DIY PCB - its shoddy. Only ever needed -23V for VEE, but theres a 480x320 that needs +28V. As these driver voltages generally only need a few mA you could use charge pumps/voltage multiplers, or a small boost converter with a coupled inductor - or voltage multiplier, I believe linear tech has some app notes on generating negative voltage for LCD displays. I also found a small 3 transistor negative voltage generator that I designed myself - although probably based off some app note - that was crap in efficiency, but used just discrete parts and generated up to -30V from 5V. Might have to reverse engineer that as it was small SMT about 10mmx15mm.

author: legacy
author_rank: Super Contributor
timestamp: July 16, 2016, 01:03:06 pm
content: in this HDL simulation the LCD is 32x8Code:--=======================================-- STN interface--=======================================--+-----+-----------------------------------| flm | first line marker--+-----+-----------------------------------| lp | line pulse signal--| | for latching the segment buffer--| | to the segment driver--+-----+-----------------------------------| cp | clock pulse signal--| | for shifting the data (D0~D3)--| | into the segment buffer--+-----+-----------------------------------| off | display on/off--+---------------------------------------

author: legacy
author_rank: Super Contributor
timestamp: July 16, 2016, 01:08:06 pm
content: Quote from: Buriedcode on July 13, 2016, 11:59:30 pmtime relation between signals, setup and hold timenote in my simulation theflmis delayed by 3 slots(I have developed the LCD with parameters, I can change it)

author: Buriedcode
author_rank: Super Contributor
timestamp: July 16, 2016, 01:27:33 pm
content: Quote from: legacy on July 16, 2016, 01:08:06 pmI too was a little confused, so I've added an extra clock delay at the end of each line, so it writes 80 times, then theres an 81st clock - but that isn't sent to the LCD, instead it sets up the hsync just before. I did this based on the EL.640.480 AF1 I have, which is a little different from LCD's as its a plasma display which uses an old FPGA for the timings. The picture below is an example with parameters set to '32 x 4'. Its actually 32 x 8 but since this version is for dual scan displays, it outputs 8 bits per write, a nibble for each panel, so effectively its 32 x 4 (4 lines per panel, two panels = 8 lines). You can see the gap in pixel clocks - I'm palnning on adding the facility to add front and back porches, which might be useful for setting up mmory access at the start of each line, but for the most part it isn't needed.

author: bktemp
author_rank: Super Contributor
timestamp: July 17, 2016, 07:42:19 am
content: Generating only 80 clocks and leaving a gap for LP is also my preferred solution. That works fine lor lcds, because all other timing signals are asynchronous to the pixel clock (TFT lcds use PCLK as a synchronous clock source sampling all signals at the clock edge).LCDs use the falling edge as the active edge, so by changing the inputs at the rising edge you have the largest setup/hold time. FLM works the same way: Just ensure enough setup/hold time around the falling egde of LP and everything is fine.I can't see enough details around CP/LP to be sure about LP setup/hold time, but except from that the timing looks good. FLM has sufficient setup/hold time.

author: legacy
author_rank: Super Contributor
timestamp: July 17, 2016, 09:41:47 pm
content: Code:do_lcd_stn : lcd_stngeneric map(x_size => 16, --240y_size => 8, --320init_time => 20,flm_delay => 1,lp_ws => 1)thanks guys, I have implemented your tips