user29770: If I want to create an interrupt and have it do something, can this 'something' be written in a regular function that I also use outside of the interrupt? 

user29899: You can do that, but it will increase the complexity of your program.
Often when entering an interrupt service routine, the first thing you do is disabling interrupts - the make sure the callback completes reliably. 
This is something you will have to consider if you want to use the same routine for a 'regular' scenario

user30005: 
If I want to create an interrupt and have it do something, can this 'something' be written in a regular function that I also use outside of the interrupt?

The right answer is yes and no.
The issue here is reentrancy : whether a function can be interrupted while it's being called by another. Not all functions are re entrant so the safer assumption is that they are.
Another issue with calling a function from within the isr is overhead.
The typical solutions are:

Make sure that the function called from the isr is re entrant.
The simplest way to assure that is to a. Limit your calling of that from the isr. Or b. Create two versions of the same function. And call them separately.

Btw, I routinely call functions from within isr. In my case through function pointers.

user31802: Yes you may.
Yet keep the function in question short, you don't want to spend too much time in interruption.
Another way is to set up a variable state in the interruption, and call the function in question in the normal cycle when the variable is in the desired state.

user7508: Yes, you can. You just have to make sure your function is reentrant.
If it accesses no memory beyond its parameters and (non static) local
variables, you should be fine. If it accesses global variables, hardware
registers, or static locals, it is unlikely to be, and only detailed
analysis will tell you for sure.
Beware also of the library functions you call: some of them are not
themselves reentrant and should therefore be avoided. See for example
the manual of strtok(), which explicitly addresses the
reentrancy problem.

29770: <p>If I want to create an interrupt and have it do something, can this 'something' be written in a regular function that I also use outside of the interrupt? </p>
 29899: <p>You can do that, but it will increase the complexity of your program.
Often when entering an interrupt service routine, the first thing you do is disabling interrupts - the make sure the callback completes reliably. 
This is something you will have to consider if you want to use the same routine for a 'regular' scenario</p>
 30005: <blockquote>
  <p>If I want to create an interrupt and have it do something, can this 'something' be written in a regular function that I also use outside of the interrupt?</p>
</blockquote>

<p>The right answer is yes and no.</p>

<p>The issue here is reentrancy : whether a function can be interrupted while it's being called by another. Not all functions are re entrant so the safer assumption is that they are.</p>

<p>Another issue with calling a function from within the isr is overhead.</p>

<p>The typical solutions are:</p>

<ol>
<li>Make sure that the function called from the isr is re entrant.</li>
<li>The simplest way to assure that is to a. Limit your calling of that from the isr. Or b. Create two versions of the same function. And call them separately.</li>
</ol>

<p>Btw, I routinely call functions from within isr. In my case through function pointers.</p>
 31802: <p>Yes you may.</p>

<p>Yet keep the function in question short, you don't want to spend too much time in interruption.</p>

<p>Another way is to set up a variable state in the interruption, and call the function in question in the normal cycle when the variable is in the desired state.</p>
 7508: <p>Yes, you can. You just have to make sure your function is <a href="https://en.wikipedia.org/wiki/Reentrancy_(computing)" rel="nofollow noreferrer">reentrant</a>.
If it accesses no memory beyond its parameters and (non <code>static</code>) local
variables, you should be fine. If it accesses global variables, hardware
registers, or <code>static</code> locals, it is unlikely to be, and only detailed
analysis will tell you for sure.</p>

<p>Beware also of the library functions you call: some of them are not
themselves reentrant and should therefore be avoided. See for example
<a href="http://www.nongnu.org/avr-libc/user-manual/group__avr__string.html#ga6ace85338eafe22a0ff52c00eb9779b8" rel="nofollow noreferrer">the manual of <code>strtok()</code></a>, which explicitly addresses the
reentrancy problem.</p>
