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

AVR (ATmega328P): UART/SPI HAL, drivers.zig, and nRF24L01+ driver (Emakefun RF-Nano V3.0)

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

Maintainers usually reply within 1 day

@matpala is already working on this.

Since Oct 8, 2026.

  • #1077 by @matpala — open
  • #1083 by @matpala — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
zig
Domain
embedded-iot

Research direction

Start with the referenced ATtiny port (#947), the related issues #637 and #701, and the existing work listed in the body, especially draft #1070. The plan spans an ATmega328P HAL, adapters, timing, an nRF24L01+ driver with unit tests, and examples; first get maintainer feedback on the open API and hardware questions. Done means the proposed steps are accepted and implemented, including tested send/receive examples.

Written by the indexing model from the issue text.

Description

I'd like to add support for the Emakefun RF-Nano V3.0 (repo): an Arduino Nano clone (ATmega328P @ 16 MHz) with an onboard nRF24L01+ on the hardware SPI bus. I have the boards and test everything on hardware.

Already up: #1063 (blinky delay), #1064 (board), #1068 (.rodata in RAM, fixes #679), #1071 (GPIO read() fix) and #1070 (UART HAL, draft).

Plan, one PR per step, with HAL files under hals/atmega328p/ like the ATtiny port (#947):

  1. UART (#1070).
  2. SPI host HAL.
  3. drivers.zig adapting the HAL to DatagramDevice, Digital_IO and ClockDevice, like ch32v, plus a small Timer0-based time.zig.
  4. An MCU-agnostic nRF24L01+ driver in drivers/src/wireless, following ssd1306.zig, with unit tests. It polls STATUS, since IRQ isn't wired on this board.
  5. Send/receive examples between two boards.

Note: on AVR, Zig 0.17.0 fails to compile some error unions with a payload (ziglang/zig#37099, fix pending). So for now there's no std.Io for the UART, and drivers can't use DatagramDevice.read.

Questions:

  1. DatagramDevice has no full-duplex transfer, so the STATUS byte the nRF24 sends back with every command is lost, and the driver needs an extra transaction to read it. Is that fine, or would you rather add a transceive operation (related to #637/#701)?
  2. ClockDevice needs a monotonic u64 microsecond clock. I'd use the Timer0 overflow (4 µs ticks), with the HAL exporting the TIMER0_OVF handler for the app to register. That takes over PWM on D5/D6. OK, or is there a preferred approach?
  3. AVR GPIO uses sbi/cbi, which need comptime operands, so the Digital_IO adapter would be one type per comptime pin (e.g. GPIO_Device(.d, 7)). OK?

Is the nRF24 driver welcome in drivers/? Any feedback is appreciated!

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.