SparkFun Forums 

Where electronics enthusiasts find answers.

Have questions about a SparkFun product or board? This is the place to be.
By JamesK
#55912
Hi Mike,

Yes, I'm using output compare modules for dot clock and hsync. Vsync is computed off of hsync. In principle I should be able to get up to about 4MHz but for some reason I lose sync above about 500 kHz at the moment. I seem to be caught in a frustrating catch where a low frequency dot clock is stable but looks bad, and the high frequency dot clock won't sync. Feels like there ought to be a happy compromise here somewhere, but it's not proving easy to find!

Update: I updated all of the sync signals (dotclock, hsync, vsync and DE) to use output compare units, and can now happily sync up to 4MHz or so. Of course I don't have any hope of being able to generate rgb data at that rate, but it was an interesting exercise. Sync at slower speeds seems to be a bit hit and miss - a lot of speeds won't sync and you have to explore around a bit to find ones that do. At about 1MHz the display doesn't look too bad for strong colours, and I might try and see how far I can get with this. For some reason mid-tones suffer very badly from flicker. Here's a new pic just for fun:

Image


James.
By mikeselectricstuff
#56030
Re.flicker - now you have a decent range of displayed colours, you should run through the initialisation sequence to see if this can be improved. In particular, the various DC/DC converter settings, as displaying large blocks of colour will load the converters differently.
When I was tweaking, the settings didn't make much difference so I left them mostly at the defaults, but my test patterns were fairly small. The datasheet does mention possible flicker issues with certain combinations of divider settings and ISTR basically says fiddle about til it looks OK!
I would expect however that at vsync times much less than 60Hz it may not be possible to get a flicker-free display in all circumstances.
By JamesK
#56056
One more for posterity (!)

Image

Nothing seems to go smoothly with this thing. I spent ages trying to work out why changing the RGB data killed the sync. I narrowed it down to transitions that involve a large fraction of the RGB pins, e.g. black/white. As long as I only switch a subset of the pins it's ok, so the above black text isn't actually black. I guess it's probably crosstalk onto the sync signals as a result of the rats nest of prototype wiring. Ho hum.

Yes, I need to stop messing around with pixels and spend some time checking out the init code. Pixel bashing is so much fun though!

James.
By mikeselectricstuff
#56085
JamesK wrote:One more for posterity (!)
I narrowed it down to transitions that involve a large fraction of the RGB pins, e.g. black/white. As long as I only switch a subset of the pins it's ok, so the above black text isn't actually black. I guess it's probably crosstalk onto the sync signals as a result of the rats nest of prototype wiring. Ho hum.
Most probably ground bounce rather than crosstalk - I suspect a short, solid ground connection of all the ground pins to your data source will fix this.
By JamesK
#56088
mikeselectricstuff wrote: Most probably ground bounce rather than crosstalk - I suspect a short, solid ground connection of all the ground pins to your data source will fix this.
Spot on Mike, your suggestion worked perfectly. Thank you!

James.
By JamesK
#56107
I spent some time trying out different init settings and I've pretty much eliminated flicker for the solid colours with a dot clock of ~570 kHz. The mid tones are still awful, and nothing much seems to change that. Still, I would rate this as very usable for apps that can manage with a limited colour palette which fortunately includes the stuff I want to do.
It's not the easiest LCD to drive, but to set expectations as to what is possible, here's a simple scrolling text console being driven by a 28pin 16Mips pic24f:

Image

To be fair, the pic is short of IO pins, memory and mips, so I've taken major shortcuts at every corner.

Here are the key init settings in case anyone else wants to try them:

#define AP (3 << 1)
#define DC1 (3 << 4)
#define BT (5 << 7)
#define GON (1 << 11)
#define DC2 (1 << 12)

#define VC 6 // was 0, 6 reduces flicker
#define VRH (14 << 3) // was 12. 0 = more flicker, 14 = good
#define PON (1 << 7) // 1 = VLOUT3 on
#define POC (0 << 9) // 0 = white display
#define DK (0 << 11)

Everything else is as per Mike's original settings. The shifts are so I can bitwise or the values together.

James.
By Random
#56108
That's awesome work!

Once things calm down here I plan to hook mine up to an STM32 ARM at 72MHz - hopefully enough horsepower and IOs to drive the thing (if not significant overkill, but maybe I'll get it working with the mobile phone camera while I'm at it), though I am somewhat concerned about memory.
By JamesK
#56123
Once things calm down here I plan to hook mine up to an STM32 ARM at 72MHz - hopefully enough horsepower
I've got some faster processors on order to try out, including a pic32 that looks similar in capability to the ARM. I don't think it will be overkill, you can absorb quite a bit of processing power trying to generate the data stream at full speed. These new generation chips like the STM32, the AVR Mega128 and the pic32 are amazing power:price compared to what was available a few years ago!

Probably the best solution is the ram + cpld or fpga that was suggested a way back in the thread. That would be new territory for me, so should be interesting!

James
By mikeselectricstuff
#56126
JamesK wrote:The mid tones are still awful, and nothing much seems to change that. .
Flickery or poor greyscale? If the former maybe this is something to do with how they get greyscales, perhaps some sort of frame-to-frame modulation that doesn't work at low rates.

For those playing with driving from an ARM ( e.g. NXP LPC2xxx), I think using the SPI/SSP port would be a reasonable way to get monochrome text - I think you could get full resolution at reasonable framerates, as the SSP has a FIFO so you should be able to get a continuous stream of data ( although ISTR you get one 'dead' bit between words - not a problem for text if font width is same as SSP word size), and start each line with a FIQ from line sync. Mono text has the dual advantages of overcoming the bandwidth and memory limitations. You could also do things like graduated backgrounds on a line-by-line basis easily on the Vsync interrupt.

The problem with most bit-bashing type schemes is getting consistent data timing - many of the more powerful processors have problems getting sufficiently consistent interrupt latency. ARMs are pretty good, and if you run the code from RAM you avoid some of the inconsistencies that come from the various memory acceleration schemes (e.g. MAM on LPC2xxx), and using FIQs gives you some dedicated registers and pretty good latency.
I've previously sucked data at nearly 4MPix/sec from an image sensor, so blowing data out to an LCD at similar rates may be viable if you can figure out where to get the data from fast enough.
By Dan_attacker
#56127
I've been messing around with the lcd over the weekend and I ran into a problem with image alignment. I'm not sure if it's due to the sync timing being off or my fpga's spi interface not working correctly. And my colors are way off, but that's because i only have a 16-bit sram and the other 2 bits are tied to vcc. I can get around that though. I'll post some pics as well once I get something that looks pretty on the screen.
By JamesK
#56134
Flickery or poor greyscale? If the former maybe this is something to do with how they get greyscales, perhaps some sort of frame-to-frame modulation that doesn't work at low rates.
I was going to say flickery, but I guess a more accurate description would be 'noisy'. Flickery might imply that the entire colour block modulated in sync, but what you actually see is a lot of line by line variation that shifts from frame to frame. I guess I should be glad that it works at all!

James.
By blboucher
#56282
James / Mike –

Your progress is quite impressive and commendable! Thanks for charging ahead with this project –

Myself, I purchased a lot of the $1 LED backlight units by themselves in hopes of using them with the Arduino for some fun multimedia art projects. I'm rather new to electronics and know just enough to be dangerous - ! :)

Could you offer some instruction on how to connect just the backlight itself? Using what resistor value and how to connect the 7 leads together to best run all embedded LEDs safely? Any specific help with how to connect 2 or more of the backlight units to a single Arduino controller would be awesome!

Please feel free to also point me in the right direction for a more relivant discussion thread or user forum for more noobie questions such as this ––

Thanks! -Ben
By Dan_attacker
#56292
There are a lot of tutorials on the internet for powering leds. As I am also somewhat new at electronics, I looked one up. I'm using a 70 ohm resistor for each led with a supply voltage of 5v. I determined that from one of the calculations on the website.

Here's the site I looked at:
http://www.kpsec.freeuk.com/components/led.htm
By Arachnivore
#56298
JamesK wrote:I was going to say flickery, but I guess a more accurate description would be 'noisy'. Flickery might imply that the entire colour block modulated in sync, but what you actually see is a lot of line by line variation that shifts from frame to frame.
This sounds like it may be a combination of spacial and temporal dithering. That is; to produce a certain half-tone, the LDC flickers between two given colors. To hide this flicker, the LCD alternates the flicker pattern of adjacent pixels (or lines of pixels to simplify hardware design).

I'm no expert (not by a long shot) but if my theory is correct, you may just need to increase the refresh rate to make this dithering less apparent. Also, I wonder if ground bounce might also be the source of your dot-clock problem.

I don't know, these are all just shots in the dark :wink:
By JamesK
#56329
blboucher wrote: Could you offer some instruction on how to connect just the backlight itself? Using what resistor value and how to connect the 7 leads together to best run all embedded LEDs safely? Any specific help with how to connect 2 or more of the backlight units to a single Arduino controller would be awesome!

Please feel free to also point me in the right direction for a more relivant discussion thread or user forum for more noobie questions such as this ––

Thanks! -Ben
Hi Ben, the link that Dan posted seems to explain it all better than I could. Just a couple of things to add, the pin out for the backlight is on the last page of the pdf on the SF sales page. The pin nearest the backlight is the common anode (+ve supply) and then there are six individual cathodes on the remaining pins (ground). You can use the individual cathodes to balance the brightness of each LED (or turn them on/off individually) , or you can do what I did and just strap them all together to make life easy. With a supply of 3.5v or less you can just connect the +ve to the anode and the ground across all the cathodes. The LEDs are spec'd for 15mA each, so this is the figure you would use to calculate the series resistor if your voltage is more than 3.3v. If you connect all 6 LEDs together (EDIT: Note that more knowledgeable folk than I have suggested that this is a bad idea) then don't forget to reduce the resistor by a factor of six to compensate (or use 15*6=90mA as the total current for doing the calculation in the first place). You don't have to run them flat out at 15mA if you don't need to, they'll be visible from probably 5mA on up.

Have fun!
Last edited by JamesK on Thu Oct 02, 2008 6:55 pm, edited 1 time in total.
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7