the nametag uses CH592 as main MCU for the nametag. why? there's a few reasons for this choice:

• peripheral support needed for this project is minimal
• it's a small and inexpensive mcu
• ...which has lots of flash storage space, which I need
• it has BLE, which I might use in the future... who knows. it's also very low power in BLE receive mode, just 3.5mA
• crystal needs no caps as bias is configured internally
• may not need a matching network for some RF designs but I haven't read into how this works yet
• adc has native "TouchKey" support, which works pretty well and is ridiculously easy to use
• supports USB device OR host, has RTC

but still ... why CH592? after all this MCU has some cons as well:

• not many peripherals
• hardware I2C shares pins with debug, and has no remap
• CH59x comes with debug locked, so first thing I have to do is connect USB just to be able to use the debugger...
• timers are only sourced from system clock, which sucks
• execution from flash memory sucks. datasheet specifies "zero-wait at the system frequency of 20MHz" though any registers relating to setting wait states are undocumented. it sure feels slower even at 16MHz but I haven't tested it yet. flash and RAM both go through the main bus in this design so there's no special benefit to executing from flash instead of RAM as there is in other designs. rather there's a negative: significantly higher power consumption and significantly slower execution speed.
• on that note... the datasheet is very terse and is missing information. sometimes it blatantly says to check example code, or it even says it will not document certain functions...

ultimately, the main factors were as listed above, but the big one was flash storage. I knew I was going to reuse the nametag code, and I haven't had time to rewrite the code to use external storage for fonts. I'll get to this eventually but I don't have time to do it now, so large flash it is. CH592 is extremely cheap for having 448K standard flash. How far we've come...

actually, I wanted to use this part until I read through the datasheet. knowing this nametag would be I2C heavy - particularly with OLED updates - I wanted a working hardware I2C peripheral, ideally with DMA so the CPU could save power. CH592 has a hardware I2C peripheral but it's on the same pins as debug, which disqualified it. debug is important. power consumption during execution was really low however: executing from RAM at 48MHz consumes about 2.5mA. pretty nice. so if I had to do soft I2C, vs doing interrupt I2C, I guess there isn't much power difference, just code architecture differences (can't interrupt I2C comms in the middle of sending bits, some devices don't like that...)

so I looked at using a different MCU. CH582 has the same slow flash, but has more RAM for code. importantly the I2C pins are not shared with debug or anything else I'd use in the design. there's also more use publicly of CH582 as it's been around longer. it costs more than CH592 but not by much: ~$0.75 vs $0.45 in badge qty. still cheap. oh, and the radio can support long range modes if I want. this has been stripped out of CH592.

by the time I got around to working on the nametag hardware I completely forgot that I researched this and went with CH592 in the final design...

so this is where we're at now. I run the soft I2C master routines at 32MHz and for this MCU at least the power consumption isn't much different between 32MHZ and WFI. of course this MCU isn't doing much in it's low speed time so I could use ultra low power mode but ... I'd only be saving a little over a milliamp. I'd like to not consume this but it's an addon. most people hardly consider power consumption anyway, lol. do I really want to be like that too? I guess not really...

for general purpose work, it's ok.

peripheral library is weak. sample code kinda sucks.

hardware peripherals are limited in type and generally very simple, though some have some interesting features (such as modem signals on UART, or built-in buffer / opamp with gain on ADC input path).

missing atomic GPIO set register like on CH32V series. but it does have atomic clear register...

timers are tied to HCLK only. can't run from the crystal. this is a big limitation.

i2c is on the debug pins. this is a big limitation.

it's less than 50 cents each in badge quantities. not like that matters much but if you've gotta cost optimize...