Most builders assume analogWrite() is just how you do PWM on Arduino: set a pin, pick a number from 0–255, done. That belief isn't wrong exactly. It's just incomplete.

The truth is that every convenience function in the Arduino core is a small tax on your microcontroller's time. Most projects never notice the bill. But once you're running a PID loop at 1–5 ms intervals, chasing a line at 1 m/s, or trying to squeeze a motor whine above human hearing, that tax starts eating the exact clock cycles your robot needs to react in time.

This post breaks down what analogWrite() actually does under the hood, what bare-metal register control looks like instead, and why more competition bots are quietly ditching the HAL for direct hardware access. By the end, you'll know which parts of your firmware are costing you time, and whether clawing it back is worth the effort.

What "HAL" Actually Means on Arduino

HAL stands for Hardware Abstraction Layer. On Arduino, it's the wrapping paper around the raw ATmega328P chip: the same chip whether you're using an Uno, a Nano, or a bare DIP-28 on a breadboard.

Functions like pinMode(), digitalWrite(), and analogWrite() exist so you don't need to know which physical register controls which pin. You say "pin 9," and the HAL quietly figures out which port that maps to, what state it should be in, and which register to touch.

That's genuinely useful. It's also not free.

What analogWrite() Is Really Doing Behind the Scenes

Every time you call analogWrite() or digitalWrite(), the function has to look up which port your pin number belongs to, check the pin's current mode, disable any conflicting timer output, and only then flip the actual bit. Independent benchmarking with a logic analyzer has clocked digitalWrite() at roughly 60–100 clock cycles per call, compared to a single clock cycle for direct port manipulation.

On a 16 MHz Uno, that's the difference between a pin flipping in under a tenth of a microsecond versus taking several microseconds. For a blinking LED, irrelevant. For a control loop trying to run every 1–2 ms, those microseconds are part of your budget.

analogRead() has a similar story: a single call blocks your program for roughly 100 microseconds while the ADC completes its conversion. If your PID loop reads five sensors every cycle, that's half a millisecond gone before you've even calculated an error term.

Bare-Metal: Talking to the Registers Directly

Underneath every HAL function sits a set of memory-mapped registers: plain bytes the CPU can read or write in a single instruction. On the ATmega328P, the ones you'll touch most are:

• DDRx (Data Direction Register): sets a pin as input (0) or output (1)

• PORTx (Port Data Register): sets an output pin HIGH or LOW

• PINx (Port Input Register): reads current pin states, all 8 bits at once

• TCCRxA / TCCRxB (Timer/Counter Control Registers): configure PWM mode and frequency

• OCRx (Output Compare Register): sets the PWM duty cycle for a timer channel

Writing to these directly skips the lookup tables entirely. Here's the same job (reading a five-sensor IR array) done both ways:

// The HAL way: five separate calls, ~100 clock cycles each
int s0 = digitalRead(A0);
int s1 = digitalRead(A1);
int s2 = digitalRead(A2);
int s3 = digitalRead(A3);
int s4 = digitalRead(A4)

// The HAL way: five separate calls, ~100 clock cycles each
int s0 = digitalRead(A0);
int s1 = digitalRead(A1);
int s2 = digitalRead(A2);
int s3 = digitalRead(A3);
int s4 = digitalRead(A4)

// The bare-metal way: all five sensors in a single clock cycle
uint8_t sensorState = PINC & 0b00011111; // reads A0–A4 at once

// The bare-metal way: all five sensors in a single clock cycle
uint8_t sensorState = PINC & 0b00011111; // reads A0–A4 at once

Same information. One of them costs your loop roughly 500 clock cycles before you've done anything with the data. The other costs one.

Same Job, Two Ways: Driving a Motor with PWM

PWM motor speed control is the clearest place to see the difference, because it's something almost every line follower needs.

// The HAL way
void setup() {
  pinMode(9, OUTPUT);
}
void loop() {
  analogWrite(9, 180); // duty cycle, 0–255, fixed at ~490 Hz
}

// The HAL way
void setup() {
  pinMode(9, OUTPUT);
}
void loop() {
  analogWrite(9, 180); // duty cycle, 0–255, fixed at ~490 Hz
}

analogWrite() on pin 9 locks you into Timer1's default frequency: around 490 Hz on a stock Uno. That's audible. Many drivers whine noticeably at that range, which is why some builders push PWM frequency above 20 kHz, clear of human hearing. Doing that through the HAL means digging into timer prescalers anyway. At that point, you may as well configure the timer directly.

// The bare-metal way: both drive motors on Timer1, 20 kHz, silent
void setupMotorPWM() {
  DDRB |= (1 << PB1) | (1 << PB2);   // pins 9 & 10 as outputs

  TCCR1A = (1 << COM1A1) | (1 << COM1B1) | (1 << WGM11);
  TCCR1B = (1 << WGM13) | (1 << WGM12) | (1 << CS10); // no prescaler

  ICR1 = 799; // TOP value → 16 MHz / 800 = 20 kHz
}

void setMotorSpeed(uint16_t leftDuty, uint16_t rightDuty) {
  OCR1A = leftDuty;   // range is now 0–799, not 0–255
  OCR1B = rightDuty;
}

// The bare-metal way: both drive motors on Timer1, 20 kHz, silent
void setupMotorPWM() {
  DDRB |= (1 << PB1) | (1 << PB2);   // pins 9 & 10 as outputs

  TCCR1A = (1 << COM1A1) | (1 << COM1B1) | (1 << WGM11);
  TCCR1B = (1 << WGM13) | (1 << WGM12) | (1 << CS10); // no prescaler

  ICR1 = 799; // TOP value → 16 MHz / 800 = 20 kHz
}

void setMotorSpeed(uint16_t leftDuty, uint16_t rightDuty) {
  OCR1A = leftDuty;   // range is now 0–799, not 0–255
  OCR1B = rightDuty;
}

The register version takes more lines to set up once. In exchange, you get both motor channels synchronized on the same timer, a frequency you chose on purpose, and finer duty-cycle resolution: 800 steps instead of 256.

Why Competition Bots Increasingly Go Bare-Metal

None of this matters for a blinking LED. It starts to matter the moment your firmware is a tight loop making real-time decisions:

• Faster PID loops. A line follower's PID loop needs to sample every 1–5 ms for the derivative term to mean anything. Every microsecond spent inside digitalWrite() or analogRead() is a microsecond not spent computing or correcting.

• Reading sensor arrays in one instruction. An 8-sensor array read through digitalRead() in a loop can cost 800+ clock cycles before your PID even sees the data. The same array read as one PINx byte costs one cycle.

• Custom PWM frequency. Pushing motor PWM above 20 kHz removes audible whine and, on some drivers, improves current smoothness. The default HAL frequencies don't give you that without touching timer registers anyway.

• Deterministic timing. Register-level code has predictable, cycle-accurate execution. That matters when you're syncing motor updates with sensor reads at millisecond precision, not "close enough."

This is also why firmware timing shows up as its own checklist item before race day: a control loop that drifts even a few milliseconds under load behaves differently on the track than it did on the bench.

One Level Further: Non-Blocking Sensor Reads

The same idea extends to the ADC. A normal analogRead() call blocks your loop for around 100 microseconds while the conversion completes. That's fine occasionally. It's expensive if you're polling several sensors every cycle.

Bare-metal firmware can configure the ADC to run in free-running mode, firing an interrupt every time a new reading is ready. Your main loop never waits on the conversion. It just picks up the latest value whenever it needs one. That's the same pattern professional motor-control firmware uses to squeeze more useful compute time out of every millisecond, and it's a natural next step once register-level PWM and port reads feel comfortable.

HAL vs Bare-Metal: Quick Comparison

When to Actually Use Each

Bare-metal isn't automatically better: it's a trade of convenience for control, and it only pays off when you need what it buys.

Stick with the HAL when: you're prototyping, your loop has no strict timing requirement, or you're building something for other people to read and modify easily. analogWrite() is not a beginner mistake. It's the right tool for most projects.

Move to bare-metal when: your control loop is timing-sensitive, you're driving multiple synchronized PWM channels, you need a specific frequency the HAL doesn't offer by default, or you've profiled your loop with micros() and found the HAL genuinely in your way, not just assumed it is.

Conclusion

The Arduino HAL exists so beginners can build working robots fast, and it does that job well. But convenient and fast aren't the same thing: every digitalWrite() and analogWrite() call is doing lookup work you don't see, and on a tight PID loop, that invisible work adds up.

Bare-metal register control trades a steeper learning curve for cycle-accurate timing, custom PWM frequencies, and the ability to read a whole sensor array in one instruction instead of eight. For a line follower chasing tight margins on race day, that trade is often worth making.

Before you rewrite anything, profile it first: drop micros() calls around your loop and see how much time the HAL is actually costing you. Where is your control loop losing the most time right now: sensor reads, motor writes, or something else entirely?

Building or upgrading your own competition bot? Check out the Mark-2 Line Following Robot, the ARC-8 IR sensor array, and the unidirectional speed controller. All three are built to handle exactly this kind of register-level tuning.