On Wed, Jul 03, 2013 at 09:25:06PM +0800, Electronic Consultation wrote: > I want to have a second interrupt, it's allright if it's not exactly 1 s >=20 > Init > while forever: > State 1 > led on > counter to 100 ( tick from background on timer) > return > State 2 > led off > counter to 100 ( tick from background on timer) > goto state1 > return >=20 > The main purpose is not only a blink, blinking LED is only a test if=20 > the init,interrupt and state machine working properly, > Any clues ? I still cannot figure out why you are caught up with counting in the main loop. The interrupt handler is perfectly capable of doing the counting for you. Do you need a task that changes faster that 1S? If not, then there is no need for counting anything in the main loop. I think your perceptual problem is that you are thinking of a system that remains in a physical location of code for a certain amount of time as opposed to an event/trigger based system that monitors a series of triggers and does an action when the trigger fires. When organized this way the main loop can handle several tasks that are triggered by different events. So let's take your example as I understand it. You want to flash the LED on an off once per second. In addition you have another interrupt that does something else. From my previous analysis we determined that we can set Timer 0 to 1:64 prescale and generate 625 interrupts/S by counting up from -125. I'm going to presume that we've set up the Timer and the interrupts. So the code for the interrupt service routine will look something like: If TMR0IF is set reset TMR0 to -125 DECFSZ TICKERL done if it's not zero DECFSZ TICKERH done if it's not zero reset TICKERH:TICKERL to 625 set a ONESECOND Flag ENDIF We do the same for the second interrupt: IF Second_Hardware_Interrupt_Flag is set do what needs to be done to turn Flag off set SECOND_INTERRUPT software flag ENDIF You can of course add more of these if you like if you have other interrupts that need to be handled. In each case, take care of the hardware interrupt issue, then set a software flag indicating that something happened. Now on to the main loop. This loop can observe the software flags that are set in the interrupt routine, then do actions based on those flags. In your example STATE1 and STATE2 are triggered by the ONESECOND Flag, while your other code is triggered by the SECOND_INTERRUPT flag. To speed things up, we only do the state code when a new state has been detected because the ONESECOND flag is set. while forever: if ONESECOND flag is set: clear ONESECOND flag: move to the next state: if STATE1: do the STATE1 code elseif STATE2: do the STATE2 code endif ; Note you can add more states here if you l= ike endif if SECOND_INTERRUPT flag is set: clear SECOND_INTERRUPT flag do code for the second interrupt endif if THIRD_INTERRUPT flag is set: clear THIRD_INTERRUPT flag do code for the third interrupt endif done So the main loop spins forever checking the flags that come from the ISR. Honestly unless it's something that really timing dependent, I don't even bother with interrupts and simply integrate the ISR code directly into the main loop. So something like: while forever: If TMR0IF is set reset TMR0 to -125 DECFSZ TICKERL done if it's not zero DECFSZ TICKERH done if it's not zero reset TICKERH:TICKERL to 625 move to the next state: if STATE1: do the STATE1 code elseif STATE2: do the STATE2 code endif ; Note you can add more states here if you l= ike endif if SECOND_Hardware_INTERRUPT flag is set: clear SECOND_Hardware_INTERRUPT flag do code for the second interrupt endif done This code will run with interrupts off. Or you can mix and match with the more important items in an ISR while the lower priority stuff can remain in the main loop. The point is unless you have a computationally intensive piece of code, this can be extended to handle a bunch of items. I'm just trying to get you to rethink how to organize your project so that you can handle more tasks/triggers at the same time.=20 Hope this helps, BAJ > thanks > On 3/07/2013 8:26 PM, Byron Jeff wrote: > > On Wed, Jul 03, 2013 at 06:34:23PM +0800, Electronic Consultation wrote= : > >> Test > > Your posts are working. I saw the flowchart you posted. I see what you = are > > trying to do. What I still don't see is why you are trying to do it > > that way other than an intellectual exercise. Why is your code simply n= ot: > > > > Init > > while forever: > > State 1 > > Delay 1 second > > State 2 > > Delay 1 second > > > > Why is the code organized in 4 different files? Why are interrupts > > required? What you seem to have is a very complicated Blink an > > LED. > > > > To answer the question that you asked in the picture, there is no > > simple way to generate an interrupt precisely 1 second after entering s= tate > > 1 using timer 0. The best you can do is wait for a flag to be raised by= the > > ISR in the timer code on the top left that is triggered by counting fas= ter > > interrupts. > > > > But the design questions remain. If your program's job is only to be in > > state 1 or state 2 for a specific amount of time, then what is the purp= ose > > of your code organization? > > > > BAJ > > > >> On 2/07/2013 8:23 AM, IVP wrote: > >>>> get to the point where you understand where all these pieces go > >>> A flow chart on a piece of paper would be a good start for organising > >>> what needs to happen, when and how > >>> > >>> http://en.wikipedia.org/wiki/Flowchart > >>> > >>> Joe > >> --=20 > >> http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > >> View/change your membership options at > >> http://mailman.mit.edu/mailman/listinfo/piclist >=20 > --=20 > http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 Byron A. Jeff Chair: Department of Computer Science and Information Technology College of Information and Mathematical Sciences Clayton State University http://faculty.clayton.edu/bjeff --=20 http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .