Driving a lmg5042xufc LCD - Page 1
Forum section: electronics / projects

author: Nick96
author_rank: Newbie
timestamp: January 25, 2023, 01:39:45 am
content: Lmg5042xufc is a 640×480, monochrome LCD that I bought for very cheap from a local electronics component supplier. It has been collecting dust for quite a long time, and I decided to finally figure out how to drive it and hopefully use it in one of my projects.There wasn't much documentation about this display on the internet, so this is what I found so far:datasheet_1datasheet_2I would like to design a pcb, or use a microcontroller (possibly raspberry pi pico) to drive this LCD, but i don't have much experience working with LCD's like this. I saw some LCD driver boards built to universally control a lot of different LCD's on the market, but I'd like to figure out how this LCD works and build a driver that could interface between this LCD's 18pin connector and have an HDMI input.If anyone worked with similar projects or has any info about this or similar boards, please comment bellow. Thank you in advance.

author: coromonadalix
author_rank: Super Contributor
timestamp: January 25, 2023, 01:51:17 am
content: they are controller less, the main driver ic is not thereyou may find some universal controller pcb on fleabay, and sometimes you can ask or check compatibility ...you have a reference for an hitachi hd66841 ...https://www.tautec-electronics.de/Datenblaetter/Schaltkreise/HD66841.pdf

author: Buriedcode
author_rank: Super Contributor
timestamp: January 25, 2023, 02:57:50 am
content: Those dual scan displays are a bit of a sod to drive - to speed up refreshing (or rather to prevent obvious flicker of a slow refresh rate) the display is split into upper and lower parts, effectively two displays each 640x240. As its a controllerless display, it has to be continously refreshed - it has no memory. So two 4-bit LCD interfaces, merged into one 8 bit. The common (but long obselete) SED1335F/S1D13700 doesn't support displays of this size, as the memory is limited by the interface, but the more obscure S1D13704 odes support dual scan displays in 8-bit mode.I haven't seen a graphics module built-in to a microcontroller that supports dual scan either (microchip had a PIC24 line specifically for displays, and I'm sure Phillips had an LPC line for them too, both over a decade ago).As for a DIY approach, whilst micros these days are more than fast enough to bit bang (pi pico, Teensy, STM black pill?), its a lot of hassle. FPGA/CPLD could work, but you'd probably need external SRAM for frame buffers - the internal RAM blocks in FPGAs might be large enough to hold one frame, but you'll probably need a few of these for double buffering, so it ends up requiring external memory. (300kb/40kB for one frame).If you're just displaying text, or something thats not full screen size, you could generate images/text on the fly rather than store the entire displays bitmap in memory. Again it would have to be continuosly refreshed, so a micro with DMA would be handy to semi-automate it, leaving only the Line and Frame sync signals to be bit banged.I do like these displays, but despite the much higher datarate required - modern TFT displays, with their built in controllers are far easier to work with for projects - and much more widely supported with libraries too. The downside being, for a TFT of similar physical size as the one you have it would have a resolution requiring HDMI interface or at least a very fast parallel interface.