The internal DAC in most of these microcontrollers is way too slow for VGA. According to this[1], for STM32 you can generally expect at most 1MHz without external additions; that's way too slow even for e.g. 320x240 which has a pixel clock of over 10MHz.
A lot of hobbyist projects use simple improvised DACs made with a few resistors. Here are mine for the ESP32[2] and the RP2040[3] (Raspberry Pi Pico), both use 320x240 (just the standard 640x480 with half the pixel clock and every line repeated to half the resolution in both width and height).
(I work at Oxide, though I wasn't around for the initial chip selection process)
It's at least partially a matter of timing: Oxide was picking its initial hardware in roughly 2020, and the RP2040 wasn't released until 2021.
A handful of people have done ports, e.g. https://github.com/oxidecomputer/hubris/pull/2210, but I expect to stick with STM32s for the foreseeable future – we've got a lot to do, and they're working well enough!
The internal RFD on the SP's design still talks about choosing RISC-V, and I don't think (or am simply bad at using search) that the move ended up being in an RFD.
The internal DAC in most of these microcontrollers is way too slow for VGA. According to this[1], for STM32 you can generally expect at most 1MHz without external additions; that's way too slow even for e.g. 320x240 which has a pixel clock of over 10MHz.
A lot of hobbyist projects use simple improvised DACs made with a few resistors. Here are mine for the ESP32[2] and the RP2040[3] (Raspberry Pi Pico), both use 320x240 (just the standard 640x480 with half the pixel clock and every line repeated to half the resolution in both width and height).
[1] https://www.st.com/resource/en/application_note/an4566-how-t...
[2] https://github.com/moefh/esp32-loser
[3] https://github.com/moefh/pico-loser
RP2040 and RP2350 PIO makes producing VGA signals criminally easy.
But many other µCs can do it too, at least to some degree. Even Atmels.
I just realized that my keyboard has two of those RP2040's on it, which is giving me some very bad ideas.
There's probably a well documented backstory on why Oxide choose stm32xx nucleo. I'm guessing VGA signals were not a top priority for hubris
(I work at Oxide, though I wasn't around for the initial chip selection process)
It's at least partially a matter of timing: Oxide was picking its initial hardware in roughly 2020, and the RP2040 wasn't released until 2021.
A handful of people have done ports, e.g. https://github.com/oxidecomputer/hubris/pull/2210, but I expect to stick with STM32s for the foreseeable future – we've got a lot to do, and they're working well enough!
The rack has no screens, so no need to drive VGA, it's true.
Probably the best history on the choice of going with ARM comes from here: https://news.ycombinator.com/item?id=28989138
The internal RFD on the SP's design still talks about choosing RISC-V, and I don't think (or am simply bad at using search) that the move ended up being in an RFD.
my thoughts too. this is a hello world bare metal step up. doing it to get to grips w gpio on a full blown os is cool too though