3 interruptions' conflicts

J.H.Sun · Joined: 27 Jun 2011 Posts: 4

Dear all

I use a pic18f458 to decode PWM signals from flight remote controller and tachometer. Also taking it to Receive the data from force gauge. That is I use " 3 " interruption simultaneously to decode the PWM, RPM and force. Now the execution of code is OK, but the accuracy is not well. When I just use CCP1 and CCP2 without using RDA,the RPM and PWM's accuracy is acceptable. While, if taking CCP1, CCP2 and RDA simultaneously to decode the signal, the error here will enlarge. The error here is likely that the true value is 2500, although the PIC can calculate 2500, but it will "jump" to 1500 very quick and back to 2500 repeatly. The frequency is not low. Therefore, I try to ask for help how to solve these kind of problems. I just think of tip if I could know the start time and end time of each interruption, maybe avoiding the conflict between 3 interruption is possible. But, how I could get the time ?? If different input signal, is it the same ??

Ttelmah · Joined: 11 Mar 2010 Posts: 19338

Critical thing is always 'keep interrupt handlers quick'.
Second thing is to understand that 'priority' does basically nothing. It sets the order in which interrupts are _polled_, but once you are inside an interrupt, unless you use hardware priority, the handler you are in, has to complete, _before_ another can occur. This is why it is always vital to get out of the handlers ASAP.

Now, your CCP1, and CCP2 handlers are quick. Your RDA handler is quick for 15 characters, but the 16'th, is appalling. You have loops inside loops (always slow), and at the centre, atof. I hate to think how long this routine will be, but, given that atof, tries to convert a value to 'float', and therefore can involve float maths. Uurgh!...
Repeat, and repeat again. Do as little as possible in interrupt handlers. If you want to do complex things, set a flag, and do these _outside_.
Rewrite your serial receive routine, in a manner like the EX_SISR. _Just_ buffer the data. Set a flag when you have a complete 'packet', and do the handling in the main code, when this flag is set.

Best Wishes

ckielstra · Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands

Just a few more remarks to save you future trouble:
1) Add the NOLVP fuse. Without this setting a glitch on the LVP pin (A6) will reset your processor.
2) Add the 'errors' directive to the #use rs232 line. This will have the compiler to add extra code to restart a stalled UART.
3) The atof function requires a zero terminated string. I doubt this is the case in your program.

In general, when working with embedded software it is better to never use floating point. Simple processors like the PIC have no floating point hardware and therefor it takes an incredible lot of processor instructions to do the math. Much better is to use a method called 'Fixed point integer' where you do calculations with normal integers and pretend there is a decimal point. For example, when you want to use the value 1.23 you do the math with the integer 123, and only in the final step when showing the calculation to the user you will insert the graphical '.'. The CCS compiler has the convenient %w parameter in the printf function to insert the dot sign for you. Fixed point integers are much faster than floating point, require less memory and are sometimes even more accurate (and sometimes less accurate).