Lead

Aug 11 09 9:55 PM

Tags : :

Hi,

we bought some S128240D-RGB and want to use them in an application using them in parallel bus mode. As we are using a 5V Atmel AVR MCU with USB to get the full processing power of the MCU, we have to do some levelshifting, which is done by an Altera CPLD supplied with 3VDC, as is the display.

I wrote some initialisation code and checked with a logic analysizer that read and writes are correct at the display (I have dedicated pinheaders for hooking up the analyser as I already expected trouble...). The display does absolutly nothing, it doesn't even start to build up LCD bias voltage.

I have no clue what I'm doing wrong. I find the datasheet of the display not very helpful, because I had to search the whole internet for some schematics how to hook up the booster caps. I definitely expect this in the datasheet to have a point to start of.

Also I am not shure about the numbering of the display pins. I attach schematic and layout. The display connector is mounted on the back of the PCB (blue traces) and is a bottom contact type. I even cut the foil cable off from an old display and used the multimeter to measure if the connections are proper. I'm almost shure the display is connected properly, but it doesn't do anything.

If someone could please have a look at the schematic and the layout for severe bugs and give me a hint I would really appreciate it.

In your tester schematic I found lately there are pull up resistors at the D0-D7 lines, but I don't know why they are neccessary (I don't have any).

Markus





Click here to view the attachment
Click here to view the attachment
Click here to view the attachment
Quote    Reply   

#2 [url]

Aug 12 09 10:31 PM

Yes, I know these two documents. I checked the data transfers with a logic analyzer, and even checked if the setup and hold times are proper. But still nothing.

Is the Pin 1 orientation on the flat foil cable correct in my layout or am I missing something here?

Are these Pullups on D0-D7 mandatory? I don't think one needs them working directly on a memory bus of an MCU....

Quote    Reply   

#3 [url]

Aug 14 09 10:45 AM

Hi Markus,
 
I have a few theories, but could do with some more information:
1) I could not access the schematics - could you re-post them as *.pdf attachements?
2) The *.c code attachement was the high level - could you post the lower-level code (write_inst, write_data, reset handling, enable handling)?
I'm after tracing the logic level of assertion through.
3) Is it simple for you to post the logic-analyser traces?
 
Martin

Quote    Reply   

#4 [url]

Aug 16 09 12:10 AM


1) I could not access the schematics - could you re-post them as *.pdf attachements?

-martinr

Sure, see attachments.


2) The *.c code attachement was the high level - could you post the lower-level code (write_inst, write_data, reset handling, enable handling)?I'm after tracing the logic level of assertion through.

-martinr

These are simple writes to certain memory locations, as the display ist hooked up via memory mapped IO to the AVR memory bus. The enable and reset stuff is managed by the Altera CPLD.
I copied the relevant stuff into attached "lowlevel.c"


3) Is it simple for you to post the logic-analyser traces? Martin

-martinr

I will try, but it will take some time. I have to hook up the analyser anyway, and I'm pretty sure the windows software provides some sort of export-as-bitmap option. Stay tuned!

Markus




Click here to view the attachment
Click here to view the attachment
Click here to view the attachment

Quote    Reply   

#6 [url]

Aug 16 09 3:59 PM

Hi Marcus,
 
I've checked out the mechanics and interconnect and all looks fine.
I do have a few questions so far - but I think they are low probability of being the root cause.
There may be an issue in the bus timing (see below).
I've run out of time this evening, but I'll look again later on in the week.
Please let me know if you resolve the issue before then.
 
Regards
Martin R
 
 
ANALYSIS
1 - OK - When the PCB is oriented with the FPC receptacle on the upper face, aperture facing the operator, pin one with be on the left.
When the LCD is oriented with the FPC exiting the top and the lcd visible area facing the operator pin one will be to the left
=> pin one of LCD is aligned with pin one of socket.
 
2-OK - When the LCD is oriented with the visible area towards the operator, the contacts on the FPC are towards the bottom.
The PCB has a bottom contact FPC
=> the LCD and connector are compatible.
 
3 - MARGINAL - With SJ5 in default (1-2) boost configured in x7 mode (with the option of x8 in the 2-3 position)
The LCD is run off 3V.
x7 boost is limited to 2v8 as specified in ST7529 v1.8 data sheet.
x7 boot can theoretically generate 21V from a 3v supply
ST7529 v1.8 sates that 20V is the maximum tolerance.
 
=> this has the potential to drive the LCD out of tolerance.
However in practice as soon as the bias is activated the boost will be loaded, and Vlcd most likely dropped below 20V.
In summary this is not great, but I thin you'll get away with it and I don't think it is the problem.
 
4 - OK IF1,2 high, 3 low 
=> 80 series 8-bit
 
5) OK - LCD_Reset# is kept high during LCD communications
 
6) OK Bus period is ~380nS (or 2.6 MHz)
 
Could you accurately measure the time (T->A) from the data changing to the time of CS deassert?  From the data sheet this is required to be Tds8 >=150nS, but appears to be 120nS from the trace.
 
QUESTIONS
 
7) What is the voltage rating of the 1uF ceramic caps for the boost circuit (some need to be at >20V)
 
8) When you run the init code, is there any voltage on any of the capacitors?
 
9) Section 8.2.2 of the manual state the reset sequence for the display - I did not see evidence of this on the analyzer traces.
I.e. is reset kept low through power application, then taken high, then ~2uS wait, then init code.?

Quote    Reply   

#7 [url]

Aug 16 09 10:20 PM




2-OK - When the LCD is oriented with the visible area towards the operator, the contacts on the FPC are towards the bottom.The PCB has a bottom contact FPC=> the LCD and connector are compatible




-martinr



. Great smile




3 - MARGINAL - With SJ5 in default (1-2) boost configured in x7 mode (with the option of x8 in the 2-3 position)The LCD is run off 3V.x7 boost is limited to 2v8 as specified in ST7529 v1.8 data sheet.x7 boot can theoretically generate 21V from a 3v supplyST7529 v1.8 sates that 20V is the maximum tolerance. => this has the potential to drive the LCD out of tolerance.However in practice as soon as the bias is activated the boost will be loaded, and Vlcd most likely dropped below 20V.In summary this is not great, but I thin you'll get away with it and I don't think it is the problem.






-martinr



. I would be glad if there would be any voltage higher than 3V.... Also I think I labeled the Jumper wrong, AFAIR it ist to select between 6X and 7X actually.



.
Could you accurately measure the time (T->A) from the data changing to the time of CS deassert?  From the data sheet this is required to be Tds8 >=150nS, but appears to be 120nS from the trace.






-martinr



. I can sample with up to 500MHz and make a detailed view of just one write access. I have to look into the Atmel datasheet and play with the waitstate options of the memory interface and try to correct this issue. But if I look into the analyser plot the data lines on the LCD stay on the same value till start of the next cycle, so whats the problem? (The LCD_D[0..7] are directly at the LCD connector, the CPU_AD[0..7] is the multiplexed CPU Data/Adress Bus)




 QUESTIONS 7) What is the voltage rating of the 1uF ceramic caps for the boost circuit (some need to be at >20V)






-martinr



I think they are 25V rated, but I'll check.




8) When you run the init code, is there any voltage on any of the capacitors?






-martinr



Not more than some 2.9V. I can measure each cap to ground and post the result. Is there a pin on the connector where one can expect some sort of pulsing (from the chargepump), I would then hook up a scope and check.




9) Section 8.2.2 of the manual state the reset sequence for the display - I did not see evidence of this on the analyzer traces.I.e. is reset kept low through power application, then taken high, then ~2uS wait, then init code.?





-martinr



Reset is hardwired in the CPLD to the MCUs Reset now, but I can route it in the CPLD to some sort of GPIO and try again. Currently there is roughly 500ms delay after power-up until starting of the init sequence because there is a CAN Controller attached to the SPI of the AVR and initialising it takes some time.I can try the reset stuff, but not before weekend. I have to pack my bags now. Thanks so far for checking my schematic, layout and the timing.

Markus



Quote    Reply   

#8 [url]

Aug 22 09 7:44 AM

Seems to be an issue with the data setup in the write access which was to short. I've inserted a 2nd wait state and now the init code builds up some 20V over the booster caps. I'm gonna play around with the init code and write some PutPixel() routines and try.

I keep you informed.

Markus

Quote    Reply   

#9 [url]

Aug 23 09 8:39 AM

Hi Markus,
 
I'm glad to hear you resolved the bus timing issue (Tds8 extend through wait-state).
 
Moving forward, I'd recommend the following:
1a) Clear the entire display memory (not just the active area) immediately after power-up (pixels 0..254 x 0..159). 
 
1b) Set a display window for the active area of the display a maximum of (0..239 x 16..144).
 
These two procedures ease the load on the charge pump, and give you better contrast over a wider temperature range.
 
2) I'd recommend measuring the boost voltage (VLCD) after a clear-screen to confirm that it is <<20V.
 
3) Also measure the boost voltage (VLCD) with a 'scope during the power-up, It may briefly over-voltage in the period between activating the charge-pump and gating the voltage followers.
 
Just to note, I can confirm that the schematic is indeed selecting between x7 and x8 boost.
 
Martin

Quote    Reply   

#10 [url]

Aug 23 09 12:44 PM

Hi,

I'm still experiencing difficulties in getting the display running. Is there a simple test to see if reading and writing to the display ram is working?

Markus

Quote    Reply   

#11 [url]

Aug 23 09 1:51 PM

Markus,
 
I have a few suggestions
1) Confirm that VLCD is around 17 to 20V
2) Confirm V0out is around 15.2V
3) Confirm that when you increase VOLCTRL that VlcdOut increases and vice-versa (expect 0.04V for every unit of increase)
 
These points achieves two things
a) That the LCD bias will give contrast so you can see the pixels (around 15.2V)
b) That the code is really controlling the display.
 
Note - when you increase V0out, VLCD will decrease as the charge-pump is loaded more.
 
4) Activate a block of pixels in the middle of the screen
I'm suggesting the middle of the LCD as the pixels at the 'top' of the video-ram are not mapped to pixels in the viewable area of the LCD!
 
5) I neither of these give you joy, then post the code you're running, and the values you're seeing for the voltages.
 
Martin

Quote    Reply   

#12 [url]

Aug 25 09 5:47 AM

I now have pixels, but initialisation is unstable, e.g. sometimes the LCD does not come up after Power On Reset. I reprogrammed the CPLD to have control over the reset line, and do a dedicted reset pulse with delay in between.

I could write the company logo to the Display, its 32 Grayscale, but the Vboost then drops from 19.8V to about 13.8V and the contrast is low even with partial display 240x128

I'm thinking about using an external supply, because the contrast issue seems to be a general problem with this display.

I adopted some sourcecode posted somewhere in the forum to render text, but there still seem to be issues with the data transfer as pixels get lost, but I have not further looked into it.

Is there BTW a simple way to turn the display 180 degrees without doing everything in software as the Display is mounted upside down unintentionally as you can see in the attached picture.

(A hint in the display datasheet about the correct orientation of the display would be VERY HELPFUL *grrr*)

I managed to flip the display by programming the scan direction stuff, but then the graphic is mirrored. I now turn the graphic in software, but it's very uncomfortable for text rendering because autoincrement is in the wrong direction then.

I attach a sample picture of the company logo. I'm not shure where the light spots are from, might be due to the conversion from windows bitmap. I have to look it up.

Markus


Click here to view the attachment

Quote    Reply   

#13 [url]

Aug 25 09 10:53 AM

Hi Markus,

It looks like you're making strong progress and are nearly there!

INIT INSTABILITY
This has the hall-marks of a signal-line sequencing issue.
I'd suggest confirming that all signal lines (including reset) are held low before during and after power is applied and stable, and for the minimum stability time from the controller data sheet.
If they are not, I've seen the same problem you're describing.

PIXEL INSTABILITY
When you say that 'pixels get lost', is this a random event, or is it the same pixels always each time?
If 'random', then I'd lean to a problem in the bus timing (I've seen this too).
If  in the same place, then I'd guess an issue with the columns.

GREY-SCALE
I've found that the built-in charge pump will support a 64x64 grey-scale image over temperature, and a 96x96 at room temp.
As you've also seen, a full area image bleeds the charge pump too low for good contrast.
Options I've considered:
1) Use an external charge pump/contrast adjustment/temperature compensation (as you're already thinking of)
2) Shrink the logo (probably not an option)
3) Convert the logo to black-and-white rather than grey (the display handles large floods of 100% black much better than the same area of grey)

ROTATION
Yes there is a simple way to rotate and/or reflect.

This is a section from your original code:
write_inst(0xbb); //common scan
write_data(0x02); //com79~com0,com80~com159
write_inst(0xbc); //data scan direction
write_data(0x00); //seg254~seg0,com160~con0
write_data(0x00); //rgb arrangement
write_data(0x04); //32gray scale 3b3p dither mode

I'm guessing that you modified the common -scan-parameter 1 from 0x02 to 0x01 to cause a simple reflection about the horizontal centroid:
write_inst(0xbb); //common scan
write_data(0x01); //com0~com79,com159~com80

Instead of that, try this to rotate 180; Change parameter 1 from 0x00 to 0x03, parameter 2 from 0x00 to 0x01:
write_inst(0xbc); //data scan direction
write_data(0x03);
write_data(0x01);
write_data(0x04); //32gray scale 3b3p

ISSUES WITH BMP
I'm answering this during my lunch-hour at work, and our company fire wall blocks the picture you posted!
If you post as a pdf I'll be able to see it.
Also if you post a *.bmp file I can see how my bmp libraries handle it on the same LCD.

Martin

Quote    Reply   

#14 [url]

Aug 25 09 12:48 PM


INIT INSTABILITY
This has the hall-marks of a signal-line sequencing issue.
I'd suggest confirming that all signal lines (including reset) are held low before during and after power is applied and stable, and for the minimum stability time from the controller data sheet.
If they are not, I've seen the same problem you're describing.

-martinr

I've just noticed a pitfall with the busy-wait delay functions of the AVR libc. It seems there is an integer overflow with delays longer than some 10ms depending on the clock frequency of the MCU.

So my 100ms delays are most probable not 100ms... I'll cross check this, and change to some timer based delay functions.


PIXEL INSTABILITY
When you say that 'pixels get lost', is this a random event, or is it the same pixels always each time?
If 'random', then I'd lean to a problem in the bus timing (I've seen this too).
If  in the same place, then I'd guess an issue with the columns.

-martinr

The company logo is reproducible OK except for the light pixels, but I think this is some kind of integer overflow. I invert the pixmap because in the converted greyscale image 0xFF is a "white" or clear pixel and vice versa. So maybe there is something wrong, but I expect correct values by just subtracting the bitmap data from 0xFF to get the correct pixel value for the LCD. The 3 lowermost bits are thrown away by the display anyways because of the 5 bits per pixel, so there is some kind of rounding.

Maybe the greyscale setup of the display is wrong. I check this.

If I render text and do single stepping in the source the text is correct, but if it is run at full speed the pixels are scrambled. I don't understand this, because the actual memory access cycle is to be expected the same in both cases. I added some delays in the WriteCmd and WriteData but it doesnt make a difference.


GREY-SCALE
I've found that the built-in charge pump will support a 64x64 grey-scale image over temperature, and a 96x96 at room temp.
As you've also seen, a full area image bleeds the charge pump too low for good contrast.
Options I've considered:
1) Use an external charge pump/contrast adjustment/temperature compensation (as you're already thinking of)
2) Shrink the logo (probably not an option)
3) Convert the logo to black-and-white rather than grey (the display handles large floods of 100% black much better than the same area of grey)

-martinr

I opt for the external power. Is there anything special about it? Where to connect it? I can start testing with a lab power supply. We have to do a PCB rework anyways because of some other issues not related to the display, so I want to have a proper display for mass production even with full size greyscale.


ROTATION
Yes there is a simple way to rotate and/or reflect.
This is a section from your original code:
write_inst(0xbb); //common scan
write_data(0x02); //com79~com0,com80~com159
write_inst(0xbc); //data scan direction
write_data(0x00); //seg254~seg0,com160~con0
write_data(0x00); //rgb arrangement
write_data(0x04); //32gray scale 3b3p dither mode
I'm guessing that you modified the common -scan-parameter 1 from 0x02 to 0x01 to cause a simple reflection about the horizontal centroid:
write_inst(0xbb); //common scan
write_data(0x01); //com0~com79,com159~com80
Instead of that, try this to rotate 180; Change parameter 1 from 0x00 to 0x03, parameter 2 from 0x00 to 0x01:
write_inst(0xbc); //data scan direction
write_data(0x03);
write_data(0x01);
write_data(0x04); //32gray scale 3b3p

-martinr

Hmm, I'm almost shure I tried every possible combination of that scanning stuff but I might be wrong. I check this. I cleaned up the init code and made some changes to it, so this is no longer the code, but that part looks familar :-)


ISSUES WITH BMP
I'm answering this during my lunch-hour at work, and our company fire wall blocks the picture you posted!
If you post as a pdf I'll be able to see it.
Also if you post a *.bmp file I can see how my bmp libraries handle it on the same LCD.
Martin

-martinr

Hmm, I have to check if I still got the "original" logo. It was 256 greyscale, but the display will round it to 32 grey. If I find it I'll attach it, otherwise I can send it via mail Zipped or something your firewall can handle. In that case just write me a PM with your email.

BTW: what timezone are you? I'm GMT+1 in Germany. So it 9:45PM here local. I will see what I find out this night. Thanks a lot for the feedback!

Markus

Markus



Click here to view the attachment
Click here to view the attachment

Quote    Reply   

#15 [url]

Aug 25 09 2:00 PM

Setting DATSDR is strange:

Setting Parameter Byte 1 to 0x01 flips the display, as expected, (but the logo is from right to left mirrored)

Changing it then from 0x01 to 0x03 I would expect Columns to be scanned opposit direction (CI) and then the image displayed correctly. But it doesn make a change at all, so setting the CI Bit has no effect.

I don't get it. Can you test this? I feel like D1 of the display not properly connected or shorted....

Markus


Quote    Reply   

#16 [url]

Aug 25 09 2:47 PM

Guten Tag Markus,

DATSDR
I have verified that changing the DATSDR parameters from {0x00, 0x00, 0x04} to {0x03, 0x01, 0x04} performs a 180 rotation for my LCD.

EXTERNAL BIAS
I can now see your logo (pdf), and I understand why large grey-scale is important.
There are a couple of ways to run an external bias.
1) The first is the most simple, flexible and is recommended by DisplayTech.
Simply connect an 18V supply straight to the VLCD pin, and run as normal!
You can use a simple charge-pump, a step-up switcher, or regulate a 12V rail etc - the current is small (I measured it at 80uA for a simple screen, and 250uA for a 128x128 256grey-scale bmp of Lena).
The only down side is that the ST7529 v1.8 spec sheet section 6.1 Vlcdout recommends that VLCDout be disconnected in order to do this
Of course you can't disconnect this as it is hard-wired in ITO on the glass.
But it works...
There may be some experimentation here in disabling the on-chip bias generation (I've not done this so I can’t offer guidance).

2) An alternative is to break the track between V0OUT and V0IN, and feed a voltage in to V0IN.
Unfortunately this method looses the LCD's regulator, built-in temperature compensation, and software bias adjustment.
The only advantage is that this is in keeping with the display driver specification.
In balance, option (1) with some validation would be the path I'd choose.

BMP
Your concept of grayscale is valid.
Our firewall is also blocking the BMP (and I guess ZIP too as well - sigh).
I'll PM you my home email so I can pick it up there.

LOCATION
I'm currently UTC-4 (Florida USA DST).
Please let me know how things go with the rest of the testing.

Martin

Quote    Reply   

#17 [url]

Aug 25 09 3:10 PM

Guten Tag Markus,

-martinr

Guten Abend! :)


DATSDR
I have verified that changing the DATSDR parameters from {0x00, 0x00, 0x04} to {0x03, 0x01, 0x04} performs a 180 rotation for my LCD.

Are your sure about the 0x04 in PB3? According to my Datasheet this isnt a valid Pixel Mode at all....
I'll try anyways (tomorrow)


EXTERNAL BIAS
I can now see your logo (pdf), and I understand why large grey-scale is important.

The logo is a nice-to-have, but if I had a 32 greyscale LCD I want to have 32 levels in good quality and not such a mess....

And right, the logo doesn't look nice in 1bit "color"...


There are a couple of ways to run an external bias.
1) The first is the most simple, flexible and is recommended by DisplayTech.
Simply connect an 18V supply straight to the VLCD pin, and run as normal!
You can use a simple charge-pump, a step-up switcher, or regulate a 12V rail etc - the current is small (I measured it at 80uA for a simple screen, and 250uA for a 128x128 256grey-scale bmp of Lena).
The only down side is that the ST7529 v1.8 spec sheet section 6.1 Vlcdout recommends that VLCDout be disconnected in order to do this
Of course you can't disconnect this as it is hard-wired in ITO on the glass.
But it works...

Fine. I'll give it a try.... Are problems expected regarding power-up sequence?


There may be some experimentation here in disabling the on-chip bias generation (I've not done this so I can’t offer guidance).

no more experiments. I'd be happy if the display runs reliable. At least the POR issue seems solved with a proper delay routine (damn avrlibc... but if you RTFM.... *sigh*)


2) An alternative is to break the track between V0OUT and V0IN, and feed a voltage in to V0IN.
Unfortunately this method looses the LCD's regulator, built-in temperature compensation, and software bias adjustment.
The only advantage is that this is in keeping with the display driver specification.
In balance, option (1) with some validation would be the path I'd choose.

Yeah, I would like to have an option for the customer to fine tune the contrast and save it in an E2PROM.

Do you have experience how much the deviation is between lets say 10 LCDs? Is the contrast setting close or does it stray a lot for the same contrast level?


BMP
Your concept of grayscale is valid.
Our firewall is also blocking the BMP (and I guess ZIP too as well - sigh).
I'll PM you my home email so I can pick it up there.

I've sent the stuff there.


LOCATION
I'm currently UTC-4 (Florida USA DST).
Please let me know how things go with the rest of the testing.
Martin

Yeah sure, but not today. I take a nap and see tomorrow...

Markus

Quote    Reply   

#18 [url]

Aug 25 09 6:52 PM

Guten Morgen  Markus,
 
DATSDR
You're right that the data sheet suggests 0x04 is not valid.
I also went down this path when I ran into problems getting the display working.
However this is the value used in the (working) DisplayTech example, and in your original posting.
There are several other locations where the DisplayTech sample departs from the manual - and some of the departures are essential for the LCD to operate.
I'd suggest sticking with the 'known-working' codebase (0x04) rather than the 'manual-values' until the display is functional, then lets take care of 'making it elegant and fast'.
In this case entering the 'correct' value appears to have the same outcome as 0x04.
 
EXTERNAL BIAS
My only recommendation here would be to ensure that the external bias ramps after the display is fully initialized.
Conversely disconnect and bled-it-down before the display is de-initialized.
I don't think the display would take kindly to being reverse powered through the charge-pump.
 
The displays appear to have a few percent variance on both the offset and scale value for the contrast setting.
They are quite usable with a default setting, however for optimum contrast in complex grey-scale images (e.g. photos) optimization improves matters.
 
I hope to take a look at the *.bmp you posted tomorrow - but I've been up since 4AM and I need to take a nap too!
 
Martin

Quote    Reply   

#19 [url]

Aug 25 09 10:35 PM


Guten Morgen  Markus, DATSDRYou're right that the data sheet suggests 0x04 is not valid.I also went down this path when I ran into problems getting the display working.However this is the value used in the (working) DisplayTech example, and in your original posting.There are several other locations where the DisplayTech sample departs from the manual - and some of the departures are essential for the LCD to operate.I'd suggest sticking with the 'known-working' codebase (0x04) rather than the 'manual-values' until the display is functional, then lets take care of 'making it elegant and fast'.In this case entering the 'correct' value appears to have the same outcome as 0x04.

-martinr

Guten Morgen,
I tried the suggested values, but then in mirrored mode the column order is wrong, e.g. each 3 pixel block is drawn in the wrong direction making the display unreadable at least without changing the software.


EXTERNAL BIASMy only recommendation here would be to ensure that the external bias ramps after the display is fully initialized.Conversely disconnect and bled-it-down before the display is de-initialized.I don't think the display would take kindly to being reverse powered through the charge-pump. The displays appear to have a few percent variance on both the offset and scale value for the contrast setting.They are quite usable with a default setting, however for optimum contrast in complex grey-scale images (e.g. photos) optimization improves matters. I hope to take a look at the *.bmp you posted tomorrow - but I've been up since 4AM and I need to take a nap too! Martin

Ok, I will give it a try with some kind of stepup converter.

Markus

Quote    Reply   

#20 [url]

Aug 26 09 5:02 AM

Hi Markus,

I converted the "Vidit " bitmap and viewed it on my LCD - things loog good.
I'm going to make five attachments
1) Vidit render with DATSDR {0x00, 0x00, 0x04} "Normal"
2) Vidit render with DATSDR {0x03, 0x01, 0x04} "180 roatation"
3) Vidit render with DATSDR {0x03, 0x00, 0x04} "180 roatation + triplet reverse" - looks 'wrong' as every three pixels are reversed.
4) Lena128x128
5) The Vidit bitmap converted to a *.h file - this will allow you to render this array to see where the stray pixels are coming in.

If you have the 3-pixel blocks drawn in the wrong order then try toggling the second parameter e.g. {3, 0, 4} instead of {3, 1, 4}

The objective was three fold
1) Give a reference of what I mean by 180 degree rotation from modifying the DATST parameters 0,0,4 to 3,1,4
2) Show the "Vidit" bitmap with no corruption
3) Demonstrate that the 18V00 external bias (lab pack) can generate sufficient contrast.
I 've also attached an image of the 'Lena' for reference (this also required an external bias supply).
When the 'Lena' is rendered as 64x64 the internal charge pump can handle the contrast.

Martin







Click here to view the attachment
Click here to view the attachment
Click here to view the attachment
Click here to view the attachment
Click here to view the attachment

Quote    Reply   
Add Reply

Quick Reply

bbcode help