CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

PIC16F887 rs232 and timer conflict problem

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
ddcchh



Joined: 28 Jun 2012
Posts: 2

View user's profile Send private message

PIC16F887 rs232 and timer conflict problem
PostPosted: Thu Jun 28, 2012 12:12 am     Reply with quote

Here is my code, this project is to run a led cube 8x8x8

Last edited by ddcchh on Fri Jun 29, 2012 11:51 am; edited 1 time in total
Ttelmah



Joined: 11 Mar 2010
Posts: 19515

View user's profile Send private message

PostPosted: Thu Jun 28, 2012 1:32 am     Reply with quote

Get rid of the code disabling and enabling interrupts in INT_RDA.
The _hardware_ handles this.
You have an absolute 'killer' in there - a search here will find more, but you must _never_ repeat _never_ 'enable_interrupts(GLOBAL)' in an interrupt handler. Doing so, _will_ result in the code/chip giving unexpected results/crashing.
Second killer though is having delay_ms(1) in the timer interrupt.

Simple rule of thumb for interrupts, only to be broken if you _know_ exactly 'why', and what you are doing, is that each interrupt handler, should _just_ do the job the interrupt signifies, _and get out ASAP_. Delays in interrupts _will_ cause problems. You are stuck inside the timer interrupt for over 8mSec. At 9600bps, this means that 6 serial characters can have been lost.

Final thing, though it 'breaks' the comment about not using delays, is that you will almost certainly need:
Code:

void Latch_data()
{
   output_low(LATCH);
   delay_cycles(1);
   output_high(LATCH);
}


'delay_cycles(1)', just inserts a single 'nop' instruction. Performing an output_low, followed immediately by an output_high, is _not_ guaranteed to actually cycle the pin (depending on the loads present). The single machine cycle delay avoids problems with this.

You need to take all your code out of the timer2 interrupt, and just have this set a flag. Perform the SPI writes, and delays in the main code, when this flag is set (and clear it here). This then also moves all the delays outside the interrupts.

As a final thing, get rid of the 64 way loop in the RTCC. This will take an _age_. You are moving data from one memory area to another, so use memcpy. The 64 way loop you currently have, will take about 1800 machine instructions, using memcpy(test,newm,64); will be about 5* faster. Difference is that array accesses are individually slow. Accessing two arrays 'byte at a time', involves about 10 instructions of setup on each side of the copy instruction. memcpy, performs the setup once, and does a block copy. Much better......


Best Wishes
ddcchh



Joined: 28 Jun 2012
Posts: 2

View user's profile Send private message

PostPosted: Thu Jun 28, 2012 3:25 am     Reply with quote

Thanks it's working with smaller delay. I used delay_cycles(150); instead of delay_cycles(1) to make the LED light.

Many thanks.
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group