A connected device rarely fails because the main wireless chip had no name recognition. It fails because the small controller around it was chosen as if it were only a cheap pin bucket. The board needs a part that wakes cleanly, reads slow inputs, drives a display or relay, stores a calibration value, survives the programmer on the line, and stays buyable after the first build. That job often lands on a general MCU or a small serial EEPROM. It is not glamorous work, but it decides whether the product can be built, serviced and revised without turning each minor function into a board spin.

P3.21 collects the ordinary controller and memory parts that fill this space. Some are old 8 bit devices that still make sense when the firmware is tiny and the hardware is mature. Some are mainstream Arm MCUs used when the connected node needs more timers, DMA, ADC behavior or firmware headroom. Some are domestic 8051 parts chosen because the cost and local supply path matter. Some are low power controllers for products that spend more time sleeping than speaking. The EEPROMs at the end look smaller, yet they often keep the device identity, calibration, limits and field settings from being tangled inside program flash.

Low cost control is not the same thing as careless control

The first group is the kind of MCU engineers can underestimate because the architecture is familiar. ATMEGA169PA-AU as an AVR MCU with an LCD driver and ATMEGA88PA-AU as a general 8 bit AVR MCU sit in that world. They are not selected to run a modern connectivity stack. They are selected when the board needs deterministic local control, simple firmware, a known tool chain and enough peripherals to avoid adding extra glue logic. A metering sub-board, keypad panel, thermostat front end or small actuator controller can still be better served by a part whose behavior is boring than by a faster controller that drags in a larger firmware surface.

The hidden strength of these parts is not raw performance. It is boundary clarity. If the wireless module or gateway processor owns the network, the local MCU can own buttons, display scan, relay timing, sensor sampling, wake qualification and a small amount of fault handling. That split keeps the radio firmware from becoming responsible for every slow edge on the board. It also gives manufacturing a simpler path for fixtures and calibration, because the local controller can expose a stable test mode even when the network side is not ready.

PIC devices cover a similar space, with their own tooling habits and package families. PIC16F57-I as a low cost PIC MCU is the kind of part that belongs in a design only after the team has accepted its limits. PIC16F914-I as a PIC MCU with an LCD driver fits better when a segment display is part of the product language. PIC18F14K50-I/SS as a PIC MCU with USB changes the discussion because USB brings enumeration, field setup and service access into a small controller. PIC24F16KA102-I/SS as a 16 bit low power PIC MCU is closer to the low power control layer where sleep current, wake source handling and peripheral mix matter more than headline clock speed.

The mistake is to treat AVR and PIC as interchangeable low-cost labels. A production design cares about the debugger that the factory already owns, the programmer contacts that fit the fixture, the firmware team that can maintain the code, the package that the assembler can place without yield surprises, and the number of spare pins left after real I/O has been counted. Cheap control becomes expensive when it forces a support team to keep a one-off tool chain alive for one small feature. It becomes valuable when it isolates a stable function and stays out of the rest of the system.

STM32 parts are often chosen for the margin around the application, not only for the core

When the local controller stops being tiny, STM32 devices enter the list quickly. STM32G0B1CBT6 as a mainstream entry MCU can suit a node that needs a modern 32 bit baseline without jumping into a large processor. STM32G473CEU6 as an MCU rich in analog peripherals is a different choice. It belongs where the MCU is pulled toward sensing, timing, motor control, power control or mixed-signal work. STM32F405RGT6 as a high performance MCU and STM32F750V8T6 as a high clock MCU with cache sit higher again, where firmware, interfaces and buffering start to shape the board.

The usual catalog comparison starts with flash, RAM, package, clock and peripheral count. That is only the visible layer. The better question is where the product needs margin. If the device samples several sensors and pushes packets through a radio module, DMA and timer structure may matter more than a few extra megahertz. If the board drives a display or collects waveform fragments, memory layout and bus access start to matter. If it controls power stages or motors, ADC trigger timing, comparator behavior and PWM synchronization become part of the real selection. If it will receive field updates for years, flash size is not a line item. It is the space where future fixes will have to live.

There is also an organizational reason STM32 gets chosen. Many teams already have libraries, debug habits, bootloaders, test scripts and reference boards around that ecosystem. That familiarity is a design input. It can shorten bring-up and reduce mistakes, as long as the team does not use a large familiar part to cover up an unclear requirement. A connected product should not pay for a heavy MCU just because the first engineer had a board on the desk. It should pay for that MCU when the surrounding firmware, validation and service life are easier to defend with the extra headroom.

A practical review should write down what is expected to change after release. Extra ADC channels, a larger radio driver, another display page, a new factory command, a second boot path, or a calibration routine can each consume a different kind of margin. That list keeps the MCU decision honest. It also exposes when a smaller part is enough because the product has no credible growth path in that local controller. Margin is useful when it is tied to named future work. Untied margin is only a quiet way to pay for uncertainty.

Domestic 8051 parts can be a rational choice when the job is bounded

STC parts sit in another practical corner of the BOM. STC15W408AS-35I-TSSOP20 as an enhanced 8051 MCU, STC8G2K64S4-36I-LQFP48 as a value 8051 MCU, STC8G2K64S4-36I-QFN32 as the QFN package of the same die and STC8G1K17-38I-QFN20 as a small package 8051 MCU are not trying to win a benchmark race. They are chosen when the function is clear, the cost target is tight, local sourcing has value, and the firmware does not need the wider ecosystem of a large Arm family.

The package choice is not a footnote here. LQFP can make inspection, rework and early production friendlier. QFN can shrink the board and improve parasitics, but it asks more from assembly process control and inspection. A small 8051 used for LED scan, fan control, switch reading, relay timing or panel housekeeping may be a good fit. The same part becomes a poor fit if the team later expects it to absorb networking security, complex diagnostics or a long field-update road map. The boundary must be written before the cost saving becomes an excuse to overload the part.

A low power Arm MCU earns its place only if the whole board lets it sleep

R7FA2E1A93CFM as a Cortex M23 Renesas RA MCU points to a common battery-device trap. Selecting a low power MCU does not create a low power product by itself. The sleep current of the MCU may look attractive, but the real node also has pullups, sensors, level translators, regulators, memories, LEDs, protection leakage and a radio wake path. A low power host is useful only when the rest of the schematic respects the same sleep state. The firmware has to shut down peripherals in the right order, hold pins in states that do not back-power neighbors, and wake on signals that are clean enough to avoid false starts. Low power is a system state, not a line in the MCU table.

EEPROM keeps product identity out of the place where firmware accidents happen

Small serial memories finish this branch because they solve a different problem. M24M02-DRCS6TP/K as a 2 megabit I2C EEPROM, M24C16-RMN6TP as a 16 kilobit I2C EEPROM, M24M01-RDW6TP as a 1 megabit I2C EEPROM and AT24C04D-XHM-T as a 4 kilobit I2C EEPROM are not chosen for computation. They are chosen because a device often needs a small, durable place for information that should outlive firmware churn. Serial number, calibration constants, regional limits, customer configuration, last service state, production trim and option flags all become easier to manage when they are not buried in application code.

The size decision should follow the information model. A few flags and trims can live in a tiny device. Logs, multiple calibration profiles or field configuration history may justify a larger memory. The write pattern matters too. EEPROM is not a scratchpad for careless firmware loops. If the code writes the same bytes every few seconds, the memory choice is already being abused. A clean design separates factory-programmed identity, rare service updates and runtime counters. It also handles brownout during a write, because a half-written configuration can be worse than no configuration at all.

There is one more reason to use an external memory. It creates a handoff point between production, firmware and service. Manufacturing can program the board identity before final firmware is loaded. Service can replace a controller board without losing a calibration record if the memory strategy supports it. Firmware can migrate settings from one version to the next without treating every update as a full product reset. None of this requires a dramatic memory part. It requires a deliberate map, versioned records and write rules that the team follows.

That is why P3.21 belongs in the connected-device BOM. The general MCU does the local work that a radio or application processor should not have to own. The EEPROM stores the small truths a product has to remember after power, repair and firmware updates. AVR, PIC, STM32, STC, Renesas RA and I2C EEPROM parts cover different corners of that job. The right choice is the one whose limits match the job cleanly, whose tools fit the team, whose package fits production, and whose supply path can survive more than the first purchase order.