Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

drivers: `I2C_Device.Address.check_reserved` rejects 0x08-0x0F and accepts 0x04-0x07 (HighSpeedMaster range is off by one bit)

Abierto Apto para principiantes
  • ¿Algo no está bien?
#1,085 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
1/5
Tiempo estimado
Menos de una hora
Aptitud para principiantes
69/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
zig
Área
embedded-iot

Línea de trabajo

Empieza en drivers/src/base/I2C_Device.zig, en Address.check_reserved, y lee la tabla de pruebas existente en el mismo archivo. El issue indica los rangos de direcciones incorrectos y los esperados, además de una reproducción solo para host. Actualiza la comprobación del rango y las expectativas de las pruebas; después, ejecuta la reproducción o zig build test desde drivers/. El trabajo estará terminado cuando se rechace 0x04–0x07 y se acepte 0x08–0x0F.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Summary

Address.check_reserved (drivers/src/base/I2C_Device.zig:55 on master) returns
error.HighSpeedMaster for 0b0001000...0b0001111 (0x08-0x0F). The Hs-mode
controller code is 0000 1XX, i.e. 0x04-0x07 — the page the doc comment links
(https://www.i2c-bus.org/addressing/ lists 00001XX X as "High-Speed Master
Code"), and the doc comment itself: "Reserved addresses are ones that match
0b0000XXX or 0b1111XXX". So:

  • 0x08-0x0F, ordinary 7-bit addresses, are refused. Through the rp2xxx HAL every
    read (.dont_allow_reserved) returns error.IllegalAddress for them before
    anything reaches the bus. A bus scan that starts at 0x08 (the usual first
    address) sees an error rather than a NACK at its first address. The same check runs
    in the nrf5x, stm32 (i2c_v2) and espressif HALs. Real parts live at these
    addresses. One is the AK09916 magnetometer at 0x0C: the in-tree ICM_20948
    driver names it MAG_ADDRESS = 0x0C. That driver reaches it through the ICM's own
    aux I2C master, so it is unaffected, but on a board that wires the AK09916 straight
    to the host bus the HAL refuses its address.
  • 0x04-0x07, the reserved Hs-mode codes, are accepted.

It is a regression from #648 (c058aa4, 2025-08-16). The bool version it
replaced was ((value & 0x78) == 0) or ((value & 0x78) == 0x78), which was right.
When that became a switch, 0000 1XX was written as 0001 XXX, and the new test table
encoded the same values (0x08 and 0x0F expect HighSpeedMaster).

Versions
tree toolchain result
microzig 0.15.1 release (mz_drivers-0.0.1-bvRa3F…) zig 0.15.2 reproduces (rc=1)
microzig master f36d59fb7b22 (tag 0.17.17, 2026-10-10) zig 0.17.0 reproduces (rc=1)
master + the fix below zig 0.17.0 fixed (rc=0)
Repro (host-only, no hardware)

repro.zig:

const std = @import("std");
const Address = @import("I2C_Device").Address;

fn reserved(a: u7) bool {
    const addr: Address = @enumFromInt(a);
    addr.check_reserved() catch return true;
    return false;
}

test "0x04-0x07 (0000 1XX, Hs-mode controller code) are reserved" {
    for ([_]u7{ 0x04, 0x05, 0x06, 0x07 }) |a| try std.testing.expect(reserved(a));
}

test "0x08-0x0F are ordinary addresses" {
    for ([_]u7{ 0x08, 0x09, 0x0C, 0x0F }) |a| try std.testing.expect(!reserved(a));
}

zig test repro.zig --dep I2C_Device -Mroot=repro.zig -MI2C_Device=<microzig>/drivers/src/base/I2C_Device.zig

Expected: both tests pass.
Actual (master f36d59f, zig 0.17.0):

1/2 repro.test.0x04-0x07 (0000 1XX, Hs-mode controller code) are reserved...0x04 accepted, expected reserved
FAIL (TestUnexpectedResult)
2/2 repro.test.0x08-0x0F are ordinary addresses...0x08 rejected, expected usable
FAIL (TestUnexpectedResult)
0 passed; 0 skipped; 2 failed.
Fix

One switch arm, plus the two test-table rows that encoded the wrong range:

-            0b0001000...0b0001111 => return Address.Error.HighSpeedMaster,
+            0b0000100...0b0000111 => return Address.Error.HighSpeedMaster,

and the existing test in the same file now expects HighSpeedMaster at 0x04/0x07 and
"valid" at 0x08/0x0F. With the patch, zig build test in drivers/ gives
123/123 tests passed (rc=0), the same count as unpatched master. The repro above
passes.

Behaviour change worth a line in the release notes: callers that pass 0x04-0x07
with .dont_allow_reserved / .allow_general now get IllegalAddress, and
0x08-0x0F start working.

I have the patch ready and can open it as a PR if you'd like.

Lenguaje dominante
Zig
Estrellas
2.3k
Forks
198
Merge medio
1 d 8 h
PR fusionados (30 d)
37

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de ZigEmbeddedGroup/microzig

Todos los issues de ZigEmbeddedGroup/microzig

Issues similares

Más issues de Embedded & IoT

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.