So while reading a tutorial to find out how many pins an SD card needs (to start totalling up how many pins I need), I found out that there's software called STM32CubeMX that conveniently does all this:

As you may be able to tell, this is the U5G7. The reason why it's not the U5G9 is because I was configuring the pinout and found out that the 100-pin package only supported either parallel or MIPI display-out. This software was very helpful in seeing all the details I missed and skimmed (and wouldn't've even bother reading until I needed to make a schematic) as well as not only knowing how many pins I have left, but the distribution of used pins.

The software has a power consumption calculator and seems to imply that 16mA is the max it would consume:

The reason I started all this was because the ESP32P4 might exist sometime this quarter (heard in Binaris discord) or sometime 2025 (heard in the ESP discord) and that has a 104-pin package, so I had the idea to use the U5Gx to get an estimate on if there would be enough pins:

One of the things I don't think the P4 has that the U5G does is a USB Type-C + Power Delivery controller, meaning that a separate chip would be needed for that. On the other hand, the dual-core clock speeds and 32MB of in-chip PSRAM means that the P4 sounds to be comparable to a Sony PSP in the compute department:

If I use a package with more pins, I could use the OctoSPI peripheral on the U5G9 to get more memory if needed. However, considering Palm PDAs shipped with 2MB and that the display buffer for Tetent/Tetinerary likely needs ~1MB, I think 3MB should be enough for now.

I also did some research into what others did when they were considering what MCU to use, and it usually boiled down to "use the highest powered chip in the series and then scale down", implying that projects rarely exceed the performance of sub-200MHz microcontrollers. One user made extensive work of the peripherals, resulting in the CPU predominantly doing nothing:

I did this by strapping together an ADC, comparator, a couple of DMA channels, bunch of timers and an intricate scheme of event/task connections of peripherals. CPU did absolutely nothing aside from starting monitoring and receiving a single interrupt after impulse was detected and recorded in RAM buffer.

Speaking of speed, I did find out about the Renesas RXv3 CPU core, which has obtains 5.8 CoreMark/MHz. The U5G is 4.1, the ESP32C6 is 2.9 and the ESP32P4 seems to do 3.0 if it's getting 2400 across both cores:

Unfortunately, even though the RXv3 core came out in 2018 and the chips it's in feature a double floating point unit (that I probably won't use), the (Rust) toolchain for it seems to be non-existent in 2024. This is another concern point for the P4 which, since it's not out yet, toolchain support would lag further behind.

Anyway, I only decided to do that research after looking into potential leads in the MPU side of things. From what I gather, the lines between MCUs and MPUs are starting to blur these days, with the only notable difference from my point of view being that they usually only come in BGA packages and support DDR memory controllers.

One of the first things I did was look into SoM's like the i.MX 8 but the lowest was still over 1000mW:

I looked into what processors are used for smartwatches and Cortex-M33 makes an appearance here, just like in the U5G:

One of the MPUs on Digikey was the STM32MP1. I can't really understand this table, but the note at the bottom does seem to reflect the sentiment (from Reddit research) that one would usually be fighting against Linux when it comes to low power consumption.

It was at this time that I decided to look into DDR costs. IIRC, the MP1 accepts up to 1GB, otherwise known in the RAM industry as 8Gbits. I looked at the options and the 2 that made financial sense was a 64MB and 512MB chip:

Considering that the PSP used 32MB and the ZGPAX S8 smartwatch I used to own ran the entirety of Android 4.4 just fine on 512MB, I think the cheaper option would be best unless something like an embedded CAD software needs more than 64MB.

Anyway, the actual price and package of the MP1 means that it's not really an option; it costs £15 alone so would be £16.50 with 64MB of RAM and it has 448 balls in it's package. Instead, what makes more sense would be the SAMA5D22, an £7.60 chip that supports up to 512MB of RAM and 196 balls that are spaced 0.75mm apart:

When it comes to BGAs, what I really have an issue with is the fanout, not really soldering the thing. If anything, it's easier because I theoretically could just line the package onto the pad and heat up. 

The SAMA5D2 Series uses sub 150mW peak and has support for 3D graphics with the NEON Media Processing Engine. Still, I don't think it's worth the effort over using the U5G7, which seems to have everything I need in a single package at the moment.

[June 8] 

There's also a new Apollo510 "System on Chip" that sounds like it's on its way. From my perspective, it looks and acts like your typical BGA (0.35mm) MCU, but its older Apollo 4 chip is also in the "SoC" section of Digikey.

Notably, it's also got a 2.5D GPU with vector acceleration and 3MB of SRAM, as well as a MIPI DSI that can transfer data faster, but has a max resolution smaller, than the U5G9 for some reason.

It has bluetooth connectivity, so hopefully this SoC gets put into a BT module similar to the ESP32 or nRF52 modules.