Optimizing IRQ latency on the STM32H743 @ 480 MHz, perhaps for NES ROM emulation... Best result so far: 100 nanoseconds input-to-output latency when the vector table and the IRQ handler are relocated to Tightly-Coupled Memory without making HAL calls. Not bad, but the GPIO controller (several buses away) looks like the real performance killer here. WARNING: buggy code, see correction https://mk.absturztau.be/notes/ajvb448y305b01i4. #electronics#STM32
Keep optimizing IRQ latency on the STM32H743 @ 480 MHz. Just enabled i-cache and d-cache, and the IRQ latency dropped from 100 ns to 70 ns. 🚀 But cache shouldn't work like this. So my code is still touching slow memory somewhere. The stack perhaps, which is still in "normal" RAM. The slow Flash perhaps also makes it slower to abort main() if an instruction is stuck in a wait state. Need to check everything carefully... #electronics#STM32
Keep optimizing IRQ latency on the STM32H743 @ 480 MHz. The 70 ns vs. 100 ns overhead mystery solved. I did not correctly relocate the vector table to Tightly-Coupled Memory properly, it was still in Flash. The STM32 HAL macro USER_VECT_TAB_ADDRESS is a flag, not a memory address! In fact, only several hardcoded addresses are available, a real user override is not provided (the name "user" is a lie). Solution: just change VTOR manually, don't trust the startup code. I'm now getting 70-ns IRQ without CPU cache. #electronics#STM32
Q: What should you do when your application needs real-time control? A: You start using an RTOS. Q: What should you do when your application really needs real-time control? A: You stop using an RTOS.
I guess the "Rewrite in Rust" movement is more about using Rust's popularity as an excuse to create community-approved breaking changes and clean-slate designs. PaX Team added the essential security feature W^X to C in the early 2000s, and guess what, this made a lot of application people very angry and been widely regarded as a bad move. But if you rewrite a whole system in Rust, nobody says you break their spacebar-CPU-heating workflow that they depend on.
#TIL Convert a video to black-and-white in ffmpeg by simulating the "connecting only the Y cable to the TV" trick. Unlike other filters, it doesn't waste CPU time on unneeded processing:
How do pirated Nintendo N-in-1 game cartridges work? In the 1990s China, it was not a NESdev page for people with too much time, it was Serious Business! With its own textbook reviewed by EE professors at a top university. Because as we all know, they were for <del>game consoles</del> educational home computers, so the engineering knowledge is of uttermost importance! :blobcatlul: #retrocomputing#retrogaming#NES#小霸王学习机
Fun fact: The full 6502 machine code of the NES game F1 Race was reverse engineered in China in 1994 by an independent developer 于春, who later wrote a 400-page NES programming textbook about it, making him a little-known NES ROM hacking and homebrewing pioneer worldwide, possibly one of the few NES experts in the world who didn't sign an NDA. Why? To make 8 millions of <del>Nintendo game console clones pretending to be</del> educational home computers in the country actually be educational as advertised. This was also the only surreal opportunity in the world for someone to become a national hero politically, for the service of REing Nintendo games. #retrocomputing#retrogaming#NES#NESdev#小霸王学习机
Previously: @niconiconi@cybre.space / Code monkey and sysadmin / No nations, no flags, no patriots. / Chaotic Neutral / Now Accelerationist / currently NEET + hikikomori / ? “Onii-chan is watching you!", use OpenPGP: FAD3EB05E88E8D6D / biologically male, self-identified as '; DROP TABLE genders;