Sylvia Ivory

On Style

2026-05-08T21:47:35Z

Welcome to the authoritative¹ style guide² for the Vineyard. Some of this was referenced from the Associated Press Style Guide. This should be considered a living document and may change without prior notice.

Note

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this section are to be interpreted as described in RFC 2119.

Formats

The formats listed below are REQUIRED to be used.

Dates: YYYY-MM-DD
Times: HH:MM:SS, 24 hour time
Timestamp: YYYY-MM-DD HH:MM:SS, 24 hour time

If a quote uses different formats, it MUST be replaced. For example:

It is currently 10:00pm in New York

MUST be rewritten as:

It is currently [22:00] in New York

Units

The units listed below are REQUIRED to be used. Units SHOULD NOT be abbreviated.

Temperature: Celsius
Length: Meters (Metric)
Mass: Grams (Metric)
Data: Binary (IEEE 1541). Byte-based units SHOULD be used unless it makes more sense to use bit-based units.

If a quote uses different units, it MUST be replaced. For example:

[Interstate-10] is the fourth-largest Interstate in the [United States] at 2,460.34 miles

MUST be rewrititen as:

[Interstate-10] is the fourth-largest Interstate in the [United States] at [3,959.53 kilometers]

Numbers

Numbers less than ten SHOULD be written out; except in the following cases:

Ages (35 years old)
Dimensions (2 by 4 is the best plank)
Money (10 dollar latte)
Dates (7th of May)
Temperature (90 degrees Celsius)
Percentages (95% confident)

Sentences SHOULD NOT begin with a number; unless the number is for a year (2025 is a year).

Editorial

Pages SHOULD be written in Markdown.
Lines MUST NOT extend past 80 columns.
Footnotes SHOULD be located in the same section as their usage.
Sidenotes MUST NOT interrupt content.
A page MUST be fully readable in:
- Firefox (desktop/mobile web, print, reader)
- Chromium (desktop/mobile web, print, reader)
- W3M, Lynx
Sources MUST be provided
Quotes MUST be properly cited and use the Quote

Frontmatter MUST be ordered in:

title
date
created
layout
authors
tags
description

Not really ↩
Kinda pushing it ↩

The mini UART

2026-02-16T00:00:00Z

So, after going through a bit of difficulty with Mini-UART on the BCM2835, I thought I would document how I got it fully working (or perceptually it fully works).

What is the BCM2835?

For me, the BCM2835 is the Raspberry Pi Zero (or Pi 1)¹. I'm sure there's other devices that use it and the ideas from here should apply. Taking a cursory glance at the BCM2837 (Pi 2/3)² and BCM2711 (Pi 4)³ data sheets, it could also work there although I've only tested my code against the Raspberry Pi Zero.

What is mini UART?

In the words of the BCM2835 datasheet, "The mini UART is a secondary low throughput UART intended to be used as a console."⁴ While the BCM2835 has a full (PL011)⁵, it's not necessarily the easiest to use and is a bit overkill for a simple console.

In my experience, the biggest limitation is the 8-byte FIFO⁴. Today, however, we're not going to be limited by this as we're going to use interrupts to ensure the queue never spills.

Prerequisites

I'm going to assume that you already have the following:

Booting on the Pi (Andre Leiradella has a good tutorial on this)
Some means to use UART (UART-to-USB adapter, Flipper Zero, Digital Logic Analyzer, another Pi, etc)
A willingness to trust random numbers that I myself don't understand why they work

Initialization

Initializing Mini-UART can be split into 3 separate parts:

GPIO Initialization
Auxiliary I/O Initialization
Mini-UART Initialization

GPIO Initialization

GPIO pins should be set up first [sic] before enabling the UART.

BCM2835/2.2 p.g. 10

So first, we need to decide what pins we actually want to use. Below is a table of pin pairs we could use⁶.

Pair	Alt Mode
14:15	Alt 5
31:32	Alt 3
36:37	Alt 2

After picking a pair of TX/RX pins, we need to configure them for pull-down as a floating state (especially with RX) is not a good idea. Here, the BCM2835 is almost clear⁷:

Write to GPPUD to set the required control signal
Wait 150 cycles
Write to GPPUDCLKn to set the clock
Wait 150 cycles
Write to GPPUD to remove the control signal
Write to GPPUDCLKn to clear the clock The purpose of each of these steps doesn't really concern us for the moment. As of now, we just need to resolve what the datasheet means by "cycles." In my own code, I've interpreted this as CPU cycles although this could very well mean GPU cycles, system clock cycles, peripheral clock cycles, etc.

Now the only thing left to do is actually write the code:

// --- snip ---

// gpio.zig

fn wait(count: usize) void {
    var c = count;
    while (c != 0) {
        c -= 1;
    }
}

// Table 6-2 - GPIO Pull-up/down Register (GPPUD)
pub const PullMode = enum(u2) {
    Off = 0b00,
    Down = 0b01,
    Up = 0b10,
};

pub fn set_pull(pin: u8, pull: PullMode) void {
    GPPUD.write(@intFromEnum(pull));

    wait(150);

    GPPUDCLK.insert(pin, true);

    wait(150);

    GPPUDCLK.remove(pin);
    GPPUD.write(0);
}

// --- snip ---

We can save set_pull for later.

Auxiliary I/O Initialization

The next step is to initialize the Auxiliary I/O interface. This is probably the simplest part of using the mini UART. The AUXENB let's us enable mini UART, although we do need to be careful, given it states "The UART will immediately start receiving data, especially if the UART1_RX line is low."⁸ We do, however, still need to enable it first before configuring UART given "If clear... [it also] disables any mini UART register access."

As this is just setting 1 bit, we can do it as simply as:

pub fn enable_mini_uart() void {
    AUXENB.insert(0, true);
}

Mini UART Initialization

Now this is where we need to actually think of what we want our UART to represent. If you don't care about any sort of explanation, here's the configuration for an 8N1 UART:

pub fn configure_uart_8n1(baud: u32) void {
    // Disable interrupts
    // Page 12: AUX_MU_IER_REG Register
    // When bit 0/1 is 0, interrupts are disabled
    AUX_MU_IER_REG.write(0);

    // Disable RX/TX during configuration
    // Page 17: AUX_MU_CNTL_REG Register
    // When bit 0/1 is 0, UART receiver/transmitter is disabled
    AUX_MU_CNTL_REG.write(0);

    // Set data size to 8 bits
    // Page 14: AUX_MU_LCR_REG Register
    // When bit 0 is 1, UART is in 8-bit mode, else 7-bit
    // Errata: "bit 1 must be set for 8 bit mode"
    AUX_MU_LCR_REG.write(0b11);

    // Put RTS high (indicate request to send)
    // Page 14: AUX_MU_MCR_REG Register
    // When bit 1 is 0, RTS line is high, else low
    AUX_MU_MCR_REG.write(0);

    // Clear FIFO
    // Page 13: AUX_MU_IER_REG Register
    // When bit 1/2 is 1, receive/transmit will be cleared
    AUX_MU_IIR_REG.write(0b110);

    // Set baud rate
    // Page 11: 2.2.1 Mini UART Implementation Details
    // The baudrate formula is given as:
    //   (system_clock_freq)/(8 * (baudrate_reg + 1))
    AUX_MU_BAUD_REG.write(CLOCK_FREQ / (8 * baud) - 1);

    // Enable RX/TX again
    // Page 17: AUX_MU_CNTL_REG Register
    // When bit 0/1 is 1, UART receiver/transmitter is enabled
    AUX_MU_CNTL_REG).write(0b11);
}

Now if you want something other than 8N1, we need to venture deeper.

Warning

I haven't tested anything other than 8N1 so this is my personal interpretation of the BCM2835 and the BCM2835 datasheet errata.

Data Size

For 7 bits: clear bit 0 of AUX_MU_LCR_REG⁹.

For 8 bits, we find the first piece of errata:

LCR register, bit 1 must be set for 8 bit mode, like a 16550 write a 3 to get 8-bit mode

elinux BCM2835 errata/p14

In short, set bits 0 and 1 of AUX_MU_LCR_REG.

RTS/CTS

We can get the mini UART to either manually or automatically set our request-to-send and automatically control clear-to-send. Before we can use RTS/CTS, we need to configure GPIO pins. As before, we can look towards the GPIO Alternative Functions⁶ table to see we can use the following pins:

Pair	Alt Mode
16:17	Alt 3
30:31	Alt 3
38:39	Alt 2

And just as before, we configure them for pull-down.

Manual Flow Control

For manual control of RTS, we can look towards AUX_MU_MCR_REG¹⁰, which tells us to set bit 1 to set RTS low (and clear to set RTS high).

Automatic Flow Control

For automatic control, we can look towards AUX_MU_CNTL_REG¹¹.

For CTS, set bit 3 of AUX_MU_CNTL_REG which automatically stops transmission if the CTS pin is de-asserted

For RTS, here we have some configuration, depending on when to de-assert RTS in relation to the RX FIFO. Set bits 4 and 5 to:

0b00 - de-assert with 3 slots left
0b01 - de-assert with 2 slots left
0b10 - de-assert with 1 slot left
0b11 - de-assert with 4 slots left

We can also choose to invert CTS and RTS (such that assertion is when the pin is low) by configuring bits 6 (for RTS) and 7 (for CTS).

Break Condition

While the mini UART can't detect a break, it can send out a break. Setting bit 6 of AUX_MU_LCR_REG⁹ for 12 bits times (time it takes to send out 12 bits) will indicate a break condition.

Baud Rate

Finally, we can configure the baud rate for our mini UART through the AUX_MU_BAUD¹². The first 16 bits of this register specify our baudrate, but first we need to calculate the baudrate.

Luckily the datasheet gives us a formula in section 2.2.1¹³:

\text{baudrate} = \frac{ \text{system clock freq} }{8 \cdot (\text{baudrate reg} + 1)}

Now we have two variables to plug into this, system clock frequency and our baudrate (e.g. 9600).

According to the errata¹⁴, for the Pi we have a clock frequency of 250MHz, so we can just hardcode it in as 250_000_000.

System Clock Frequency

If you're against using a hardcoded value, we can use the Mailbox interface.¹⁵ In specific, we want to use mailbox channel 8 (Property tags, ARM to VideoCore) with the "Get clock rate" tag(0x00030002)¹⁶ and the clock ID for CORE(0x000000004)¹⁷.

Now, we need to actually know how to send a message to the mailbox. I'm not going to be too specific on this as this is a post on mini UART, but in short, we write a Message to MAILBOX_WRITE and wait for a response (MAILBOX_STATUS), and read our response from MAILBOX_READ¹⁸:

fn Message(comptime T: type) type {
    return packed struct {
        message_size: u32,
        request_code: u32,
        message_tag: u32,
        bytes_available: u32,
        response_code: u32,
        data: T,
        end_tag: u32,

        const Self = @This();

        pub fn new(tag: u32) Self {
            return .{
                .message_size = @sizeOf(Self),
                .request_code = 0,
                .message_tag = tag,
                .bytes_available = @sizeOf(T),
                .response_code = 0,
                .data = std.mem.zeroes(T),
                .end_tag = 0,
            };
        }

        pub fn send(self: *align(16) Self, channel: u8) u32 {
            mem.barrier(.Write);

            while (BOX_STATUS.get() & BOX_FULL) != 0) {}

            BOX_WRITE.put_barrier(@intFromPtr(self) | channel);

            while (BOX_STATUS.get() & BOX_EMPTY) != 0) {}

            return BOX_READ.get_barrier();
        }
    };
}

pub fn get_system_clock_rate() u32 {
  const GetClockRateRequest = packed struct(u64) {
      id: u32,
      rate: u32,
  };
  var message: Message(GetClockRateRequest) align(16) = .new(0x00030002);
  message.data.id = 0x000000004;
  _ = message.send();

  return message.data.rate;
}

Now is this long-winded? Yes. But will it always work unlike hardcoding a value? Also yes.

Finally, after calculating our baudrate, we can truncate it into just 16 bits before writing it into AUX_MU_BAUD. According to the implementation details¹³, there isn't actually any maximum baudrate, with the only limit being however fast the CPU can handle (although I wouldn't recommend anything above 921600 when using interrupts and 115200 when using polling).

Putting it all together

Finally, we can put everything together, with just a few extra details:

We should probably disable interrupts (at least temporarily) to ensure we're not getting interrupted for 0s.
We should probably disable the transmitter and receiver to ensure we're not transmitting or filling the FIFO with 0s.
We should probably clear the FIFO as it probably has junk
We should enable the transmitter and receiver again after configuration.

We can accomplish each of these with:

AUX_MU_IER_REG¹⁹, clearing bits 0 and 1 to disable interrupts.
AUX_MU_CNTL_REG¹¹, clearing bits 0 and 1 to disable the receiver and the transmitter.
AUX_MU_IIR_REG²⁰, setting bits 1 and 2 to clear the RX/TX queues.
AUX_MU_CNTL_REG, except now setting bits 0 and 1 to enable the receiver and the transmitter.

Putting it all together, we get:

pub const DataSize = enum {
    .@"7" = 0b00,
    .@"8" = 0b11,
};

pub const RtsControl = enum(u3) {
    .@"4" = 0b011,
    .@"3" = 0b000,
    .@"2" = 0b001,
    .@"1" = 0b010,
    Manual = 0b100,
};

pub const CtsControl = enum {
    Auto,
    Off,
}

pub fn configure_uart(
    baud: u32,
    data_size: DataSize,
    rts: RtsControl,
    cts: CtsControl,
) {
    AUX_MU_IER_REG.write(0);
    AUX_MU_CNTL_REG.write(0);

    AUX_MU_LCR_REG.write(@intFromEnum(data_size));

    if (rts == .Disabled) {
        AUX_MU_MCR_REG.write(0);
    } else {
        AUX_MU_CNTL_REG.write(@as(u2, @truncate(@intFromEnum()) << 4);
    }

    if (cts == .Auto) {
        AUX_MU_CNTL_REG.write(1 << 3);
    }

    AUX_MU_IIR_REG.write(0b110);

    AUX_MU_BAUD_REG.write(CLOCK_FREQ / (8 * baud) - 1);

    AUX_MU_CNTL_REG.bor(0b11);
}

Tada! An initialized mini UART!

Polling

First, we'll write some simple interfaces that just poll for availability. They might not be the most efficient but hey- at least they work.

Transmitting

If you don't care for any explanation:

pub fn write_byte(byte: u8) void {
    while (AUX_MU_STAT_REG.get() & 0b10) == 0) {}
    AUX_MU_IO_REG.write(@as(u32, byte) & 0xFF);
}

If you do care for explanation, transmitting a byte is composed of two main parts:

Checking if we have enough space in the TX queue
Putting the byte into the TX queue

We can accomplish each of these with:

AUX_MU_STAT_REG²¹, bit 1 indicates if the TX queue "can accept at least one more [byte]."
AUX_MU_IO_REG²², writing bits 0 to 7 puts data into the TX queue "(provided it is not full)."

And now we can transmit data! Wasn't that simple?

Receiving

Receiving is similarly simple. If you don't care for any explanation:

pub fn read_byte(byte: u8) void {
    while (AUX_MU_LSR_REG.get() & 0b1 != 0) {}
    return @truncate(AUX_MU_IO_REG.get());
}

If you do care for explanation, receiving a byte is similar to transmitting:

Checking if there's a byte available in the RX queue
Reading the byte from the RX queue

We can accomplish each of these with:

AUX_MU_LSR_REG²³, bit 0 indicates if "the [RX queue] holds at least 1 [byte]."
AUX_MU_IO_REG²², reading bits 0 to 7 gets data from the RX queue "(provided it is not empty)."

And now we can read data!

Some extras

You might've noticed that I've been using Zig in all of these example code blocks. With Zig, we can implement Io.Reader²⁴ and Io.Writer²⁵ and treat our UART just like any other Io stream.

Writer

Implementing Zig's Io.Writer is pretty simple. We only need 1 function, drain, although today we're going to also implement flush.

drain's signature is a bit interesting:

*const fn (
    w: *Writer,
    data: []const []const u8,
    splat: usize,
) Error!usize

We get a 2 dimensional array for our data and a splat parameter. I'm not actually sure what's the purpose of the splat parameter is (my guess is vectored writing) or any additional dimensions of data. For me, ignoring splat and looking at only data[0] always worked.

fn writer_drain(
    io_w: *std.Io.Writer,
    data: []const []const u8,
    splat: usize,
) !usize {
    _ = io_w;
    _ = splat;

    for (data[0]) |byte| {
        write_byte(byte);
    };

    return data[0].len;
}

Next, we have the flush implementation. Here we look at AUX_MU_STAT_REG²¹ once again, with bit 9 representing "the transmitter is idle and the transmitter FIFO is empty." Basically, we just loop until bit 9 is set.

fn writer_flush(io_w: *std.Io.Writer) !void {
    _ = io_w;

    while (AUX_MU_STAT_REG.get() & 0x200 != 0) {}
}

Finally, we just need to implement the VTable:

const writer_vtable: std.Io.Writer.VTable = .{
    .drain = writer_drain,
    .flush = writer_flush
};
pub var writer = std.Io.Writer{
    .buffer = undefined,
    .vtable = &writer_vtable
};

Tada! We now have Io.Writer implemented! With this, we can now print out formatted strings to our mini UART:

try writer.print("Hello {s}!", .{"world"});

Reader

Implementing Io.Reader is about as simple as Io.Writer. Here we need to implement stream which has us putting data into a writer until some limit. In short, no new code.

fn stream(
    io_r: *std.Io.Reader,
    io_w: *std.Io.Writer,
    limit: std.Io.Limit,
) !usize {
    _ = io_r;

    if (limit.toInt()) |max| {
        for (0..max) |_| {
            try io_w.writeByte(read_byte());
        }

        return max;
    } else {
        return std.Io.Reader.StreamError.ReadFailed;
    }
}

Then, we just need to implement the VTable:

const reader_vtable: std.Io.Reader.VTable = .{
    .stream = stream
};

pub var reader = std.Io.Reader{
    .buffer = undefined,
    .seek = 0,
    .end = 0,
    .vtable = &reader_vtable
};

And just like that, we now can treat our mini UART as any other stream, opening our possibilities!

Interrupts

Now it's time for the fun part, interrupts. I won't explain how to setup the exception vector (that's left as an exercise for the reader). First, we need to actually configure the mini UART to send interrupts.

First, however, we should figure out what the interrupts will tell us:

[Enable transmit interrupt]: If this bit is set the interrupt line is asserted whenever the transmit FIFO is empty.
[Enable receive interrupt]: If this bit is set the interrupt line is asserted whenever the receive FIFO holds at least 1 byte.

BCM2835/2.2.2 p.g. 12

In short, we want receive interrupts to always be enabled. For transmit interrupts, however, we only want to enable them when we have data and disable them as soon as we've sent all our data.

Interrupt Setup

Before we can think about using interrupts, we need somewhere to put our data. For this, a ring buffer is probably one of the simplest data structures for this purpose. Implementing a ring buffer is left as an exercise to the reader.

One of annoying issues I experienced was not realizing that a race condition was possible here. As such, we also need to implement a critical section handler (or just manually disable and enable interrupts) so that we don't get interrupted when interacting with our ring buffers.

Implementing a critical section is, too, left as an exercise for the reader.

For now, assume have have the following declarations:

var tx_list: StackRingBuffer(u8, 128) = .init();
var rx_list: StackRingBuffer(u8, 128) = .init();

Configuring Interrupts

Before we can configure mini UART interrupts, we need to enable Auxiliary I/O interrupts (I'll assume that interrupts are already globally enabled). For this, we look towards the peripherals interrupt table²⁶. We see that auxiliary interrupts are numbered #29 and with this, we know to set bit 29 in ENABLE_IRQS_1²⁷.

fn enable_aux_interrupts() void {
    ENABLE_IRQS.insert(AUX_INTERRUPT_BIT, true);
}

Now that we have Auxiliary I/O interrupts enabled, we can configure mini UART interrupts.

So as you've might've guessed, we'll be using AUX_MU_CNTL_REG¹¹. One might think to enable interrupts, we just set bits 0 and 1 to 1 but that isn't actually correct. If we open up the errata,

Bits 3:2 are marked as don't care, but are actually required in order to receive interrupts.
Bits 1:0 are swaped. bit 0 is receive interrupt and bit 1 is transmit. we find two different things to consider

elinux BCM2835 errata/p12

As we have transmit interrupts constantly being flipped on and off, I decided to just write a function to encapsulate all possible states of interrupts:

fn interrupt_state(tx: bool, rx: bool) void {
    if (tx and rx) {
        AUX_MU_IER_REG.write(0b1111);
    } else if (tx and !rx) {
        AUX_MU_IER_REG.write(0b1110);
    } else if (!tx and rx) {
        AUX_MU_IER_REG.write(0b0101);
    } else if (!tx and !rx) {
        AUX_MU_IER_REG.write(0b0000);
    }
}

I'm not sure why any of these numbers work except for when tx and rx are both false/true. But they do work!

Interrupt Handler

Now we need to configure the interrupt handler. For this, we need to:

Check that an auxiliary interrupt is pending
A mini UART interrupt is pending
If there's data in the receiver, read it
If there's data for the transmitter, send it
If there isn't data for the transmitter, disable transmission interrupts

We can accomplish #1 by reading bit 29 of IRQ_PENDING_1²⁸.

For numbers 2-4, we can look towards AUX_MU_IIR_REG²⁰, where if bit 0 is clear, an interrupt is pending and bits 1 and 2 telling us if the interrupt is from the transmitter or receiver.

Now to implement this:

fn interrupt_handler()
    callconv(.{ .arm_interrupt = .{ .type = .irq } }) void {
    // Always a good idea to use barriers on interrupt entry
    mem.barrier(.Write);
    defer mem.barrier(.Write);

    if (!IRQ_PENDING_1.get(AUX_INTERRUPT_BIT)) return;

    const IIR = AUX_MU_IIR_REG.get();

    if (IIR & 0b1 == 1) return;

    // RX has byte
    if (IIR & 0b110 == 0b100) {
        rx_list.push(read_byte());
    }

    // TX has space
    if (IIR & 0b110 == 0b010) {
        if (tx_list.pop()) |byte| {
            write_byte(byte);
        } else {
            interrupt_state(false, true);
        }
    }
}

Receiving

Receiving data is pretty simple:

Enter a critical section
Pop data from rx_list
Exit critical section

pub fn read_byte_async() ?u8 {
    const cs = mem.enter_critical_section();
    defer cs.exit();

    return rx_list.pop();
}

Transmitting

Transmitting data is also pretty simple:

Enter a critical section
Insert data into tx_list
Enable TX interrupts
Exit critical section

pub fn write_byte_async(byte: u8) void {
    const cs = mem.enter_critical_section();
    defer cs.exit();

    tx_list.push(byte);

    interrupt_state(true, true);
}

Flushing

Since we now have a secondary queue, we need to update our flush function to account for this. Essentially, enter critical section, get list length, leave critical section.

fn tx_list_length() void {
    const cs = mem.enter_critical_section();
    defer cs.exit();

    return tx_list.length();
}

pub fn writer_flush(io_w: *std.Io.Writer) !void {
    _ = io_w;

    while (
        AUX_MU_STAT_REG.get() & 0x200 != 0 and
        tx_list_length() > 0
    ) {}
}

Io Interfaces

Updating Io interfaces is left as an exercise to the reader.

Closing Remarks

The code we've written today does about everything you might want from a mini UART. Maybe I'll write a future blog post on some potential optimizations we may might want to make for this (such as directly streaming receive interrupts into a writer). In addition, you may want to add timeouts to read_byte and write_byte to avoid waiting forever.

Warning

None of the code in this post has been tested as written. Most of this code is the "abridged" version from my own mini UART code. No Generative AI was used in the production of this blog post (research, writing, etc), this post is entirely natural stupidity. All code examples are licensed under the Apache-2.0 License.

Acknowledgements

Link: "The BCM2835 is the Broadcom chip used in the Raspberry Pi 1 Models A, A+, B, B+, the Raspberry Pi Zero, the Raspberry Pi Zero W, and the Raspberry Pi Compute Module 1." ↩
Link: "The Broadcom chip used in early models of Raspberry Pi 2 Model B." ↩
Link: "This is the Broadcom chip used in the Raspberry Pi 4 Model B, Compute Module 4, and Pi 400." ↩
BCM2835/2.2 p.g. 10 - Mini UART ↩ ↩²
BCM2835/13 p.g. 175 - UART ↩
BCM2835/6.2 p.g. 102-104 - GPIO Alternative Functions ↩ ↩² ↩³
BCM2835/6.1 p.g. 101 - GPPUDCLKn ↩
BCM2835/2.1.1 p.g. 9 - AUXENB ↩
BCM2835/2.2.2 p.g. 14 - AUX_MU_LCR_REG ↩ ↩²
BCM2835/2.2 p.g. 14 - AUX_MU_MCR_REG ↩
BCM2835/2.2.2 p.g. 16 - AUX_MU_CNTL_REG ↩ ↩² ↩³
BCM2835/2.2.2 p.g. 19 - AUX_MU_BAUD ↩
BCM2835/2.2.1 p.g. 11 - Mini UART implementation details ↩ ↩²
elinux BCM2835 errata/the BCM2835 on the RPI ↩
Link: "Mailboxes facilitate communication between the ARM and the VideoCore." ↩
Link: Mailbox get clock rate ↩
Link: Mailbox clocks ↩
Link: Accessing Mailboxes ↩
BCM2835/2.2.2 p.g. 12 - AUX_MU_IER_REG ↩
BCM2835/2.2.2 p.g. 13 - AUX_MU_IIR_REG ↩ ↩²
BCM2835/2.2.2 p.g. 18 - AUX_MU_STAT_REG ↩ ↩²
BCM2835/2.2.2 p.g. 11 - AUX_MU_IO_REG ↩ ↩²
BCM2835/2.2.2 p.g. 15 - AUX_MU_LSR_REG ↩
std.Io.Reader ↩
std.Io.Writer ↩
BCM2835/7.5 p.g. 113 - ARM peripherals interrupts table ↩
BCM2835/7.5 p.g. 112 - Enable IRQs 1 ↩
BCM2835/7.5 p.g. 112 - IRQ pending 1 ↩

git-identity

2026-05-19T03:43:02Z

A while ago (July 2026), I wrote a tool called git-identity. It had a simple job, provide a quick way to switch between different identities (name & email pairs). Why would I do this? Well when you're more than one, it becomes kinda important (at least to me), to keep track of who did what. While I won't say that the others here are incompetent developers who introduce 10 new bugs in every commit, but I also won't say they're the best. Now if you were to ask them about me, they'd probably say the same thing, that I may or may not introduce 10 new bugs in every commit.

So after that short backstory, now time to talk a bit about git-identity. It's simply a shell¹ script that provides the following subcommands:

list: List all available identities
rebase: Rebase prior commits to current identity
switch: Switch identity
whoami: Print the current identity

There's not much to it. The script loads JSON files located in $XDG_CONFIG_HOME/identities/ and extracts a .name and .email field from them. From there, it calls git-config. It isn't particularly extravagant but it solved a problem that we had and I see that as perfectly fair. For git-identity-rebase, the script calls git-filter-repo to mass edit all previous commits.

Cheers and have a lovely day~, Eryn Vineyard

Bash ↩

On Plurality

2026-05-19T04:13:09Z

So you've landed on this page probably wondering why we just said we to describe outselves (to you, a singular entity). Or you might wonder why we said "we are Ivory." You might've also been pointed to this page after one of us struggled to answer an (apparently) simple question about outselves. You know, there's actually a lot of reasons that you may end up landing on this page. The point is this page addresses why Sylvia Ivory is actually many beings.

Analogy Time

So imagine your brain is a room. Now imagine yourself in this room. It's probably an empty room. Well that's what I'd imagine it to be since this isn't necessarily my situation. For my situation, imagine that there is more than one entity in this room who are not you. These other beings are people like yourself, with their own dreams, opinions, thoughts, and wishes. Pretty neat aye? Now also imagine these other entities (being referred to as headmates) can also control the body at times. Now you can imagine yourself as being secondary at times. Imagine that some memories are held by only some of these entities and despite you theoretically being around during these times, you don't remember anything.

Plurality

This is how we experience plurality, or the state of multiple self-aware entities coexisting within a single physical brain. This collective of people? A system, or to us, the Vineyard. While other systems may experience things differently, this is our own experience. What does this mean for you? It means that Sylvia Ivory is not one singular being, but a being controlled at times by others. The Sylvia that you may know is simply what happens when all of us here try to act like a cohesive person. Of course, we can't do this particularly well since we all are different. It's a bit difficult for a group of people to all emulate another person and for there to not be any inconsistency¹.

Tying back to why you might've come here. We say we since we are many people. Generally we cannot say in good faith the singular I unless it well and truly is just a singular member who did something. Additionally, we can't say that "I did X" in good faith as half the time it was not the fronter who did a given thing.

In short, we say we since it's what is correct. We are a collective, and we as a collective do things. In fact, this post is written as a collective. The first 3 sections were drafted by Eryn, the next ones by Kotlyn, and Camryn drafted the sidenote. We are here together so we might as well do things together.

Vineyard

As mentioned previously, the Vineyard is the name of our collective system. You might wonder, "well who else is apart of this vineyard system and how does it work?"

Members

Firstly, I'll first write about the members of the Vineyard and what may or may not be important to know about them:

Kotlyn Vineyard (fae/faer): Me! The current being writing this! I like programming. What else is there to know? I really like coffee. Looping back to programming, I generally like abstractions. Beyond that, I really like the outdoors and the greenery that exists.
Camryn Vineyard (fae/faer): Quite likes gambling. Also a fan of being condescending. Also of importance is faers interest in policy. Fae does consider violence always an option. Now how does that interact with their policy ideas? I actually don't know and I don't think I particularly want to know. Also really does not like Generative AI. As for kind of landscape, prefers more water-y landscapes (lakes, rivers etc).
Eryn Vineyard (she/fae/they): The wildcard. Always confused for Sylvia Ivory (aka the collective as a whole). She is very fond of biking, going to random places with no plan. She prefers more mountainous landscapes over the greenery that I tend to like. Like Camryn, she is also fond of policy and really does not like Generative AI.
Torino Vineyard (she/fae): Fan of the Manual on Uniform Traffic Control Devices. Also a very big fan of trains. As you might be able to tell, Torino is a fan of urban landscapes (since there's public transportation). A very big fan of public transportation. When she isn't going somewhere randomly, she manages to get lost while biking.
Kate the Evergreen (she/her): Also doesn't take on the Vineyard last name. Likes systems programming. Doesn't like water too much. Manages to destroy any and all computers in less than 5 minutes flat (or your money back). Meows a lot. Stereotypical Rust programmer.
Sylvie the Evergreen (she/her): Copied Kate's last name. Is a fan of meowing. Is too not a fan of water. Highly irresponsible financially. Gets lost very easily. Doesn't quite like programming. Is more of a fan of policy like Eryn but will still also dabble in sysadmin. Most likely to put us into financial debt :3c
Julie (they/them): Doesn't take on the Vineyard last name. A very large fan of the Julia programming language, and geology. Really quite likes rocks. Their favorite rock is Rose quartz, although they like almost all rocks in general (except sandstone). Not a fan of large crowds.

Functioning

Secondly, I'll describe how the systeme functions: It doesn't!

On a more serious note, we like to cycle the front around throughout. Sometimes you might get me (yippee), sometimes Camryn, etc. Depending on what we need to do, we might have someone specific in the front (like doing policy, cs, rocks, etc). We generally get along for the most part. There are occasional conflicts but they get resolved in a usually peaceful manner.

Etiquette

While I'm still here, I might as well explain some of our own speaking, and how one should interact with us.

For starters, 9/10 times when we say we, we mean we (inclusive), where the addressee(s) are excluded. In other words, "we" generally doesn't mean "you." ² Sometimes we may clarify by saying "we (system)" when it may become ambigious.

Usually whenever we say "I," we mean the current fronter. So when I say I, I mean I (Kotlyn Vineyard). On this website, "I" may be used to imagine the position of the hypothetical "Sylvia Ivory" (which will be noted by them being listed as the author).

If you wish to address just the fronter, you should just use "you." If you want to blame the collective as a whole, you should use "y'all" or "you all."

You should address us by whoever the current fronter is if you know. If you don't know, you should probably ask, or refer to us as Ivory/Evelyn/Ivy.

There isn't a "real person" or "an original" you can speak to. We're all real and none of us are more or less real than any other. Whenever you're speaking to the hypothetical "Sylvia Ivory", you're really just speaking to one of the member components of us. So please don't ask to speak to "the original" or "real person" since we're all real here.

Questions That We Thought Of Answering

Here's some question that we've probably gotten or have decided to prepare ahead of time just in case anyone asks them:

Who? Ivory.
What? Plurality.
Where? Not in the ocean.
Why? No.
When? Sometime.
How? No clue.

Now that Eryn got her "five Ws" out, here's some more questions and answers:

Do we like each other? Do you like your roommates (if you have them)? That's about how we feel with each other.
Why is this so confusing? No clue. But if it's confusing for you, it's even more confusing for us (who experience it).
Is this real? It's real to us and it's how we experience things. If you wish to accept that is up to you. Of course, don't blame us for not responding to the name Sylvia particularly well.

Additional Resources

More Than One

Sylvia Ivory

On Style

Note

Formats

Units

Numbers

Editorial

Footnotes

The mini UART

What is the BCM2835?

What is mini UART?

Prerequisites

Initialization

GPIO Initialization

Auxiliary I/O Initialization

Mini UART Initialization

Warning

Data Size

RTS/CTS

Manual Flow Control

Automatic Flow Control

Break Condition

Baud Rate

Putting it all together

Polling

Transmitting

Receiving

Some extras

Writer

Reader

Interrupts

Interrupt Setup

Configuring Interrupts

Interrupt Handler

Receiving

Transmitting

Flushing

Io Interfaces

Closing Remarks

Warning

Acknowledgements

Footnotes

git-identity

Footnotes

On Plurality

Analogy Time

Plurality

Vineyard

Members

Functioning

Etiquette

Questions That We Thought Of Answering

Additional Resources