Searching \ for '[PIC] HI-TEC C interrupts question' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ints.htm?key=interrupt
Search entire site for: 'HI-TEC C interrupts question'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] HI-TEC C interrupts question'
2012\04\21@043912 by Goran Hosinsky

flavicon
face
Can do a GOTO from an interrupt and continue in another part of the main program - or will the return
from interrupt mix up the program?

I spend most of the time in  __delay_ms with delays of 30 seconds. In case of an UART interrupt I need to
get out of the delay routine, do some housekeeping (closing ports) and go elsewhere in main where I will
handle the rs232 data.

Goran, Canary Islands

2012\04\21@083042 by Brendan Gillatt

flavicon
face
On 21 April 2012 09:31, Goran Hosinsky <spam_OUThosinskyTakeThisOuTspam8gh.com> wrote:
> Can do a GOTO from an interrupt and continue in another part of the main
> program - or will the return
> from interrupt mix up the program?

Using a GOTO itself is no biggie, the problem comes with making sure
the code being "GOTOed" works concurrently without error. For example,
if your code uses a global variable (not on a stack) GOTOing to the
routine from an interrupt while it is being executed from the main
code will almost certainly clobber the variable.

> I spend most of the time in  __delay_ms with delays of 30 seconds. In
> case of an UART interrupt I need to
> get out of the delay routine, do some housekeeping (closing ports) and
> go elsewhere in main where I will
> handle the rs232 data.

If I understand correctly, you want the interrupt routine to cancel
the delay loop and execute a different bit of code. This isn't going
to work with a simple GOTO from the interrupt handler: you can execute
the other bit of code but at some point in time you will have to
return from the interrupt context so that future interrupts can be
handled. At this point your new execution point will have to stop and
the old code (inside the delay loop) will continue as before. If the
new code is fairly short this may not be a problem (does it matter if
the delay code is extended by the length of the alternative code?).
YMMV.

A better way to do that would be to have a flag (a binary semaphore in
concurrent processing nomenclature) which is set by the interrupt when
the jump should be performed. The delay loop (which is by nature
executing instructions continuously) can poll the flag and execute the
GOTO from the main code. Since testing for a flag can be done in a
fixed number of cycles (two for a BTFSS) the timing delay can be
adjusted to accommodate the extra instructions.

Best regards,
Brendan

-- Brendan Gillatt
http://www.brendangillatt.co.uk

2012\04\21@092838 by alan.b.pearce

face picon face
> A better way to do that would be to have a flag (a binary semaphore in
> concurrent processing nomenclature) which is set by the interrupt when
> the jump should be performed. The delay loop (which is by nature
> executing instructions continuously) can poll the flag and execute the
> GOTO from the main code. Since testing for a flag can be done in a
> fixed number of cycles (two for a BTFSS) the timing delay can be
> adjusted to accommodate the extra instructions.

I agree - in fact it sounds like the OP should be using a state machine in the code where delays are being used, and look to the interrupt to notify a change of state, unless the delay times out giving a different change of state.

-- Scanned by iCritical.

2012\04\21@103515 by Goran Hosinsky

flavicon
face
I am perhaps going at this in the wrong way. It is a watering system and I need delays in the range of 10's of
minutes up to many hours. The chip is a 16F887 and for the delays I use the HI-TEC C __delay_ms()  macro.
This macro can handle delays up to about 50 seconds and I use a loop with it to get the necessary total delay.
I would like to be able to interrupt via RS323 and change the parameters for the watering. The precision of the
timing is not important.

I am afraid that my experience with PIC is very limited and my last programming in C was many years ago.

Goran

On 2012-04-21 14:28, .....alan.b.pearceKILLspamspam@spam@stfc.ac.uk wrote:
>> A better way to do that would be to have a flag (a binary semaphore in
>> concurrent processing nomenclature) which is set by the interrupt when
>> the jump should be performed. The delay loop (which is by nature
>> executing instructions continuously) can poll the flag and execute the
>> GOTO from the main code. Since testing for a flag can be done in a
>> fixed number of cycles (two for a BTFSS) the timing delay can be
>> adjusted to accommodate the extra instructions.
> I agree - in fact it sounds like the OP should be using a state machine in the code where delays are being used, and look to the interrupt to notify a change of state, unless the delay times out giving a different change of state.

2012\04\21@114051 by David
flavicon
face
On 21/04/2012 15:33, Goran Hosinsky wrote:
> I am perhaps going at this in the wrong way. It is a watering system and
> I need delays in the range of 10's of
> minutes up to many hours. The chip is a 16F887 and for the delays I use
> the HI-TEC C __delay_ms()  macro.
> This macro can handle delays up to about 50 seconds and I use a loop
> with it to get the necessary total delay.
> I would like to be able to interrupt via RS323 and change the parameters
> for the watering. The precision of the
> timing is not important.

If I was aiming to do this I would probably approach it:

1) Calculate a fixed period delay that divides into your minimum "off"
time.  Ideally you should be able to use a hardware timer for this that
can work while the device is in sleep mode.

2) Sleep for 99% of the time.  Great for batteries.

3) Wake the device when the timer fires, increment a counter.  Set a
flag, defined like 'volatile char timer_flag'[1].  I would do this in
the ISR.

4) Check for the timer_flag.  If set, see if the number of interrupts
(e.g. 5 * 1 minute = 5 minutes) is now greater than your "off" time.  If
so start watering.  I would do all of this in the main loop.

5) Go back to sleep.

Using interrupts makes it easier to add other features.  If you want to
wake on RS232 you can, it's just another interrupt and another variable
"flag".  Timer reloads and peripheral (e.g. TMR0IF) resets obviously
need to be accounted for in the ISR.

Note you don't actually have to "sleep" the PIC hardware if you don't
want to.  I have used this approach for everything from decoding IR
(microseconds) to sleeping for hours (waking once a minute for 3 above).

To me this is a very simple version of the "state machine" that Alan
mentioned.  I'd draw a flowchart, perhaps there's a good website that
can produce them quickly.

If you'd like I can throw up some code on pastebin that illustrates the
above.

David

1 - Whilst not ANSI C compliant Hi-Tech will allow unsigned bit
timer_flag, which is what I'd normally use

2012\04\21@134203 by Goran Hosinsky

flavicon
face
Thanks David for your comments. I will change the logic and use a timer instead for the Hitec
inbuilt delay function. This should resolve the problem and, as you say, leave the possibility for
other types of interrupt open,

Goran

On 2012-04-21 16:40, David wrote:
{Quote hidden}

> timer_flag, which is what I'd normally use

2012\04\22@021230 by cdb

flavicon
face
If you get stuck, I have some code for a water timer that is publicly available (published as a project in Nuts and Volts magazine). It isn't in HiTech 'C' but it is in 'C' and should be easily portable.

Colin
--
cdb, colinspamKILLspambtech-online.co.uk on 22/04/2012
Web presence: http://www.btech-online.co.uk   Hosted by:  http://www.justhost.com.au
 This email is to be considered private if addressed to a named  individual or Personnel Department, and public if addressed to a blog,  forum or news article.

2012\04\22@174945 by Brent Brown

picon face
On 21 Apr 2012 at 9:31, Goran Hosinsky wrote:

> Can do a GOTO from an interrupt and continue in another part of the main
> program - or will the return
> from interrupt mix up the program?
>
> I spend most of the time in  __delay_ms with delays of 30 seconds. In
> case of an UART interrupt I need to
> get out of the delay routine, do some housekeeping (closing ports) and
> go elsewhere in main where I will
> handle the rs232 data.

Hi Goran. No problem with the interrupt interrupting the delay routine... interrupts are made for interrupting, so that part is ok. But yes you will have major problems if you try to use a GOTO to get back to some other part of the main program from the interrupt routine.

One method would be to get the Interrupt routine to set a flag when RS232 data has been received. In some of my applications the interrupt routine also does some basic parsing/filtering of the data, taking care not to spend too much time in the interrupt routine so it can be rady to respond to the next received character, and then the flag is only set when valid data has been received. You mentioned in another post that your 30 second delay is a loop of smaller delays. Somewhere within the delay loop you could check for the received data flag, perhaps exiting the delay altogether to process the data and do whatever else needs to be done.

-- Brent Brown, Electronic Design Solutions
9 Titoki Place, Pukete,
Hamilton 3200, New Zealand
Ph: +64 7 849 0069
Fax: +64 7 849 0071
Cell: +64 27 433 4069
eMail:  .....brent.brownKILLspamspam.....clear.net.nz

More... (looser matching)
- Last day of these posts
- In 2012 , 2013 only
- Today
- New search...