I/O Port speed difference?
Daphyl
Posts: 17
Does anyone know if there is any I/O port speed difference between the BS2 and the BS2p?· I know the processor is much faster, but I can't seem to find any data concerning the 16 I/O ports (if there is a technical site, I would appreciate the link).· Performing the calculations faster won't help me if it's going to bottleneck there.
David
David
Comments
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen
David
·
········ I have a perf board that is 16” long and 6” high.· Believe it or not, over the last year I have soldered and wired 336 individual red LED’s to this board.· They are configured in a matrix of 48 vertical rows of seven LED’s by seven horizontal columns of 48 LED’s (7 x 48 = 336).· All 48 LED’s in each of the seven horizontal columns has the anode wired to one of the seven high I/O ports (creating a common anode) through a 33 ohm resistor, and each of the seven LED’s in the 48 vertical rows are soldered to create a common cathode connected to the collector of a 2N2222 transistor.· The emitter of the 2N2222 is connected to ground.· The base of the 2N222 is wired to the output of a 74LS04 inverter chip through a 10 kilo ohm resistor.· The input side of each inverter chip is connected to one of the 16 outputs of a 74LS154 (4 to 16 demultiplexer chip).· I had to use the 04 chips because the selected output of the 74LS154 chip is always low (the 15 remaining outputs are held high).· Three 154 chips and each chip controls 16 rows, equals 48 rows.· (A small portion of this circuit is at the end of the dissertation.)
· ····
···· ··All of this means that I’m using seven of the eight upper ports with each port driving one column of 48 LED’s.· However by selecting which of the 48 2N2222 transistors, and which of the three demultiplexers is active, only one of the rows of LED’s will be active at a time (meaning each port drives just one LED at any given time).
·
···· Four of the lower I/O ports are used as data selects for the 154 chips to select which one of the 16 outputs will be active. By changing the condition of these four ports and pulsing any of the seven high I/O ports, I can light up any or all of the LED’s in a given row.· And finally by using three more of the lower I/O ports I can also select which 74LS154 chip is active when the seven high I/O ports are pulsed.
·
·· ··The beauty of all this is that with just three variables, two sets of data (one data set to select which of the upper I/O ports to pull high, and one data set for the lower I/O ports), and a dozen lines of code; I can create scrolling messages across the 48 rows of LED’s.
·
·············································· ·······Now to the problem…
·
When I’d pulse the seven upper I/O ports to light the LED’s, for some reason they were all still very dim.· So instead I just pulled the selected ports high. ···
Ex:
READ leds + counter, result··
OUTH result·· (If result is DEC 127 = BIN 01111111, all seven of the LED’s in the row would light up even though they would still be dim.)· By adding a 2 to 4 millisecond pause, the LED’s lite up beautifully.· But the pause (even 1 millisecond) caused the program to slow down so much that the rows of LED’s would flicker.· This made the letters seem to flash across the display in a wave like effect.· A pause beyond 10 milliseconds slows the program so much that one row of LED’s at a time would light up and then turn off before the next row of LED’s lights up.
·
If the ports are fast enough as someone else stated, then the problem is in my program. Here is the program with the letter ‘H’ displayed about half way across the display (each number in control selects the appropriate 154 chip and also tells the chip which transistor to turn on so that the proper row of LED’s will light up:
·
·
·
·
'{$STAMP BS2pe}
'{$PBASIC 2.5}
counter VAR Byte
result VAR Byte
values VAR Byte
leds DATA 127, 8, 8, 8, 127
control DATA 197, 181, 165, 149, 133
DIRS = %1111111111111111
·
main:
FOR counter = 0 TO 4
READ leds + counter, result
READ control + counter, values
OUTH = result
OUTL = values
PAUSE 2·· ‘ This is the problem line!
NEXT
GOTO main
····
·
·
Anyone have any ideas?
·
·
David
· ····························································
·············································· To demultiplexer:
Another key symptom is that if you run it full-speed, the LED's look "Dim", but if you put a pause in there they look full brightness. This implies your power system is unable to handle the load when one row of LED's is 'turning off' while the next row is "turning on".
Note that 48 LED's in one row, at 10 mA per LED, will be pulling 480 mA. You don't say how you're supplying that current, or how the BS2 is controlling that current, but is surely can't be through a BS2 I/O pin. Those are limited to 50 mA, not 500 mA each.
David
Correct me if I'm wrong, but I don't see any latch in the hardware scheme. So, the light output from a 100 microsecond pulse to the LEDs will naturally look dimmer than a 1 millisecond pulse.
One solution is to use brighter LEDs (higher current) for the shorter pulses. That may take a high side driver that can operate at a higher voltage. I don't know, there may be practical minimum for visual perception on the order of one millisecond.
Another solution would be to latch the outputs so the LEDs stay lit until changed. That is quite a different hardware scheme from what you have now with the common anodes and cathodes. Or, a capacitor scheme like the candle effect, to charge a capacitor in parallel with each LED (336 of them!?) to stretch its ON time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
'{$STAMP BS2pe}
'{$PBASIC 2.5}
counter VAR Byte
result VAR Byte
values VAR Byte
leds DATA 254, 16, 16, 16, 254
control DATA 197, 181, 165, 149, 133
DIRS = %1111111111111111
main:
FOR counter = 0 TO 4
READ leds + counter, result
READ control + counter, values
OUTH = result
OUTL = values
PAUSE 2
GOSUB off
NEXT
GOTO main
off:
OUTH = %00000000 ' turns off all I/O ports to clear display before lighting next row of LED's
RETURN
Also, I had thought about using caps, I was just hoping for a way around another 672 solder connections!
David
The way you've done it, the LED's are off for quite some time -- a Next, the next FOR calc, and the two READ's from the eeprom (which can take some time, I believe). But the LED's only need to be off for a very short time.
The program could run faster and avoid the chaotic results if the data is stored as words in one table instead of bytes in two tables, to wit:
'{$STAMP BS2pe} '{$PBASIC 2.5} counter VAR Byte result VAR Word ' <-- word and leds are words, too leds DATA Word $fec5, Word $10b5, Word $10a5, Word $1095, Word $fe85 DIRS = %1111111111111111 main: FOR counter = 0 TO 4 READ leds + (counter*2), Word result OUTS = result NEXT GOTO mainI think with all the ports being set at the same time, there should not be a problem with the timing skew that is created when the Low and High are done by separate instructions. However, like Alan pointed out, putting an OUTS=0 immediately before the OUTS=result would effect a complete break before make action.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
···· The lower eight I/O ports specify which 154 chip is active and which one of the 16 output pins on the 154 demultiplexer chip will be set to high (actually it's set to low, but all the outputs go through inverter chips) to turn on a 2N2222 transistor.· By sequentially turning the transistors on and off and selectively setting the upper ports high, I can scroll a message across all 48 rows.
···· I·hope this helps explain it better.· I tried moving the gosub·as per Allen's suggestion and I was shocked at the difference it made!· The wave affect is gone and now the·LED's twinkle nicely!· His suggestions also made me wonder why I was continually forcing all the·high I/O ports low, when all I had to do was disable the active 154 chip.· So by removing the OUTH statement,·turning off one lower I/O port in the off subroutine, and moving the gosub off statement; I now have a beautiful bright display.· I really like the idea of one data statement and I'm going to try that tomorrow.· Right now the wife is giving me some really mean looks, so I guess I'd better go.
···· By the way, I won two hundred and fifty LED's in a drawing at one of the local electronics stores.· Next time I build one of these I'm going to use 5 x 7 LED·matrix blocks!
Thanks to all for your help,
David Milsop·
This is just a debugging suggestion from someone more familiar with software than hardware, but I suspect it may have some real merit. I would propose that what you are going to eventually find as the source of your problem, is something you said earlier. You said, in part:
"The input side of each inverter chip is connected to one of the 16 outputs of a 74LS154 (4 to 16 demultiplexer chip)."
Check the propagation delay on those mux/de-mux chips, as well as the inverters, and you may find your culprit. It may be most easily seen "graphically" by probing the output(s) with a "silly scope". I highly doubt that you will find that the program (software) or PIC/SX output buffer (Stamp hardware) is hiolding you up.
Regards,
Bruce Bates
Post Edited (Bruce Bates) : 12/30/2006 12:22:28 PM GMT
···· I think I am going to add some buffers/line drivers·to the I/O ports.· When I put my scope on the outputs, I noticed that the voltage on the ports where only getting up to about 2.95v before shutting off.· I'll have to change the 33 ohm resistors too because these open collector drivers pump out a lot more current.
David
The 105 microseconds for the BS2pe is the time that the interpreter takes to execute the instruction. The actual transition at the output is very rapid, on the order of nanoseconds. Setting the outputs in two instructions like this:
OUTH=result
OUTL=values
leaves a 105 microsecond skew where OUTL still has the old value while OUTH has the new value. With this syntax:
OUTS=result ' a word value
the time skew is only a few nanoseconds, due to the different propogation delays through the high side switches and the low side mux.
The output drivers in the Stamp (SX48) are remarkably robust, but their output resistance is on the same order of magnitude as your 33 ohm resistors. Assuming the LED is dropping 1.5 volts, that leaves about 1.5 volts across the 33 ohm resistor, which means the current to the LED is about 45 milliamps. (The effective output resistance of the Stamp pin is (5 volts - 3 volts)/0.045 = 44 ohms and the Stamp is dissipating 90 milliwatts into heat as a result.)
From the SX48 data sheet, the maximum source or sink current on each individual BS2pe pin is 45 milliamps, and the maximum allowable for each 8 bit port (such as OUTH) is 50 milliamps total. But if all 7 LEDs happen to be on at once, then the total current for the port would be 315 milliamps--way over limit! That would not be a problem if it were a 1:48 cycle, but if the whole sign lights up with most of the 336 LEDs lit at once, the total could be very hard on the BS2pe.
I think your idea to add a source driver on the high side is wise. It will both protect the Stamp and also allow for brighter LEDs. For a choice of discrete transistor as a source driver, I really like the LP0701 P-channel mosfet, from Supertex (Mouser carries them). It is a TO92 package that can source up to 1.5 amps in full on, and the gate can be driven directly from a Stamp pin on 5 volt power, low on gate turns the mosfet on. I don't know the ratings of the LEDs you are using. Are they superbrights? It is usually safe to drive LEDs quite hard, when the duty cycle is 1/48. That is, up to a point which should be found on the LED data sheet.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
Thanks again,
David Milsop