On 15 Sep 97 at 18:44, Martin R. Green wrote: > Ok, there's a couple of fairly simple calculations that will tell > you what you need to know, but Microchip is being a _wee_ bit > optimistic. > > For maximum brightness, to minimize I/O load on the PIC, and to get > the best efficiency from the driver transistors (discreet or in the > PIC), you should use the longest character on time you can. All > LED's should be sequenced in less than 1/30 second to avoid flicker > (a few rare people can detect flicker at this high rate so you might > want to use 1/40th or 1/50th sec. instead). Now divide that value > by the number of LED's and you have your scan time per character. > For instance, if you have eight 7 segment LED's, and you want a full > scan in 1/30th of a second, each character should get 1/240th of a > second. At this speed, given a reasonably normal clock speed, you > will have oodles of time to process other stuff between display > servicing calls. > > Note that because you have to write the character PIC port > separately from the segment port, you may get some segment "bleed" > due to the short time that the segment outputs from the PIC are for > a different character than the character output from the PIC. The > simple solution for this is to write a 0 (or FF, depending on CA or > CC LED's) to the segment port to blank the display just before you > write to the character port. Then write the character port, > followed by the new value for the segment port. Voila, no more > bleed. This applies to other multiplexed display types too, such as > VFD's. > > As for current, there are two parts to this, one for LED current, > and one for PIC drive current. > > In general, to get a multiplexed LED to display the same brightness > as a direct driven LED you should overdrive each segment by the duty > cycle of the scan. That is, in our 8 LED example, if the LED > display the brightness you need at 20mA per segment when driven > directly, then you need to drive it at 160mA per segment to get the > same brightness when multiplexing, since each LED is only on for > 1/8th of the time. In my experience, LED's seem to be able to take > this low duty cycle overdrive with no problems, but if you are > squeamish about it, you can edge the calculated current down a bit, > but be aware you may not get the brightness you need. > > The other side to the current equation is the PIC drive > capabilities, and this is where there are a couple of gotchas. Each > PIC port pin can source 20mA and sink 25mA, so you can see from this > that using our calculated drive current of 160mA per segment is > going to be optimistic at best. I have no idea whether the maximum > values specified by Microchip are affected by the duty cycle, > probably a bit, but even at low duty cycles, sinking 160mA into a > PIC port may be pushing it. This of course doesn't even account for > the character driver port, which must be able to handle the segment > current times the # of segments. In our 7 segment example above, > each character could draw up to 1120 mA, albeit at the 1 in 8 duty > cycle. > > So you can see why Microchip specify a maximum of 7mA per segment in > the direct drive multiplex example application notes. You have to > use some pretty small and efficient LED displays to get adequate > brightness at 7 mA per segment, especially at low duty cycles. > > The other big gotcha, that is not obvious in the PIC specs is that > although each port pin can source 25mA, the total for _all_ pins is > 50mA, which really limits the real world drive capability of a PIC, > IMHO. That 7mA per segment restriction in the app notes takes this > into account (7mA time 7 segments = 49mA). > > So you can see why, IMNSHO, despite Microchip's examples, it is not > really practical to drive a multiplexed LED display directly from a > PIC, at least not the character drive anyway. You can probably get > away with driving the segments directly, and driving the characters > via transistor or other buffers, but this will require fairly > efficient or small LED's. Good coverage of led muxing. What do you think of the idea of muxing even *faster*, and driving only *one* segment at any one time, at the absolute max currents? That wouldn't violate the pin or package limits, but would increase s/w complexity. MikeS (remove the you know what before replying)