PIC speed problems

[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

[skimask]

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

You're still using a 16F87 right?
How about your hardware? How's that all hooked up? LEDs? Serial input? Anything else hooked up?
Get me that info...lemme cook on it for a bit...

[The Master]

Ive managed to sort it out. I almost came back with the info but i wanted to try and fix it myself. Ok, it took about 3 hours but i got there in the end.

Ive tried changing the pre-scaler too. i thought maybe a 2:1 ratio would free up a little extra processing time. Well, in theory it should because the PWM side of things is only using half the processing power. Unfortunately it didnt affect it in the way i wanted at all. All it did was make the lights flicker a bit because they were flashing too slow so i disabled the pre-scaler.

Now then, theres a sort of random problem. I currently have VB 6 in a loop sending 513 bytes of data. The PIC is processing the data and setting the PWM values. Well, its setting the same values over and over but its still processing and holding different colors in different PWM positions. Its actually working perfect

Now the random problem. If i have a scroll bar that sends the data in the onchange/onscroll then the LEDs flicker quite bad. I really dont understand how that could happen. The circuit is obv working and im sending 513 bytes of data so the baud rate isnt so high that its affecting it. The only thing i can think of is the gap between the last byte and the first byte of the next set of data is less than the gap between the bytes in 1 packet. That seems impossible though and if it did that then i wouldnt have thought you would notice.

Do you have any ideas? I just cant get my head around this one

Edit: Ive added some code to time the serial data going out of VB. Aparently it sends a full 513 bytes every 35-46 milliseconds and thats when it works fine

[The Master]

I have a theory! I just added some code to the loop (the working part) to change the value of the red LEDs and its started flickering a little. I belive the problem is in the way ive done the PWM.

The PWM counter starts at 255. Everytime TMR0 overflows it decrements that value then compares it with the value of each LED. If they match then it turns the LED on. When it gets to 0 it resets back to 255 and turns off any LEDs whos value is less than 255. I think that by changing the value sometimes the PWM counter "misses" the LEDs value so it never turns on until the PWM counter resets to 255 and comes around to the new value.

When testing DT's code i think he does it the oposite way. Turn the LEDs on and count up then turn them off when the value matches. When testing that code the LEDs seemed to flash brightly rather than turn off for half a second.

Im gonna try and fix that problem but again i wouldnt have thought missing 1 PWM cycle would affect the LEDs that bad