Prelude

When I was 15 or so, I started playing with microcontrollers. As I recall, flashing AVR’s used to be a pain. The AVR ISP interface needed at least 5 pins to work:

• GND
• RST
• SCK
• MISO
• MOSI

Afterwards, Microchip (or was it Atmel?) invented a new programming and debugging interface based on two wires only:

• GND
• UPDI

It’s really neat. The protocol offers flashing capabilities and debugging ones. It’s effectively possible to interact with the microcontroller during runtime. Notably, it’s possible to read the RAM while the main program is running.

UART over UPDI

For some project, I needed to debug the logic and thus some microcontroller-to-host communications. Toggling some leds wasn’t enough, and, as I was using a small IC, I didn’t have any pins left for an UART interface.

So I thought: if the host can read the MCU’s RAM, then we could pass content through its memory directly.

When the MCU needs to send a message, it would be written to a (blocking or not) ring buffer. When the host reads the contents, it writes back the bytes written and the message can continue to be streamed.

I was developing in Rust (using the good Rahix/avr-hal library) and there was no equivalent crate. It was a good time to invent the wheel ;-).

The ramlink struct looks like that:

pub struct RB<const SIZE: usize> {
    /// This eats 3 bytes for "nothing" but is useful for
    /// debuging purposes to ensure that the RAM address is correct
    _magic_marker: [u8; 3],
    /// Size of the ring buffer.
    /// Could be removed if both parties agree on a defined size
    size: u8,
    /// Producer slot
    producer: u8,
    /// Consumer slot. If producer = consumer, ring buffer is empty
    consumer: u8,
    /// The actual buffer
    content: [u8; SIZE],
}

The _magic_marker field is not really needed, but I found out that it makes finding the RB in ram easier. Indeed, it not always easy to specify the memory location of the struct in RAM. So by adding these fields, it’s just a matter of searching for the [0x88 0x88 0x88] bytes.

size is also optional, but then it needs to be specified on the consumers side, which is a pain.

Hardware considerations

I use the really nice jtag2updi firmware flasher to flash my AVR. It works with avrdude and “basically” implements the JTAGICE mkII protocol on one end and the UPDI on the other. The mkII protocol supports writing from/to RAM for their debugging products. However, jtag2updi doesn’t implement these features. I had to create a small modification to allow reading and writing the RAM without locking up the CPU. At this point of writing, it’s still not merged.

The code

If you’re interested, you can find ramlink here

Example

And if you want it to try out yourself, you can check out this code which implements a simple producer (running on an AVR) and a consumer.

The producer runs on an Attiny42 and periodically writes the "Hello!" string followed by the [1,2,3] numbers.

The consumer connects to the MCU through the jtag2updi programmer and streams the output.