Given specific requirements one usually has a very wide choice of matching microcontrollers. Other than avoiding tags like "not for new designs" and such, is there anything one can do to ensure that the product one chooses is still available several years from now? Are there some manufacturers that are known to have longer lifecycles than others, or is that completely unpredictable in advance? Or is it just that I would have to order huge amounts of the part I plan to use for a long time?

  • \$\begingroup\$ How many years are you looking for? Some micro controllers give promise of longetivity, some will give same pin to pin replacement options. \$\endgroup\$ – User323693 Jun 17 '18 at 7:55
  • \$\begingroup\$ It is just a general question about how go about that topic because I noticed that on DigiKey I happen to find many interesting parts with "not for new designs". Can you give an example of an MCU where the manufacturer promises longevity, and where to find that promise written down? \$\endgroup\$ – oliver Jun 17 '18 at 8:02
  • 3
    \$\begingroup\$ st.com/content/st_com/en/support/resources/… i would also approach the vendors directly. If the product is designed for manufacturing, there will be honest suggestions too from the vendors, for a big scale businesses. If we are prodcuing it for very low scale volume, then best option is to have pin compatible MCUs already in mind. \$\endgroup\$ – User323693 Jun 17 '18 at 8:04
  • 2
    \$\begingroup\$ Microchip has a good reputation for not (often) dropping poducts. Some others (TI? Dallas?) had a reputation for offering products that were never even manufactured (or wit a MOQ in the millions). Hint might be to look at what is available from a manufacturer, and check how many obsolete-looking products are still available. \$\endgroup\$ – Wouter van Ooijen Jun 17 '18 at 8:15
  • 1
    \$\begingroup\$ 80C51 has a good history. \$\endgroup\$ – Jasen Jun 17 '18 at 9:22
  1. look at the spread of family of products. STM32 has about 800 or more MCU options to choose for 32 bit ARM platform. It helps you to have multiple MCUs with same footprint options as well as easy upgrading of ROM and RAM memory options within the same family of MCUs.
  2. How old are previous MCUs from the same vendor? how many other products are there which have guaranteed long term availability or available form very long time?
  3. How do they manage LTB (last time Buy notices, how many years or months they will give the guarantee of supply, in case it happens)
  4. From declaration of EOL (End of Life) and LTB, one will be also able to find alternate MCUs with same foot print (in order to keep zero change in hardware) and ideally almost same eco system for maintaining and compiling code. If one is capable of storing the products in recommended storage conditions, one has to act now.
  5. Look for obvious declarations.. a few examples below from ST, Renesas etc.
  6. Choosing the MCUs with flexibility in RAM and ROM (same package can offer from 256 KB to 1 MBytes of internal memory). When in case the product runs out of stock, there will be chances of getting MCUs with may be higher memory options from other second sources
  7. Depending on the business we have with MCU vendors, there will be early flags which can be learnt from the vendors. It is not like a quarterly report of companies which has to be kept very secret until declaration.
  8. Stating requirement directly to the vendors also helps in filtering out most obvious fault choices
  9. Keep the programs still modular and not specific to one MCUs. Migrating MCUs is still a pain unless drivers, applications, middle wares are well coded structurally.
  10. Ask Ask Ask. vendors, suppliers, second level suppliers, Field application Engineers and also team from plants directly
  11. prefer the vendors who have atleast two or three fabrication plants in different locations (think about war, earthquake or even just building collapse for some reason)
  12. History of sourcing ability, debug support, support for internal release and qualification of products, help and support channels should also be considered.
  13. Voluntarily subscribe to notification on product status change (business units will automatically get information from vendors, really in formal ways, but why not keep a voluntary check too? also about being in touch with FAEs (Field Application Engineer, or also sales representatives) once in a year to discuss about the products life term).
  14. Think in advance about your product line up for coming years down the line. Which feature may be needed ( Ex.: Security, hardware encryption etc) which may help in not dropping the chosen MCU because of product requirement reason and not because MCU is now obsolete.

Below are just examples where i could easily find about longevity promises (ofcourse with *) i also see this as an hint on vendors i would prefer. Why would one choose from the vendor who has no such programs unless there is a huge record of not making parts obsolete? isn't it?


Link here
enter image description here


Link here enter image description here

Si Labs

Link here
enter image description here

STM32 Microcontrollers

Link here enter image description here

Microchip (covers ATMEL also now) My answer will be incomplete without mentioning Microchip.

enter image description here

| improve this answer | |
  • \$\begingroup\$ One other thing that can be helpful with obsolescence generally is to try to pick automotive qualified parts, car companies hate component obsolescence so these usually have EOL notification well in advance of the event. \$\endgroup\$ – Dan Mills Jun 17 '18 at 13:04
  • \$\begingroup\$ @DanMills i agree. I have also seen most of the MCUs are not off the shelf but custom designed to reduce price and redundant features. \$\endgroup\$ – User323693 Jun 17 '18 at 13:49

Ask your supplier (Arrow, Avnet, Farnell etc.) - they know best and usually have some "insider" information regarding longevity.

For example NXP has a site where you can check longevity of some of their products. Microchip is also famous for not obsoleting anything (or at least providing drop-in replacements).

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.