Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#1,072 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
zig
Ambito
embedded-iot

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Zig
Stelle
2.3k
Fork
198
Merge medio
1g 8h
PR unite (30g)
37

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di ZigEmbeddedGroup/microzig

Tutte le issue di ZigEmbeddedGroup/microzig

Issue simili

Altre issue su Embedded & IoT

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.