hamster

Fix for LogicStart 7 segment ghosting>

Recommended Posts

If you have a problem with ghosting on the the LogicStart's seven segment display, check that the Vcco jumper (a group of three just above the FPGA) is set to 3.3V. When set to 2.5V the display doesn't work very well at all.

 

Also, try to not switch directly from digit to digit, but have a bit of quiet space between them - the displays are bright enough when  a digit is displayed only 25% of the time.

 

post-29509-0-30905500-1360164509_thumb.j

Share this post


Link to post
Share on other sites

FYI, the wishbone core I wrote for the 7 segment is able to control brightness using a 16-level PWM. With an ambient light sensor you can eventually make its brightness optimal.

 

Alvie

Share this post


Link to post
Share on other sites

As I just got done slaying a ghosting bug moments ago, I'd like to add to this cautionary tale...

 

In the example I'm working on with the Papilio Pro, I've got a few clock-driven VHDL processes in action: one for PWM-style blanking on the order of 16 KHz (for dimming), one on the order of 64 KHz to handle display refresh/multiplexing, and one to simply clock the sample data (10 Hz). Each clock was derived separately from the master clock - nothing fancy, and no odd warnings (no gated clock warnings or such). Besides signals for I/O, the intermediate counters and states were mostly defined using variables and constants.

 

Despite all this effort, I kept getting some faint but very definite ghosting coming from each adjoining digit (driving this in reverse digit order also reversed the direction of the ghosting. I was even careful to blank the anodes first thing in my refresh process, before updating the anode counter and the data pointer!

 

I tried cramming all three clocked processes into one process... it didn't change a thing.

 

Then I remembered something I'd previously read: a given process doesn't update I/O signals until the entire body of that process is executed. So my attempt to blank the display before updating it had no effect whatsoever - the end result was that I was, for one clock cycle for each digit, displaying the previous digit's data using the next anode's index. Voila! The bug behind the ghosting was revealed. (And it'd have gotten away with it too, if not for those meddling FAQs!)

 

To fix the ghosting, I added a "settling" counter/toggle that blanks the display for one refresh cycle after switching to the next anode. This also has the effect of adding a bit of dimming (in addition to the separate dimming process I have in place). Note: even with all other dimming code disabled, making this one change eliminated ghosting... I tend to use an on/off duty cycle so my blanking comes after a short "on" period. It's good to have that "quiet space", but particularly before and immediately after changing to the next anode, particularly if you're doing that within a process block

PS: If you ever try blanking (dimming) in one process and refreshing in another, or even in the same one, it's evidently wise to have the refresh clock at least n times faster than the blanking clock. Otherwise, you can encounter all sorts of vexing display artifacts (e.g., some digits stop turning on all the time). Looks kinda cool, IF that's the desired effect (it's usually not).

 

tl;dr - Ghosting may be caused by code side-effects - when processes are involved it's easy to forget that signal settings (e.g., for anodes) won't get updated until AFTER the process is done.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now