how Tadya can sell them for $1.25
Hi John,I see . It's ok with leds . We did pulse testing on such leds.But it will increase the decay of light a little bit . You can try an samples .
Frequency is 1.0hz .1 time per second. We tested 3 monthes . And if leds ok . then we use the chips.
Hi John,No . 30mA is the max current .150mA will burn the leds.If need 150mA . You should use 0.5W
So pulses at a frequency of 100Hz or more actually appear brighter to the eye than a continuous light of the same average intensity.
So running the LED for half the time only loses a quarter of the perceived brightness, and you could go down to 1:7 ratio before losing half the perceived brightness.
Why not use thirteen TPIC6B95s as the column drivers and eight P-channel mosfets as the row drivers?
I have used SPI and each driven chip needs a chip select input ? So if I need 24 chip selects I could do that with 3 CD4017s and one clock pin of the arduino ?
If the receiver detects an interrupt ( I am hoping it is only when a message arrives ) it will presumably disrupt the display refresh?
I am also trying to get my head round the array to store the data in. It used to be a binary byte for the 7 seg , which I just called up for shifting out the data for each digit.Now I must send out the right byte pattern for the top row of the number for each digit, latch it in, then load the second row, and so on ?
I am going to write a sketch to run this one display to show a couple of letters, using shiftout for now, if anyone has some pointers I will appreciate it .
You don't need 24 chip selects, you can daisy=chain the TPICs from the SPI pins just like you do with ShiftOut. So one CS pin for all the TPICs.
Or, if you can afford to wait a few microseconds before servicing the interrupt (which depends on whether the receiver can buffer incoming data), then you can disable interrupts while you send data to the TPICs.
Use an array with 8 bytes per 8x8 display, one byte for each row. Shift out the bytes for the rows you want to update.
Can I send out 24 bytes in one go while the CS is low, and then raise it to latch the data?