Teensy 3.0 Clock Pins and setup

[Donziboy2]

I'm currently trying to figure out what pins I need to start controlling some TLC5940's.
I need 2 clocks to do it, one for data and one for gray scale (GSCLK). I will be using the SPI clock for data but cannot for the life of me find any information on what pins can be used for other clocks and how to set them up.
I need the GSCLK to be able to reach 20-30Mhz in my final design, but I am finding the 1227 page manual and the small reference manual for the Teensy 3's chip to be of little help.

I am also in search of any information in order to decide if I will need direct port manipulation on at least 4 digital pins. I would like to be able to switch the pins from low to high in less then 1us. Which is under 50 clock cycles at 48Mhz.

Ultimately I am looking to run 4 TLC5940's and control 64 RGB led's, I will be multiplexing them using a design from Matt Pandina. Demystifying the TLC5940
Im shooting to refresh all three colors every 400us or so, about 142us per color.

[PaulStoffregen]

Wow, those are some pretty incredible speeds for only 64 RGB LEDs. Do you really need that? No humans can perceive color changes on those incredible short time scales!

There is a library for the TLC5940, but it currently uses AVR specific registers and hasn't been ported to Teensy 3.0.

The one part of this which is easy is direct I/O on Teensy 3.0. The functions digitalWriteFast() and digitalReadFast() always compile to a single bus cycle operation. You must use constants for the pin numbers.

[Donziboy2]

Reading the datasheet shows that I can run the SCL at up to 25Mhz (24Mhz on 48Mhz main clock?), that should take care of my second clock. Sadly the search function does not generally lead you to the pin assignment page, which actually is of some use....

The high speeds will be because it will be rotating similarly to the 595 version in my Signature. Im hoping for the POV effect.
Each color set has about 428us to complete, I want to leave time for pulling data from an SDcard, or if there is enough process power/ram to actually run an array, but that is where the Teensy 3++ will come in someday
I have from experience learned to shoot faster, and then slow things down as limits appeared. I was shooting for 1000+ rpm's in my 595 version but the hardware was not up to the challenge.

I saw mention of the digitalWriteFast, and ReadFast. I will have to look into them more, I was under the impression the only way to get extreme speed was to natively call the ports.

[Donziboy2]

Paul would you know of a way to switch the SCL pin on? And set its clock rate?
Or any other pins other then SCK that can run at High Speeds?

Also if I code it right I should be able to run each color for about 100uS, at about 11-12 FPS. I will breadboard an LED in a few days and set it up to run for 100uS and then wait the 85ms or so before it would be lit again, and see if it is viewable.

[Donziboy2]

Actually according to the datasheet, the I2S is only good for up to 12.5Mhz, which is to slow... which is the audio bus..... Reinstalling dunce cap, I hate that datasheet.
Guess I need to find a different clock.

[Donziboy2]

Ok, ran the Teensy 3 and a red led and it is visible, it was somewhat dim but I believe it is being limited by the Teensy 3. Even after increasing the on delay to 400uS it was still just as dim, which is the time that same led would have been lit using my 595 globe, and that's with an 8mA limit on the globe and I was using a 10mA limit with the Teensy. And yes the 595 was using 5v and the Teensy is 3.3v.

int led = 21;

// the setup routine runs once when you press reset:
void setup() {                
  // initialize the digital pin as an output.
  pinMode(led, OUTPUT);     
}

// the loop routine runs over and over again forever:
void loop() {
  digitalWriteFast(led, HIGH);   // turn the LED on (HIGH is the voltage level)
  delayMicroseconds(100);               // wait for a 100uS
  digitalWriteFast(led, LOW);    // turn the LED off by making the voltage LOW
  delay(85);               // wait 85mS
}

[PaulStoffregen]

You're turning the LED on for only 100 us, then leaving it off for 85000 us. That's a duty cycle of only 0.12%. I'm actually amazed you can observe any light from it at all.

To appear at normal brightness, you'd need the pulse of current during those 100 us to be 850 times the normal amount. That would be 8.5 amps! That just isn't practical. Most LEDs can handle pulse currents about 20 to 100 times their average, but not 850X.

This is one of the many challenges of persistence of vision applications. If you want a small number of LEDs traveling at high physical speed to paint a huge image, they need to be EXTREMELY bright, because the movement essentially spreads their brightness over a very large area. No amount of software trickery can change this reality of the physical world.

The one nice upside is you can probably use the air flow due to the movement to more easily cool the heatsinks that are required for such incredibly bright LEDs.

[PaulStoffregen]

Here's a project I did a couple years ago with an LED that has the level of brightness you probably need.

http://www.dorkbotpdx.org/blog/paul/...ykles_lightbar

Of course, this isn't a POV project, but you might look at that Avago ASMT-MT00-00001 part. It needs 350 mA of current per color, which you obviously can't get directly from a Teensy pin.

Also, take a look at the heatsink on the back of the PCB, and the pattern of vias just outside the solder area, intended to couple the heat through the PCB to the heatsink. Those little guys got really hot, but they were used for many hours several parties and 2 years at Burning Man, so it's probably just barely enough cooling with natural convection.

[Donziboy2]

The design in my sig is running at 400us per scan line. And I did run it with randoms a few times and it looked plenty bright even in a lit room. And it was only 8mA per channel. The TLC version will be 17-18ma per channel.
I recorded it in a dark room because my camera had a hard time with the lights on.

My biggest challenge is just getting a single TLC5940 running, then I can mount a test unit on my existing frame and see what will work and what wont, if I have to switch to running 12 TLC5940's instead of multiplexing 4 I will, its just a lot more wires.

At the moment I need to figure out where to get my second high speed clock from. And the best way to implement an interrupt counter to that second clock.
Then its just a matter of setting timings.

[Donziboy2]

Doing some figures, using different bit settings for grayscale clock(GSCLK) I get.
Here are clock minimums and would need a timer or interrupt to the BLANK pin at the end of the pulse count cycle.

At 700 RPM and 192 scan lines. These are using 140us per color
4MHz for 9 bit/511 pulses. <This is a nice minimum, that's plenty of colors.
8MHz for 10 bit/1023 pulses.
15Mhz for 11 bit/2047 pulses.
30MHz for 12 bit/4095 pulses.

Im sure there is a clock I can steal from something that is only 4MHz? Along with a timer that will trigger the reset after 511 pulses? Providing it can be done in parallel with the SPI data.


Im still hoping to multiplex this, if it has to be done with 12 TLC's it would greatly increase PCB costs. x3 along with the cost of six 32 pin ribbon cables...
Here is my current PCB design, 35x400mm or 1.38x15.75 inches. This will not be a globe, but a tube shape. And this would have more then one use, im sure you could have fun with a battery and a small handle.

[PaulStoffregen]

Im sure there is a clock I can steal from something that is only 4MHz?

On Teensy 3.0, you can use analogWriteFrequency(). Details are here:

http://www.pjrc.com/teensy/td_pulse.html

[Donziboy2]

Doh, I looked over that the other day and dismissed it, guess I should have read a little more.
Awesome I will play around with that after work.

[Donziboy2]

Thanks Paul after a few minutes of fiddling I was able to get a 25MHz clock signal from Pin 3

SPI and pin 3 running at 25Mhz.
Top is SCK, second is DOUT, last is pin 3 PWM.


If I set it for 15Mhz i get 16.66MHz which is good enough to run 11 bit/2047 pulses per color.
One step closer.

[Donziboy2]

Still tinkering, was checking out digitalWrite and digitalWriteFast and OMG!! doing a high and then low with digital write creates a 675nS pulse, digitalWriteFast High and Low creates a 45nS pulse!!! And in some cases its 15ns!!

Having the logic sniffer really makes it easy to see what actually happens to your output signals, having several pins running an IC like the TLC5940 really makes timing important.

void loop(){
  
  
analogWrite(GSCLK, 128);
spi_send_bytes(gsData, len);

analogWrite(GSCLK, 0); // Turns off GSCLK 1uS before SPI finishes, based on test data
digitalWrite(XLAT, HIGH);
digitalWrite(XLAT, LOW);
delayMicroseconds(10);

}
   
void spi_send_bytes(uint8_t *data, int)
{ 
for (int i=0; i < len; i++)
SPI_WRITE_8(data[i]); 
}