Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Noob wants to understand Physical display driver

Status
Not open for further replies.

ReWallt

New Member
So I've some experience with microcontrollers and making PCB's. I've been really interested in making a PCB for a "physical" display driver(saying physical so it will not be confused with a program). But the problem is, I can't find a single tip on working with the display driver components(Not even the second page of google had any help). So I read the datasheet of the HV5812WG-G display driver. But could barley make anything out of it.

I went to other forums and told them something similiar, but the just anwswered "just read the datasheet bro".

So I want to make a PCB for a display driver, but I have no info on how to program or connect the device to a microcontroller. So would really appreciate it if someone where to help/guide me in the right direction. Or tells me where I can get the info I need.

Thank you in advance.
 
Entirely depends on what displays you're talking about. Smaller graphical displays mostly use serial SPI. Bigger displays often use HDMI.
 
The HV5812WG isn't made any more, and it's designed for driving Vacuum Fluorescent Displays (VFDs) that are also rare, so you might want to consider whether you want to use it.

If you do use an HV5812WG, it contains circuitry that is easier to understand if 4 parts of it are looked at separately:-
1629323565579.png


1) On the left is the 20 bit shift register. It has 2 input lines (DATA IN and CLK), and 20 output lines, one for each bit. There is also a DATA OUT line, but you can ignore that unless you are using more than one HV5812WG.
The shift register allows a microcontroller to separately control each of the 20 output lines from the 2 input lines. It's only there to save on number of connections. It allows control by storing the state of the DATA IN line each time the CLK line goes high. Bit 1 has the value, 0 or 1, that DATA IN had just one clock rise ago. Bit 2 has the value that DATA IN had 20 clock rises ago.
2) The 20-bit latch takes the data from bit 1 to bit 20 of the shift register, and either passes it on to the next stage, or leaves the data going to the next stage unchanged. It's function allows the display to remain the same while the data in the shift register is being set up. Usually, after that the STROBE wire is taken high by the microcontroller and the data in the 20 outputs of the shift register goes on to the next stage.
3) Blanking. There are 20 AND gates, all connected to BL (via an inverter). When BL goes high, the display is turned off. This allows the display to be turned on and off without loading the data, that takes a lot longer.
4) The triangles represent drivers that take the output of the AND gates that do the blanking, and use that to enable 20 drivers that a capable of switching the high voltages used by the VFDs
 
What type of display do you want to drive?
 
Assuming you want direct pin drive or matrix drive, as for an array of LEDs, as you mention the HV5812:

If the display operates at 5V, then you can use bipolar transistors and resistors, or N channel and P channel FETs to drive high & low sides.

For higher voltages, you can use such as MIC5891 for high side and MIC5841 for the low side.

Those operate in a similar way to the HV5812WG, but each is an 8 bit / 8 output section. They have a shift register for input, easily driven by either an SPI port in an MCU, or software bit-banging.
Once the data is loaded to the shift registers, which can be cascaded through as many devices as needed, a pulse on the strobe pin loads it to the latches, which feed all the power drivers on the output pins.


It may sound slow to send data serially - but the data in can run at several megabits, so less than 2uS per 8 bit byte transferred; eg. a 16 x 16 array with two high side ICs and two low side IC could be reloaded in less than 10uS, with hardware SPI or a fast MCU.
 
The HV5812WG isn't made any more, and it's designed for driving Vacuum Fluorescent Displays (VFDs) that are also rare, so you might want to consider whether you want to use it.

If you do use an HV5812WG, it contains circuitry that is easier to understand if 4 parts of it are looked at separately:-
View attachment 133218

1) On the left is the 20 bit shift register. It has 2 input lines (DATA IN and CLK), and 20 output lines, one for each bit. There is also a DATA OUT line, but you can ignore that unless you are using more than one HV5812WG.
The shift register allows a microcontroller to separately control each of the 20 output lines from the 2 input lines. It's only there to save on number of connections. It allows control by storing the state of the DATA IN line each time the CLK line goes high. Bit 1 has the value, 0 or 1, that DATA IN had just one clock rise ago. Bit 2 has the value that DATA IN had 20 clock rises ago.
2) The 20-bit latch takes the data from bit 1 to bit 20 of the shift register, and either passes it on to the next stage, or leaves the data going to the next stage unchanged. It's function allows the display to remain the same while the data in the shift register is being set up. Usually, after that the STROBE wire is taken high by the microcontroller and the data in the 20 outputs of the shift register goes on to the next stage.
3) Blanking. There are 20 AND gates, all connected to BL (via an inverter). When BL goes high, the display is turned off. This allows the display to be turned on and off without loading the data, that takes a lot longer.
4) The triangles represent drivers that take the output of the AND gates that do the blanking, and use that to enable 20 drivers that a capable of switching the high voltages used by the VFDs
Yeah I chose this one because it was the cheapest on digikey.com that I found.

But thank you very much. This really helped allot
 
I was thinking of an oled display
Okay.... OLED's come in a variety of types an sizes... small OLEDS ( eg 128x64 ) come with "physical" drivers on board.

The chip you mentioned would be next to useless unless you are driving said VFD's... We are at a point where we need to know where your going with this..

If you intend on driving a mega sized resolution display's you will need much more electronics... The bigger you go the bigger the chipset.

As for connection to an MPU... This will also depend on screen resolution... OLED displays in phones are driven by VLSI chipsets as the speed of updating the screen, either fully or sections, relies on application... Like I said.. Where are you going with this...
 
I was thinking of an oled display
OLED panels usually have built-in driver ICs, due to the number of internal LED connections that would otherwise be needed.

The connection to the panel is often either I2C or SPI.
 
Okay.... OLED's come in a variety of types an sizes... small OLEDS ( eg 128x64 ) come with "physical" drivers on board.

The chip you mentioned would be next to useless unless you are driving said VFD's... We are at a point where we need to know where your going with this..

If you intend on driving a mega sized resolution display's you will need much more electronics... The bigger you go the bigger the chipset.

As for connection to an MPU... This will also depend on screen resolution... OLED displays in phones are driven by VLSI chipsets as the speed of updating the screen, either fully or sections, relies on application... Like I said.. Where are you going with this...
Well it was actually for a small display for you eyes(think smart glasses or virtual reality headset size)

The chip was just the cheapest I found on digikey.com. I could use other chips, but again I'm a noob. So do you have any recommendations?
 
What physical size and pixel resolution display do you need?

Also remember that if you will be displaying images, you need an MCU with enough storage and RAM to manipulate them, and a fast enough data output to the display to give a reasonable update speed.
 
What physical size and pixel resolution display do you need?

Also remember that if you will be displaying images, you need an MCU with enough storage and RAM to manipulate them, and a fast enough data output to the display to give a reasonable update speed.
Well I haven't reallt figured that out yet honestly. I thought that if I first got some info, that it would be easier to figure out.

As for the MCU, I was thinking a stm32 microcontroller. But I want to display live footage from the display. Not just a single image that stays stuck on the display. Like, displaying footage live from a camera.

Again, I'm still new to some parts, so sorry if I'm a bother
 
Okay... Good resolution... You can buy small 320x4240 screens that would give reasonable viewing, but you would need a SSD1963 type of controller These are quite large (pin wise) 128 pin... They drive raw... ie similar to a TV with frame sync data etc.. But then again its as cheap to buy the display with this on..

I saw a great video on youtube where this guy made a headsup display... Can't find it again.. sorry!
 
Okay... Good resolution... You can buy small 320x4240 screens that would give reasonable viewing, but you would need a SSD1963 type of controller These are quite large (pin wise) 128 pin... They drive raw... ie similar to a TV with frame sync data etc.. But then again its as cheap to buy the display with this on..

I saw a great video on youtube where this guy made a headsup display... Can't find it again.. sorry!
Ah thanks for the info
 
If you use a small display that has HDMI input, you could feed video directly from such as a Raspberry Pi.
You can definitely get displays down to 3.5" diagonal, so small enough to fit a typical VR type headset mount.
There may be smaller ones as well.
 
If you use a small display that has HDMI input, you could feed video directly from such as a Raspberry Pi.
You can definitely get displays down to 3.5" diagonal, so small enough to fit a typical VR type headset mount.
There may be smaller ones as well.
Well the thing is that I was just interested in trying to make a working display driver myself(it's about the journey, not the destination). Also to fill curiousity on how a display driver actually works. I also thought that I would save some cash by making it myself. But maybe it's better for now to stick with premade things and make it myself a little simpler. Not making it ALL THE WAY from scratch.

Any way, I want to thank everyone for putting effort in trying to help me out.
Thank you
 
I think from your comments... You would like to build a controller from scratch.. A tough job.. OLED's and LCD's have two types of interface.

1) RGB with clock sync and sutch..
2) frame and sync and voltages..

here is a quote from a guy who tried.
The guy said:
We worked with an bare LCD awhile ago, something like 30 pins for a 4 digit seven segment display, the number of pins of a decent sized LCD screen would be (400x600 res => at least 1000 pins plus "extras") In order to prevent killing the LCD you need to supply an AC voltage to the pixels (blinking the segments prevents them from becoming stuck) So where you would normally go from VCC to ground you should go VCC to BP (back plane) which is a high frequency square wave (i think ours was using a 40kHz BP) going from ground to VCC. A 50% duty cycle on BP will only get you half the "darkness" of the pixel. Because there is only a voltage difference across the pixel for half the time. So VCC ought to be not BP. Confused yet?

So what you get in basic circuit form per pixel is:
BP => pixel => !BP = darkened pixel.
BP => pixel => BP = "clear" pixel.
no connect => pixel => no connect = randomly blinking pixel

large panel LCD's with small pixels may run on a much lower voltage start small and work up until you see the pixel darken, I don't think it will be a fade to black thing i think once you reach a good voltage difference it'll switch, you shouldn't need anymore than that.

you end up having immense control over the LCD but the catch is that you have a lot a lot of overhead to do it.
SOOO>>> If you learn FPGA programming.... Make a physical driver!! But!! putting a arm based MPU on an LCD with a controller is quite simple..
 
To further put it in context, an OLED driver IC for just a 128x64 pixel monochrome display has 281 connections, 192 of those being drive connections for the OLED array.

A slightly more capable one - 128x128 pixel full colour - has 512 outputs to the OLED panel. 384 of those have 256 levels of current control to set the brightness of each of the R-G-B elements within each pixel.

Speaking as both a hobbyist and professional electronics designer / programmer, there are lots of things that can be practically done using "built up" hardware, but direct control of a graphics display panel is just not practical, no matter how much experience you have.
It's one of the things that is only really possible with dedicated integrated circuits and custom assemblies.

The electronics for a CRT display system (VDU) are childsplay by comparison.
 
Status
Not open for further replies.

Latest threads

Back
Top