This is a position paper that I originally circulated inside the firmware
community at X. I’ve gotten requests for a public link, so I’ve cleaned it up
and posted it here. This is, obviously, my personal opinion. Please read the
whole thing before sending me angry emails.
tl;dr: C/C++ have enough design flaws, and the alternative tools are in good
enough shape, that I do not recommend using C/C++ for new development except in
extenuating circumstances. In situations where you actually need the power of
C/C++, use Rust instead. In other situations, you shouldn’t have been using
C/C++ anyway — use nearly anything else.
This post is the third in a series looking at the
design and implementation of my Glitch demo and the
m4vgalib code that powers it.
In part two, I showed a fast way to push pixels out of an STM32F407 by getting
the DMA controller to run at top speed. I described the mode as follows:
It just runs full-tilt, restricted only by the speed of the “memory” [or
memory-mapped peripheral] at either side…
But there’s a weakness in this approach, which can introduce jitter and hurt your video quality. I hinted at it in a footnote:
…and traffic on the AHB matrix, which is very important — I’ll come back
Quite a bit of m4vgalib’s design is dedicated to coordinating matrix traffic,
while imposing few restrictions on the application. In this article, with a
minimum of movie puns, I’ll explain what that that means and how I achieved it.