| ??? 10/29/04 11:48 Read: times |
#79998 - RE: Prog.CounterArray irq problem Responding to: ???'s previous message |
1. Is match has been detected really? By other words - when CH,CL == CCAP0, then is CCF0 bit set to 1? If match is not detected then it means that bit MATn was not set. Reasons of it: OK, Match have not been detected. I don't now how to verify: is matching occurs or no... 1a.1b. So, I verifyed all this once more. And i thing that here everyfing is all right. 2c. PCA module interrupt disable (ECCFn=0); I have a question: Have I to disable ECCFn, when i perfom CCAP0 increasing or no? As i understand, if EA and EC are cleared, there are no reasons to clear ECCFn in ISR. Am I right? 2d. the ISR has the same or lower priority level than current executed ISR. (For example, when match is detected inside PCA ISR then new ISR will not be executed until program leaves current ISR). I set EA = 0; so, how can this situation occurs? - you configured PCA module 0 to Compare Mode with CCAP0=0x0100. - you enable the interrupt (ECCF0=1, EC=1, EA=1) and start PCA timer. - at match (CH,CL=0x0100) the ISR is executed. - you increase CCAP0 with, let say, 0x0050 and so the new compare value loaded into CCAP0 is 0x0150. - during ISR, PCA timer (CH,CL) is not stopped, it still runs! It may happen that it counted upto 0x0200 before you setup new value into CCAP0. Take in consideration that it may occur not only because your code is huge and slow but because an interrupt with highter priority may take program execution time as well. - so let say, CH,CL is 0x0200 when you load 0x0150 into CCAP0. Then you leave ISR. Now, match control is enabled and PCA timer counts up. But its value is already above compare one! So it counts upto 0xFFFF then to 0x0000... And only when it comes to 0x0150 then new ISR is executed. I thaught about this possibity. It's very likely to be. But there are some misunderstandings for myself: 1) isr time is apprx. 10 mikrosec. Inc. value = 100 mikrosec. EA = 0... How can this situation occur? 2)I use module0 to measure time like this: t1 = get_module0_time(...); // some actions t2 = get_module0_time(...); When 'some actions' took long time - (t2-t1) is expected value. Bit when 'some actions' took small time (t2-t1) is unexpected value (because there is pca problem)... ____________________ And if you are right (your last idea), how to overcome such a problem. I'm interested in typical solutions.:) Thanks greatly, Regards, Zahar. |
| Topic | Author | Date |
| Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
| RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 |