user41570: I wanted to run the following code as something similar to Tone or pwm. However for some reason that I am unable to seek it doesn't work.
#define WAIT 3200UL

void setup() {
  DDRB |= B00000001;  // set pin8 as output
}

void loop() {
  unsigned long t;
  while (1) {

    PORTB &= B11111110; // clear pin 8
    
    for (t = 0 ; t < WAIT; t++);

    PORTB |= B00000001; // set pin 8
    
    for (t = 0; t < WAIT; t++);


    //            PORTB &= B11111110;
    //            delayMicroseconds(WAIT);
    //            PORTB |= B00000001;
    //            delayMicroseconds(WAIT);

  }
}

the code is pretty simple, just toggling a pin. If I use the commented section, it works fine but as is, it doesn't work.
I removed the "while(1)" statement since it was unnecessary for now, it started to work improperly, (changing the WAIT didn't have any effect and I'm not sure I'm getting a full swing).
Pin 8 is connected to an LED + R to ground and a piezzo in parallel to them. the LED seems to be steady on yet the buzzer makes a low noise. I measured a   voltage of 3.8v DC and arround 9v AC on the pin, other pins I ran the code for were similar.
As another attempt I put a Serial.print in the beginning of the while(1) but it printed out only once.
Also looked at the assembly code generated for a clue to find out what does delayMicroseconds() do but couldn't figure out what's wrong.
Appreciate your help.

user31105: First
t = WAIT;
for (t = 0; t < WAIT; t++);

The first statement is not useful, since t will be assigned to 0 in the for loop.
However, since t is not used, probably it is optimized and removed by the compiler, meaning it will not perform a delay.
You should make t volatile. This prevents the compiler from optimizing it (out).
The only difference with or without the infinite loop is that variable t does not need to be allocated for (and keeps its value from the previous loop), but since the value is overwritten it does not make a difference.

user7508: First, I will give you some unsolicited advise about your coding style.
Instead of writing:
PORTB &= B11111110;
...
PORTB |= B00000001;

you could write:
PORTB &= ~_BV(PB0);
...
PORTB |= _BV(PB0);

These are standard AVR idioms, and they make it clearer that you are
toggling the pin PB0.
Then, to answer your actual question, your delay loop does not work
because it got optimized-out by the compiler. This has already been said
in Michel Keijzers' answer, but let me elaborate.
All modern compilers are optimizing compilers. This means they can
change your code in whatever way they see fit, as long as the visible
effects remain the same. The effects considered visible are usually
I/O and access to variables declared volatile. Quite importantly, the
slowness of the program is not considered a visible effect for the
purpose of optimization. And if you think about it, it makes good sense:
if the slowness of the program were to be preserved, then any form of
optimization would be impossible. Thus, a loop that has no effect other
than slowing your program down can legitimately be optimized-out.
The solution to your problem is quite simple: if you want a delay, then
call delayMicroseconds(). Or maybe even delay() if you are OK with
its low resolution. On the other hand, if you need sub-microsecond
resolution, you can call _delay_us(), from the avr-libc. This function
(or rather, macro) provides single-cycle resolution. If you write
#include <util/delay.h>

...
_delay_us(1.375);

you get exactly what you ask for, i.e. a delay of 22 CPU cycles
(on an Arduino Uno clocked at 16 MHz). The issues with this
function are that it is AVR-specific, and its argument must be a
compile-time constant.
It has been suggested to you to write your delay loop using a volatile
loop counter. I strongly advise you against doing that, for three
reasons:

Doing so will force the counter to be allocated to RAM, thus
consuming a scarce and valuable resource for no good reason.
Incrementing a RAM-based 32-bit counter takes 20 CPU cycles. Add
to this the time required to test the end-of-loop condition and you
will realize that your delay resolution is way worse than that of
delayMicroseconds().
Your actual delay will depend on the clock frequency, and probably
also on the compiler's version, making your code pretty fragile.


41570: <p>I wanted to run the following code as something similar to Tone or pwm. However for some reason that I am unable to seek it doesn't work.</p>
<pre><code>#define WAIT 3200UL

void setup() {
  DDRB |= B00000001;  // set pin8 as output
}

void loop() {
  unsigned long t;
  while (1) {

    PORTB &amp;= B11111110; // clear pin 8
    
    for (t = 0 ; t &lt; WAIT; t++);

    PORTB |= B00000001; // set pin 8
    
    for (t = 0; t &lt; WAIT; t++);


    //            PORTB &amp;= B11111110;
    //            delayMicroseconds(WAIT);
    //            PORTB |= B00000001;
    //            delayMicroseconds(WAIT);

  }
}
</code></pre>
<p>the code is pretty simple, just toggling a pin. If I use the commented section, it works fine but as is, it doesn't work.</p>
<p>I removed the &quot;while(1)&quot; statement since it was unnecessary for now, it started to work improperly, (changing the WAIT didn't have any effect and I'm not sure I'm getting a full swing).</p>
<p>Pin 8 is connected to an LED + R to ground and a piezzo in parallel to them. the LED seems to be steady on yet the buzzer makes a low noise. I measured a   voltage of 3.8v DC and arround 9v AC on the pin, other pins I ran the code for were similar.</p>
<p>As another attempt I put a Serial.print in the beginning of the while(1) but it printed out only once.</p>
<p>Also looked at the assembly code generated for a clue to find out what does delayMicroseconds() do but couldn't figure out what's wrong.</p>
<p>Appreciate your help.</p>
 31105: <p>First</p>

<pre><code>t = WAIT;
for (t = 0; t &lt; WAIT; t++);
</code></pre>

<p>The first statement is not useful, since t will be assigned to 0 in the for loop.</p>

<p>However, since t is not used, probably it is optimized and removed by the compiler, meaning it will not perform a delay.</p>

<p>You should make t volatile. This prevents the compiler from optimizing it (out).</p>

<p>The only difference with or without the infinite loop is that variable t does not need to be allocated for (and keeps its value from the previous loop), but since the value is overwritten it does not make a difference.</p>
 7508: <p>First, I will give you some unsolicited advise about your coding style.
Instead of writing:</p>

<pre><code>PORTB &amp;= B11111110;
...
PORTB |= B00000001;
</code></pre>

<p>you could write:</p>

<pre><code>PORTB &amp;= ~_BV(PB0);
...
PORTB |= _BV(PB0);
</code></pre>

<p>These are standard AVR idioms, and they make it clearer that you are
toggling the pin PB0.</p>

<p>Then, to answer your actual question, your delay loop does not work
because it got optimized-out by the compiler. This has already been said
in Michel Keijzers' answer, but let me elaborate.</p>

<p>All modern compilers are <em>optimizing</em> compilers. This means they can
change your code in whatever way they see fit, as long as the <em>visible
effects</em> remain the same. The effects considered <em>visible</em> are usually
I/O and access to variables declared <code>volatile</code>. Quite importantly, the
<em>slowness</em> of the program is <em>not</em> considered a visible effect for the
purpose of optimization. And if you think about it, it makes good sense:
if the slowness of the program were to be preserved, then any form of
optimization would be impossible. Thus, a loop that has no effect other
than slowing your program down can legitimately be optimized-out.</p>

<p>The solution to your problem is quite simple: if you want a delay, then
call <code>delayMicroseconds()</code>. Or maybe even <code>delay()</code> if you are OK with
its low resolution. On the other hand, if you need sub-microsecond
resolution, you can call <code>_delay_us()</code>, from the avr-libc. This function
(or rather, macro) provides single-cycle resolution. If you write</p>

<pre><code>#include &lt;util/delay.h&gt;

...
_delay_us(1.375);
</code></pre>

<p>you get <em>exactly</em> what you ask for, i.e. a delay of 22&nbsp;CPU cycles
(on an Arduino Uno clocked at 16&nbsp;MHz). The issues with this
function are that it is AVR-specific, and its argument must be a
compile-time constant.</p>

<p>It has been suggested to you to write your delay loop using a <code>volatile</code>
loop counter. I strongly advise you <em>against</em> doing that, for three
reasons:</p>

<ol>
<li>Doing so will force the counter to be allocated to RAM, thus
consuming a scarce and valuable resource for no good reason.</li>
<li>Incrementing a RAM-based 32-bit counter takes 20&nbsp;CPU cycles. Add
to this the time required to test the end-of-loop condition and you
will realize that your delay resolution is way worse than that of
<code>delayMicroseconds()</code>.</li>
<li>Your actual delay will depend on the clock frequency, and probably
also on the compiler's version, making your code pretty fragile.</li>
</ol>
