Code C - [expand] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 unsigned char state; void main() { state = 1; } static void interrupt isr() { if(T0IF) { T0IF = 0; TMR0 = -40; switch(state) { case 1: GPIO2 = ~GPIO2; state = 2; break; case 2: GPIO1 = ~GPIO1; state = 1; break; default: ; } } }
It may be required in some cases. If alternative code pathes exist in an ISR, there's nothing against a case structure. It's usually more effective than if..else..if spaghetti code.But its a bad design to use switch case in interrupt.
Code C - [expand] 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 #include <pic.h> __CONFIG(0x00C2); #define max_bit 16 unsigned int encode_val; volatile unsigned char state,encode_count; void start_tx(unsigned int val); static void interrupt isr() { if(T0IF) { T0IF = 0; TMR0 = -4; switch(state) { case 1: GPIO0 = ~GPIO0; state = 2; break; case 2: GPIO1 = ~GPIO1; state = 1; break; default: break; } } } void main() { CMCON0 = 7; ANSEL = 0; TRISIO = 0; start_tx(1); // TMR 0 configuation T0CS = 0; PSA = 0; PS2 = 1; // prescale 1:32 PS1 = 1; // PS0 = 1; // T0IE = 1; // TMR0 Interrupt GIE = 1;; } void start_tx(unsigned int val) { unsigned int i,parity = 0; for(i=0;i<max_bit;i++) { if((val>>i)&1) { parity++; } } if(parity&1) { encode_val = val | 0x8000; } state = 1; }
bhengsoh said:It shows me that the switch case is stuck at case 1 when timer interrupt.
Yes, I mentioned the same. There should be a while(1); at the end of main(), otherwise the code will possibly restart all over again.I don't see a main loop
FvM said:Yes, I mentioned the same.alexxx said:I don't see a main loop
It's O.K. to repeat this point, I didn't want to complain, just wondering why it's unchanged.Maybe you 're right and I should have used your words in quotes, sorry about that.
I use the timer overflow flag as interrupt, and that's how it get interrupt every few usec without main loop.
You previously reported state to be stuck in case 1 rather than GPIO not set correctly. Obviously this is not the same. Anyway, why do you assume a RMW problem? Do you overload the GPIO pins?Anyway, I believe it is the read-modify-write problem.
I won't assume, that your compiler is inserting arbitrary code for case structures. So the most likely explanation is, that the code is exactly representing the complexity of the problem. But we have to guess here, because you didn't show the real code. It's not important by the way, how many code lines are generated in total. The interesting point is, how many are executed in the active state.However, the switch case is really bothering me, as it is disassembled into many lines of codes, and the second interrupt might happen before the first interrupt end, especially when I have a long statement. But I still need it as my code will have like 7 cases.
Maybe your code is already taking care of this point, but at least you're excellent in ignoring pretty strong hints.you still need to have a loop to ensure that the execution never exits the main function
bhengsoh said:Another method I found online was to use array of pointer to function method, but I dunno it is worth or not.
That would be my guess, too. But in addition, they aren't available for PIC10 as far as I understand.Although I use function pointers I avoid them inside interrupt routines, because I get slower execution time.
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?