Communicating with a TLC5947

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

Hi Guys,

 

I wonder if some kind soul could point me in the right location with the above.

 

I've designed a board with an Atmega328P and a TLC5947.  I tested this using the Adafruit5947 library and it works as expected.  So far so good.

 

I now want to replicate the functionality with native C code using Studio 7.  The board uses MISO/MOSI etc ports for ISP programming.  The Arduino code allows you to use any of the digital ports to send the serial data to the TLC.  Having read a number of posts on this subject in the forums, it would appear I need to bitbang the ports.  Is this correct?  If so, the code I've looked at seems fairly complex, yet the Arduino lib just seems to fire out the data to the TLC via digital writes.

 

Would it be better to redesign the boards and make use of native SPI (hate to ditch the boards though) or is it a fairly simple thing to do (Arduino code was adequate speed wise)?

 

Any guidance would be appreciated

 

regards

 

This topic has a solution.

 

 

Last Edited: Tue. Dec 1, 2020 - 08:12 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!

 

No, you do not need to bit bang the ports.  you can use the same SPI pins for communicating with the TLC5947 that are also used for ISP.

 

Lemme look in my files.  I might have something as I have used that part in the past

 

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

The OP seemed to suggest that the current board layout DOES NOT have the slave connected to the standard TWI pins, perhaps because Arduino seems to allow the use of any pins. 

 

For the original poster, nikm, if done smartly, bit-bang can be almost as good has hardware interface at standard I2C speeds. A library with very high reputation is the Fleury I2C master code. As I recall, it provides either the built-in TWI/I2C or a bit-banged version that can be used on almost any pins. Check

 

http://www.peterfleury.epizy.com...

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

ka7ehk wrote:
DOES NOT have the slave connected to the standard TWI pins,

 

Where does it say anything about TWI.  TLC I see plenty though....

 

And teh TLC5947 is an SPI device for comms...

 

East Coast Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

I was getting a little excited there for a mo smiley, but yes sadly Jim is correct it's SPI. That said you are also correct, the current board connects to the TLC's with ports that are not SPI specific.

 

regards

 

 

 

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

My bad... Sorry

 

SPI is even easier to bit-bang than TWI. There are also a fair number of libraries around. Some even have software implementations. Just google: AVR SPI library  

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

nikm wrote:
Would it be better to redesign the boards and make use of native SPI (hate to ditch the boards though) ...
fyi, mega328PB adds a second SPI that's shared with TC3 and 4 ADC signals.

AN_42559 AT15007: Differences between ATmega328/P and ATmega328PB

 

"Dare to be naïve." - Buckminster Fuller

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

I looked at the code I have and I don't think it will be of much use for you as it uses the SPI engine rather than bit-bang.  I also noticed that there is no commenting in it which will make life difficult to understand as well.  Surprised as a fellow freak came up with this snippet for me a few years ago.

 

As said, bit bang SPI is not a big deal.

 

Also remember that the control for each LED is 12 bits, and you need to update ALL the leds EVERY time you want to make a change.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
/*!
 *  @file Adafruit_TLC5947.c
 *
 *  @mainpage Adafruit 24-channel PWM/LED driver
 *
 *  @section intro_sec Introduction
 *
 * 	Driver for Microchip's TLC5947
 *
 * 	This is a library for the Adafruit TLC5947
 * 	http://www.adafruit.com/products/
 *
 * 	Adafruit invests time and resources providing this open source code,
 *  please support Adafruit and open-source hardware by purchasing products from
 * 	Adafruit!
 *
 *  @section author Author
 *
 *  Limor Fried/Ladyada (Adafruit Industries).
 *
 * 	@section license License
 *
 * 	BSD (see license.txt)
 *
 * 	@section  HISTORY
 *
 *     v1.0 - First release
 *      18 Dec 2019 modified to 'plain' C - kartman
 */

#include <Adafruit_TLC5947.h>

uint16_t *pwmbuffer;
uint16_t numdrivers;

#define TLC_PORT PORTB
#define TLC_DDR DDRB
#define TLC_CLK 3
#define TLC_DAT 4
#define TLC_LAT 5

/*!
 *    @brief  Writes PWM data to the all connected TLC5947 boards
 */
void write() {
  TLC_PORT &= ~(1<<TLC_LAT);
  // 24 channels per TLC5974
  for (int16_t c = 24 * numdrivers - 1; c >= 0; c--) {
    // 12 bits per channel, send MSB first
    for (int8_t b = 11; b >= 0; b--)
    {
      TLC_PORT &= ~(1<<TLC_CLK);

      if (pwmbuffer[c] & (1 << b))
        TLC_PORT |= (1<<TLC_DAT);
      else
        TLC_PORT &= ~(1<<TLC_DAT);

      TLC_PORT |= (1<<TLC_CLK);
    }
  }

  TLC_PORT &= ~(1<<TLC_CLK);

  TLC_PORT |= (1<<TLC_LAT);
  TLC_PORT &= ~(1<<TLC_LAT);
}

/*!
 *    @brief  Set the PWM channel / value
 *    @param  chan
 *            channel number ([0 - 23] on each board, so chanel 2 for second board will be 25)
 *    @param  pwm
 *            pwm value [0-4095]
 */
void setPWM(uint16_t chan, uint16_t pwm) {
  if (pwm > 4095)
    pwm = 4095;
  if (chan > 24 * numdrivers)
    return;
  pwmbuffer[chan] = pwm;
}

/*!
 *    @brief  Set LED
 *    @param  lednum
 *            led number
 *    @param  r
 *            red value [0-255]
 *    @param  g
 *            green value [0-255]
 *    @param  b
 *            blue value [0-255]
 */
void setLED(uint16_t lednum, uint16_t r, uint16_t g,
                              uint16_t b) {
  setPWM(lednum * 3, r);
  setPWM(lednum * 3 + 1, g);
  setPWM(lednum * 3 + 2, b);
}

/*!
 *    @brief  Setups the HW
 *    @return True if initialization was successful, otherwise false.
 */
boolean begin(uint8_t n)
{

numdrivers = n;

  pwmbuffer = (uint16_t *)malloc(2 * 24 * n);
  memset(pwmbuffer, 0, 2 * 24 * n);
  if (!pwmbuffer)
    return false;

  TLC_DDR |= (1<<TLC_CLK);
  TLC_DDR |= (1<<TLC_DAT);
  TLC_DDR |= (1<<TLC_LAT);

  TLC_PORT &= ~(1<<TLC_LAT);

  return true;
}

Converted to 'plain' C.

Last Edited: Thu. Dec 19, 2019 - 12:17 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not sure why there would be any problem at all in sending out the data on any bit-banged pins.  It only requires maybe 6-7 lines of simple code.  Even in assembly maybe 25 instructions.  Do you feel you need some sort of library to toggle a few pins?

 

In fact, I always use bit-bang*, even if my part is connected to the MOSI &  MISO pins.    I like to add some small RC caps to the lines to help improve immunity for wired (cabled) devices.  Making my own clock & data pulses, lets me generate much improved setup & hold times.  so ringing, settling, noise, etc issues are minimized.  Instead of 10ns timing margins, I can use 200 ns,  500 ns, or whatever I want.  The design of the spi block is the opposite; they try to shave the timing margins down to the minimum tolerable/usable margins (in order to allow for the fastest speeds).  Why use the minimum possible safety margin, if you are not in a blazing  hurry? 

 

Also, since most SPI chips are static, there is no need to generate all the bits at once, or pre-pack them together when bit-banging.  Say you need to spit out 14 config bits.  Three of them can be generated & spit out in the keyboard routine, 4 of them are generated by some sensor monitor &  the rest generated by another routine.   Calling each of these routines performs its specific share of the data transmission---easy & straightforward.  No extra bit twisting, shuffling, dicing, byte-alignment, etc needed when bit banging. You can efficiently send 1 bit, followed by 5 bits, followed by 3 bits, etc (very convenient).

 

* well, 95% of the time; whenever I don't need MHz transfer rates which is generally never. 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Dec 18, 2019 - 04:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for looking, I appreciate it.

 

I've had a good search over the last 36 hours, most code snippets are based on hardware but I have enough to go on now.  

 

Regarding updating the LEDS, yes I'm aware of that.  I have 3 TLC's daisy chained to give me 64 outputs.  I've done tests with the Adafruit library and performance is acceptable. Perhaps in the next iteration of the board I'll split them up using 2 more pins for SS which will make it more efficient.  I'll also wire up the SPI pins to make things easier

 

regards

 

 

 

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

Forgive me, I'm still fairly new to this hardware stuff.  

 

The code examples I looked at weren't very obvious in their workings with regards to SPI or at least they weren't to me

 

regards

 

 

 

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

I’m a bit confused, you said you had working code, and performed well too, why change?

why not use what you have?

jim

 

 

Keys to wealth:

Invest for cash flow, not capital gains!

Wealth is attracted, not chased! 

Income is proportional to how many you serve!

 

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

It's written for the Arduino.  I'm using Studio 7.  Plus there's the license issue.

 

regards

 

 

 

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

nikm wrote:
 Plus there's the license issue.

 

What license issue?  Use the Arduino extension inside Studio and you're golden

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

"Dare to be naïve." - Buckminster Fuller

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

I converted in to 'plain C'. I don't see what the license issue is - have you read the various licenses for Atmel Studio 7? BSD is less restrictive than GPL. The gcc libraries are GPL and you don't seem to have issue with that.

 

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

Kartman wrote:
The gcc libraries are GPL

 

I think avr-libc is BSD.

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

El Tangas wrote:
I think avr-libc is BSD.

modified BSD:

 

The AVR-LIBC Home Page wrote:

AVR Libc is licensed under a single unified license. This so-called modified Berkeley license is intented to be compatible with most Free Software licenses like the GPL, yet impose as little restrictions for the use of the library in closed-source commercial applications as possible.

 

https://www.nongnu.org/avr-libc/

 

See also:  https://www.microchip.com/webdoc/AVRLibcReferenceManual/index_1license.html

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nikm wrote:
It's written for the Arduino.  I'm using Studio 7.

jgmdesign wrote:
 Use the Arduino extension inside Studio

+1

 

See:  https://www.youtube.com/watch?v=7WnOe00dVu0

 

Or, as Kartman showed in #9, it's not so hard to convert to plain 'C'.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In #10, avrcandies wrote:
The design of the spi block is the opposite; they try to shave the timing margins down to the minimum tolerable/usable margins (in order to allow for the fastest speeds).  Why use the minimum possible safety margin, if you are not in a blazing  hurry? 

For discussion of that point, see:  https://www.avrfreaks.net/forum/spi-hardware-vs-bitbang

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
The gcc libraries are GPL ...
with the run-time exception for most, not all, instances of GCC.

https://github.com/gcc-mirror/gcc/blob/master/COPYING.RUNTIME

 

"Dare to be naïve." - Buckminster Fuller

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

Thanks Guys,

 

All the advice given here got it working, many thanks

 

I have 2 questions though which relates to Kartman's posted code.

 

In the converted write function, it's sending 12 bits to the TLC, yet the buffer consists of  uint16's  how does that work?

 

secondly, in the same function it's sending the data serially to the TLC, how is the speed set?  Can it be run faster?  I can't quite follow the code and would like to understand it

 

regards

 

 

 

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

In the converted write function, it's sending 12 bits to the TLC, yet the buffer consists of  uint16's  how does that work?

 The for loop only shifts 12 bits, so 4 bits in the uint16_t are not used. You could devise a method to pack it all in, but that would add a level of complexity. If your application couldn't waste 25% of th bits, then you'd have to pack them.

 

 

secondly, in the same function it's sending the data serially to the TLC, how is the speed set?  Can it be run faster?  I can't quite follow the code and would like to understand it

 

The loop works as fast as it can. The Arduino's digitalWrite functions are well known to be slow - the price you pay for flexibility, so replacing these with direct port access makes the loop faster. The person who wrote the code didn't optimse as he used variable bit shifts - the poor old AVR can only do one bit shift per instruction, so this is slowing down the loop as well. 

 

/*!
 *  @file Adafruit_TLC5947.c
 *
 *  @mainpage Adafruit 24-channel PWM/LED driver
 *
 *  @section intro_sec Introduction
 *
 * 	Driver for Microchip's TLC5947
 *
 * 	This is a library for the Adafruit TLC5947
 * 	http://www.adafruit.com/products/
 *
 * 	Adafruit invests time and resources providing this open source code,
 *  please support Adafruit and open-source hardware by purchasing products from
 * 	Adafruit!
 *
 *  @section author Author
 *
 *  Limor Fried/Ladyada (Adafruit Industries).
 *
 * 	@section license License
 *
 * 	BSD (see license.txt)
 *
 * 	@section  HISTORY
 *
 *     v1.0 - First release
 *      18 Dec 2019 modified to 'plain' C - kartman
 */

#include <Adafruit_TLC5947.h>

uint16_t *pwmbuffer;
uint16_t numdrivers;

#define TLC_PORT PORTB
#define TLC_DDR DDRB
#define TLC_CLK 3
#define TLC_DAT 4
#define TLC_LAT 5

/*!
 *    @brief  Writes PWM data to the all connected TLC5947 boards
 */
void write() 
{
  TLC_PORT &= ~(1<<TLC_LAT);
  // 24 channels per TLC5974
  for (int16_t c = 24 * numdrivers - 1; c >= 0; c--) 
     {
      // 12 bits per channel, send MSB first
      for (int8_t b = 11; b >= 0; b--)
          {
          TLC_PORT &= ~(1<<TLC_CLK);

          if (pwmbuffer[c] & (1 << 11))  //test the msb (most significant bit)
            {
            TLC_PORT |= (1<<TLC_DAT);
            }
          else
            {
            TLC_PORT &= ~(1<<TLC_DAT);
            }
          pwmbuffer[c]<<=1;      //shift the next bit along
          TLC_PORT |= (1<<TLC_CLK);
        }
  }

  TLC_PORT &= ~(1<<TLC_CLK);

  TLC_PORT |= (1<<TLC_LAT);
  TLC_PORT &= ~(1<<TLC_LAT);
}

/*!
 *    @brief  Set the PWM channel / value
 *    @param  chan
 *            channel number ([0 - 23] on each board, so chanel 2 for second board will be 25)
 *    @param  pwm
 *            pwm value [0-4095]
 */
void setPWM(uint16_t chan, uint16_t pwm) {
  if (pwm > 4095)
    pwm = 4095;
  if (chan > 24 * numdrivers)
    return;
  pwmbuffer[chan] = pwm;
}

/*!
 *    @brief  Set LED
 *    @param  lednum
 *            led number
 *    @param  r
 *            red value [0-255]
 *    @param  g
 *            green value [0-255]
 *    @param  b
 *            blue value [0-255]
 */
void setLED(uint16_t lednum, uint16_t r, uint16_t g,
                              uint16_t b) {
  setPWM(lednum * 3, r);
  setPWM(lednum * 3 + 1, g);
  setPWM(lednum * 3 + 2, b);
}

/*!
 *    @brief  Setups the HW
 *    @return True if initialization was successful, otherwise false.
 */
boolean begin(uint8_t n)
{

numdrivers = n;

  pwmbuffer = (uint16_t *)malloc(2 * 24 * n);
  memset(pwmbuffer, 0, 2 * 24 * n);
  if (!pwmbuffer)
    return false;

  TLC_DDR |= (1<<TLC_CLK);
  TLC_DDR |= (1<<TLC_DAT);
  TLC_DDR |= (1<<TLC_LAT);

  TLC_PORT &= ~(1<<TLC_LAT);

  return true;
}

 

The original code used the loop variable b to pick out which bit. I changed the code to pick out bit 11 (0..11 = 12bits) then each time through the loop I shuffle the bits along. Hopefully this is faster. Maybe you could run the code in the Atmel Studio simulator and measure the two solutions to see which one is faster and by how much. There are one or two more optimisations we could try, but the law of diminishing returns kicks in.

 

How does it all work? It's a bit like a sausage machine - crank the handle (toggle the clock pin) and another sausage (data bit) comes out. Do this 12 times and toggle the latch pin to tell the TLC we've sent it 12 bits. If you really want to dig deep, get a pencil and paper (grid.graph paper preferable) and draw out a 'timing diagram'. Step through the code manually and draw the clock going high and low, the data bits etc. Look at the timing diagram for the TLC device and hopefully it should become clear. You might want to compare it with the SPI peripheral which basically does the same thing. The above code does 'bit bashing' which has the advantage of being able to use any available port pins whereas the SPI peripheral constrains you to specific ones.

 

 

The beauty of the Arduino system is that the tricky stuff has been done for you. When you don't use Arduino, you need to figure out all the tricky stuff for yourself - 'how hard can it be'? You might ask? If you don't have a background in electronics and software, then you're up for some learning - the hard way.  Like yourself, we get plenty of posts from people wanting to 'escape' the evils of the Arduino due to it's 'bloat' and 'inefficiencies'. About the only inefficient thing in Arduino (on the AVR) is the digitalWrite/digitalRead functions. These are well known to be sluggish. The Arduino designers made a design decision to trade ease of use for speed. For the most part if you're switching relays or flashing leds, it makes no difference. The good thing is that the Arduino system doesn't lock you in to using their functions - you can easily write your own. This is what many people fail to realise. As for 'bloat' - there's a little bit of stuff that comes along for the ride, but you probably want that anyway. 

 

 

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

Teh TLC requires you to update all of the LED's at the same time.  You cannot update a single LED without updating all the others...even if nothing changes for them.  So, 24 channels with 12 bits per channel works out to 288 bits.  divide 288 by 8(the amount of bits the AVR's SPI can send per transmission), you get 36 bytes need to be sent in order to update all of the led's

 

The code simply shifts the bits around so that the SPI sends everything out inline so when you flip the XLAT line all the LED's update properly.

 

Look at pages 8 and 12 of the TLC datasheet:

 

http://www.ti.com/lit/ds/symlink...

 

There are 288 clocks, then the XLAT pulses, and the process repeats a needed.

 

On page 12 there is a block diagram of the internal setup of the device.  Data goes into a 288 bit shift register that feeds a 288 bit latch that is loaded with each XLAT pulse.

 

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user

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

The SPI lines are shared by all the devices connected to the SPI bus, including the AVR's ISP programming interface.    There will be a separate chip-select line for each SPI device.  When the device's CS line is not active, the device ignores the data on the SPI bus.

 

AVR's ISP interface uses the SPI lines, but it is a special condition that has the reset line pulled low to active state

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

Kartman wrote:
When you don't use Arduino, you need to figure out all the tricky stuff for yourself - 'how hard can it be'? You might ask?
or replace the Arduino framework with an alternative (FastArduino)

Basics: gpio & time | FastArduino: FastArduino API Tutorial

 

P.S.

Amazing (1KB program space, 0 bytes of data space, tiny84A)

http://fast-arduino-lib/examples/complete/Conway at master · jfpoilpret/fast-arduino-lib · GitHub

 


via https://www.avrfreaks.net/forum/avr-studio-mac-linux#comment-2440271

FastArduino is compiled by FSF AVR GCC 7.

 

"Dare to be naïve." - Buckminster Fuller

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Thanks for all your help guys,

 

In the end I couldn't get rid of flicker at certain pwm levels with more than 1 TLC5947 despite trying numerous options.  In the end I went for TCL5940's and they work perfectly.(4 x daisy chained)  I think the clock was getting corrupted. Now I have control of the GS clock.

 

regards

 

 

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

Please mark post 28 as the solution

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"Step N is required before you can do step N+1!" - ka7ehk

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB, RSLogix user