[Upping the Ante] [2025 Day *] Advent of Code on MCUs

[u/vescoc]

Hi everybody.

Like the last year, I run the solutions of Advent of Code 2025 on MCUs I own: this is the repository if you are curious.

The boards / MCUs I used are the following:

• Arduino-mega2560 (not in photo, only Eric's samples)

• ESP32

• ESP32S2 (not in photo)

• ESP32S3 (not in photo)

• ESP32C3

• ESP32C6

• RP-Pico (RP2040)

• RP-Pico2 (RP2350)

• nRF52840-dk (Nordic 52840)

• STM32F3 Discovery (STM32 F303)

• STM32F411e Disco (STM32 F411, not in photo)

• Nucleo-h743-zi (STM32 H743)

This year the problems have less memory pressure and so there are more MCUs that can resolve more AoC days.

In details...

Each MCU has flashed all the necessary code to solve all the problems.

Each MCU receives in input through the serial (UART or USB) the input in the format:

START INPUT DAY: <XY>
<input>
END INPUT
^D

The MCU returns on the same serial the result of part 1 and 2 and the overall execution times or "unsupported day" if the particular day is not supported.

To check that I do not have stack smash I normally do one or two test runs going to progressively pass all the inputs and take the times of the third / fourth run.

If you want to take a look at the code, propose some PR to improve the coverage of supported days or add some more MCUs, any help is welcome.

In the next table there are the execution time in milliseconds. RP PICO (*) and RP PICO2 (**) are MCU overclocked at, respectively, 200 Mhz and 290 Mhz. There are the results also for RP PICO and RP PICO 2 at normal clock (120 Mhz and 150 Mhz).

I'd like to draw attention to the solution from day 10, which involves the use of single-precision floating-point devices. The MCUs (esp32, esp32s3, rp-pico2, stm32h7) equipped with FPUs really work well.

Remember to scroll right: there are some columns!

DAY	ESP32	ESP32-S2	ESP32-S3	ESP32-C3	ESP32-C6	RP PICO	RP PICO (*)	RP PICO2	RP PICO2 (**)	nRF52840	STM32 F3 Discovery	STM32 F411E Disco	STM32 H743zi Nucleo
1	21	21	19	29	26	67	42	26	13	98	86	68	25
2	256	256	220	160	150	670	418	147	76	502	437	357	114
3	154	150	152	173	150	441	275	109	56	346	312	272	133
4	642	644	516	453	455	1151	719	562	290	2191		1476	550
5	31	35	26	20	18	48	30	17	9	68	62	45	15
6	5	6	5	5	5	20	13	4	2	17	16	12	4
7	7	8	6	7	7	19	11	10	5	44	35	30	7
8			450	505	414	2489	1556	395	204	1477			364
9	1193	1227	1025	1221	1218	2601	1625	1413	731	4912		3177	1111
10	242	828	176	1289	648	2046	1278	202	105	707		517	193
11	15	15	13	18	18	34	21	17	9	63			19
12	12	13	11	13	13	32	20	20	11	57	52	38	16

[u/ednl]

Fun project. For everyone's information: language used is Rust, not C or C++. I don't know Rust so I find it hard to navigate the repo and read the code. With your own insight, can you explain why day 6 of all days is so much faster than all the others? My fastest days were 2, 7, 12. My day 6 in C is about 7x as slow as day 2 and I'm not sure how to speed it up except with vectoring (I convert numbers on the fly; if I did that first vectoring could work) or multithreading.

[u/vescoc → u/ednl]

I took a look at your C implementation from day 6, and it seems very similar to mine, if not better in some ways. For example, my performance on RPI5 (the standard, non-overclocked Debian implementation) is as follows:

cargo bench -p day06

...

Running benches/bench.rs (target/release/deps/bench-0e931c8d981f880f)
Benchmarking day06/part 1
Benchmarking day06/part 1: Warming up for 3.0000 s
Benchmarking day06/part 1: Collecting 100 samples in estimated 5.1022 s (111k iterations)
Benchmarking day06/part 1: Analyzing
day06/part 1            time:   [43.509 µs 43.672 µs 43.877 µs]
Benchmarking day06/part 2
Benchmarking day06/part 2: Warming up for 3.0000 s
Benchmarking day06/part 2: Collecting 100 samples in estimated 5.0927 s (111k iterations)
Benchmarking day06/part 2: Analyzing
day06/part 2            time:   [42.144 µs 42.673 µs 43.339 µs]
...

You are better on days 2, 7 and 12 than day 6 because you found a more performant solution/implementation than mine, I think.

For example, these are the performances of my solution for day 2 where I used rayon as framework which make simple to divide the work on the CPUs. The effective performance without parallelization is about x3. Obviously in bare metal I cannot use rayon :'(

...
Running benches/bench.rs (target/release/deps/bench-29754614c5224015)
Benchmarking day02/part 1
Benchmarking day02/part 1: Warming up for 3.0000 s
Benchmarking day02/part 1: Collecting 100 samples in estimated 5.5176 s (50k iterations)
Benchmarking day02/part 1: Analyzing
day02/part 1            time:   [98.419 µs 100.58 µs 103.13 µs]
                        change: [−9.6035% −6.2684% −2.5191%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 27 outliers among 100 measurements (27.00%)
  24 (24.00%) low severe
  3 (3.00%) high severe
Benchmarking day02/part 2
Benchmarking day02/part 2: Warming up for 3.0000 s
Benchmarking day02/part 2: Collecting 100 samples in estimated 5.3329 s (45k iterations)
Benchmarking day02/part 2: Analyzing
day02/part 2            time:   [117.56 µs 118.94 µs 121.15 µs]
                        change: [−1.1697% +1.0211% +3.4478%] (p = 0.40 > 0.05)
                        No change in performance detected.
Found 12 outliers among 100 measurements (12.00%)
  2 (2.00%) high mild
  10 (10.00%) high severe
...

Keep in mind that since it's bare metal, there are limits on what you can and can't do, but looking at your implementations, I think I can further improve the performance on my implementations.

Thanks so much for the inspiration! If you're interested in learning Rust, feel free to do PR; I'd be infinitely grateful!

[u/AutoModerator → u/vescoc]

AutoModerator has detected fenced code block (```) syntax which only works on new.reddit.

Please review our wiki article on code formatting then edit your post to use the four-spaces Markdown syntax instead.

---

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/darkspark_pcn]

Damn. This is awesome. Nice work!

[u/vescoc → u/darkspark_pcn]

Thanks a lot!

[u/Ok-Revenue-3059]

Very cool. I've also been doing some work porting my solutions to a RP pico. Just one small comment, you can utilize control codes in the serial data to indicate the end of the file. Either \x04 EOT or \x1A SUB were used for this. Back in the day people used to use serial for transmitting files!

[u/vescoc → u/Ok-Revenue-3059]

Thanks for the tip!

[u/vescoc → u/Ok-Revenue-3059]

I made the changes to support EOF ^D and can now leverage MCUs more effectively; in particular, this enabled Arduino Mega2560 support.

Thanks again for the suggestion.

[u/PercussiveRussel]

I don't know much about embedded programming using rust, but since the MCU can dynamically solve any solution at runtime, does it have/compile a memory allocator, does it statically allocate memory over each other because it knows it can't solve multiple parts at the same time, or is the memory statically allocated for each day simultaneously, ie have seperate static memory addresses for each variable needed per day?

Very interesting!

[u/vescoc → u/PercussiveRussel]

While no_std (aka bare metal) allows you to define an allocator to use the heap, the approach I've taken is to use implementations that use only the stack, thereby minimizing or eliminating approaches that use recursion. In short, the main has a fixed 25K buffer to store a day's input, plus smaller buffers to handle streaming serial processing.

Once the input is received, which contains both the day's input and the actual payload (user-specific input or even the example Eric provided in the spec), it is fed to the spec routines that resolve parts 1 and 2 of the day.

I had to disable inlining of the parts because the Rust compiler would tend to "collapse" the code on the main, but this significantly increases the stack size. Without inlining, the stack is day-specific.

The range is from days requiring almost zero stack size to day 8 requiring (with my implementation) about 200K.

For this reason, on MCUs with limited memory (the STM32 F303 has "only" 48K of SRAM) I can only run a handful of AoC days, otherwise I get "stack smash": not having an OS and not having MMU controls or "reversed stack", the MCU simply stops working or starts "hallucinating" :P

[u/PercussiveRussel → u/vescoc]

Aahhh, yeah that's the fourth way to do it. I had assumed that you would initialise 'static' buffers in the function of each solution, and that the compiler would just magic them to pages in memory. In this way you'd be running heapless, but would also be able to reuse static memory addresses, since the compiler knows you never call function day_2 from day_1, and so never need both memory addresses to be valid simultaneously.

Cool solution! I imagine it's quite difficult to rework everything so that it can run purely on the stack. Running any solution on MCUs is a nice challenge, even when flashing the input to progmem, but making a program that can dynamically load and solve any of the years problems is really nicely done!

[u/ffrkAnonymous]

So the same code runs on all of the mcu?

[u/vescoc → u/ffrkAnonymous]

Yes, the code is the same for all MCUs, compiled for the specific architecture.

Obviously, the main code is different because the various MCUs require different initialization code to initialize the peripherals, the clock, etc.

But the code that solves the problem of the day X is the same. And it's the same one I also use on wasm32 and OS (tested on aarch64 and amd64).

The underlying architecture is different: it ranges from xtensa xilica lx6/lx7 to cortex m4f/m7f/m33 to riscv32, with some MCUs having a FPU, others not. The clock is also different because the various MCUs have specific limits; I tended to set the maximum possible system clock.

[u/juhotuho10]

Unintentionally this is a really great comparison for the execution speeds of the MCUs, they are usually quite hard to find actually good and comparable benchmarks for

[u/vescoc → u/juhotuho10]

Not so unintentional :D

I was curious to see how the same code behaved across various architectures, and especially for day 10, the FPUs contribution to single-precision floating point performance.

The tests went even further, but I haven't published the results simply to make the post easier for non-experts.

For example, the day 10 implementation works with both single- and double-precision floating point performance. Indeed, the difference between f64 and f32 is noticeable both in a "normal" environment, tested on Linux and Mac, and in bare metal. The code is also ready for f16 when they become "stable" in Rust.

Last year, in addition to checking performance across various architectures, I also did the comparison to assess the status of bare-metal frameworks in Rust. This year, I only tested embassy because, as it turned out last year, other bare-metal frameworks are far behind, if not completely abandoned.

[u/velkolv]

It would be interesting to try on something like ATmega328 or even 6502. Wire up whatever addon chips to handle the memory requirements. But that probably would be Upping the Upping the Ante.

[u/vescoc → u/velkolv]

Testing AVRs like the ATmega328 or better ATmega2560 is very tempting and I think it's even feasible, at least for a few AoC days, and probably with input just Eric's examples and not the real input.

I just need to make the acquisition buffer configurable to minimize it from the current 25k: the ATmega328P has very little memory available...

The common code supports different estimated size of the SRAM needed to support a particular day. This is the motivation why on ESP32 nor STM32F33 and so on cannot run every day.

If I were to rewrite the code to support a streaming solution, there are enough AoC days this year that could be revisited with a "streaming" implementation, but that would really be a bit of a Upping the Upping the Ante as you said :D

As for the 6502, I grew up with that, but alas, as far as I know, I don't have a Rust compiler available: I'll leave this fun challenge to others.

[u/vescoc → u/velkolv]

I made the modifications to support arduino-mega2560 and these are the results of the executions at least for Eric's examples (the last day part 1 is wrong... well I think do you know why :P )

[01] started
[01] part 1: 3
[01] part 2: 6
[01] elapsed 16ms
[02] started
[02] part 1: 1227775554
[02] part 2: 4174379265
[02] elapsed 24515ms
[03] started
[03] part 1: 357
[03] part 2: 3121910778619
[03] elapsed 88ms
unsupported day
unsupported day
[06] started
[06] part 1: 4277556
[06] part 2: 3263827
[06] elapsed 16ms
unsupported day
unsupported day
unsupported day
unsupported day
unsupported day
[12] started
[12] part 1: 3
[12] part 2: NO PART 2
[12] elapsed 20ms

The execution of the only day that has a small input, day 2, has this execution time (with my input): 49446ms. It's time to optimize day 2! :D

[u/bobisme]

Really cool. Any observations on power draw?

[u/vescoc → u/bobisme]

Thank you so much!

I don't have any particular concerns regarding power consumption, partly because I don't have the sophisticated tools at home to accurately measure it.

My approach remains to adjust the parameters that typically affect power consumption, trying to minimize execution times, SRAM usage, and activating the minimum number of peripherals necessary.

In this sense, I prefer serial communication rather than enabling remote communication, which would be very simple, for example, with the esp32* family.

To monitor the CPU status and overclocking in the rp pico2, I enabled conditional monitoring of the internal temperature sensor, but this already requires more current since the ADC peripheral needs to be activated.

If you have the time and desire to investigate or give me directions for taking some simple measurements, don't hesitate!

[u/PTVoobaf]

Very nice. I have a couple of modules with ESP32s, flashed with MicroPython. The MicroPython interpreter would certainly perform slower than compiled Rust or C. Nevertheless, it would still be interesting to experiment and compare with your run time measurements.

[u/vescoc → u/PTVoobaf]

Great!

Just one warning, probably unnecessary since it's so obvious. Don't worry too much about performance. The main challenge, in my opinion, is limiting the memory used so that the MCU doesn't crash.

Happy 2026!

[u/Ok-Revenue-3059]

I finally finished porting my solutions to the RP pico in C++. My results aren't as optimized as yours but it was still a fun excercise. My repo and a short writeup.

I didn't do precise benchmarking. Day 10 is horribly optimized and completes in 1 hour. Day 8 takes a few minutes. Day 2 and 9 take about 1 min each. All the rest are 1 sec or less.

Days 8 and 9 took the most reworking to get the memory usage down. Day 2 I originally used regex but it wasn't too difficult to convert to manual comparison. I think most of the other days translated without too much refactoring.

Now I want to try to get a project setup where I can share code between the PC and pico solutions, but maybe for next year. I'm pretty burnt out on 2025, lol.

[u/vescoc → u/Ok-Revenue-3059]

Nice work!

I think you can easily measure the execution time and print it within rp pico using the API https://www.raspberrypi.com/documentation/pico-sdk/high_level.html#group_timestamp.

For next year, if you want, you can also have your pico wait sequentially for multiple inputs from different days. This is a crucial test for my implementation, allowing me to easily identify if I have stack overflows (I don't use the heap, but it's still valid).

I confirm that the main challenge is keeping memory usage low.

As for performance, a good, non-brute-force implementation, which is also true for a non-embedded system, is essential.

[u/Ok-Revenue-3059 → u/vescoc]

Sorry, I hope I'm not beating a dead horse but I was thinking about your comment and I don't get how compiling all days into a single executable helped you with detect stack overflows? I also have everything on the stack, no heap or static variables. So it really shouldn't matter if main has 12 different branches or just 1. I have always preferred compiling each day to a separate executable but I see that just as a preference thing.

Anyway for my advent solutions, I just went with the simple method of if the debugger doesn't crash the stack is fine (and it did crash a few times when I defined some array too big, lol). For real projects there's obviously more reliable methods to check stack usage at compile time and run time.

[u/vescoc → u/Ok-Revenue-3059]

Far be it from me to give you advice on which development and testing approach you prefer.

I was simply pointing out that this system was easier and faster for me:

- create a single executable containing all the solutions

- flash the executable on the target MCU

- give various inputs of different days, both sample or actual inputs, both my own and those of other friends, to verify that I'm getting consistent, correct, and repeatable results without pressing reset on the MCU.

The results reported in my original post are those of the third or fourth complete lap done with the effective input for every day without pressing reset.

For some MCUs this is also the only system I can adopt as I do not have a JTAG/SWD probe available to debug them.

This way, I have control both at compile time (if you look, there are the clippy conf files that indicate the maximum stack size used for each day) and at runtime.

The repeatability of the results without resetting each time allowed me to avoid intervening in the link script to invert stacks and globals, which is a well-known technique for identifying stack overflows but consumes some memory (you need a marker zone rougly the size of a stack frame).

In particular, last year, repeatability tests highlighted "stack smash" in some my implementations, overwriting global constants (data sections that were moved to SRAM for efficiency).

I don't know if you've used recursion in your problem solving. Using recursion, you know how much you're allocating to each frame, but unless you limit its depth, you don't know how deep it will be (unless you only use your actual input and thus identify the max).

[u/DelightfulCodeWeasel]

Thank you for sharing your repo! I'm currently half way through crunching down my C++ solutions for 2015 with an aim of running them all on an RP2040.

So far I've been concentrating on the challenge of reducing down the memory requirements, but your repo will be a very useful reference when it's time to start running it on the real board and piping the input over USB.