A Shared Syntax for Custom Languages

2026-08-25T00:00:00+00:00

Introduction

I've been thinking about a universal syntax for programming languages, DSLs and data formats / config files. The motivation comes from a few different angles:

S-Expressions

I find Lisp's S-Expressions very intriguing. They are universal in a way the syntax of other languages doesn't tend to be.

Yet I don't quite want to use them. A lack of experience is certainly a part of it, but I find them quite hard to read.

Then there's also the formatter thing. Since the same syntax is used for everything it's quite hard for a formatter to know which formatting would be appropriate.

Data Formats

I also like using formats like JSON and RON. Especially in combination with Serde.

There is one persistent frustration however. And that is the lack of language server support.

It's quite frustrating to have a static schema in the form of type definitions, but to still get no support in the editor with finding the right names and seeing available fields.

There are solutions for this, like Tombi, but that's limited to JSON Schema. While a static schema is the baseline of what I want it's not quite sufficient.

To illustrate, let me talk about a templating language for PDFs I started to build once. The idea was to template Laser-PDF elements with a structure like Mustache. There was an external definition of available fields.

Notably the fields could be recursive, like a GraphQL schema. The template would first be evaluated to get a tree of used fields. That tree would then be used to actually fetch the data.

I was building this on top of RON and Serde at the time, so I couldn't even get the static list of elements in my editor. But to fully support this I would have needed to get the available templating fields in the editor as well.

Those weren't static. The program would read the schema from a file at runtime.

So this can't be done with a JSON Schema style solution. We need to be able to execute code in the LSP implementation.

LLMs and Non-Turing-Complete Languages

As I expanded on here, I think it's a good idea to have as much of LLM generated code as possible be in very restricted languages that aren't Turing-complete.

Unfortunately today, switching to a custom DSL or a config format often means loosing most of the editor support you get from your main general purpose language.

Why not KDL?

The KDL language is very interesting and seems to want to solve some of the same problems. However, it's clearly not meant to be used for anything that starts to resemble a programming language too much. It is very focused on an XML style structure of nodes with attributes and children and since the values of attributes can't contain other nodes, representing a programming language or certain kinds of DSLs with it would become very awkward.

An Attempt at a Solution

I really like using Nushell. One interesting thing about it (and most shells to a degree) is the way nested commands start looking like S-Expressions.

ls (pwd -P)

In Nushell the resemblence grows when you have to add parens toplevel when you want to split a command over multiple lines.

What if we use this as the starting point for our universal language? Meaning top level calls (whatever that means in the particular language; in a config format they'd be used for enum variants for example) don't need parens around them.

In order to avoid newline sensitivity and needing toplevel parens around multiline calls we'll add semicolons to separate them.

foo 12;
bar "12" (nested_call 12);

Now since any real laguage has some form of nesting we need something like blocks. Since we don't want to make any decisions that are specific to procedural languages where a block is a list of statements, we'll use the same syntax for blocks and lists.

foo [
  bar 12;
];

Maps

Now we get to something annoying.

Clojure has a dedicated syntax for maps. And it's a little bit awkward. Since, as a Lisp, Clojure aims to be homoiconic, the quoted form of a map is also a map.

This means you can't have the same function call multiple times as a map key:

{
  (my_function) 12
  (my_function) 13
}

This gets rejected even though my_function might have some internal state that makes it produce a unique key each time, which is possible since Clojure isn't a purely functional language.

Of course this isn't a huge deal in practice, since there are more ways to create maps, but it's still a little awkward.

Maps are also a bit of a point of weirdness in JSON. For the most part JSON is just a syntax and thus doesn't say anything about the uniqueness of object keys or whether the order of keys matters. RFC-8259 merely makes uniqueness a SHOULD.

I've actually ran into this with MariaDB's EXPLAIN FORMAT=JSON, which sometimes produces duplicate "table" keys instead of making it an array. This is valid JSON, but means you'll have a hard time processing it with standard tools like JQ.

I want my language to also have the property of just being a syntax, but I want to avoid the problem of unclear semantics. I also want to make it possible to build a Lisp style homoiconic language.

Because of this I decided to just represent maps as lists of calls, a bit like you'd do in KDL:

map [
    my_key 12;
    my_other_key 12;
]

The map here would be how you would handle it in the hypothetical homoiconic language, in other usecases like Serde deserialization it would be clear from context that the list needs to be parsed into a map. If you were to implement a Rust-style language with this syntax you'd also use that pattern for structs:

MyStruct [
  field_a 12;
  field_b 12;
]

And for struct definitions:

struct MyStruct [
  field_a u32;
  field_b i16;
];

You can already see how the call syntax can be used for more than just representing actual function calls. For example enum variants would also fit this pattern.

Pipes

There's another thing I want to steal from shells. Pipes.

I really like how you can use pipes allmost like method calls in Nushell for example:

start (ls --long ~/tmp | sort-by --reverse created | first | get name)

Many programming languages implement pipes in a way that that inserts the expression before the pipe as the first argument to the function after the pipe. For example consider this Gleam code from their language tour:

"Hello, Mike!"
  |> string.drop_end(1)
  |> string.drop_start(7)
  |> io.println

That is equivalent to this nested call:

io.println(string.drop_start(string.drop_end("Hello, Mike!", 1), 7))

This makes it tempting to support pipelines as a purely syntactic transformation while parsing.

So we would take syntax like this:

"Hello, Mike!" | drop_end 1 | drop_start 7 | println

And parse it to the same AST as:

println (drop_start (drop_end "Hello, Mike!" 1) 7)

I don't want to do it in this way, however. The reason is that a lot of languages have their own way of handling pipelines or method calls, that isn't simply equivalent to passing a first parameter.

For example in shells it means piping to stdin. Or in most object-oriented or adjacent languages method calls get resolved in the scope of the type (meaning something like method definitions inside the class defintion instead of just calling freestanding function with the given name).

So I think it makes sense to unify all those usecases with a single pipe syntax and let the particular language decide what they mean of whether to support them at all.

Beginnings of an Implementation

So far I've mostly been thinking about this language, but I have started to implement something.

I've made a declarative macro in Rust that parses my syntax into an enum. I mostly just wanted to stop myself from thinking about parser libraries and whether to just write my own parser.

I do however think supporting usage from a macro as well as parsing from strings will stay useful even after we have a proper parser. Though it'll probably become more of a function that gets called in procedural macros that define DSLs.

The goal of the syntax is to not have any special keywords. So anything from true to async just gets parsed as an identifier on the syntax level. It's up to the language whether those will then be handled specially or not.

The same goes for most symbols like +, - and so on. The exceptions are the few symbols that are needed for the structure: (, ), [, ] and |.

As a declarative macro we can't implement these rules perfectly. So for example some-thing is parsed the same as some - thing. With procedural macros we could look at the byte offsets, but I'm not sure I like that.

I think it's ok for the macro version to not be perfectly identical to the actual language. It's just about having an easy way to use a custom language inline sometimes. For example it could be useful for testing an implementation of a DSL without having string literals all over your tests.

I've also started implementing a Serde deserializer that operates on this data-structure. Of course a real one should be more efficient than this and skip the AST entirely.

The interesting part is that we can't fully support being self-describing using deserialize_any because our syntax doesn't differentiate between maps and lists and so we need the hint for those.

Let's see if I have the motivation and time to build out this implementation enough to make it useable. I decided to write this post mostly because I want to at least get the idea written down in case I don't.

GUI Experiments Link Collection

2026-03-29T00:00:00+00:00

This is just a collection of links to my various experiments around building GUI libraries. I'll expand this with new stuff over time.

These all have readmes that go into a little bit of detail about how they work.

https://github.com/lasernoises/wraptatui

This is a Ratatui wrapper where I implemented a bit of a weird widget API to work around limitations in the Rust type system.

https://github.com/lasernoises/spicetime

This is a small crate that implements owned and weak generational references. Weak references are Copy, but require a runtime generation check to read.

https://github.com/lasernoises/fluorine

This is a reactivity library with a design that is quite different from the ones I usually see.

https://github.com/lasernoises/egrikor

This is an older repo from a long abandoned attempt. I recently updated it with a readme that explains some of the problems I ran into at the time. I made some YouTube videos back when I was working on this that go into a lot more detail.

Is it time for more non-Turing-complete languages?

2026-03-26T00:00:00+00:00

I've been thinking a lot about our AI future and how we can manage the growing complexity associated with that. It's a topic that is being discussed a lot, but what I haven't seen being talked about a lot is the role of non-Turing-complete languages could play.

A different term for this would be DSLs (domain-specific langauge). And DSLs are of course a bit of a classic topic people have very different opinions about. I think it's a bit clearer to talk about non-Turing-complete langauges though, since nothing says that a DSL can't be turing complete. And I think it's usually bad when a DSL becomes turing complete (deliberately or not).

I think non-Turing-complete langauges have a lot of potential because there are so many thing that can't go wrong when a language is restricted by design. And the poperties that can't be violated can be designed into the language. Which tends to be much harder, if not impossible to design into a programming framework or library for the same problem space.

An example

A concrete thing I've been thinking about HTML templating.

Mustache is a good example of non-Turing-complete HTML templating, but I would suggest going a bit further.

Firstly I'd prefer the templating to be structure aware and while we're at it we can ditch the ugly SGML syntax.

div {
  "Some text"
  for my_var {
    span {
      "some other text with a {{ variable }}"
    }
  }
}

This has the property that we can statically prevent it from generating invalid html.

This is nothing special by itself, but there is one very interesting property that a Mustache-style language has. You can easily extract a tree of the variables and fields it uses. And that is quite close to a GraphQL query.

So I think we could build a query langauge that integrates with GraphQL (it doesn't have to be GraphQL in principle, just some tree structured query system). If you then combine that with a GraphQL server generated from a DB schema, you can basically build simple CRUD apps without any need for a Turing-complete language.

(Maybe something like this already exists. I haven't really researched this.)

I think a sensible next step would be to actually restrict the HTML tags and attributes to forbid any JavaScript directly in the template.

Making it work in practice

I think there are some important things to make non-Turing-complete languages not a bad idea in practice.

LSP integration

This might be the hardest bit.

I often find config files written in something like TOML to be a bit annoying in practice for a relatively dumb reason. And that is that my editor can't tell me what kind of keys I can use where. But there isn't really a good reason it should be this way. In principle writing a language server for such a language should be a whole lot easier than for a full general purpose programming language.

And it seems there's projects like Tombi that solve this problem. Though I think it's a bit unfortunate having to determine the relevant schema based on the filename. Maybe the XML idea of directly referencing the schema in the file itself isn't the worst idea (just please keep that ugly XML syntax away from me).

It seems the KDL language is going in an interesting direction there.

Escape hatches

The other thing is that you need a way to get to code written in a general purpose language for things that the non-Turing-complete langauge can't do.

I think for the HTML templating + GraphQL example this would be done at multiple layers. Firstly for the frontend you could use web components for things that can't be done in plain HTML. I think that's a better idea than allowing JavaScript in attributes.

Then of course if you have a generated GraphQL server you need a way to call custom code there. And maybe you even need a way to run custom code for HTML generation, but I'm not so sure how common that would be.

I think the important thing for all of these is that the escape hatch should be very explicit. And that the code it calls shouldn't be inline with the non-Turing-complete langauge, but in a separate place where you can keep an eye on its complexity.

What is a monad again?

2026-03-03T00:00:00+00:00

I keep being confused about what a monad is. I have previously convinced myself that I understand, but the feeling of understanding doesn't seem to last very long. So I thought I'd just write it down here in a way that is easy for me to understand should I get confused again in the future.

Monads are a mathematical thing defined in terms of operations and properties that need to hold. Haskell and some other languages have typesystems advanced enough to specify a monad as construct in the language. While other languages don't necessarily have sufficiently advanced typesystems to be able to represent a monad as an interface you can implement, any combination of a type and functions that satisfy the right properties is still a monad.

In Haskell the Monad typeclass looks like this:

class Monad m where
  (>>=)  :: m a -> (  a -> m b) -> m b
  (>>)   :: m a ->  m b         -> m b
  return ::   a                 -> m a

If you're like me this looks like absolute gibberish, so let's decode it a little bit. >>=, >> and return are functions. >>= is called bind and >> is sometimes called then. >> is just a shortcut for >>= with a value instead of a function for when m b doesn't depend on a.

With that sorted out, let's transform this typeclass definition into a pseudo syntax that a curly-bracket-brained person like me can read more easily:

class Monad m {
  fn bind(m<a>, fn(a) -> m<b>) -> m<b>;
  fn then(m<a>, m<b>) -> m<b>;
  fn return(a) -> m<a>;
}

There are also rules associated with this interface: https://wiki.haskell.org/index.php?title=Monad_laws.

Let's translate these to our pseudo-syntax as well:

Left identity: bind(return(a), h) == h(a)
Right identity: bind(m, return) == m
Associativity: bind(bind(m, g), h) == bind(m, fn(x) -> bind(g(x), h))

Monadic I/O

A while ago I made a very simple Rust implementation of an I/O monad to help me understand how monads are helpful for purely functional I/O. This isn't practically usable because bind accepts a function pointer and so you can't use closures there. And closures are an important part of making monadic I/O actually work of course.

enum IO<T> {
    GetChar(Box<dyn FnOnce(char) -> IO<T>>),
    PutChar(char, Box<IO<T>>),
    Done(T),
}

impl<A: 'static> IO<A> {
    fn bind<B: 'static>(self, f: fn(A) -> IO<B>) -> IO<B> {
        match self {
            IO::GetChar(g) => IO::GetChar(Box::new(move |c| g(c).bind(f))),
            IO::PutChar(c, x) => IO::PutChar(c, Box::new(x.bind(f))),
            IO::Done(x) => f(x),
        }
    }

    fn then<B: 'static>(self, b: IO<B>) -> IO<B> {
        match self {
            IO::GetChar(g) => IO::GetChar(Box::new(move |c| g(c).then(b))),
            IO::PutChar(c, x) => IO::PutChar(c, Box::new(x.then(b))),
            IO::Done(_) => b,
        }
    }

    fn ret(a: A) -> Self {
        Self::Done(a)
    }

    fn eval(self) -> A {
        match self {
            IO::GetChar(g) => {
                let c = std::io::stdin().bytes().next().unwrap().unwrap() as char;
                let next = g(c);
                next.eval()
            }
            IO::PutChar(c, x) => {
                print!("{c}");
                std::io::stdout().flush().unwrap();
                x.eval()
            }
            IO::Done(x) => x,
        }
    }
}

fn put_char(c: char) -> IO<()> {
    IO::PutChar(c, Box::new(IO::Done(())))
}

fn get_char() -> IO<char> {
    IO::GetChar(Box::new(|c| IO::Done(c)))
}

This can then be used like this:

get_char()
    .bind(|c| put_char(c))
    .then(put_char('h'))
    .then(get_char())
    .then(get_char())
    .then(IO::ret('r'))
    .bind(|c| put_char(c.to_ascii_uppercase()))
    .eval();

Lisp Formatting

2026-02-27T00:00:00+00:00

This is just a quick rant about formatting in Lisp that I felt the urge to write down.

I've been reading more about Lisp and I do really like the simplicity of S-expressions. What really annoys me though is the typical convention about formatting that everyone seems to use.

(let loop ((n 1))
  (if (> n 10)
    '()
    (cons n
      (loop (+ n 1)))))

This is just a random example from the Scheme Wikipedia page. What really bothers me is how all the closing parens are just piled up at the end.

(let loop ((n 1))
  (if (> n 10)
    '()
    (cons
      n
      (loop (+ n 1))
    )
  )
)

This is how I'd want to format that. It feels immediately much more readable to me that way.

I get that it uses more space, but I don't think that's actually a bad thing necessarily. Imagine I formatted my Rust code like this:

fn abc(a: bool) {
  some_other_function(
    1,
    if a {
      def()}
    else {
      2})}

Doesn't that feel cursed? It just looks like I'd rather be programming in Python.

Well this is how I feel whenever I read some Lisp code. It just feels like whoever wrote it would rather be using a whitespace sensitive language.

I actually kind of think this is the reason people make jokes about all the parens in Lisp. Aside from basic arithmetic Lisp doesn't really have more brackets than other languages, it's just that piling them up on the end of a line really draws attention to them.

But of course this is a personal preference thing. I'm sure you can get used to this formatting, though I think at that point you have to actually ignore the closing parens and look at the indentation. And I'm also sure that using a structural editor helps with this as well.

I'm also a bit of an extremist when it comes to putting closing syntax on new lines. For example, before using a formatter I was known for doing this:

a
  .b()
  .c()
  .d()
;

And even this:

some_function(
  a
    .b()
    .c()
    .d()
  ,
  12,
);

This also has the advantage of making the diff cleaner when you insert an additional call at the end of the chain, similar to trailing commas.

Creating a VGA Signal in Hubris

2025-09-15T00:00:00+00:00

A while ago I got a ST Nucleo-H753ZI evaluation board because I wanted to try out Hubris, Oxide's embedded operating system. After getting the basic demo app with the blinking lights running I set it aside for a lack of an idea what to do with it. A few weeks ago I was looking through old Raspberry Pi accessories on the hunt for a project. What stuck out to me wasn't any of the Raspberry Pi stuff, but the old 4 by 3 VGA monitor I had standing around. Could I just wire those pins in the VGA cable up to the GPIOs and produce a signal? As it turns out, yes you can just do that.

Getting Rid of the Sys Task

In the beginning I thought I was gonna be changing the GPIO pins from normal code, so switching them on and off at very high speeds. In hubris there's a stm32xx-sys task that normally controls the GPIO pins and also handles enabling clock to the different components through the Reset and Clock Control (RCC) block.

So normally if you want to set a GPIO pin you'd send a message to the sys task and it would do that for you. I was worried that the overhead of the context switching was gonna be a problem there.

So I decided to get rid of the sys task and do it all in my task.

The Plan

My first plan was to get the screen to just display a single color. I thought that it would be enough to get the vsync and hsync signals right and then just have the green pin high all the time to get a green picture.

Mapping the Registers

The peripherals of our chip are all controlled with registers. Those are memory mapped and to certain addresses. There is a gigantic 3000 page reference manual that describes all those registers. It's all very overwhelming. Luckily there's a Peripheral Access Crate (PAC) that defines an API for reading and writing those registers.

Since we're running under memory protection we need to first make sure we can actually write to those registers. In Hubris that sort of thing happens in an app.toml where all the tasks for an app are defined.

[tasks.vga]
name = "drv-vga"
priority = 1
uses = ["rcc", "gpios", "tim3"]
start = true

In this case the tim3 memory region wasn't a thing the Hubris build system knew about yet. The regions you can use there are defined in a chip.toml for the specific chip you have. In our case that's chips/stm32h7/chip.toml.

[tim3]
address = 0x40000400
size = 0x400

You get those values from a fun table called "Register boundary addresses" from the manual.

Blinking an LED with a Timer / PWM

The timers on this chip have a Pulse-Width-Modulation (PWM) feature which we should be able to use to generate the VGA sync signals. But the first step was to get a light blinking using PWM. The basic Hubris demo app does have a blinking LED, but that's not using PWM. Instead it uses the timer feature of the kernel, which makes a lot of sense for a Hubris demo, but we want to involve the CPU as minimally as possible for generating the signal.

My initial plan was to measure the PWM with my multimeter to see it working. I chose PB0 for this from the pinout table in the user manual of the board (which is different from the reference manual of the chip). PB0 is hooked up to timer 3, channel 3 (TIM3_CH3). Looking at the "Solder bridges and jumpers" section I found out that that's also connected to an LED on the board by default, so I chose to just test it that way.

By default here means that there's a bunch of predefined places on the bottom of the board where you can make connections by adding a bit of solder or remove connections by cutting traces or removing zero ohm resistors.

So after a whole bunch of fiddling I got all the registers set up right to get the LED blinking.

Setting up the H-Sync and V-Sync Timers

The first thing I sort of used for some guidance was this site where someone had done a similar project: https://www.programmerall.com/article/26476558/ That was pretty useful for the wiring itself and a basic understanding of how the signal works.

The basic idea is that there's three pins for red, green and blue and two pins for horizontal and vertical sync. The horizontal sync signal needs to be on for a bit between each line of pixels and the vertical one between frames. You can connect any of the color that you don't need to display to ground.

To connect the end of the cable to the GPIO headers on the board I ended up using some jumper wires and a breadboard. (The breadboard is just for all the things connected to ground.)

I could take off black plastic cover on the end of the jumper wires and clip off the pointy end. That left a sort of hollow bit that I could wrap some electrical tape around and stick onto the pins of the VGA cable. The connection is a bit loose, but it makes contact.

Before that I had tried soldering and that was a horrible idea because I don't have enough hands to hold the soldering iron, the solder and the jumper.

Then there's this site which has timing information for all the different resolutions: http://www.tinyvga.com/vga-timing

At first I chose 640×480 because I wanted a minimal pixel count. I got that sort of working to the point where the monitor would recognize a signal, but it would need a bit of time to auto-adjust.

I then decided I'd switch to 800×600 like they did in the link above, because those numbers add up much nicer: http://www.tinyvga.com/vga-timing/800x600@60Hz

Each timer has a prescaler that can be used to divide the base clock, which is 200 Mhz in our case. The timer will then count up until it reaches the value in the auto-reload register (ARR). Then there's also the capture/compare register (CCR), which determines for which part of the cycle the output is on when doing pulse-width modulation.

For hsync I set the prescaler to zero, meaning the frequency is divided by one, because that register is offset by one. Then I set the ARR to 5279 (also offset by one) and the CCR to 640 (not offset by one). That means the timer counts up 200 times per microsecond. 5280 / 200 gives us the 26.4 µs that we need for one line and 640 / 200 gives us the 3.2 µs for the sync pulse.

For vsync I set the prescaler to 21119. 21120 / 200 gives us 105.6 µs, which is the width our sync pulse should be. So then we can set the CCR to 1. The ARR is set to 156 to give us 105.6 µs * 157 = 16.5792 ms, which is exactly the time a whole frame should take.

All Green all the Time Not Working

My hope was that I could get to a fully green picture pretty easily by just hooking up the green pin to a GPIO pin that was on. That ended up not working, I suspect because the monitor uses the voltage that's on the color pins during the h-sync as a baseline or something like that.

DMA to the DAC

The next plan was to continuously repeat a single line. I decided to try to use the Digital-to-analog converter (DAC) for this.

The basic way the DAC works is that you first need to set a GPIO pin that's hooked up to the DAC into an analog mode. This isn't one of the altenate functions like you'd use for the timer, but a whole separate mode. Then there's a data holding register you can write an 8 or 12 bit value into. That will determine the output voltage you get on the pin.

Now, we don't want to keep the CPU fully occupied with constantly setting that register, so we need a better solution. Luckily the h7 has dedicated units for copying memory around. There's actually at least four different kinds of these, but we'll start with a "normal" direct memory access controller (DMA). There's two of those, but well use DMA1.

When I wanted to map the DAC control registers into my task I got a build error. As it turns out, the memory protection unit only supports eight memory regions at a time, meaning per-task in Hubris. I resolved that by grouping some timers together. They also need to have a power-of-two size and be aligned to their size, which would lead to problems later when I tried to group more things together, but it worked out for the timers.

What I ended up doing here is to hooking up the timer to the DAC and configuring the DMA request multiplexer (DMAMUX) to be triggered by the DAC. Then I set up the DAC in circular mode with a pointer to a buffer.

Eventually I got it looking like that (with a lot of flickering of course):

Now that wasn't looking very much like the data that I wanted to DMA into DAC. It was also changing quite a bit based on what exactly the code around it did (like adding something do a debugging ringbuffer). It appears that the DMA unit doesn't go through the CPU caches, so likely this was some random data.

After some digging I found out that there's different kinds of memory on this chip that are configured differently in Hubris. You can see that configuration in chips/stm32h7/memory-large.toml. Among others there's a dma flag that can be set for a region. I'm not sure what that does exacly (it looks like one thing is that the kernel will refuse to copy from or to there), but putting my buffer there using the link_section attribute seems to make our DMA work.

After I got that to work all that was left was a lot of confusion because I had gotten the math for the pixel timing wrong. But after I had figured that out I was able to produce a nice gradient.

(If you're confused about the color: I had switched to blue instead of green at some point.)

Switching between on and off pixels leads to a pattern like this:

The DAC seems unable to produce sharp edges and also the average output seems to get higher after switching on and off a couple of times.

Here they used the SPI hardware support to produce an image, so maybe I should try that next as well.

Return of the Sys Task

The next thing I wanted to do of course was to produce an actual 2 dimensional image. So far the CPU hadn't been involved after setting up the registers. The DMA would keep going even if the CPU was halted.

This starts to become a problem for a 2D image though. If we were to keep our circular mode buffer and wanted to store a whole image in it we'd need a bunch of bytes for that. While we can horizontally repeat the same pixel 8 times (by decreasing the timer frequency), we can't do that vertically. So we'd need 132 (1056 / 8) × 628 = 82896 bytes for that buffer.

That would fit into one of the sram regions, but it's a bit of an inconvenient format for a framebuffer with vertical pixels being 8 times smaller than horizontal ones.

Luckily there's the master direct memory access controller (MDMA), which can be triggered by the completion of other DMA controllers and supports much more complex configuration.

But at this point I was definitely out of regions that could be mapped to my task. Since it was very clear at this point that we weren't goint to do high speed GPIO toggling on the CPU we could actually re-introduce the sys task. This means that we could get rid of two regions from our task (RCC and GPIO) and we'd have space for the MDMA control registers. It's kind of funny how this hardware limitation can encourage splitting things into different tasks.

I was able to get the MDMA copying into the DMA buffer, but I haven't quite been able to get a framebuffer working yet. So this is the end of this post. I hope I'll find some more time for this project soon and I'll try to make another post if I get something more interesting going. I already have some ideas about what to do with a working framebuffer.