MCU MICROCONTROLLER SOURCING
Turn an MCU requirement into a quote-ready sourcing request.
- Provide the exact MPN when the build requires an unchanged device.
- Record technical must-haves before an alternative is considered.
- Use application context to make the request easier to evaluate.
Exact part or family
State the manufacturer part number, device family or the information you already know.
Design-critical attributes
Call out memory, interfaces, package, temperature and any parameter that cannot change.
Approval boundary
Specify whether alternatives may be reviewed and who must approve a proposed change.
START WITH THE RIGHT SOURCING PATH
Three common MCU requests, each needing different information.
An MCU request becomes more actionable when it reflects the decision you are making—not just the product category. Select the route that best matches your project, then provide the relevant detail in your RFQ.
Exact MPN replacement
Use this when the approved design must retain a specific device. Include the full MPN, quantity, package and any date-code, packaging or documentation conditions that matter to your purchase process.
Supply-constrained MCU
Describe the reason for review and separate non-negotiable parameters from preferred ones. A suggested device should not be assumed to be pin-, firmware- or system-compatible without your engineering approval.
Early-stage design brief
When the final part is open, share the application, preferred architecture, I/O, memory range, connectivity and target package. This creates a practical starting point for a structured discussion.
MCU RFQ CHECKLIST
The details that help define the right microcontroller request.
A part number is powerful, but it is not always enough. Add the design and approval information that helps a buyer or engineer understand what must be protected when availability, packaging or a proposed change is discussed.
| RFQ detail | What to state | Why it matters |
|---|---|---|
|
Part identity Essential |
Full MPN, manufacturer, revision or device family; note if a partial marking is all that is available. | Distinguishes a precise component need from a category-level inquiry. |
| Core and memory | Architecture preference, Flash, SRAM, EEPROM or external-memory requirement where known. | Prevents a request from overlooking the resources the firmware and board design require. |
| Peripherals and interfaces |
ADC, PWM, timers, UART, SPI, I²C, CAN, USB, Ethernet or other required functions. | Captures the I/O and communication roles that affect practical device fit. |
| Package and conditions |
Package, pin count, voltage range, operating temperature and handling or packaging requirements. | Links the device request to assembly, environment and purchasing constraints. |
|
Alternative boundary Approval |
Whether alternatives are permitted, what can change and who reviews a proposed substitute. | Keeps an alternate from being treated as an automatic drop-in replacement. |
MCU FAMILY REFERENCE
Use the MCU class to frame the technical conversation.
The categories below help organize an inquiry before a final MPN is confirmed. They are not availability statements or a substitute for reviewing the relevant datasheet, design and approval criteria.
Manufacturer names and series are buyer-reference examples only. They do not indicate authorization, affiliation, stock or a sourcing commitment.
The prototype part is no longer the only option
The BOM has more than one owner
Build quantities expose planning gaps
A late change becomes more expensive to explain
FROM DESIGN INPUT TO A CLEARER MCU INQUIRY
No complete part number? Build an MCU brief in four practical steps.
A concise brief does not replace engineering validation. It gives your team a better record of what the selected device must support before a sourcing or alternative discussion starts.
Use this page to prepare the request. Final component selection, firmware migration, compliance review and system validation remain decisions for your qualified engineering and quality teams.
APPLICATION CONTEXT MATTERS
The same MCU family can mean different constraints in different products.
Instead of relying on a generic “MCU needed” description, tell the sourcing team where the device sits in the product. It gives the inquiry a clearer technical context and makes approval questions visible early.
Smart-home controls
Consumer electronics
Wearables & portable devices
Motor & appliance control
WHEN THE FIRST-CHOICE MCU IS CONSTRAINED
Treat an MCU alternative as an engineering decision, not a quick substitution.
A similar core, Flash size or package may be relevant, but it does not establish a drop-in replacement. Put the approval process around the proposed change before it reaches the build.
- Document what must remain unchanged.
- Request differences to be made visible for review.
- Route technical, quality and purchasing approval to the right owner.
Build alternative boundaries into the first RFQ.
Use the Quality Assurance page to frame the evidence, change-control and approval requirements that support an order-specific decision.
- Specify whether the part must be exact, functionally reviewed or open to alternatives.
- List the design, compliance, test or document requirements your internal process needs.
- Keep a decision point before a material change moves toward shipment.
RELATED PRODUCT LINES
Connect the MCU request to the components around it.
A complete control-board or connected-product request may include more than the microcontroller. Explore related categories, then bring the combined BOM or part list to the RFQ.
Wireless & connectivity ICs
Power management ICs Regulation, charging, conversion and power-control design needs
Power management ICs
Regulation, charging, conversion and power-control design needs
Driver ICs
Display, motion and power-control components that commonly share board context
Manufacturer and category references
Use the Line Card to organize a manufacturer, family or partial-MPN inquiry
MCU SOURCING FAQ
Useful answers before you request an MCU quote.
These answers help turn common sourcing questions into details that can be recorded in the RFQ. They do not replace datasheet review or engineering validation.
What should I include if I have the exact MCU part number?
Provide the full manufacturer part number, quantity, package and destination. Add the conditions that matter to your project, such as approved alternatives, date-code expectations, packaging, documentation or a required delivery window.
Can an MCU alternative be treated as a pin-compatible replacement?
Not automatically. Pin count, core type or memory size alone do not prove equivalent electrical behavior, peripheral operation, firmware compatibility or system performance. Any proposed alternative should follow your own engineering and approval process.
What if I know the application but not the MCU model?
Describe the product role, required interfaces, memory range, package, voltage, operating environment and any non-negotiable design features. This creates a clearer technical brief than a category name alone.
Does a series or manufacturer reference confirm stock or authorization?
No. A reference helps identify a component family or inquiry direction. Availability, source conditions, pricing, lead time and any distribution status are order-specific matters that must be confirmed separately.