Reverse engineering the Hosiden HLM8218 Display from an old photocopier
Already have an account? Log in.
To make the experience fit your profile, pick a username and tell us what interests you.
Some months ago I disassembled an old Ricoh photocopier and I wanted to reuse the 240x320 STN display. I haven't found any libraries to control it so I decided to try to make one looking at the datasheet of a similar display (HLM8619).
The goal is to have the display working and make a port of AdafruitGFX.
HLM8619-010300-HOSIDEN.pdfAdobe Portable Document Format - 380.54 kB - 04/23/2017 at 07:53 |
|
|
The screen needs a -18V power supply for the LCD and 5V for the logic, so I'm using one from a DVD player.
After connecting the power supply, the display resurrected and showed some noise
The very first arduino code used digitalWrite, it was extremely slow, so after investigating about using the ATMega328 registers I came up with this code:
Mati
#define S_LOW (PORTB&=(~(1<<5)));
#define S_HIGH (PORTB|=(1<<5));
#define CP1_LOW (PORTB&=(~(1<<1)));
#define CP1_HIGH (PORTB|=(1<<1));
#define CP2_LOW (PORTB&=(~(1<<0)));
#define CP2_HIGH (PORTB|=(1<<0));
void setup() {
pinMode(13,OUTPUT); // S
pinMode(9,OUTPUT); //CP1
pinMode(8,OUTPUT);//CP2
//Only 2 out of 4 pixels should be drawn
analogWrite(3,200);
analogWrite(4,200);
}
void loop() {
S_HIGH
CP1_HIGH
asm("nop");asm("nop");
CP1_LOW
asm("nop");asm("nop");
S_LOW
for(int y=0;y<240;y++){
CP1_HIGH
asm("nop");asm("nop");
CP1_LOW
for(int bx=0;bx<80;bx++){//4 pixel block
CP2_HIGH
asm("nop");asm("nop");
//send pixels here
CP2_LOW
asm("nop");asm("nop");
}
}
}Great, it shows 2 pixels per block as expected, but I need to figure out why some lines are missing (maybe EMI?)
So that's all for today, next task: Fill the entire screen with pixels and then map an array to the screen.
Now I have a STM32F4, but I'm not really sure which kind of interface would be easier to use instead of bitbanging the clock and latch, what would you recommend?
Jake Wachlin
Charles Dean Modrich
Md. Khairul Alam
kender.arg
Looks like a clever trick to use analogWrite! I always use a STM32 to drive such controller-less screens, and generally works fine, I can even use FRC to get 16 shades of greyscale out of these screens. The biggest problem of using a uC like AVR or 51 is that they generally do not even have enough RAM to hold the framebuffer while the screen needs to be refreshed constantly, it would make programming much harder. Great work overall, but using a better uC would make things much easier.