Hi guys. I'm using interrupts for UART receiver and Comparator. Since, I already solved my previous problem. I would like to ask if it's okay to place function calls inside an interrupt routine? Thanks

 

It's not advised, what if another interrupt happens while the function is running?

Keep interrupt routines as absolutely short as possible. I limit mine to simply setting flags. Then in the main loop, I have several if (flag){do work} blocks, this keeps most all the processing outside the interrupt loop. If it is a short/quick task, such as getting a byte from UART buffer, that is OK for doing in the interrupt, but processing the byte and putting it on an LCD is too much.

Basic "rules" for interrupts:
1) Never miss processing an interrupt
1a: This means watch your code, be aware it may be interrupted at any time
1b: Don't set up too many interrupts, unless that is the basis of your system, such as a RTOS. Then the interrupts are ONLY used for the "Operating System", and all other communication is done with semaphores.

 

Thank you for your reply thatoneguy,

So it means that I have to check the flags always in a never ending loop? Will it consume a lot of battery?
Supposedly I provide these choices. What do you think is better?
1. while(1) loop is empty; interrupt function is handling functions for uart and for comparator, designated functions are called inside the interrupt function.
2. while(1) loop has the flags, interrupt functions only set flags for uart and for comparator, designated functions will then be called inside the main program.
3. while(1) contains if statements for checking uart received characters; uart receive interrupt is disabled and the only interrupt enabled is comparator

Which also will consume more power? I'm aiming for a program that can save its power.

 

I'm afraid I have to disagree.

It is quite normal to run other functions from inside the interrupt service routine particularly if you have more than one interrupt enabled. The normal procedure in that case is to check the interrupt flags and then call the appropriate function depending on which flag is set.

What you must not do however is call any function from inside the ISR that can also be called outside the ISR.

As for missing interrupts, as long as you use a bit of common sense and don't run long delay loops from inside the ISR, missing interrupts should not present a problem

When an interrupt occurs the processor automatically sets the relevant interrupt flag, jumps to the ISR and disables all further interrupts (clears GIE bit) but even though further interrupts are disables if another interrupt even occurs the relevant interrupt flag will get set. There is no need however to continually pole the flags. Returning from the ISR automatically sets the GIE bit enabling interrupts again but if any of the interrupt flags are set the processor will jump straight back to the ISR.

So the correct way to handle interrupts is:
1 In the ISR scan the interrupt flags, when you find one that is set
2 Clear the flag and then process the relevant interrupt (if you have more than one interrupt enabled its cleaner to use a separate function() for each one)
3 Return from the ISR, if more interrupts occurred while you were sevicing the original interrupt then the relevant flags will be set and the processor will jump right back to the ISR.

 

Thank you for your reply thatoneguy,

So it means that I have to check the flags always in a never ending loop? Will it consume a lot of battery?
Supposedly I provide these choices. What do you think is better?
1. while(1) loop is empty; interrupt function is handling functions for uart and for comparator, designated functions are called inside the interrupt function.
2. while(1) loop has the flags, interrupt functions only set flags for uart and for comparator, designated functions will then be called inside the main program.
3. while(1) contains if statements for checking uart received characters; uart receive interrupt is disabled and the only interrupt enabled is comparator

Which also will consume more power? I'm aiming for a program that can save its power.

Yes, I was thinking a more basic program, as you are just getting started with interrupts. Once you have a solid understanding of running multiple things and having it work, you will be more confident and able to write code such as AlexR has described.

I'm a believe in small steps when learning, and it is discouraging for members if their programs simply "never work" or glitch. So my post is at the Simplistic/paranoid end of the spectrum, where AlexR has posted a more common usage. The difference being knowing roughly how many cycles will be used in each function, what your interrupts are, etc.

 

Sorry for the delayed reply. Thanks a lot for the useful information. I learned new things. Can someone answer about my question about power consumption? If my while endless loop keeps on checking IF statements always (is this what we call "Polling"?), will it consume more power than having an empty while loop and just waiting for an interrupt to occur?

 

Any time the processor is running, it is using electrical power, and the amount doesn't change more than a trivial amount according to what kind of processing it's doing. If you want to save power, consider putting the processor into "sleep" mode and having the interrupt wake it up, if that's possible. If the interrupts aren't very frequent, that really would help.

Yes, "polling" in this case means checking a flag to see if an event has occurred.

 

The best way to save power is to run a dual clocked system, and run it at 3.3v.

Power consumption of a device is roughly V^2 * f

f is frequency, and changes linearly, ex, 1Mhz uses 1/4 the power of running at 4Mhz.

V is the supply voltage, so running at 3V instead of 5V also gives you 1/4 the power used.

There are a few low power app notes on running your uC at 32kHz in idle/polling mode, then switching to 4 or 20Mhz for the processing to take place if an interrupt or polling event indicated that action was required. Once the high speed processing is done, the clock can be reduced back to 32kHz (in software), or put into sleep mode (Where it will wake on an interrupt).

Check out microchips low power design tips and tricks PDF if you are concerned about battery life. First on the list would be running at 2-3V if possible, then using the lowest clock you can manage. Those two don't require code changes for power savings (other than defining the initial clock speed to a lower value).

Dynamic clocking and sleep save a massive amount of power, but require a good deal of coding to work with as well.

 

The best way to save power is to run a dual clocked system, and run it at 3.3v.

Power consumption of a device is roughly V^2 * f

f is frequency, and changes linearly, ex, 1Mhz uses 1/4 the power of running at 4Mhz.

V is the supply voltage, so running at 3V instead of 5V also gives you 1/4 the power used. Newer PICs will run stable down to under 2v and up to 5v.

There are a few low power app notes on running your uC at 32kHz in idle/polling mode, then switching to 4 or 20Mhz for the processing to take place if an interrupt or polling event indicated that action was required. Once the high speed processing is done, the clock can be reduced back to 32kHz (in software), or put into sleep mode (Where it will wake on an interrupt).

Check out microchips low power design tips and tricks PDF if you are concerned about battery life. First on the list would be running at 2-3V if possible, then using the lowest clock you can manage. Those two don't require code changes for power savings (other than defining the initial clock speed to a lower value).

Dynamic clocking and sleep save a massive amount of power, but require a good deal of coding to work with as well.

 

Thanks John P and thanks also thatoneguy, well said