The goal of this library is to be a sort of "Digital Datasheet" for microcontrollers starting with AVR and more specifically the ATmega328.
will be an ATmega328 only CoreAVR and have most of the major features supported. The key will be to get the current implementation cleaned up and setup for distribution with a version number so it can be included in projects. Then I want to refine the ATmega328 version of CoreAVR through feedback. As that starts to feel more solid then work on getting generated code for other chips. The generated code would go in chunks of feature sets. will start to add support for other AVR microcontrollers. The most commonly used features will be added for other chips, lagging behind the ATmega328. Once sections of the ATmega328 are feeling more stable then these will be ported over to `HALGEN` which will use the ATmega328 code as a template to then generate the same code for other AVR chips.| Section | Support | |
|---|---|---|
| 8 | Memory | ❌ |
| 9 | System Clock and Clock Options | ❌ |
| 10 | Power Management and Sleep Modes | ❌ |
| 11 | System Control and Reset | ❌ |
| 12 | Interrupts | ✅ |
| 13 | External Interrupts | ✅ |
| 14 | I/O-Ports | ✅ |
| 15 | 8-bit Timer/Counter0 with PWM | ✅ |
| 17 | 16-bit Timer/Counter1 with PWM | ✅ |
| 19 | Timer/Counter0 and Timer/Counter1 Prescalers | ✅ |
| 20 | 8-bit Timer/Counter2 with PWM and Asynchronous Operation | ✅ |
| 21 | SPI – Serial Peripheral Interface | ✅ |
| 22 | USART0 | ✅ |
| 23 | USART in SPI Mode | ❌ |
| 24 | 2-wire Serial Interface | ❌ |
| 25 | Analog Comparator | ❌ |
| 26 | Analog-to-Digital Converter | ❌ |
| 27 | debugWIRE On-chip Debug System | ❌ |
| 28 | Self-Programming the Flash | ❌ |
| 29 | Boot Loader Support | ❌ |
This has to do with how SourceKit interprets modules. When a module contains a module.modulemap-file, it will be interpreted as a Clang module, and thus only C symbols will be loaded. For it to be loaded as a Swift module, we'd have to remove the modulemap, and separate out the C sources into another package. However, because of the fact that S4A's Toolchain uses a mix of SPM and Make, CoreAVR needs its modulemap in order to be a valid S4A module, thus making it inherently incompatible with SourceKit.
However, there was a proposal going around to adding official support for so-called "mixed targets", modules containing both Swift and C/C++/Objective-C, which would exactly fit CoreAVR's needs. However, this proposal was canned in July 2025, because of the difficulties in implementing it, supporting Linux and Windows, and the efforts into unifying SPM's and Xcode's build systems. If this proposal were to get revisited in the future, CoreAVR could make use of it, and finally bring autocompletion support to the project.