PIC speed problems

[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

[The Master]

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

I have been kinda trying to do that. I have a buffer in the form of an array (4 elements). When a byte is received it gets copied to a temp variable. Each one that arrives increases a counter. When the counter is between the lights address and the lights address plus 4 it copies the bytes into that buffer. Once the count reaches 512 then it moves the buffered bytes into the variables that control the PWM.

I suppose i could lose the temp variable meaning 1 less copy operation per byte. I actually added the buffer because its possible to send 1 byte at a time from the PC and i didnt want the PWM to update until all the data has been sent. It also syncs the lights better because the first one wont change until the last one is ready to change.

Because of the ram problem i need to process the first byte as soon as it comes in. One bit of that tells the light whether its using the line ID or the address so it knows which bytes to look for. Then im going to need an if statement to check if the byte is one of those that its looking out for. I can do everything else in the main loop if the datapos is 512.

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

[The Master]

Ive been reading the datasheet for this PIC again. Ive found the bits that talk about the timer and interrupts etc. It says "Timer0 module will increment every instruction cycle (without prescaler)." and "8-bit timer/counter". So it appears that it will count up by 1 on each instruction cycle and keep counting until it reaches 255. The next increment will cause an overflow (resetting it to 0). If INTCON.5 is enabled then this overflow causes an interrupt.

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?

[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