Electronic – the difference between TCCR1A and TCCR1B

I've been monitoring this question, and since no one has answered yet, I'm going to take a stab at it. I apologize in advance if my reasoning ends up being flawed, but I'll do my best.

I think the possibility of making your project work depends upon how many RGB LEDs you plan on using. I've been going over the Allegro datasheet, and it looks like you need to pair one IC with one each of red, green, and blue LEDs (i.e. one RGB pixel). All of the data gets transmitted down the chain of 6280s.

If you want to only have one RGB pixel, or more specifically, N pixels displaying the same temporal information, then I think you might be able to get away with using SPI. I think your linked list idea is the right way to go, but obviously the key is to latch LI at the right time (every 31 bits), and it won't be on 8 bit boundaries. The only SPI libraries I've ever used on micros take a byte, clock out the data and read the response byte. In your case, you'll need to figure out how to make an SPI function that can trigger LI during a byte transfer.

Since SPI requires transferring one byte at a time, you'll be forced to send 32 bits when you only want 31. So the 32nd bit will actually be the first bit of your second set of RGB data. You'll set LI before clocking out the 32nd bit. For the next round of data, you'll trigger LI before clocking out the 31st bit. You might be able to do this without writing your own SPI library, but I'm not sure.

If you want to support scrolling data, then things look like they will be a bit trickier. I'm having a hard time formulating the explanation, but timing LI will be interesting. LI determines how quickly your display is going to scroll, since it dictates when one 6280 outputs the data to the next.

For the first set of RGB data, you will trigger LI as soon as you've clocked out 31 bits. You've also clocked out 1 bit for the next set of data. You will then clock out another 3 bytes of data, plus 6 more before triggering LI. But if your scroll time is slow, you can't send out the byte that contains the last 6 bits until you are ready to trigger LI, because you don't want to overflow the shift register buffer! But once you are ready to trigger LI, you'll send out this byte. Now 2 bits for the next set of data is already in the serial buffer. Send out another 3 bytes (26 bits total), and wait until you need to trigger LI. When it is time, send out the next byte (that has the remaining 5 bits). Repeat this over and over again.

I hope this makes sense. Like I said, I don't have experience with this chip, but what I've written here is at least the first step I'd take to trying to solve this problem using SPI.

Good luck, and keep us posted!

I know it's a bit late, but I've just got this sabe doubt. After looking around, I've come across this Microchip Doc that shows some examples.

First, we calculate \$\text{PR2}\$. From this formula,

$$ F_\text{PWM} = \dfrac{1}{(\text{PR2} + 1) \times 4 \times T_\text{OSC} \times \text{T2CKPS}} $$

we get

$$ \text{PR2} = \dfrac{1}{F_\text{PWM} \times 4 \times T_\text{OSC} \times \text{T2CKPS}} - 1 $$

where \$T_\text{OSC} = 1/F_\text{OSC}\$, and \$\text{T2CKPS}\$ is the Timer2 prescaler value (1, 4 or 16).

Therefore, if we want \$F_\text{PWM} = 20\text{kHz}\$, and choosing \$\text{T2CKPS} = 1\$, we get \$\text{PR2} = 249\$. We should choose higher values for \$\text{T2CKPS}\$ only if \$\text{PR2}\$ exceeds 8 bits (\$\text{PR2} \gt 255\$) for the given prescale.

Now we calculate the max PWM resolution for the given frequency:

$$ \text{max PWM resolution} = \log_2(\;\dfrac{F_\text{OSC}}{F_\text{PWM}}\;) $$

That gives us \$9.9658\$ bits (I know, it sounds weird, but we'll use it like that later).

Now, let's calculate the PWM duty cycle. It is specified by the 10-bit value \$\text{CCPRxL:DCxB1:DCxB0}\$, that is, \$\text{CCPRxL}\$ bits as the most significant part, and \$\text{DCxB1}\$ and \$\text{DCxB0}\$ (bits 5 and 4 of \$\text{CCPxCON}\$) the least significant bits. Let's call this value \$\text{DCxB9:DCxB0}\$, or simply \$\text{DCx}\$. (x is the CCP number)

In our case, since we have a max PWM resolution of \$9.9658\$ bits, the PWM duty cycle (that is, the value of \$\text{DCx}\$) must be a value between \$0\$ and \$2^{9.9658} - 1 = 999\$. So, if we want a duty cycle of 50%, \$\text{DCx} = 0.5 \times 999 = 499.5 \approx 500\$.

The formula given on the datasheet (also on the linked doc),

$$\text{duty cycle} = \text{DCx} \times T_\text{OSC} \times \text{T2CKPS}$$

gives us the pulse duration, in seconds. In our case, it's equal to \$25\text{ns}\$. Since \$T_\text{PWM} = 50\text{ns}\$, it's obvious that we have a 50% duty cycle.

That said, to calculate DCx in terms of duty cycle as \$r \in [0,1]\$, we do:

$$ \text{DCx} = \dfrac{r \times T_\text{PWM}}{T_\text{OSC} \times \text{T2CKPS}} = \dfrac{r \times F_\text{OSC}}{F_\text{PWM} \times \text{T2CKPS}} $$

Answering your other questions:

2) The resolution of your PWM pulse with period \$T_\text{PWM}\$ is

$$ \dfrac{T_\text{PWM}}{2^\text{max PWM res}} $$

3) Because CCPRxL, along with DCxB1 and DCxB0, determine the pulse duration. Setting CCPRxL with a higher value than \$2^\text{max PWM res} - 1\$ means a pulse duration higher than the PWM period, and therefore you'll get a flat \$V_{DD}\$ signal.