Carol, On Wed, 29 Aug 2007 21:20:39 -0300, Carolina Dieguez wrote: > Howard, > One more thing... > Do you say "All the work is done in the ISR, which isn't ideal, > but it does work". Please, why do you think that? Well in this case it's not a problem because it's such a simple problem, but usually the main loop would be doing something - maybe a lot of things! - and having the interrupt routine take a lot of time is bad because it may delay something important in the main loop. As a general rule, you want to spend as little time as possible in the ISR. To turn this into a more generally useful solution, the ISR would just set an indicator to say that the 30 seconds is up and then return. Then within the main loop you'd check the indicator at a point where nothing critical is about to happen, and do the time-consuming part if the indicator is set. As I say, in this case there is nothing else happening, so it's not a problem. > Many thanks for takig your time to help me. No problem - I like to dabble in other peoples' programs from time to time - ask my former programming team and I'm sure they'd say I did it far too much! :-) Incidentally, doing this I discovered a new way of working, using PICkit2 and MPLAB. The latest software for PICkit2 has a button "Auto import Hex and write device", which when active will watch a .HEX file that you specify, and when it changes it programs the PIC with it. So I left this running, connected to the PICkit2 and its development board with the "Target power" on, and edited the program in MPLAB. When I did a Build that had no errors and resulted in a new .HEX file being created, it was seen by the PICkit2 software and immediately programmed into the PIC, which then ran the new version, so instead of a edit-compile-program-test cycle, it was just edit-compile and the rest happened automatically. Neat! :-) Cheers, Howard Winter St.Albans, England -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist