Allegro A6280 with PICBASIC

HI there, I'm very new in picbasic and need to have some expert's advise in here. I wish to drive an Allegro A6280 with PIC16F628 by using shiftout. It seems that the data can be sent but the problem is I need to continuously pulse the clock with the code below to keep the A6280's PWM in order to run.

clksend:
high clk
low clk
goto clksend

It seems that when I execute this command, my pic is busy with the code and I can't send the next data to the A6280. Anyone can give me a good suggestion in here as I'm lost in no where right now. Thanks in advise.

Hi makson,

Not the easiest way to drive 3 LED's is it?

Well, I'm going to make it sound even harder. :eek:

The 6280 has 10-bit PWM counters. So, to get around 100hz PWM to the LED's, you'll need about 100 Khz going to the clock input continuously.

This can be easily acheived with the CCP module of the 16F628, but you can't use the HPWM command because the frequency is too high, so the registers will have to be set manually.

Now for the hard part.

Using SHIFTOUT to send the data may cause blinking when you update the PWM values. You would need to turn off the CCP module to allow SHIFTOUT to control the clock pin, shift the data out, then turn on the CCP module again to keep the clock going.

It's possible that you may not even be able to see it because it will be more of an elongation of 1 PWM cycle, so you should try that way first.

If it is noticable, you'll need to manually shiftout the data "In Sync" with the CCP clock cycles, which can be done with the TMR2IF flag. But try it with SHIFTOUT first to see if there's a problem or not. If there is, I can show you how to "sync" the data.

HTH,

Dear Darrel,

Thousand thanks to your reply. I really appreciate your help and I'm now going to try the method you mention. Before that, I've encountered that when the circuit is power on, there's 5V in the OEI pin of a6280. I don't really understand how to operate with OE. Do I need to sink it to ground with a resistor in order for the LED to light up? Please kindly advise. Thanks & hope u enjoy your weekend.

Warmest Regards,
Kevin Loh

You can just tie the (OEI) Output Enable Input to ground. (No resistor required)

If you want more control later, you can connect OEI to a PIC pin. Then HIGH is LED"s OFF, and LOW is LED's ON.

But, you can still turn them ON/OFF by putting 0 or 1023 in the PWM register, so using OEI doesn't help all that much. Which is why I say, Just ground it.
<br>

Dear Darrel, sorry for the trouble again, below is the code that I'm trying to work with but it doesn't light up the led as expected. Please kindly advise. Thanks in advance.

@ DEVICE HS_OSC
DEFINE OSC 4
include "bs1defs.bas"

CMCON = 7 ' PortA = digital I/O
VRCON = 0 ' A/D Voltage reference disabled
TRISB = %00000000 ' B.3=PWM,B.0,B.1,B.2 blink LEDs
PR2 = 25 ' Set PWM for approximately 38KHz
CCPR1L = 13 ' Set PWM Duty-Cycle to 50%
CCP1CON = %00001100 ' Mode select = PWM
T2CON = %00000100 ' Timer2 ON + 1:1 prescale

d2pin var portb.0
c2pin var portb.3
latch var portb.4
'oe var portb.1


funct var byte
rvar var word
gvar var word
bvar var word

funct = 0
gvar = %0011111111
rvar = %0000000000
bvar = %0000000000

begin:
high porta.0
pause 1000
low porta.0

CCPR1L = 0
shiftout d2pin, c2pin, 1, [funct\1,gvar\10,rvar\10,bvar\10]
gosub latching

pause 1000
gosub bringpwm


goto begin




bringpwm:
PR2 = 25 ' Set PWM for approximately 38KHz
CCPR1L = 13 ' Set PWM Duty-Cycle to 50%
CCP1CON = %00001100 ' Mode select = PWM
T2CON = %00000100 ' Timer2 ON + 1:1 prescale
return

latching:
high latch
pause 500

low latch
return

Putting 0 in CCPR1L just stops the output with a 0% duty cycle. The pin is still controlled by the CCP module.

CCP1CON = 0 &nbsp; Will allow SHIFTOUT to use the PIN.

And for 100Khz, use PR2 = 9 and CCPR1L = 5.
<br>

Dear Darrel,

Thanks to you. The code running well now. I can turn the color from Red to green and to blue. You are really good. Thanks again. But now, the story continue...... I need to know how to use the Dot Correction because I don't really understand the concept. Besides that, Do I really need to use the Dot Correction? Please kindly advise.

Great! Glad you got it working.

Quote:

---

Besides that, Do I really need to use the Dot Correction?

---

I guess you don't "really need" to use them. You could just set the current with the REXT resistor, and use the PWM like normal. But if you want to match the brightness of the 3 LED's, then you'll need to set the DOT correction registers.

They Power-up at 36% of the REXT current setting.
So be sure you don't have too much current set-up before trying this. I don't want to blow up your LED's.
But this should set the DOT registers to full current.

Code:

---

Rdot VAR BYTE
Gdot VAR BYTE
Bdot VAR BYTE
Zeros VAR BYTE : Zeros = 0

Rdot = 127  ; Set these to match LED brightness (max 127)
Gdot = 127
Bdot = 127

SetDots:
    funct = 1
    CCP1CON = 0
    shiftout d2pin, c2pin, 1, [funct\1,Zeros\3,Gdot\7,Zeros\3, _
                              Rdot\7,Zeros\3,Bdot\7]
    high latch
    @ NOP
    low latch
    CCP1CON = %00001100
    funct = 0
RETURN

---

Then just GOSUB SetDots

HTH,

Dear Darrel, thanks for the code so I think maybe you're right. The dot correction might not playing a necessary character in here. I still have a question if you don't mind, I'm trying to dim the led by decreasing the value of bvar (let say from 1023 to 0) but no luck. May I know why? Besides that, do u have a complete set of code for this IC's controller for sale? Hope you have a good day.

I don't know why it wouldn't, except maybe for the PAUSEs.
The last code posted would take over 42 minutes to dim from 1023 to 0 with the included pauses.

Can you post your code again the way it is now?
<br>

BVar = 1023

blue:
shiftout d2pin, c2pin,1 [funct\1,Rvar\10,Gvar\10,Bvar\10]
gosub latch
gosub BringUpPWM
pause 100
Bvar = Bvar - 2
if bvar < 3 then goto end
gosub blue

end

I was expecting gradual dimming of the LED, but it pulsates and intensity seems the same.

END is a reserved word and can't be used as a label.

The blue loop is GOSUBing back to itself. It should be GOTO.

And, it needs to turn off the CCP module before shifting any data.

Make sure the PAUSE 500 is NOT in the latching: subroutine anymore.

Code:

---

BVar = 1023

blue:
    CCP1CON = 0
    shiftout d2pin, c2pin,1 [funct\1,Rvar\10,Gvar\10,Bvar\10]
    gosub latch
    gosub BringUpPWM
    pause 100
    Bvar = Bvar - 2
    if bvar < 3 then goto BlueDone
GOTO blue

BlueDone:

---

Ok, I'll try the code tomorrow morning as it is too late now. Hope it works, thanks and I'll let you know the result by tomorrow. Thanks

BINGO! Darrel, you're the best! Thank you again for the code, now I can dim the LED. Now, the only think in my concern is that when I control too many clusters, the PIC might not be able to store that much of data isn't it? Do you have any recommendation? Hehehe, sorry if I ask too much but really appreciate your help. God bless. Thanks again.

Awesome!

Not bad for someone that's never seen that chip before. eh :)

Well, as far as the memory requirements go. At 6 bytes per cluster (PWM only), you can run an awful lot of clusters with just about any chip. But if it gets to be too many, just throw on a serial FRAM, and you could light up several hundred or thousand clusters, easily.

Well, assuming you had that may pins on your PIC.
Since each cluster needs it's own Latch line, it's kind of limiting. :(
Of course you could always run the devices in series with a common latch, or add some shift registers to increase the Latch count, but now I'm getting into a whole different area.
<br>

Dear Darrel, I still need some help here. Can you kindly give me your email address? I need to send some attachment to you. Thanks & have a great weekend.

Warmest Regards,
Kevin Loh

Using SHIFTOUT to send the data may cause blinking when you update the PWM values. You would need to turn off the CCP module to allow SHIFTOUT to control the clock pin, shift the data out, then turn on the CCP module again to keep the clock going.

It's possible that you may not even be able to see it because it will be more of an elongation of 1 PWM cycle, so you should try that way first.

If it is noticable, you'll need to manually shiftout the data "In Sync" with the CCP clock cycles, which can be done with the TMR2IF flag. But try it with SHIFTOUT first to see if there's a problem or not. If there is, I can show you how to "sync" the data.

HTH,[/QUOTE]


Dear All, especially to DT,
My brother had tried out the shiftout part of the codes, it worked perfectly. But to my calculation, that will be way to slow for our requirement, pausing to wait for the shiftout to complete will take impractically long in our project.
You mentioned of using TMR2IF flag. Both me and my bro are new. I tried playing with the TMR2 to synch the data send: ie using the PWM as clock drive. But seems like my understanding of the TMR2 is wrong. Please correct:

1. TMR2 counts from 00 to value in PR2 then resets.
2. If TMR2 count reaches value in CCPR1L, then duty cycle is completed, hence going to the low cycle of the PWM and therefore our "clock"

So my aim is to send the data on the duty cycle time via the data pin and prepare for the next data bit in the low time. I set the PR2 = 9 and CCPR1L =5 as in your earlier code with the above assumption. Thinking the Low time will be after TMR2 = 5, so I wrote:

For Counter = 1 to 31
while TMR2 <= 5 then
high DataPin
wend
low DataPin
next Counter

Will this work?
Didn't use TMRIF2 as I am still struggling to understand the interrupts.
Can you show how to synch CCP with the TMRIF2 as you have mentioned?
Thanks a lot.
Heng.

Hello,

I don't understand the principle of the shift register of the A6280. I need to control 20 RGB pixels separately. Is this principle work ? :

1) Load RGB data of pixel 1
2) Load RGB data of pixel 2
..) ...
20) Load RGB data of pixel 20
21) Latch
22) Load RGB data of pixel 1
....

Thank tou for your help

If pixel 1 is the LAST one in the string, then yes.
Send the data for all pixels then latch it. All pixels update at the same time.
<br>

ok, thank you for this fast reply,
A6280 is perfect for my application : (low resolution screen).

I'm going to test it soon

I know I'm coming in on this thread a little late, but I'm trying to control the A6280 as well. I'm using a PIC16F873a which has a SPI port. Supposedly it is very easy to use the SPI port because it handles the serial clocking of the data and such. I was wondering if someone could clarify something though. Does the SCK pin maintain a constant clock pulse. I believe how it's setup is to deliver OSC/4 to that.

Quote:

---

Originally Posted by Photovor

Does the SCK pin maintain a constant clock pulse.

---

It Does NOT.

It only puts out a CLK when data is being sent.
The A6280 needs a CLK all the time though, not just when there's data.
<br>

Thanks for the clarification. Is there a way to utilize the oscillator that is supplying the clock for the PIC to also supply the clock pulse for the A6280, and use the SPI functions as well? Or would SPI not work at all in this example? It's a shame that the A26281 just comes in a QFN package, considering it has its own internal PWM counter.

Quote:

---

Originally Posted by Photovor

... Is there a way to utilize the oscillator that is supplying the clock for the PIC to also supply the clock pulse for the A6280, and use the SPI functions as well? ...

---

It's possible, with external hardware, extra pins on the chip, and a great deal of thoughtful programming.

But since you can use the CCP module in co-operation with SHIFTOUT commands on 2-3 PINs and no external hardware .... Why?
<br>

I was just curious if it was possible or not. I'll have to play with the examples above and see what I can get out of it. I've never used the CCP module, but I like the idea of not having to rely on any external clock sources.

Ok, I got around to trying the example in this thread. I had to change a piece or two because I'm using a PIC12F683. The main changes were to change TRISB to use TRISIO (since there is only one GPx PORT), and of course the SHIFTOUT command to use the correct pins on that port as well.

I'm getting no results, and it doesn't seem that the CCP module is working correctly. Is there a way I can test this individually?