PIC speed problems

[skimask]

On that page Darrel said "There's no way to combine Basic Language (A.K.A. ON INTERRUPT GOTO) type interrupts, with ASM interrupts". Does that include PIR1.5 then?

Not necessarily true anymore. Look into the Instant Interrupts. You can combine them, but it's a bit of a pain.
http://darreltaylor.com/DT_INTS-14/intro.html

[The Master]

Ive had a read through a few pages on there and it seems that it shouldnt be a pain. I like the bit that says "It all "Just Happens".". Ill test it out when i get home from work.

Just out of interest, what actually happens in the ASM part? It sounds like there is a main loop running that checks each of the interrupt flags then allows the PBP bit to run. Its a little confusing because a pause command doesnt seem to affect it even though pause should stop code executing for a set amount of time. I have been told that to create a pause in ASM you need to have a loop that does nothing. Im guessing the interrupts are checked on each iteration of that loop too.

ASM is on my "to learn" list but i havnt found time to start yet

[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.