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

[matpala]

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 (atmega: add USART0 HAL for the ATmega328P #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 Create i2c (and spi) generic interface #637/proposal: rework timeouts, StreamDevices and DatagramDevices #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!

[arkadiuszwojcik]

There is always place for new drivers ; )

[Grazfather]

1. Transceive would be nice
2. You're saying we can't use pwm if we create a handler to count a full u64 since we need an overflow handler interrupt? That is fine, but it would be nice if we could disable it.
3. Unfortunate, but that should be OK.

[matpala]

Thanks both! Then:

1. I'll add an optional transceive to DatagramDevice in its own PR first (an optional vtable entry, so existing implementations keep working), and the nRF24 driver will use it to get STATUS with each command when it's available.
2. The timer will be opt-in: it only runs if the application calls its init and registers the TIMER0_OVF handler, so Timer0 stays free for PWM otherwise.
3. 👍