user27355: For a driving application I need the PWM mode to be phase correct and the prescaler to be 1. The issue is that the board I am working with has the load hooked up to a PWM pin reliant on timer0. The firmware running on this board makes use of the delay(), delayMicroseconds(), and millis() functions from wiring.c. The goal is to make the timer0 change, shown below, and then make small modifications where the firmware calls the wiring.c timing functions. My approach was to find a scaling factor to be applied to the call of these functions. The scaling factor I came to was 32.12549, calculated by taking the wiring.c expected timer0 behavior: prescaler=64 and TOV0 flag every 256 counts, and comparing it to the actual values after my change: prescaler=1 and TOV0 flag every 510 counts
Calculation: 64*256/510=32.12549
Timer0 change:
// Set timer0 to phase correct PWM
TCCR0A = TCCR0A & 0b11111100 | 0x01;

// Set prescaler for timer0 to 1
TCCR0B = TCCR0B & 0b11111000 | 0x01;

The other timers are all configured in phase correct PWM mode, with a prescaler of 1.
...When I apply this scaling factor to a value returned from millis() to keep time it works well. For example the two pieces of code below proved to be equivalent through the timer0 change:
Use of millis() before timer0 change:
//current time
long unsigned now = millis();

//delay for 1 second
while(millis() - now < 1000){}

Use of millis() after timer0 change:
//current time
long unsigned now = millis();

//delay for 1 second, with x32.125 scaling coefficient
while(millis() - now < 32125){}

The two snippets of code above both delayed for 1 second
Now comes the problem: when I try to apply that same scaling factor to delay() or delayMicroseconds() it seems to give unreasonable delays...
Use of delayMicroseconds() before timer0 change:
// wait 1.5ms for mux to switch
delayMicroseconds(1500);

...this delays for 1.5ms
Use of delayMicroseconds() after timer0 change:
// wait 1.5ms for mux to switch, with x32.125 scaling coefficient
delayMicroseconds(48188);

...this delays for ~20ms. 
Assuming this is still linearly scalable:
 if 48188 -> 20ms, therefore 1.5ms -> 3614 
But when the following code is used...
// wait 1.5ms for mux to switch, scaled
delayMicroseconds(3614);

...this delays for ~4.5ms
Why is it that delayMicroseconds() and delay() cannot be linearly scaled to account for a timer0 change? Furthermore, is there any simple modification to how these functions are called or utilized that can account for the effect of changing timer0?

user7508: The millis() roll over
By making Timer 0 faster, your millis() will roll over much more
often than normal: every 37.1 hours instead of every 49.7 days. Thus,
when you “scale” millis(), you should be careful to do it in a
rollover-safe way. From the code you show, it appears that you are doing
exactly the right thing. Well done! Don't change anything. Don't be
tempted to scale the value returned by millis().
The overflow in delayMicroseconds()
As this function just burns cycles in a busy loop, it is not affected by
your configuration of Timer 0. You can just use it as is, with no
scaling. Beware however that it's argument should always be smaller than
16384 (on a 16 MHz board). Otherwise it will overflow when it is
multiplied by 4 in order to get a loop count.
For example, when you call delayMicroseconds(48188);, the function
computes the number of loop iterations to make as
48188 × 4 − 5 = 61675 (modulo 216)
Then, it burns about 15 ms of CPU time (0.25 µs per
iteration), which is close to the 20 ms you see. For the
difference, see below.
The cycles burned by the Timer 0 ISR
This ISR, which keeps the millis() counter updated, is supposed to run
every 1024 µs. Each time it runs it burns a few cycles, but it's
usually not a big deal. With your new timer configuration, it is now
running far more often: every 31.875 µs.
From the numbers you give in the question, I would say the ISR is
eating about 20% of your CPU power: when you call
delayMicroseconds(3614);, that function burns 3614 µs of CPU
time, yet you measure a delay of about 4500 µs. The difference is
taken by the Timer 0 ISR.
Use another timer for millis()
If you can spare a timer, you could both restore the normal behavior of
millis() and avoid wasting so much CPU in the Timer 0 ISR:

configure Timer 0 to not trigger interrupts
configure your spare timer just like the Arduino core would normally
configure Timer 0
write an overflow ISR for your spare timer that just calls the Timer 0
overflow ISR.

This way your spare timer is basically replacing Timer 0. Example using
Timer 2:
// This Timer 2 overflow ISR simply forwards the call to the Timer 0
// overflow ISR from Arduino core.
ISR(TIMER0_OVF_vect);
ISR(TIMER2_OVF_vect, ISR_NAKED) {
    TIMER0_OVF_vect();
    asm volatile("reti");

    // Alternatively, just:
    // asm volatile("jmp __vector_16");
}

void setup()
{
    // Set timer0 to phase correct PWM
    TCCR0A = (TCCR0A & 0b11111100) | 0x01;

    // Set prescaler for timer0 to 1
    TCCR0B = (TCCR0B & 0b11111000) | 0x01;

    // Disable Timer 0 interrupts.
    TIMSK0 = 0;

    // Configure Timer 2 to replace Timer 0.
    TCCR2A = _BV(WGM20)   // fast PWM, TOP = 0xff
           | _BV(WGM21);  // ditto
    TCCR2B = _BV(CS22);   // clock at F_CPU / 64
    TIMSK2 = _BV(TOIE2);  // enable overflow interrupt

    pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
    // Blink the LED at 1 Hz.
    uint32_t now = millis();
    static uint32_t last_toggle;
    if (now - last_toggle >= 500) {
        last_toggle += 500;
        digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
    }
}

I wrote a “naked” ISR to avoid having plenty of CPU registers saved and
restored twice (once by each ISR in the call chain), but then I had to
put the return instruction explicitly in assembly (ret and reti
would be equivalent in this instance). The version with jmp is
slightly more efficient, but you have to know the “real” name of the
ISR, which is MCU-dependent (__vector_16 on an Uno).
Notice that with this technique micros() will not work, as it reads
TCNT0 directly. And delay() will not work either because it relies on
micros().

27355: <p>For a driving application I need the PWM mode to be phase correct and the prescaler to be 1. The issue is that the board I am working with has the load hooked up to a PWM pin reliant on timer0. The firmware running on this board makes use of the <code>delay()</code>, <code>delayMicroseconds()</code>, and <code>millis()</code> functions from wiring.c. The goal is to make the timer0 change, shown below, and then make small modifications where the firmware calls the wiring.c timing functions. My approach was to find a scaling factor to be applied to the call of these functions. The scaling factor I came to was <strong>32.12549</strong>, calculated by taking the wiring.c expected timer0 behavior: <strong>prescaler=64</strong> and <strong>TOV0 flag every 256 counts</strong>, and comparing it to the actual values after my change: <strong>prescaler=1</strong> and <strong>TOV0 flag every 510 counts</strong></p>

<p><strong>Calculation:</strong> 64*256/510=32.12549</p>

<p><strong>Timer0 change:</strong></p>

<pre><code>// Set timer0 to phase correct PWM
TCCR0A = TCCR0A &amp; 0b11111100 | 0x01;

// Set prescaler for timer0 to 1
TCCR0B = TCCR0B &amp; 0b11111000 | 0x01;
</code></pre>

<p>The other timers are all configured in phase correct PWM mode, with a prescaler of 1.</p>

<p>...When I apply this scaling factor to a value returned from millis() to keep time it works well. For example the two pieces of code below proved to be equivalent through the timer0 change:</p>

<p><strong>Use of <code>millis()</code> before timer0 change:</strong></p>

<pre><code>//current time
long unsigned now = millis();

//delay for 1 second
while(millis() - now &lt; 1000){}
</code></pre>

<p><strong>Use of <code>millis()</code> after timer0 change:</strong></p>

<pre><code>//current time
long unsigned now = millis();

//delay for 1 second, with x32.125 scaling coefficient
while(millis() - now &lt; 32125){}
</code></pre>

<p><strong>The two snippets of code above both delayed for 1 second</strong></p>

<p>Now comes the problem: when I try to apply that same scaling factor to <code>delay()</code> or <code>delayMicroseconds()</code> it seems to give unreasonable delays...</p>

<p><strong>Use of <code>delayMicroseconds()</code> before timer0 change:</strong></p>

<pre><code>// wait 1.5ms for mux to switch
delayMicroseconds(1500);
</code></pre>

<p>...this delays for 1.5ms</p>

<p><strong>Use of <code>delayMicroseconds()</code> after timer0 change:</strong></p>

<pre><code>// wait 1.5ms for mux to switch, with x32.125 scaling coefficient
delayMicroseconds(48188);
</code></pre>

<p>...this delays for ~20ms. </p>

<p>Assuming this is still linearly scalable:
 if 48188 -> 20ms, therefore 1.5ms -> 3614 </p>

<p>But when the following code is used...</p>

<pre><code>// wait 1.5ms for mux to switch, scaled
delayMicroseconds(3614);
</code></pre>

<p>...this delays for ~4.5ms</p>

<p>Why is it that <code>delayMicroseconds()</code> and <code>delay()</code> cannot be linearly scaled to account for a timer0 change? Furthermore, is there any simple modification to how these functions are called or utilized that can account for the effect of changing timer0?</p>
 7508: <h2>The millis() roll over</h2>

<p>By making Timer 0 faster, your <code>millis()</code> will roll over much more
often than normal: every 37.1 hours instead of every 49.7 days. Thus,
when you “scale” <code>millis()</code>, you should be careful to do it in a
rollover-safe way. From the code you show, it appears that you are doing
<em>exactly the right thing</em>. Well done! Don't change anything. Don't be
tempted to scale the value returned by <code>millis()</code>.</p>

<h2>The overflow in delayMicroseconds()</h2>

<p>As this function just burns cycles in a busy loop, it is not affected by
your configuration of Timer 0. You can just use it as is, with no
scaling. Beware however that it's argument should always be smaller than
16384 (on a 16 MHz board). Otherwise it will overflow when it is
multiplied by 4 in order to get a loop count.</p>

<p>For example, when you call <code>delayMicroseconds(48188);</code>, the function
computes the number of loop iterations to make as</p>

<p>48188 × 4 − 5 = 61675 (modulo 2<sup>16</sup>)</p>

<p>Then, it burns about 15&nbsp;ms of CPU time (0.25&nbsp;µs per
iteration), which is close to the 20&nbsp;ms you see. For the
difference, see below.</p>

<h2>The cycles burned by the Timer 0 ISR</h2>

<p>This ISR, which keeps the millis() counter updated, is supposed to run
every 1024&nbsp;µs. Each time it runs it burns a few cycles, but it's
usually not a big deal. With your new timer configuration, it is now
running far more often: every 31.875&nbsp;µs.</p>

<p>From the numbers you give in the question, I would say the ISR is
eating about 20% of your CPU power: when you call
<code>delayMicroseconds(3614);</code>, that function burns 3614&nbsp;µs of CPU
time, yet you measure a delay of about 4500&nbsp;µs. The difference is
taken by the Timer 0 ISR.</p>

<h2>Use another timer for millis()</h2>

<p>If you can spare a timer, you could both restore the normal behavior of
<code>millis()</code> and avoid wasting so much CPU in the Timer 0 ISR:</p>

<ul>
<li>configure Timer 0 to <em>not</em> trigger interrupts</li>
<li>configure your spare timer just like the Arduino core would normally
configure Timer 0</li>
<li>write an overflow ISR for your spare timer that just calls the Timer 0
overflow ISR.</li>
</ul>

<p>This way your spare timer is basically replacing Timer 0. Example using
Timer 2:</p>

<pre class="lang-c++ prettyprint-override"><code>// This Timer 2 overflow ISR simply forwards the call to the Timer 0
// overflow ISR from Arduino core.
ISR(TIMER0_OVF_vect);
ISR(TIMER2_OVF_vect, ISR_NAKED) {
    TIMER0_OVF_vect();
    asm volatile("reti");

    // Alternatively, just:
    // asm volatile("jmp __vector_16");
}

void setup()
{
    // Set timer0 to phase correct PWM
    TCCR0A = (TCCR0A &amp; 0b11111100) | 0x01;

    // Set prescaler for timer0 to 1
    TCCR0B = (TCCR0B &amp; 0b11111000) | 0x01;

    // Disable Timer 0 interrupts.
    TIMSK0 = 0;

    // Configure Timer 2 to replace Timer 0.
    TCCR2A = _BV(WGM20)   // fast PWM, TOP = 0xff
           | _BV(WGM21);  // ditto
    TCCR2B = _BV(CS22);   // clock at F_CPU / 64
    TIMSK2 = _BV(TOIE2);  // enable overflow interrupt

    pinMode(LED_BUILTIN, OUTPUT);
}

void loop()
{
    // Blink the LED at 1 Hz.
    uint32_t now = millis();
    static uint32_t last_toggle;
    if (now - last_toggle &gt;= 500) {
        last_toggle += 500;
        digitalWrite(LED_BUILTIN, !digitalRead(LED_BUILTIN));
    }
}
</code></pre>

<p>I wrote a “naked” ISR to avoid having plenty of CPU registers saved and
restored <em>twice</em> (once by each ISR in the call chain), but then I had to
put the return instruction explicitly in assembly (<code>ret</code> and <code>reti</code>
would be equivalent in this instance). The version with <code>jmp</code> is
slightly more efficient, but you have to know the “real” name of the
ISR, which is MCU-dependent (<code>__vector_16</code> on an Uno).</p>

<p>Notice that with this technique <code>micros()</code> will not work, as it reads
TCNT0 directly. And <code>delay()</code> will not work either because it relies on
<code>micros()</code>.</p>
