PIC speed problems

[The Master]

Ive been working on this for about 2 hours now and ive just got it working. Ive tested it by sending 512 bytes of data at 115200 baud and it all seems to work fine. At first the LEDs were flickering really bad but i just had to change the SPWM_FREQ. Im going to start tidying the code up a little and adding my code back in. Hopefully it wont slow it down at all.

Thanx for pointing that out and a big thanks to Darrel for writing it!

[The Master]

Ive added a little code in now and it seems to be causing problems. Heres what my code looks like

serialData:

    'Get a byte of data
    temp=RCREG

    datapos=datapos+1
    
    select case datapos
        case 1           
            vred=temp
        case 2        
            vgreen=temp
        case 3
            vblue=temp      
        case 4
            vwhite=temp
            datapos=0
    end select
             
@ INT_RETURN

As you can see theres nothing special. It simply sets each byte to one of the 4 colors in turn. The problem is that if i set any color to half on (anything other than 0 and 255) i get really bad flashing on all the LEDs. Thats even just sending 1 byte of data at a time. Im gonna try messing with it to see if i can get it to work better. Do you have any ideas?

[skimask]

'cause your PWM freq isn't high enough in the first place. The freq of a 0% duty cycle wave is...0. The freq of a 100% duty cycle wave is...0.

[The Master]

Ive tried changing SPWM_FREQ to a bunch of different values. Anything below 60 causes the LEDs to continously flash. Anything above 50 causes bright flashes or dimming whenever data is received. I think its because there isnt enough processing power to accept serial data at that speed aswell as doing PWM at a frequency of 50+

Would it be best to try and find a PIC18F so i can use a higher oscillator? Other than that i can only think of lowering the baud rate and/or reducing the amount of data sent. I suppose that is an option but with each light using at least 4 bytes of data i wont be able to have many lights

[skimask]

Fact: There's plenty of processing power to do what you want to do...
Fact: There's not enough knowledge behind the keyboard to do it....YET!

Ok, as good as SSPWM is and as good as the Instant Interrupts are, I want you to take a look at the attached file. It's a program I wrote to handle a single RGB LED (actually a string of them) and serial data, no SSPWM, no Instant Interrupts, works great for me. The only reason I have it set up for 2400 baud right now is because of the distance between the controller and slave unit. On the bench, it worked just fine at 57.6Kbaud (or whatever that divisor comes out to)...but it wouldn't work reliably out in the field (again, because of the distance), and 2400 baud was plenty fast for me.
Take a look at the file. I'll clean it up a bit and re-upload it soon.

[The Master]

Well, thats good news (about having enough processing power). I will learn this properly now matter how long it takes.

Your program looks similar to the way i was doing things origionally. I had a loop that kept checking if serial data had arrived thought. You are using oninterrupt aswell. I think the difference is how i did the timing for the PWM. I didnt use pause at all, instead i used the speed of the loop. The faster the pic chip runs the faster the PWM should run. In theory that should have worked fine. The problem i had is that when serial data arrived it was delaying a few iterations of the loop and causing a flash.

I see that you are using the timer. That should do what i was trying to do in the first post of this thread. I wanted to add extra delays when the serial data wasnt arriving etc to balance things out. The timer should automatically do that.

Its a little late now so im gonna go to bed. A good nights sleep usually helps with things like this. Ill have another go tomorrow. Ill start again from scratch and try using the timer from within PBP which seems to be intcon.2. Im going to try coding the data receive code better too. Each light only needs to look out for about 4 bytes of data. It can ignore the rest. I also have an idea to test how much of an impact the serial data has on the program so ill give that a try too

[skimask]

I had a loop that kept checking if serial data had arrived thought.

A loop is a loop until you start to do stuff in that loop. That's when a loop becomes something else.

You are using oninterrupt aswell. I think the difference is how i did the timing for the PWM. I didnt use pause at all, instead i used the speed of the loop. The faster the pic chip runs the faster the PWM should run. In theory that should have worked fine. The problem i had is that when serial data arrived it was delaying a few iterations of the loop and causing a flash.

Yep, and I'm doing my PWM in a controlled manner. Basically, I'm doing nothing more than the hardware PWM already does except I'm doing it manually. Manually updating the count, manually doing the compare to either turn on or off the output.

I see that you are using the timer. That should do what i was trying to do in the first post of this thread. I wanted to add extra delays when the serial data wasnt arriving etc to balance things out. The timer should automatically do that.

Pull the data out of the serial port as fast as you can and process it later. It's not going anywhere and this type of thing isn't time critical (i.e. you won't have a nuclear meltdown if you don't update the RED LEDs right now!).
Just a quicky 'block' example of an idea for you...

'setup all the variables, pins, etc.etc.etc.etc.

'On Interrupt
'checks Tmr0 overflow and updates outputs based on duty cycle registers
'checks Serial RX register and saves value
'Returns from interrupt

'subroutines

'more setup

'main loop
'acts on serial data received to change desired duty cycle registers for individual LEDs
'for example, break the received byte into bits...
'b7-b4 = LED duty cycle to modify (b7=Red,b6=Green,b5=Blue,b4=White)
'b3-b2 = increase/decrease/max/min (b3=increase by x, b2=decrease by x)
'b1-b0 = increase-decrease amount (00=by 1, 01=by 5, 10=double or half depending on b3-b2, 11=max or min depending on b3-b2)

'goto main loop

'on interrupt fires as often as it needs to fire, every time Tmr0 overflows (19.5khz) and/or whenever a data byte is received at the serial port (i.e. 115,200 baud isn't too fast)

So, using this example, you send %11111011, it will:
1111 = bit 7 thru bit 4, all LEDs selected
10 = bit 3 thru bit 2, increase by x
11 = increase values to maximum