PIC speed problems

[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

[The Master]

I was thinking about swapping to a 18F. They seem to be better for ram and oscillator speed although im already using 20Mhz and you say that is enough.

I understand your explanation about instruction cycles but you lost me a bit with the us explanation.

If i have all these cycles spare then does it matter whether i process the data in the main loop or the interrupt handler? What exactly is an "instruction cycle"? Is it the same as a word? (I mean word asin "Success : 100 words used", not the data type)

How do you know how long it takes to execute each instruction cycle? The datasheet says its 200us but that changes depending on the oscillator.

[skimask]

Instruction cycle = oscillator/4, i.e. 20Mhz oscillator = 5Mhz instruction cycle rate = 200ns per instruction cycle. Most things in a PIC are based off the instruction cycle, not the actual oscillator.
Yes, 20Mhz is more than plenty.
Spare instruction cycles - best to handle as much as you can in the main loop. Get in and out of the interrupt handler as fast as possible. While you are in the interrupt handler, you generally can't handle another interrupt (well, you can, but that's beyond the scope at the moment), therefore, you can't handle anything else until you get out of that interrupt routine.
Instruction cycle - a NOP takes one instruction cycle, it also takes one word of code space.
A GOTO takes 2 instruction cycles, but takes up only one word of code space. That info is in the 'Instruction Set' section of your PICs datasheet.
But to figure out how long it takes each 'block' to execute, you either have to count it out, or use one of a few different methods to calculate it (MPLAB, use one of the PICs timers, etc.etc.).

[The Master]

In making sense of that i just realised i forgot about microseconds. Nano seconds are 1000 times faster than i thought.

So when a datasheet says "200ns instruction cycle" thats calculated for the highest possible oscillator you can use with it. In this case 20MHz.

If the serial data comes in at about 86.8us then i work that out to be once every 434 cycles. Now it sounds more realistic.

So if i have a main loop that doesnt pause or anything then would it make sense to only have an interrupt for the PWM and repeatedly check PIR1.5 in the main loop? That way the interrupt might still be run when serial data arrives but it wont have to do anything and will be straight out of the interrupt handler. The main loop should then be able to pick it up on its next iteration and do all the processing within 434 cycles.

I guess i dont really have 434 cycles to play with because the PWM interrupt will use up a few cycles. Using your example it should run almost twice between each byte of serial data. If we say it uses 100 cycles to be on the safe side then i should have over 234 left to do the processing.

Does that make sense or have i got it all mixed up again? Its starting to look just like my original code except for the timer. When i first started this thread i was trying to do the timer's job manually and i think thats where it all went wrong

[skimask]

So if i have a main loop that doesnt pause or anything then would it make sense to only have an interrupt for the PWM and repeatedly check PIR1.5 in the main loop?

No...PIR1.5 (i.e. the serial port, either TX'ing a byte or RX'ing a byte) will trigger an interrupt if properly set up...that's the way interrupts work. If you can't get an interrupt to trigger, it might be because there's nothing there to trigger that interrupt and/or your serial port isn't working in the first place.

[The Master]

What i meant is that the interrupt would copy the byte from RCREG into a temp variable. Then the code in the main loop would need a way of knowing when a byte has been received to process it (possibly a bit variable). What im saying is why not just check PIR1.5 instead of having another variable to say serial data has arrived and why not use RCREG directly in the main program loop instead of having another byte variable. It would mean the serial interrupt completes much quicker because it doesnt do anything.

Should i be removing the byte from RCREG in the interrupt? If it doesnt matter as long as i do it before the next one arrives then doing it in the main program loop looks like a better way of doing it