Choosing a Microcontroller for a New Hardware Product

Freeze the choice only when those constraints are written, and when each rejected part is recorded with the requirement it failed. A wireless module can move the antenna and a regulatory file. It does not delete this list. Every figure below is hypothetical teaching maths: not a distributor price, not a lead time, and not a BrahmWorks result.

List every neighbour: sensors and their buses, a display, a relay, a radio or a module, a clock, a tamper switch, a boot strap, a debug port. For each, write the voltage, the direction, and whether the line must hold its level while the core sleeps. Count pins after reset, clock, boot, debug and power have taken theirs. A row that says only "SPI" hides chip-selects and a busy line, and those pins are where small parts run out.

If the product frame is still a slogan, stop. Who uses it, in which environment, and which function is mandatory, is settled in the hardware product development process before a part number is serious. ## Power states and the memory map

A low sleep current loses to a hungrier part if that part returns to sleep sooner and the radio, not the core, sets the duty. Name which oscillators stay up, which RAM is retained, and which pins keep their level, in the mode you will actually enter. A front-page current for a mode you cannot enter is not the budget.

Write the supply window beside that mode. A source that sags when a load switches is a brown-out problem. Reset thresholds have to sit below the rail you can hold, including sag, not below the stiff bench supply a kit used. If the part needs a rail the cell cannot hold at end of life, the regulator and its quiescent current join the budget before the silicon price means anything.

Split flash before anyone says there is room: bootloader, application, a second image if the product updates in the field, configuration, a log, and the next feature you have already named. Split RAM the same way: stack, the largest buffer you will hold, and a heap only if you have decided to keep one. A part that fits a demo and not the update scheme forces a new footprint, unless a larger device in the same package is a real escape. Record the lifecycle state on the day you choose, and name a person to read it again before you freeze a tester or a tool.

The compiler, the debugger and the production programmer are part of the component. A toolchain one person can demo, and nobody else can release, costs more than the gap between two parts. Write who owns the build, whether a release rebuilds from a tagged source, and how a unit is programmed after the board is inside the enclosure. A header under a cell, behind a welded lid, or under a display glued before test, means the part and the mechanical design disagree. Fixture pads, or a port you already expose, are part of the choice.

A leaded package a prototype assembler can rework is a fair first article. A leadless package your production assembler cannot inspect moves cost into test and scrap, even when the silicon looks cheaper. The thermal pad and the rework rule are layout constraints. If you have not tried to route the larger package, route it before you reject it.

A second source is a part you can place on this board, with firmware you have already built, in a quantity you can buy. Another family that needs a new pinout is a redesign plan, which is useful and is not a second source. If you accept a single source, write the trigger: a last-time buy, a broker, or a board spin. "Widely available", with no distributor line and no date, is a hope.

This product is invented for the exercise. A wall controller, fed by an external low-voltage adapter, speaks on an RS-485 pair to a reader, drives one relay, keeps time across a short outage, reads a tamper switch, and is programmed on a fixture after the enclosure is closed. The base product has no radio. MCU-A and MCU-B are fictional labels, not catalogue numbers.

MCU-A has two hardware UARTs, a backup domain for the clock, a leaded package, a larger sibling in the same footprint, and a toolchain the team already releases with. MCU-B is cheaper on the teaching list, has one hardware UART, needs an external chip or software to keep time, is leadless, has no larger sibling, and depends on a toolchain one engineer knows. The relay driver and the transceiver sit outside both. The choice is which core makes those neighbours dull.

MCU-B saves 180 − 150 = INR 30 on parts once the clock chip is included. At the teaching quantity, 30 × 1,000 = INR 30,000 on that batch.

Set a layout respin beside that saving, as arithmetic only. Assume the bit-banged port misses its timing and the board must move to MCU-A. Teaching cash: bare boards INR 40,000, assembly INR 18,000, twelve engineer-days at a teaching INR 1,000 a day, so 12 × 1,000 = INR 12,000. Spin total: 40,000 + 18,000 + 12,000 = INR 70,000.

INR 30,000 is smaller than one invented spin of INR 70,000. The saving is collected only if the port and the clock work on this board, in this enclosure, before the layout is committed. Until then the INR 30,000 is a claim. The day rate and the cash figures are invented. They are not a quotation and not a schedule.

The flash map is separate teaching arithmetic, on a fictional 512 KiB device standing in for MCU-A, with field update in the frame:

• Bootloader: 48 KiB
• Application: 200 KiB
• Second image: 200 KiB
• Configuration: 8 KiB
• Spare: 512 − 48 − 200 − 200 − 8 = 56 KiB

A named next feature of a teaching 80 KiB does not fit in 56 KiB. The larger sibling is the escape, and only if it shares the footprint. Drop field update from the frame and the second 200 KiB becomes spare: that is a different product. Write which map you are buying.

Each line needs an owner and a date, or it is still open.

• Every interface has voltage, direction, and behaviour while the core sleeps.
• Pin count includes reset, clock, boot, debug and power.
• The supply window, including sag, sits above the brown-out threshold you will enable.
• The sleep mode is named tightly enough that its current can be checked.
• Flash and RAM are split, including update, log and the next named feature.
• A larger same-footprint device is identified, or its absence is accepted.
• Lifecycle state is recorded, with a person to read it again before tooling.
• Errata have been read against the peripherals this product uses.
• A named person can build a release, not only a demo.
• The unit can be programmed after the enclosure is assembled.
• The package can be inspected by the assembler you will use.
• A second source is buildable on this board, or the single-source trigger is written.
• Rejected parts are filed with the requirement they failed.

Use it to learn the toolchain and to expose sloppy requirements, then choose again. Translate every header and regulator into a line the product needs or does not. Familiarity never appears on the BOM, which is why it survives a weak review.

When the radio, the antenna and the evidence for the market you will sell into are the risk, and the module vendor's conditions match your enclosure and your region. You still judge memory, sleep, package and programming. A module skips a radio layout. It does not skip the list.

Enough for the map you wrote: boot, application, the update scheme you are shipping, configuration, log, and the next feature already named. A percentage borrowed from another product is not a rule. If you cannot name the next feature, say so, and prefer a same-footprint larger device over a round margin nobody can test.

The requirement that failed, the quantity assumed, the date, and the person. "Too expensive" without a quantity, or "not enough pins" without the pin list, will be reopened at the next slip. The note stops the team buying the same argument twice.

Bring the interface list, the memory map, the programming method inside the enclosure, and the parts you rejected. A review can say whether the choice is ready to lay out, or whether one hole still dominates the price difference.

Review the next stage with BrahmWorks