Transistor Mosfet pairs to drive LED cube layers

[KrisBlueNZ]

Yeah, the Si2333DDS-T1-GE3 is one of those. But it's a P-channel MOSFET running from 5V and the signal is 3.3V/0V.

 

[rjamjb]

Update

Just thought I'd give an update. Given the huge help that I've had here, I'll post an update every so often on this, even if I don't have any question - some pics too at some point just to keep you appraised!!

Just got three TLC's and 48 leds (3 x 16 RGB LEDs) cascaded on a breadboard and bitbanging is quick enough to provide POV. Now going to cascade another three and trial a software shortcut I thought of - bit banging the rgb colors simultaneously to reduce processing time in my ISR (actually need 4 for each color but the breadboard isn't quite long enough for four and I' ve only got 2 breadboads) - this should give me six TLCs and I shall see if bit banging is fast enough by rough extrapolation for the twelve that I'll need in the final board. (If not then I'll move to SPI but bit banging is a lot easier to program). Anyway I shall see. In the test I'll need to program a duty cycle of 7 off to 1 on states to replicate the PoV situation on the final cube.

I got delivered today TC4467 driver ICs and SI2333DDS mosfets SOT23. The latter do seem a bit bigger than the previous mosfets and, now that you've given me a bit more confidence I shall have a go at soldering together the switch circuit. Reading the data sheet for the IC drivers indicates that the circuit for these driving the mosfets should be fairly straight forwards. However, I'll draw up a schematic first as I'd like an opinion before I commit to soldering onto a board. Hope that's ok?

Still not started the actual cube yet - it is still very cold in my garage - but will head off to buy some wood for the jigs at the weekend.

Russell

 

[rjamjb]

Ok, here is my circuit. According to the truth table for the TC (focusing only on inputs 1, 2 and output 13) if 1 is high and 2 is low then output 13 is high. Therefore hook 2 directly to ground and when my chip provides a 3.3V high then output is high.

So, couple of questions about the circuit - is there any need for the resistors 1 to 4? seems that the current flow here will be negligible so are these needed.

Is there any need for Cap C5 - I'm copying the Cap from one of the earlier proposed schematics - if so what value.

Obviously this is for 4 switches so I'll need to duplicate for all 8 switches with my second TC4467

Does this work?????

 

[rjamjb]

EDIT - just realised mosfets connected incorrectly - will redo schematic

 

[rjamjb]

Here is the updated circuit

 

[BobK]

Deleted, didn't read the circuit correctly.

Bob

 

[rjamjb]

What's the issue Bob? - Can't you read the pdf's?

 

[BobK]

No issue except my stupidity. I thought you were driving the gate with 3.3V, but you are not.

Bob

 

[rjamjb]

Another edit - I just realised that when 1 and 2 are both low then output is high. The way I've got this connected then there will always be a permanent high from the output 10. I will need to connect all the inputs 2,4,6,9 to high to give me the logic I want.

Sorry about this I will need to re-draw another schematic.

 

[rjamjb]

... and there you go, hopefully the finished item.

 

[KrisBlueNZ]

That's looking pretty good.
I have some suggestions.

1. Your circuit should define the active and inactive states for input signals. For example, "3.3V = enable; 0V = disable" (or the other way round; I'm not sure).

2. Re the decoupling cap across the IC, yes it's needed; the data sheet should have recommendations.

3. Gate resistors yes, say 10 ohms to limit peak current to 0.5A sink, 0.5A source. ANYONE ELSE have opinions?

4. It might be a good idea to enforce gaps between the enable pulses; this may be wanted anyway, to prevent ghosting.

5. DOES ANYONE THINK it's worthwhile adding pulldown resistors on the MOSFET drains? I don't think there's any point; leakage and capacitances won't be an issue. In any case, a good sequence for firmware to use at each multiplex phase advance is:

During multiplex phase: calculate new pattern data for next slice; load new data serially into the cathode display driver ICs; wait for multiplex phase advance signal (see below); turn off anode drive control signal for current multiplex phase just ending; delay ~1 us (a few NOPs should be enough unless you're using a very fast MCU); disable cathode drivers (if this can be done quickly and globally through a single I/O output from the MCU); transfer new slice data from holding latches to LED drivers within the cathode driver (I assume the TLC whatever can do this; check the data sheet); enable the anode driver for the new slice just starting; enable the cathode drivers globally.

Re timing. There are many approaches. Would you like me to describe them? Are you happy with the scheme you've worked out?

Have you tried calculating a rough bit-banging rate using instruction timings? Are you writing the bit-banging loop in assembler?

Thanks for keeping us involved

Edit: Another comment: I don't think the capacitors on the input signals are appropriate. As long as the driving microcontroller pins are always set as outputs, nothing else should be needed, and capacitors will delay signal state changes.

 

[rjamjb]

Will place the logic on a revised circuit when I get back home later including the following items. A couple of points raised.

Timing test circuit per the data sheet shows both a 1uF film capacitor and a 0.1uF ceramic capacitor between VDD and ground so will go with these values. There is also a 470pF cap between outputs and ground. I don't have the latter cap on my circuit, would this be needed?? - seems like it might actually slow down rise/fall times on the outputs, probably something I'm missing.

Also per the datasheet there is an output gate resistance between 10-15Ohms. Does this mean I can do away with the proposed gate resistors?

I think that you are right on the delays, from reading other sites on led multiplexing ghosting can be an issue and creating a few mops delay between cube-off and latching the next data set in seems to be a cure.

Timing - rather than do a lot of calculations I'm cheating a bit with the timing. I've created an ISR where the update of the chips takes place. This ISR gets called and reset based on a timer variable. I've already got an update function working within the ISR for my three-chip/six-chip breadboard test. This will need to be expanded a little to cater for all 12 chips. I intend to gradually reduce the time variable (so the ISR gets called faster and faster), rerun the code each time and then check that the updated time still work at each reduction. At some point the time variable will be so small that there is not enough time in the ISR to do the full update and at this point I will have the ISR down to the minimum possible time to execute all its code.(this is kind of assuming that the code gets executed under the time for PoV in the first place). Per an earlier point of yours the max update that the led driver chips can take is 30MHz which is less than the clock speed of the chipkit (80MHz) so that is the limiting factor.


I'm writing the code in c. However instead of using standard in built functions I'm using direct port and register writing to update the chipkit pins eg SET/CLR/LAT and bitwise functions eg << and | to read/write and fetch data etc. I think that this is about as close to assembler I can get without actually writing it. I'm teaching myself programming as I go along which is why it took so long to get the ISR working but there is a good programming flowchart on the TI website for the TLC5940 which helps a lot and which I've used for the code I've written already. (I'm not a complete novice I used to be fairly proficient in Basic programming back in the day (BBC micro, ZX spectrum etc!!!!) and the principles aren't that different) Bit of a clue on a range of age for me there!!!!!

One thing I did notice - the high inputs to the IC in my circuit are all hooked to the 5V supply. I think that they should be hooked to the 3.3V supply?? I will correct this when I revise the circuit later.

 

[KrisBlueNZ]

There is also a 470pF cap between outputs and ground. I don't have the latter cap on my circuit, would this be needed?? - seems like it might actually slow down rise/fall times on the outputs, probably something I'm missing.

If you're talking about the switching time test circuit, this is not an application suggestion; it's the test setup for measuring the device's performance operating into a capacitive load. (A MOSFET gate is a capacitive load.) So they don't intend you to use a 470 pF capacitor in a practical application circuit.

Also per the datasheet there is an output gate resistance between 10-15Ohms. Does this mean I can do away with the proposed gate resistors?

Yes. I don't think you'll need them. One application circuit (in the Microchip data sheet) for an H-bridge shows no external components in the drive circuit for an N-channel MOSFET, but there is a series resistor with a diode across it in the drive for a P-channel MOSFET. This is probably done to prevent shoot-through (short overlapping conduction in both devices at the switching time), which is not relevant to your application. So I don't think you need any external components in this application.

I think that you are right on the delays, from reading other sites on led multiplexing ghosting can be an issue and creating a few mops delay between cube-off and latching the next data set in seems to be a cure.

Right.

Timing - rather than do a lot of calculations I'm cheating a bit with the timing. I've created an ISR where the update of the chips takes place. This ISR gets called and reset based on a timer variable. I've already got an update function working within the ISR for my three-chip/six-chip breadboard test. This will need to be expanded a little to cater for all 12 chips. I intend to gradually reduce the time variable (so the ISR gets called faster and faster), rerun the code each time and then check that the updated time still work at each reduction. At some point the time variable will be so small that there is not enough time in the ISR to do the full update and at this point I will have the ISR down to the minimum possible time to execute all its code.(this is kind of assuming that the code gets executed under the time for PoV in the first place).

Personally I would check the feasibility now, instead of going with an approach that may prove to be impractical for the final system. I would rather be confident from the start.

You can estimate the percentage of time currently spent in your ISR by toggling an I/O line high at entry and low at exit, and measuring the voltage on that I/O line with a DC voltmeter. If VCC is 3.3V then the percentage of time spent in the ISR will be 100 x measured_voltage / 3.3. For example if you measure 1.65V then your MCU is spending 50% of its time in the ISR.

Per an earlier point of yours the max update that the led driver chips can take is 30MHz which is less than the clock speed of the chipkit (80MHz) so that is the limiting factor.

It's only the limiting factor if you can clock the data out at more than 30 MHz using bit-banging. I wouldn't assume that an 80 MHz MCU can bit-bang SPI at 30 MHz. It will probably be a lot slower.

Another important thing to consider is the structure of the cathode driver data. You may be able to improve your bit-banging speed by structuring the data in memory in a different way.

I'm writing the code in c. However instead of using standard in built functions I'm using direct port and register writing to update the chipkit pins eg SET/CLR/LAT and bitwise functions eg << and | to read/write and fetch data etc. I think that this is about as close to assembler I can get without actually writing it.

If it turns out that an ISR written in C can do all the bit-banging with lots of time to spare, then that's fine.

I'm teaching myself programming as I go along which is why it took so long to get the ISR working but there is a good programming flowchart on the TI website for the TLC5940 which helps a lot and which I've used for the code I've written already. (I'm not a complete novice I used to be fairly proficient in Basic programming back in the day (BBC micro, ZX spectrum etc!!!!) and the principles aren't that different) Bit of a clue on a range of age for me there!!!!!

Wow, you're keen!

One thing I did notice - the high inputs to the IC in my circuit are all hooked to the 5V supply. I think that they should be hooked to the 3.3V supply?? I will correct this when I revise the circuit later.

In the Electrical Specifications summary, the "Logic 1 input voltage" is specified as anything between 2.4V and VDD, the positive supply for the IC, so either option will work. I would leave them connected to VDD.

Edit: EinarA, rjamjb wants the MOSFETs to switch as quickly as possible, hence the MOSFET driver IC.

 

[rjamjb]

Thanks for all of that. I've attached the schematic for the switches together with the switching logic. In hindsight probably should have gone with the 4468 variant as the logic is currently inverted (i.e low output from chipkit turns anode layers on and vice verse). Not a problem just an extra thing to keep in mind when programming.

You have persuaded me to have a go at checking the timing. I have an o scope I bought when putting my router together (was having problems with creating a charge pump circuit using a 555 IC) and this helped me sort it out. So can measure fairly accurately.

I shall have a go at measuring the timing by using the ISR to toggle an unused pin either side of my code.

Not sure if this is the right forum for this [let me know if I should move out to the programming forum - I'll maybe be asking a few questions there if I get stuck!!!) but here is the current state of my ISR for what its worth - this actually works. I know that there are a few timing improvements that I can make and this is a smaller scale (as it is used just for the small scale set up I've got I can scale up the number of TLCs to 12 and then this is what I'll try to measure - (NB the various activities like setLow/setHigh etc are really the following #define setHigh(port, pin) ((port) |= (1 << (pin)))


void __ISR(8,IPL4) Timer2handler(void) {
uint16_t firstCycleFlag = 0;
if (outputState(VPRG_PORT, VPRG_PIN)) {
setLow(VPRG_PORT, VPRG_PIN);
firstCycleFlag = 1;
}
uint16_t GSCLK_Counter = 0;
uint16_t Data_Counter = 0;
setLow(BLANK_PORT, BLANK_PIN);
for (; {
if (GSCLK_Counter > 4095) {
setHigh(BLANK_PORT, BLANK_PIN);
pulse(XLAT_PORT, XLAT_PIN);
if (firstCycleFlag) {
pulse(SCLK_PORT, SCLK_PIN);
firstCycleFlag = 0;
}
break;
} else {
if (!(Data_Counter > TLC5940_N * 192 - 1)) {
if (gsData[Data_Counter])
setHigh(SIN_PORT, SIN_PIN);
else
setLow(SIN_PORT, SIN_PIN);
pulse(SCLK_PORT, SCLK_PIN);
Data_Counter++;
}
}
pulse(GSCLK_PORT, GSCLK_PIN);
GSCLK_Counter++;
}
IFS0CLR = 0b0000000100000000; // clear timer 2 interrupt flag
}

 

[KrisBlueNZ]

The diagram in the PDF is incomplete - it's too wide for the page.

The P-channel MOSFETs are activated by a LOW voltage on their gates, so the inputs to the driver IC are active-high, not active-low.

My suggestion about marking the signal states was simply to note "3.3V = enable, 0V = disable" next to the four input signals. Also you should remove the capacitors from the input signals to ground.

I'd be interested to hear the results of your speed testing.

 

[rjamjb]

The P-channel MOSFETs are activated by a LOW voltage on their gates, so the inputs to the driver IC are active-high, not active-low.

Ahhh, that's a definite "Doh" moment on my part - I went through all that logic to end up with P-channel as opposed to N-Channel when I originally came up with my first schematic - thank you for pointing that out - definitely have the right IC then. Thanks for that.

Will look again at the pdf - seemed to work ok previously (probably user error!!). You seem to be able to post a schematic directly into your updates

Speed testing - the code that I have executes in 1,360uS, I can definitely cut some out of this (currently colours held in 16 bit but the chip only requires 12 bits per colour for example) but will have to add some more code to deal with the three colours separately. Also some code to change layer's but this will be small compared with the 60 leds x 3 colours x 12 bits for the main updates to the chips.

So.... the fact that exists is that current code is 1, 360us per update - Where do I go from here??

 

[rjamjb]

Post my own reply here for consideration.

1 update of a layer = 1,360uS, need 8 updates for the whole cube. Therefore the whole cube is turned on in total time of 8 x 1360uS = 10,880uS.

10,880us = 10.9mS = 0.00109S

If working frame rate is 100hz = 0.01S then the 0.00109S should be very adequate... Is my logic correct

 

[rjamjb]

One other point that I did want to check on the ICs. I had thought that I should keep the highs to each of the inputs at the same voltage. For example (for inputs 1 and 2) if I would have a high of +3.3V on input 1 and if I then needed a high on input 2 then I should also use+ 3.3V. Now, the way that this is set up then I will have a 5V high on pin 2 and then a high of 3.3V on pin 1. Reading through the datasheets (which don't mention anything other than a range of Vs )and your comments this seems to be ok and will work. Just curious that's all.?? (i.e if the high's are at different voltages then the logic will still work)

 

[rjamjb]

Revised schematic - why take away the input decouple caps?

 

[rjamjb]

Bye the way - the suggestion with the voltmeter measuring the average current. That is an excellent trick - does it really work?. My volt meter, while digital and quite accurate (and very budget basement!!) seems to take a little while to update to changes in voltage/resistance, I think this would hamper any average testing like suggested.