PIC speed problems

[skimask]

Aparently the PIC im using only has 368 bytes of ram. There isnt enough room to buffer 512 bytes of data.

Time to switch boats and go with an 18Fxxxx...

I see why my origional code didnt work. The PWM part worked fine. I could fade the LEDs in and out etc. The problem was with serial. As soon as a byte arrived it stopped everything else processing to deal with the data. Simply accepting the byte and updating the PWM values even worked fine when sending 1024 bytes. The problems seem to start when if-thens and select cases are added. From what i know about this interrupt stuff i think i can still have all those ifs/selects but as long as they are in the main loop then the interrupt can break out half way through to update the outputs then carry on with the processing.

This all looks good but i thought thats what Darrel's code does. Darrel did mention that his code uses something like 70% of the processing power because of all the interrupts. Wouldnt i just get the same thing in PBP? From what ive heard ON INTERRUPT is even worse

ON INTERRUPT is worse in most cases, yes. I've managed to get along with it ok, just have to keep track of what's going on. Yes, SSPWM can take a lot of processing power, depending on what you're doing.
Example...4 LED channels to update, Serial port reading, etc.etc.
Tmr0 overflows every 256 instruction cycles...When the interrupt hits, a couple cycles to get to the int-code, check the flag, 2 more, reset the flag, 2 more, update the pwm counter, a couple more cycles, update all of the LEDs, say 4 cycles each for 16 total, kick out of the interrupt code, 2 more cycles, comes out to roughly 30-ish cycles (probably more, but just an example)...
Add in a Serial port interrupt...couple of cycles to get to the int-code, check the flag, grab the data, store the data, exit the interrupt, roughly another 16-ish cycles.
Call it 100 cycles just to be overestimating everything by a load... That still leaves the PIC with another 156 cycles until the next overflow to process the incoming data 'packet', update anything it needs to update, etc.
At 115,200, a byte can possibly show up every 86.8us. Timer0 would overflow every 256us (assuming prescale of 1:1) when running the PIC at 4Mhz. Run the PIC at 20Mhz, and Timer0 would overflow every 51.2us (again, assume prescale of 1:1), leaving you with plenty of time to handle the serial, handle the 4 channels of lights, and so on and so on.
So I guess the moral of the story is, if you're running 4Mhz, time to bump that up a bit...

Now if i look at the OPTION_REG Register i see some stuff about this "prescaler". If i set that to 2:1 does that mean the timer increments once every 2 instruction cycles?

That's why it's called a prescaler