diff --git a/README.adoc b/README.adoc index dd8fcab..cb4e432 100644 --- a/README.adoc +++ b/README.adoc @@ -6,17 +6,17 @@ image::logo-text-auto.svg[] image::https://img.shields.io/discord/824493524413710336.svg?logo=discord[link=https://discord.gg/ShUWykk38X] [NOTE] -This is in development, breaks in the API are bound to happen +This is in development; breaks in the API are bound to happen. toc::[] == Contributing -Please see the https://github.com/orgs/ZigEmbeddedGroup/projects/1/views/1[project page], its used as a place to brainstorm and organize work in ZEG. There will be issues marked as `good first issue`, or drafts for larger ideas that need scoping/breaking ground on. +Please see the https://github.com/orgs/ZigEmbeddedGroup/projects/1/views/1[project page], it's used as a place to brainstorm and organize work in ZEG. There will be issues marked as `good first issue` or drafts for larger ideas that need scoping/breaking ground on. == Introduction -This repo contains the infrastructure for getting started in an embedded Zig project, it "gets you to main()". Specifically it offers: +This repo contains the infrastructure for getting started in an embedded Zig project; it "gets you to main()". Specifically, it offers: * a single easy-to-use builder function that: ** generates your linker script @@ -31,7 +31,7 @@ For MicroZig internals please see the xref:docs/design.adoc[Design Document]. == Does MicroZig support X hardware? -MicroZig is designed to cover as wide swath of hardware as possible. The https://github.com/ZigEmbeddedGroup[Zig Embedded Group] has some repositories that contain hardware-specific code. You will find them with the `hardware-support-package` label. If you can't find your specific device, it doesn't mean that you can't run Zig on it, it's likely you're just the first! In that case see xref:#getting-microzig-on-new-hardware[Getting MicroZig on New Hardare]. +MicroZig is designed to cover as wide a swath of hardware as possible. The https://github.com/ZigEmbeddedGroup[Zig Embedded Group] has some repositories that contain hardware-specific code. You will find them with the `hardware-support-package` label. If you can't find your specific device, it doesn't mean that you can't run Zig on it, it's likely you're just the first! In that case, see xref:#getting-microzig-on-new-hardware[Getting MicroZig on New Hardare]. Start with an empty Zig project by running `zig init-exe`, and add the hardware support package as a submodule. We'll use `microchip-atmega` in our example: @@ -86,7 +86,7 @@ If you have a board/chip that isn't defined in microzig, you can set it up yours * SVD or ATDF file defining registers * flash and ram address and sizes -First use https://github.com/ZigEmbeddedGroup/regz[Regz] to generate the register definitions for your chip and save them to a file. Then define the chip: +First, use https://github.com/ZigEmbeddedGroup/regz[Regz] to generate the register definitions for your chip and save them to a file. Then define the chip: [source,zig] ---- @@ -107,7 +107,7 @@ const backing = .{ }; ---- -It's important that the chip name actually match one of the entries under `devices` in the generated code. +It's important that the chip name actually matches one of the entries under `devices` in the generated code. === Optional: JSON Register Schema @@ -134,7 +134,7 @@ const nrf52832 = Chip{ == Interrupts -The current supported architectures for interrupt vector generation are ARM and AVR. To define the Interrupt Service Routine (ISR) for a given interrupt, you create a function with the same name in an `interrupts` namespace, which is nested in a `microzig_options` namespace: +The currently supported architectures for interrupt vector generation are ARM and AVR. To define the Interrupt Service Routine (ISR) for a given interrupt, you create a function with the same name in an `interrupts` namespace, which is nested in a `microzig_options` namespace: [source,zig] ---- diff --git a/docs/design.adoc b/docs/design.adoc index 4e97a2d..075279a 100644 --- a/docs/design.adoc +++ b/docs/design.adoc @@ -10,7 +10,7 @@ The build portion of MicroZig sets up a dependency graph like the following. image::deps.svg[] -Your application lives in `app`, that's where `main()` resides. `root` contains the entry point, and will set up [zero-initialized data] and [uninitialized data]. This is all encapsulated in an `EmbeddedExecutable` object. It has methods to add dependencies acquired from the package manager. +Your application lives in `app`; that's where `main()` resides. `root` contains the entry point and will set up [zero-initialized data] and [uninitialized data]. This is all encapsulated in an `EmbeddedExecutable` object. It has methods to add dependencies acquired from the package manager. The `microzig` module has different namespaces, some are static, but the nodes you see in the diagram above are switched out according to your configured hardware. @@ -20,9 +20,9 @@ The configurable modules, with the exception of `config`, are able to import `mi === `cpu` -This module models your specific CPU, and is important for initializing memory. Generally you shouldn't need to define this yourself, it's likely that MicroZig will have the definition for you. +This module models your specific CPU and is important for initializing memory. Generally, you shouldn't need to define this yourself, it's likely that MicroZig will have the definition for you. -Further research is needed for SOCs with multiple, heterogenous CPUs. Likely it means patching together multiple `EmbeddedExecutable`s. +Further research is needed for SOCs with multiple, heterogeneous CPUs. Likely it means patching together multiple `EmbeddedExecutable`s. === `chip` @@ -74,7 +74,7 @@ When making a package that defines chips for others, see xref:hardware_support_p === `hal` -This module contains hand-written code for interracting with the chip. +This module contains hand-written code for interacting with the chip. TODO diff --git a/docs/hardware_support_packages.adoc b/docs/hardware_support_packages.adoc index 4b8605f..595f082 100644 --- a/docs/hardware_support_packages.adoc +++ b/docs/hardware_support_packages.adoc @@ -4,4 +4,4 @@ toc::[] -This document goes over the _suggested_ way to structure a hardware support package. At the end of the day, MicroZig is designed for flexibility, we do not require all "supported" hardware be defined in one monorepo. Instead we make it so that you can define your hardware locally if that best suites your project. +This document goes over the _suggested_ way to structure a hardware support package. At the end of the day, MicroZig is designed for flexibility, we do not require all "supported" hardware be defined in one monorepo. Instead, we make it so that you can define your hardware locally if that best suits your project.