无FPU平台下16位传感器湿度值的整数计算优化方案问询

Great call on ditching floating-point operations for your FPU-less platform—integer math is the perfect fit here, and your current scaled integer approach is already heading in the right direction. Let's refine it for better efficiency, especially focusing on replacing slow division with faster bitwise operations, which is a game-changer for low-power/resource-constrained MCUs.

Key Observations About Your Current Code #

Your existing line:

int16_t rhint = ((uint32_t)buf*12500 / 65536)-600;

works because you're scaling the humidity value by 100 to retain two decimal places, but the division by 65536 (which is 2^16) can be swapped out for a bitwise right shift—an operation that executes in a single cycle, compared to dozens of cycles for a software division routine on most small chips.

Optimized Implementation #

Here's the refined code with speed and correctness improvements:

uint16_t buf = 0x7C80; // Example 16-bit sensor reading

// Step 1: Calculate scaled humidity (x100) using shift instead of division
// Using uint32_t ensures we avoid overflow during multiplication
int32_t rh_scaled = ((uint32_t)buf * 12500) >> 16;

// Step 2: Apply the offset from the original formula
rh_scaled -= 600;

// Step 3: Clamp to valid range (0% = 0, 100% = 10000)
if (rh_scaled < 0) {
    rh_scaled = 0;
} else if (rh_scaled > 10000) {
    rh_scaled = 10000;
}

// Extract integer and decimal parts (e.g., 5479 → 54% and 79 hundredths)
uint8_t rh_integer = rh_scaled / 100;
uint8_t rh_decimal = rh_scaled % 100;

Why This Is Better #

1. Faster Division Replacement: >> 16 is mathematically identical to dividing by 65536 for unsigned values, but it's vastly faster—critical for platforms without hardware division units.
2. Overflow Safety: Using uint32_t for the intermediate multiplication ensures we don't hit overflow. Even the maximum 16-bit value (65535) multiplied by 12500 gives 819,187,500, which fits comfortably in a 32-bit integer.
3. Explicit Range Clamping: The code clearly enforces the 0-100% range, which your original code might have missed. If the sensor returns an out-of-bounds reading, this ensures you don't end up with negative humidity or values over 100%.

Validation with Your Example #

For buf = 0x7C80 (31872):

• Floating-point result: (31872 * 125 / 65536) -6 ≈ 54.79%
• Optimized integer result: (31872 * 12500) >>16 = 6079 → 6079 -600 = 5479 → 54 (integer) and 79 (decimal), which matches exactly.

Extra Optimization Tip #

If you're working with an extremely stripped-down platform, you could pre-calculate the 12500 scaling factor as a shifted constant, but the above implementation is already as efficient as it gets for most use cases.

内容的提问来源于stack exchange，提问作者NStorm