SPI Questions

Go To Last Post
19 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've got a 7 segment display working with this driver (TLC5916) and it works great. I am now trying to switch the driver into "special mode" so that I can program the brightness of the 7 seg display.

I can't seem to get my head around how best to go about making the switch. I think it will require manual bit banging of the SPI clock pin and OE and LE pins, but I'm not sure if I can manually change the level of the SCK pin when in SPI Master mode, or if there is a better way to do this.

Can anyone offer some advice? I'm adrift in a sea of confusion right now. Maybe some time away from the bench will help too...hehe...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

why do you want to bit bash the SPI? and if you do, just dont setup the SPI and you will have full control of the SCK pin etc

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't want to bit bang the SPI. In order to switch from normal mode to special mode, the output enable and latch enable pins need to be toggled in a certain sequence in time with the SPI clock (SCK). I'm not sure how to do this. The sck does not operate unless there is data in the out register. I'm also unclear on how fast the SCK operates.

I could really use some help. Thanks guys.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK, looks to me like you hook up power and ground, set the output current with r-ext, hook your leds up to out0-7, connect output enable to a PWM pin if you want different brightnesses or just connect to ground if you want them to always be on. Connect LE to SS, CLK to SCK, SDI to MOSI and SDO to the next chips SDI or back to the uC MISO.

Now that takes care of everything as far as i can see. Now the only difference is that ss goes high when you start talking, and put it low hen you're done sending your data. I haven't read the whole data sheet, or used the chip before so i could be wrong but that's what i gather from page 3, Terminal Descriptions

So looks like all it is is a 595 with current limited outputs?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks nedward. I have the SPI interface working already, that's not the issue. I am having a hard time implementing the switch from "normal mode" to "special mode" as described in the datasheet. In special mode I can set the current gain, and thus the brightness via an internal configuration register.

Although, good idea on using PWM on the OE pin. This is a much better plan B than I had. I was thinking I would have to resort to a simple pot on the Rext pin. Thanks for the excellent idea.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok, i may have another read tonight for you then :) sorry for not understanding the question, my fault :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay, well I've found an issue with my OE pin, so perhaps this is blocking my otherwise successful attempts at getting into "special mode".

Apparently the OE pin on the TLC5916 only goes to about 0.8V when "high" and 0V when low. Strange for a pin that has an internal pull-up according to the data sheet.

Any ideas?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, I fixed the voltage issue on my OE pin and was able to set up PWM on the OE pin of the TLC5916 driver. That's the good news. The bad news is that the LEDs driven by the driver dim for a couple seconds and then go dark. Oscilloscope says the OE pin is being driven appropriately.

So, while I am trying to figure out if the PWM is a good solution, would anyone mind pointing me to some info on general bit-banging techniques?

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry I don't have an answer to your actual question, but I had a quick read through the data sheet, as I found it odd one might have to change modes to utilize all of the functions.

What also struck me as odd is that the header on the data sheet, listing the chip's key features, says that it has a 30 MHz clock frequency. This is also stated at the end of the first paragrah in Description/Ordering Information, directly below the bullet items sited above.

However, in the Absolute Maximum Ratings table it indicates that Fclk Max is 25 MHz.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The challenge with entering "special mode" is that it involves both the SCK pin of the SPI interface and a couple GPIO pins. I have no clue how to toggle the GPIO pins in sync with the SCK pulses. Any tips there would be appreciated.

My only other feasible solution to switch to "special mode" is to turn off SPI on the AVR, bit bang a SCK signal while toggling the two GPIO pins appropriately, then turn on SPI to send a byte to the configuration register, then turn off SPI so that I can bit bang to get the chip out of "special mode". Not really liking the sound of that, but I think I can do it. Never done bit banging before, so I have no idea where to start (to do it correctly).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I finally took a look at the spec-sheet for that LED driver IC. Its interface is so totally botched that there must have been some enormous-volume customer who locked in on the unwieldy nightmare early for TI not to have corrected the design. Kind of like those oddball AVRs that have only twelve I/O pins, but are packaged in 294-pin hairbrushes, 'cause that's what General Motors ordered (I know, I exaggerate somewhat...). I would expect TI to offer a similar part, but with a sane interface that you could switch to; do they?

But, of what use is an LED driver with only eight linearly-programmable current-sink outputs? Do you really have only one seven-segment display to run? 'Cause if you're intending to drive a multiplexed display, you've no business wasting any of the available ON-time power as heat anyway; just control the duty cycle of each package in your muxing sequence, if you want variable brightness.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

krich11 wrote:
The challenge with entering "special mode" is that it involves both the SCK pin of the SPI interface and a couple GPIO pins. I have no clue how to toggle the GPIO pins in sync with the SCK pulses. Any tips there would be appreciated.
You can't do this with the AVR SPI hardware. You would have to throw in additional hardware to synch with the right clock pulses. Not recommended.
krich11 wrote:
My only other feasible solution to switch to "special mode" is to turn off SPI on the AVR, bit bang a SCK signal while toggling the two GPIO pins appropriately,
Yes.
krich11 wrote:
then turn on SPI to send a byte to the configuration register,
Why? If you already bit-bang, why not just continue bit-banging for that byte?
krich11 wrote:
then turn off SPI so that I can bit bang to get the chip out of "special mode".
Just continue bit-banging.

Stealing Proteus doesn't make you an engineer.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Levenkay wrote:
Its interface is so totally botched...

Yeah, I didn't pay much attention to the "special mode" until I realized I would need to dim the displays.

Levenkay wrote:
I would expect TI to offer a similar part, but with a sane interface that you could switch to; do they?

Now that's the best idea yet...hehe...

Levenkay wrote:
Do you really have only one seven-segment display to run?

I have 7, 7 segment displays to run. I was not planning on multiplexing, rather just using the SPI to cascade the displays and just shift in the new values. Not sure I gain anything from attempting to multiplex.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

krich11 wrote:

I have 7, 7 segment displays to run. I was not planning on multiplexing, rather just using the SPI to cascade the displays and just shift in the new values. Not sure I gain anything from attempting to multiplex.
Hmm.. If you multiplex, using external row and column driver ICs roughly the same as the ones you're looking at, you use least five fewer of them. You can save six of them if you have enough I/O pins available on the AVR to let it sink the individual segment currents directly (and the size and efficiency of the displays are such that they're adequately bright on just 4mA of segment current). You have about 42 fewer individual nets to route on the circuit board. The display runs more efficiently at any given intensity, due to persistence effects in human vision (Multiplexed 7::1, each digit gets only 1/7th as much average current, but appears about 1/(sqrt(7)) as bright)

On the "debit" side of the ledger, there are large blasts of switched current flowing through sizeable loop areas, making the display radiate noise. And multiplexing imposes a larger burden on the CPU. The interrupt-driven 7-digit multiplexed, dimmable display refresher I wrote imposes just under a 1% load on the CPU's time (at an 8MHz instruction rate). And the multiplexing service uses one of the AVR's timers (although in my case, the same timer tick is also used for OS scheduling ticks and crude time-of-day accounting). On the whole, I'd expect that the advantages of multiplexing outweigh the disadvantages in the vast majority of cases.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Excellent breakdown Levenkay. I do have a few requirements that would fit the multiplexing scenario. Battery life, therefore average current utilization, is one of them. Very tempting argument.

My application, however, lends itself nicely to modularization and the cascading I can do with shift registers. I am building a medium sized scoreboard. Digits about 6 or 7 inches tall, each with their own LED driver, all cascaded back to a single SPI port on my AVR (currently a mega328p).

My plan is to connect a serial wifi module to the AVR and develop an app for iPhone and Windows Mobile to control the board.

This is a "one off" build, so I need not be too concerned about saving on the cost of ICs.

Interestingly enough, it looks like ST has a similar driver (pin compatible, it seems), that uses a similar switch to "special mode", but is only used for short and over current detection. It states plainly in the datasheet that the OE pin can be driven to dim from 0% to 100%, unlike the TLC5916.

The TLC5916 is still crapping out when driven with PWM on the OE pin. I may make the switch to ST on this project...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't see the problem with 42 extra nets. They all are very local; if you use a sensible component layout of course :)

I think the 5916 gets confused when PWMing the OE as its used for the special mode entry logic. Having SPI and OE activity at the same time coukd mess up the control logic. Try disabling PWM when reloading the data.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good news and bad news.

As is the case many times on this forum, I manage to semi-intelligently discuss a strange problem at length only to find that it's my own inadequacy that's to blame.

So, the simple fix to my PWM problem is to connect the ground pin to ground. Somehow during the breadboarding of my prototype 7 segment digit, the ground connection to the ground pin on the TLC5916 became disconnected. In my defense, it was under the 7seg board and not easily visible. Odd, though, that it even functioned at all.

Turns out that both the ST and the TI chips are pin compatible and both have tested flawlessly when properly grounded. :roll:

Now, leaving "special mode" in the dust, I move on to much more interesting and fun things...serial comms, wifi, and iphones.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This was an absolutely perfect thread! I was just scratching my head on the whole "special mode" thing on a TLC5916 tonight. I MUCH more like the idea of stuffing NOE (Not Output Enable) on a PWM and DIRECTLY control the brightness of the display.

Not having to switch into special mode (after first disabling SPI) with bit banging, sending the byte (bit banging or SPI), reenter normal mode with bit banging THEN reenable SPI so I can start sending character data again... What a pain...

Changing a single PWM duty cycle seems like a LOT easier way to do this! And cleaner too!

 

Clint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

myself wrote:
If he uses the output compare pins for latching and output enable, he can pretty much go nuts with other stuff, and still have it look good.

That's what I advised you to do in the other thread :(