Writing a Quad 7segment driver, input needed on dimming
rwgast_logicdesign
Posts: 1,464
Since ive gotten into the propeller Ive basically been doing all hardware work and just following some code tutorials here and there. Its about time I sat down and got serious about writing code for the propeller.
I want to start by doing something I believe should be relatively simple. I would like to write a driver for a Quad Digit 7 segment common anode LED display. I would like to write it in Spin, C, and PASM. I figure the Spin and C versions shouldn't take me to long at all, this is really an exercise to get acquainted with programming drivers and learning PASM.
Now i figure it should just be a simple interface that you can call and pass a character and position to, so basically one function like sevenSeg(1,3) would display 3 in the third digit. It should also have a function to clear characters and another to turn the colon on and off. The whole thing just seems like a super simple interface which is very nice for the end user only having 3 functions to drive a peace of hardware
. But I was thinking I would like to go the extra mile here and implement a way to set the displays brightness. At least in the final project.
Now being a fairly huge hardware newb, Im wondering what is the standard practice to do this? Im thinking of going the PWM route, but im not sure if something like that is standard practice and if it would break compatibility with other seven segment displays (Im assuming almost all common anodes have the same pin out, and as far as lturning digits off and on most drivers will work with any display?) Im not to sure about all the details about PWMs work yet, I just know they can dim the display via there frequency, slowing the pulse dims the display right? What concerns me is can a pwn burn out an LED it was never meant to drive?
My second idea to dim the display is to use a some readily available ds1809 100k digital pots... now this seems like a bad idea becuase im requiring an extra chip to get the dimming functionality... Come to think of it this way really doesnt sound all that appealing at all but maybe it is the right way to do things? Im really new to all this so I just dont know what good practices are and what is genrally the better way of going about things. The digital pot seems horrible to me but maybe from a hardware perspective its playing things a little safer?
Any input you guys have on this would be great. Im sure there are 7 seg drivers out there already but i like to reinvent the wheel!! No, no like I said its purely academic, this is just a starting point for me to start writing code to connect with hardware and hopefully learn what passes for good practice while doing it.
I want to start by doing something I believe should be relatively simple. I would like to write a driver for a Quad Digit 7 segment common anode LED display. I would like to write it in Spin, C, and PASM. I figure the Spin and C versions shouldn't take me to long at all, this is really an exercise to get acquainted with programming drivers and learning PASM.
Now i figure it should just be a simple interface that you can call and pass a character and position to, so basically one function like sevenSeg(1,3) would display 3 in the third digit. It should also have a function to clear characters and another to turn the colon on and off. The whole thing just seems like a super simple interface which is very nice for the end user only having 3 functions to drive a peace of hardware
. But I was thinking I would like to go the extra mile here and implement a way to set the displays brightness. At least in the final project.Now being a fairly huge hardware newb, Im wondering what is the standard practice to do this? Im thinking of going the PWM route, but im not sure if something like that is standard practice and if it would break compatibility with other seven segment displays (Im assuming almost all common anodes have the same pin out, and as far as lturning digits off and on most drivers will work with any display?) Im not to sure about all the details about PWMs work yet, I just know they can dim the display via there frequency, slowing the pulse dims the display right? What concerns me is can a pwn burn out an LED it was never meant to drive?
My second idea to dim the display is to use a some readily available ds1809 100k digital pots... now this seems like a bad idea becuase im requiring an extra chip to get the dimming functionality... Come to think of it this way really doesnt sound all that appealing at all but maybe it is the right way to do things? Im really new to all this so I just dont know what good practices are and what is genrally the better way of going about things. The digital pot seems horrible to me but maybe from a hardware perspective its playing things a little safer?
Any input you guys have on this would be great
. Im sure there are 7 seg drivers out there already but i like to reinvent the wheel!! No, no like I said its purely academic, this is just a starting point for me to start writing code to connect with hardware and hopefully learn what passes for good practice while doing it.
Comments
You have not said how many pins your Quad display has ?
Common is one line for each digit, and common segment/dp pins. ( so 4+8 )
You drive each Anode line one at a time high, and output that digit's segment info.
The Hi drive path needs to source all segment currents, and at the peak-drive level.
So already right there, you have a duty cycle and a digit scanner
- and yes, if it 'stalls' on one digit, that digit has 4x the average drive it was expecting. Usually ok for short time.
You can apply another PWM on top of this one, but you may prefer to just add some expanding 'none on' time, which then means you just need to keep above a flicker-effect frequency.
A short (some us) none-on inter-digit blanking time can be needed anyway, if you use moderate switching speed devices, with softer drive for less RFI.
OR, some designs use a variable supply for the LEDs and apply analog dimming, often this has a very low cost, if your LED supply already has a separate regulator path. Analog DAC output from a Prop is easy.
Please see http://obex.parallax.com/objects/876/
This is my seven segment driver that can be set for common anode. It has a variable that can be adjusted to provide dimming. (you increase the refresh rate really high and it essentially lowers the duty cycle).
There may be some good pointers in there for you. It does up to 8 digits as is and does numbers and letters. It is written entirely in spin, but should give some pointers on prop operations re: timers and the like.
Have fun.
Ok so first of all thank the both of you i appreciate it!!
@Invent-O-Doc
Hey your driver is amazing man it has soooo many features for such a simple piece of hardware lol. This thing is by far going to help out. I would have never even thought of adding some of the functionality you have In there!!! I probably still wont, I guess I figure if you want to do all that stuff you should probably get something other than a 7 segment based display
@JMG
Thanks man, as usuall your post is a bit over my head and knowledge but usually after I read your answers after a bit more research they make a little more sense
Im also curious about some spin and driver practices in general. I figured id define all my pins and segments in the cons section #1 because in most language a precompiled constant is a lot more effiecent than a variable, and two if I base the rest of the code of the constant names pins can be adjusted and added easily by adding more constants or changing them. It also seems to me I would want to leave the usual PLL stuff out of a generic driver correct? This a way the users code calling the driver would be controlling the clock.
Also is there a DOC or AppNote im missing about good spin techniques? There are so many good books for C on the PC like code complte, better c, yada yada that teach you good practices and tight optimizations. For instance (I know on the PC this is long gone and any compiler will write the tighter ASM) is bit shifting saving cycles over division in Spin? To types like byte actually matter (im confused about this) or is that just for the coders convience, and everything is a long in reality? Id really hope theres some kind of document out there to help a spin newb code in the best way possible, Im writing in a new language on a new architecture im not sure how much acually carrys over from the c world but I like to write nice clean code optimized to the best of my ability's, Im sure learning PASM will teach me this as x86 asm did, but im really hoping there is a something out there to get us Spin newbs rolling out clean fast code, at least the ones who care!