PIC speed problems

[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

[skimask]

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.

Well, if you're receiving serial data in packets, the main loop should know when a full 'packet' has been placed into the 'buffer' and the main loop can clear the 'buffer' once it's done with it so the interrupt can start loading it again.

'4 byte buffer
Int: buf[3] = buf[2] : buf[2]=buf[1] : buf[1] = buf[0] : buf[0] = RCREG
RESUME

Everything in the receive 'buffer' got shifted up one, and the newest byte is in the lowest buffer position...
Now the main loop looks at all four bytes, decides it's a good packet, copies the packet and clears it so the interrupt can reload it.

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

Problem with that is 'feature creep'... You never know what you're going to put into the main loop later on. You say you won't add that much...but who knows how many 'not that much's are going to creep in later on. If the interrupt handles it, it's handled, 'nuff said.

[The Master]

I see your point. I will be adding some extra stuff to the main loop but the other stuff will only get executed if the current bit doesnt.

It just seems like your way does a lot of unnecessary stuff. I can give it a go but it looks like a lot of processing that doesnt need to be done. Having said that, you know what your talking about and im new to this. Plus you say your code actually works and mine still doesnt

[skimask]

It just seems like your way does a lot of unnecessary stuff. I can give it a go but it looks like a lot of processing that doesnt need to be done. Having said that, you know what your talking about and im new to this. Plus you say your code actually works and mine still doesnt

It really doesn't do a lot of extra/unnecessary anything. All it does (or rather would do) is, the interrupt's would handle the PWM'ing on the LEDs for you (you update them in the main loop as required) and would handle putting any serial data received into a buffer (you pull the buffer in the main loop to update the LEDs brightness levels in the main loop as required).
Really very simple...That file that I attached earlier has a whole LOAD of code in it for handling various modes for this, that and the other thing (sleep mode, flashing, fading, color 'phasing', etc.etc.)...a LOT of stuff you wouldn't even come close to needing for your setup.

I modified that file I was talking about...4 channels (RGBW)...
Change it up a bit to fit your PIC and hardware and try it out. No serial support, but it'll show you how the main loop can work PWM'ing with interrupts on the LEDs.
The LEDs MUST be on portA for this exact code to work right. If you split up the LEDs between different ports, they may flash a bit funny...

[The Master]

Ok, thanx. Im home now and im having a little trouble getting the timer interrupt working so ill read that file and see if i can get it working