Operators

Lesson 42: Using <= Less Than or Equal To Comparison Operator

Learn how <= includes the boundary value so conditions pass for smaller values and equal values.

Progress indicator

Lesson 42 of 57

Learning Objectives

  • Understand what the less-than-or-equal operator (<=) checks.
  • Use <= for inclusive upper-limit comparisons.
  • Compare <= with < and choose correctly for boundary behavior.
  • Use <= in if/else conditions with sensor data.
  • Predict branch behavior at below, equal, and above edge values.
  • Avoid common inclusive-comparison mistakes.

Concept Explanation

What is the Less Than or Equal To Operator (<=)

The <= operator checks whether the left value is smaller than or equal to the right value.

This means two cases return true: lower-than and exactly-equal.

Less Than or Equal To Syntax

if (valueA <= valueB) {
  // runs when valueA is smaller than or equal to valueB
}

How <= Works

  1. Evaluate the left and right expressions.
  2. Check if left is smaller than right.
  3. If not smaller, check equality.
  4. Return true if either lower-than or equal case is true.

Comparing Variables and Values

  • temperatureC <= maxSafeTemp for safe-range checks.
  • batteryPercent <= 20 for low-battery action at boundary.
  • sensorValue <= LIMIT when equal should still pass.

<= vs < (Comparison)

  • < passes only strictly smaller values.
  • <= passes smaller values and equal value.
ExpressionValue = 1200Behavior
value < 1200falseOnly 1199 and below pass
value <= 1200true1200 and below pass

Using <= in Conditions

Use <= when the boundary value should be included in the true case. This is common in limit checks and threshold-based control.

Real embedded examples

  • if (motorTemp <= maxTemp): keep motor running in safe range.
  • if (batteryDropCount <= 3): allow retry attempts up to limit.
  • if (distanceCm <= stopDistance): trigger stop at boundary too.

When to Use <=

  • Inclusive upper-limit checks.
  • Safety limits where boundary counts as acceptable.
  • Threshold logic where equal value should trigger action.

Edge-Value Behavior (Important)

Boundary checks are where most beginner bugs happen. Always test three points: below, exactly equal, and above.

sensorValueConditionResult
11991199 <= 1200true (if-branch)
12001200 <= 1200true (if-branch)
12011201 <= 1200false (else-branch)

Example Code

This sketch turns LED ON when the value is at or below the limit.

const int LED_PIN = 2;
const int LIMIT = 1200;

int sensorValue = 0;

void setup() {
  pinMode(LED_PIN, OUTPUT);
  Serial.begin(115200);
}

void loop() {
  sensorValue = analogRead(A0);

  if (sensorValue <= LIMIT) {
    digitalWrite(LED_PIN, HIGH);
    Serial.println("At or below limit -> LED ON");
  } else {
    digitalWrite(LED_PIN, LOW);
    Serial.println("Above limit -> LED OFF");
  }

  Serial.print("sensorValue = ");
  Serial.println(sensorValue);
  delay(300);
}

Example Code Explanation

  1. const int LIMIT = 1200; defines an inclusive boundary value.
  2. sensorValue = analogRead(A0); reads the latest input sample each loop.
  3. if (sensorValue <= LIMIT) checks below-limit and equal-limit together.
  4. If true, LED is set HIGH and a clear Serial message is printed.
  5. If false, value is above limit, so LED is set LOW and else message is printed.
  6. Serial.print lines help verify exact runtime values against the limit.
  7. delay(300) slows the cycle so branch transitions are easy to observe.

Real-life analogy

A parking gate allows vehicles with height up to and including 2.0 m. That rule isheight <= 2.0. At exactly 2.0 m, the gate still allows entry.

What Happens Inside

  1. Left and right operands are evaluated.
  2. The CPU checks lower-than path and equality path.
  3. A boolean result (true/false) is generated.
  4. Compiler-generated branch instruction picks if or else block.
  5. GPIO state is updated so hardware reflects branch decision.
  6. Serial monitor confirms runtime decision with textual feedback.
  7. Loop repeats with new readings and re-checks the boundary.

Common Mistakes with <=

  • Using < when equal should be allowed.
  • Setting wrong limit value and misreading boundary behavior.
  • Not testing exact boundary values like 1200 in this example.
  • Comparing values from different scales without conversion.

Best Practices for <=

  • Use named constants for comparison boundaries.
  • Document whether the check is strict (<) or inclusive (<=).
  • Test below-limit, equal-limit, and above-limit values.
  • Keep threshold constants centralized so updates stay consistent.
  • Use Serial logs that print both current value and limit for fast debugging.

Practice Task

  1. Set LIMIT to 1000 and test 999, 1000, and 1001.
  2. Replace <= with < and compare the 1000 boundary result.
  3. Print both sensorValue and LIMIT each loop.
  4. Add && systemEnabled so condition only runs when enabled.

Try it now

Open the simulator workspace and test below, equal, and above boundary behavior with <=.

Run in Simulator