Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

regz: AVR peripherals generated at address 0 when the register-group name matches the module (ATDF)

Open
  • Is something wrong?
#1,072 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@matpala is already working on this.

Since Oct 15, 2026.

  • #1091 by @matpala — open

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
zig
Domain
embedded-iot

Research direction

Start in tools/regz/src/atdf.zig, especially load_module_type and the inlined register-group path; compare it with load_register_group, which infers the lowest register offset. Check generated AVR peripherals such as ATmega328P.zig and verify the result for the listed ATmega and ATtiny devices, while preserving genuinely zero-based peripherals such as ATtiny1616 VPORTA. Done means generated peripheral pointers use valid bases and the reported Zig address-zero failure is avoided.

Written by the indexing model from the issue text.

Description

On AVR, many generated peripherals end up at address 0 with absolute register offsets. For example, in the generated ATmega328P.zig:

pub const SPI: *volatile types.peripherals.SPI = @ptrFromInt(0x0); // SPCR is at offset 0x4C

Using it with Zig 0.17.0 fails with pointer type '*volatile types.peripherals.SPI.SPI' does not allow address zero, so these peripherals can't be used through microzig.chip.peripherals.

Data-space peripherals at address 0 in the files generated locally from the current atpacks:

  • ATmega328P: TWI, ADC, AC, EXINT, SPI, WDT, EEPROM, CPU
  • ATtiny85 and ATtiny84: AC, ADC, USI, EXINT, EEPROM, WDT, BOOT_LOAD, CPU
  • ATtiny1634: TWI, ADC, AC, EEPROM, EXINT, CPU, USI, WDT

Cause (tools/regz/src/atdf.zig): in the ATDF, these instances have offset="0x00" and their registers use absolute data-space offsets. When a module's only register-group has the same name as the module (SPI, TWI, ...), load_module_type inlines it and skips the offset inference, so the instance keeps the zero base. When the names differ (USART0, PORTB, ...), load_register_group infers the lowest register offset and the instance uses it, which is why those come out right (0xC0, 0x23).

Possible fixes: run the same inference on the inlined path (SPI would get base 0x4C and SPCR offset 0), or emit an allowzero pointer for zero bases. The second would also cover the ATtiny1616's VPORTA, which really is at 0x0000.

Workaround I'm using for the ATmega328P SPI (tested on hardware): one pointer per register, keeping the generated types:

const SPI_Regs = microzig.chip.types.peripherals.SPI;
const SPCR: *volatile @FieldType(SPI_Regs, "SPCR") = @ptrFromInt(@offsetOf(SPI_Regs, "SPCR"));

I'm happy to try a fix in regz if that helps.

Dominant language
Zig
Stars
2.3k
Forks
198
Avg merge
1d 17h
Merged PRs (30d)
23

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ZigEmbeddedGroup/microzig

All issues in ZigEmbeddedGroup/microzig

Similar issues

More Embedded & IoT issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.