I was recently invited to be the keynote speaker at a “Technology Day” event in Milwaukee, WI.  (If you have never attended one of these events, you should seriously consider it, as they provide an excellent venue for valuable interactive technology discussions between us and our customers.)    Seizing upon the opportunity, I chose to speak about a topic that is near and dear to my heart, and perhaps the greatest threat facing the microcontroller industry today.  I titled my speech “Will microcontrollers go the way of DRAMs?”  For those of us old enough to remember the DRAM saga, it was a fairy-tale story of a high-tech product with handsome margins and excellent growth potential.  But it didn’t end happily-ever-after, as DRAM margins began to erode, and the whole industry sank into the commodity space.  One by one, manufacturers dropped out when they realized they couldn’t use innovation as a competitive weapon, and the whole situation degenerated into all-out fab wars.  The problem was exacerbated when some unscrupulous DRAM manufacturers who were determined to own this market began dumping product below cost, thus hastening the inevitable end.

Could the microcontroller industry be headed toward a similar cataclysmic finale?  As George Santayana put it, “Those who cannot remember the past are condemned to repeat it.”  So, to understand where the microcontroller industry is going, we need to look at where it’s been.

The microcontroller had a quiet and humble nativity in the wee morning hours of July 4^th, 1971, when Gary Boone and his team at Texas Instruments got their first prototype of a “computer on a chip” to work.  Unfortunately, TI underestimated the full potential of this breakthrough, and for a couple of years, the TMS1000 was used exclusively in TI calculators.  The microcontroller world would be a quite different place today had TI not waited until 1974 to make this chip available to the general market.  By then, Intel had already established a dominant foothold in this fledgling market.

The first fifteen years of the microcontroller age saw relatively few suppliers jump into the fray.  If you wanted to join this exclusive country-club of MCU players, you had to pay the hefty entry fees, and not many could afford the dues.  Several barriers to entry included:

1.  Expensive silicon foundry and fabrication facilities.

2.  The priesthood of silicon mages who understood how to design MCU cores was small indeed, and those who could wield this magic were well compensated.

3.  Unlike other semiconductor products that were pretty much stand-alone, additional resources were required to support an MCU family with assemblers, monitors, debuggers, development systems, etc.

Put all of these pieces together, and an image begins to form of a product with a huge appetite for development dollars which could only be satiated by big companies with deep pockets and/or well-endowed investors.

Now fast-forward to present day.  The microcontroller market has matured into a global presence representing estimated annual revenue of $18B in 2015, split amongst 40 or so suppliers.  What happened to cause this explosive proliferation?  Let’s take a look at three main events which changed the microcontroller world forever...

1.  Owning a silicon fab was a very prized, but very expensive proposition.  Operating margins were directly linked to your ability to keep your fab running all the time at full capacity.  As a result, many MCU manufacturers who owned fabs started renting out spare fab capacity in order to maintain a predictable backlog of silicon starts.  Related to this effect, third-party fabs began to spring up all around the globe.  Even many of the “big guys” started outsourcing some of their fab requirements to lighten their asset costs.  Suddenly the first barrier was down, and smaller companies now had access to fabs to manufacture their own MCU products.

2.  As the uC/uP market matured, the mystique of core design began to dissipate.  Mature players in this market were looking to recoup early R&D costs by licensing older core technologies (like the 8051) to the general market.  But perhaps the most devastating body-blow to the elitism of proprietary cores was delivered by a British company named Acorn Computers.  In the late 80s they developed a core which they called the “Acorn RISC Machine”, and began licensing it to other companies, including Apple and DEC.  In 1990, Acorn Computers spun-off the core design team into a new business called “Acorn RISC Machines, Ltd”, or simply “ARM” for short.  Now, a non-proprietary core with an upwardly mobile migration path was generally available for a relatively small licensing fee.  This concept caught on like wildfire, and by 2005, 98% of all mobile phones contained at least one ARM processor.  The second barrier came down with a resounding “thud” that could be heard around the world.

3.  Even with the first two barriers down, playing in the MCU space was still an expensive proposition due to the huge overhead burden required for support products and services.  But it was inevitable that as the MCU industry matured, third party support services began to pop up everywhere.  If you have ever been to Austin TX, you know exactly what I’m talking about.  Guys on street corners carried cardboard signs that read “Will test silicon for food”.  Neon signs glowed softly in the night…“Bubba’s Barbecue and peripheral design services”.  (OK, maybe I’m exaggerating a little, but you get my point.)  At the end of the 90’s, I recall a conversation I had with a division manager for the semiconductor company I worked for at the time.  To paraphrase, he said, “Just about everything we do here can be outsourced.  With my connections, I’m sure I could start my own MCU company if I wanted to, and just outsource everything.  And if I can do it, I’m sure there’s a whole bunch of other people around here who can do it too!”  As I left his office that afternoon, I finally realized that all the barriers were down, and the MCU industry was turning into the Wild West.

In the next part of this blog, I will discuss the strategies taken by some of the entrenched MCU suppliers to remain competitive in the face of almost certain commoditization.

With more and more MCU suppliers pouring onto the battlefield, the entrenched players found themselves under siege.  Would MCUs be forced to surrender to the same fate that DRAMs did years earlier in the commodity wars?  With so much at stake, MCU suppliers were determined to not let this happen to them, and to not take this onslaught lying down.  After all, they still represented the dreadnoughts of the industry with big guns and even bigger R&D budgets.  Smaller MCU companies instinctively knew not to engage this fleet head-on, or be obliterated.  But they were becoming more successful and more emboldened at outflanking the bigger MCU battleships in the niche corners of the market where agility was more important than sheer firepower.  As a result, several strategies were initiated by the established MCU players to keep them ahead of the pack:

1.  Powerful New Cores:  To prove that the concept of the proprietary core was not dead, and to combat the plethora of different cores that were flooding the market, established MCU players developed application specific cores designed to excel at certain types of calculations.  Perhaps the most notable example of this is the C2000 core from Texas Instruments.  With its Harvard architecture, single-cycle multiply-accumulate capability, and new vector math instructions, it is a perfect fit for real-time control applications such as digital power, motor control, closed-loop control, etc.  Once a core has proliferated to the extent that the C2000 has, it starts to take on a life of its own, and becomes very difficult to uproot as an incumbent choice for new designs.

2.  Continuous fab process innovation:  Unlike power semiconductor products where price is dictated by how many acres of silicon are required to support a given power level, MCU costs are heavily impacted by Moore’s law, which eats away at revenues every year like a cancer from the inside out.  Last year Intel demonstrated a laptop containing a processor built using 14 nm geometries.  The semiconductor industry is forecasting 10 nm geometries for 2016, 7 nm for 2018, and 5 nm by 2020!  As geometries shrink, so do the prices, which is undeniably a good thing for the consumer.  But does shrinking fab geometries translate into a sustainable competitive advantage for the manufacturer?  This question is particularly relevant when you consider that many third-party fabs offer geometry capabilities that rival the proprietary fabs.  It’s kind of like steroids.  As long as you are the only one taking them, you have a competitive advantage.  But when everyone is taking them, it levels the playing field again.  While remaining engaged in the fab war is important, it does not represent a sustainable competitive solution.  If DRAMs have taught us nothing else, it should be that shrinking the geometry only provides a temporary “fix” to keep you ahead of your competitors.

 3.  Innovative New Peripherals:  Older MCUs were considered innovative if they simply incorporated the uP core with some memory, and maybe some GPIO.  But today’s powerful MCUs incorporate everything but the kitchen sink!  Reaching out into the system to gobble up support silicon and auxiliary functions is a common strategy for MCU designers.  But in order for this strategy to work effectively, you must have broad shoulders to support a large family of MCUs, since the integrated peripherals you need are different for different applications.  As a result, this strategy works well for larger MCU companies who can afford to do this.

Not only are there more peripherals, but the peripherals are becoming more powerful.  In some cases, the peripherals themselves contain independent processor cores, like the Control Law Accelerator (CLA) from TI.  For much of my career I designed MCU peripherals for the motor control industry.  I was convinced that the best way to establish a distinct competitive advantage was to add unique features to these peripherals.  But I was quickly disillusioned when I realized how short this distinction lasted before someone else had the same or comparable feature.  And if you patented your improvement, all it did in many cases was broadcast your idea so that competitors could develop a work-around solution with the same or similar functionality.  Don’t’ get me wrong…peripheral innovation is crucial, and I am very proud to work for a company that prizes its leadership position in peripheral development.  But as I look at the motor control MCU market, I am compelled to admit that the peripherals from different manufacturers are all very similar in their basic functions with only subtle differences.  Therefore, I would again argue that in and of itself, fancy peripherals are insufficient to keep MCU suppliers ahead of the competition.

But there is one more super-weapon yet to be unveiled which has the potential to keep MCU manufacturers out of the gaping jaws of commoditization for years to come.  It has already been deployed by various MCU companies with varying levels of success.  Can you guess what it is?  I will discuss this in my next and final blog on this topic.

In this series we have been discussing the challenges facing the microcontroller industry over the last few decades, and some of the steps taken by MCU companies to remain competitive in a market that is becoming more and more crowded.  Recently a few MCU manufacturers (including TI) have turned to software as a secret weapon to win this war.

While software is certainly no stranger to the MCU industry, it has until recently been relegated to a support role for the MCU itself.  For example, even though MCU compilers are sold as a separate product, they are intended to support the main money-making product, the MCU.  Reference design software is often free, and again designed to support silicon sales.  This subjugation is understandable considering that the MCU industry was born out of the silicon industry.  At TI for example, 96% of our revenue comes from the sale of silicon based products.  If that much of your revenue is linked to silicon, it is easy to develop a mindset that your product must therefore be silicon.  I would argue that this is not true.  In fact, I would argue that most companies today don’t understand the true nature of their product.  For example, if I were to ask you “what is your product?” what would you say?  I suppose you might respond by telling me what you manufacture.  But your real product is not what you manufacture, but what you sell.

(Are you confused yet?)

Simply put, your customer is buying a lot more from you than what you manufacture.  They are buying your reputation, your support, and most importantly, the unique set of skills, creativity, and IP brought to bear which breathes life into what you manufacture, thus making it unique.  So if you accept that definition, should MCU companies consider their product to be “fancy sand”, or something far far more?  At the last semiconductor company I worked for, I made the statement that “any MCU company who still thinks their product is silicon will be out of business within a decade”.  Needless to say, I wasn't the popular kid on campus anymore.  Despite being harsh and perhaps mildly overstated, this statement makes my point exactly.  I still believe the industry as a whole needs to embrace a broader mindset that silicon is just part of their product; and in many cases, just the wrapper for their product.

Which brings me back to software.  I believe that the surviving MCU companies of the next decade will recognize and embrace the importance of software as part of their product portfolio.  I am glad that TI management understands this very well, and is aggressively instituting this concept with products like InstaSPIN-FOC^TM.  For those of you who are unfamiliar with InstaSPIN-FOC, it is a powerful sensorless field oriented control algorithm used in motor control applications which is instantiated in ROM on select C2000 based products.  It’s a win-win proposition that solves an industry problem for our customers at a fraction of the cost it would take them to develop a comparable solution.  PLUS it allows TI to field a value-added non-commodity solution to the market.  You can find more information about InstaSPIN-FOC here.  Of course, embracing software as a product instead of a support mechanism comes with a unique set of challenges that require MCU manufacturers to change how they do business.  Here are a few examples…

1.  You can’t please all the people all the time.  This statement is doubly true when it comes to software.  Most engineers agree that C should be the language of choice for embedded software, but that’s pretty much where the agreement ends.  For InstaSPIN-FOC, TI has made a conscious decision to embrace an object-oriented approach which is documented in a 487 page User’s Manual.  The code that interfaces with InstaSPIN-FOC is contained in MotorWare^TM, which is TI’s new suite of software modules which adhere to our object-oriented coding standard.  But despite our best attempts to make MotorWare as easy to use as possible, we still get complaints that our software is too complicated, or is too structured, or ________(fill in the blank).  We recognize the challenge that this presents, and are continuously updating our training strategies and documentation in an effort to make our software easier to use.

2.  Some customers don’t trust the “black-box” approach.  As one who has a hard time trusting software tools and plug-in libraries, I can identify with this concern.  This has come up from time to time with InstaSPIN-FOC, but the number of instances I personally know of where we couldn't resolve this problem can be counted on one hand.  In many cases we can diffuse this issue by pointing out that if they are using our API libraries or IQ math routines (which are in ROM), then they have already been using a black-box approach.

This also means that whatever portions of your algorithm you chose to put in ROM must absolutely be tested through and through, because bugs in ROM code just confirm the black-box fears.  So far we have been very pleased with how robust and error-free the InstaSPIN-FOC ROM code has been.

3.  Some customers feel threatened by this approach.  When I sat down after delivering this speech in Milwaukee, I was immediately approached by an engineer who worked for a drives company who expressed this exact sentiment.  These customers typically fall into one of two categories:

a.  Engineers who feel you are doing THEIR job.  These are mostly software engineers responsible for writing the product code itself.  This can be a real problem, especially if their concerns are legitimate.  The last thing you want to do is alienate the very customers you are trying to help!  With InstaSPIN-FOC, engineers need to realize that it is NOT a complete motor drive solution.  Each module is designed to make your job easier, not replaceable.  Also, the structure of these modules is designed to allow you to use just as much or as little of the functionality as you want.

b.  Companies who worry that you are entering THEIR market.   For the case of TI and InstaSPIN-FOC, this is very easy to address.  I can unequivocally state that TI has no intention to enter the motor drives business.  We don’t have the expertise to navigate the complexities of this market, and would just as soon leave that to you, our customers.  We are content to offer pieces of the motor drive solution, but let our customers put them together.

4.  Marketing Approach.  MCU suppliers will need to be more flexible and adaptive with their marketing strategies.  For example, we have seen that certain segments of the market (like appliances, automotive, medical, hobby, etc.) have embraced InstaSPIN-FOC much more enthusiastically than we could have ever imagined!  But conversely, there has been less interest than expected from other segments, such as Industrial Drives.  This actually makes sense when you think about it.  The motor drives industry has already invested years of R&D to develop their own proprietary sensorless observers that are perhaps as good as (or maybe even better than) InstaSPIN-FOC in some cases.  So we have had to adapt our marketing tactics to serve our customers when and where it makes the most sense.

5.  Applications Support.  Finally, we have had to shift our applications support model from one that was almost exclusively silicon oriented, to one which also includes end application and software expertise.  This doesn't mean that we are reducing our hardware support capabilities, but it does mean that more software resources are being added.

__________________________

In conclusion, will MCUs go the way of DRAMS?  How do we as an industry keep from being sucked into the commodity black hole?

Should we continue to improve our fab processes?  Of course!

Should we integrate more peripherals?  Absolutely!

Should we continue to make our peripherals more powerful?  Again, the answer is yes.  But I am concerned that these actions alone do not represent a sustainable competitive strategy.  Unless we as an industry take bold steps to change how we perceive our products, I fear that we are in constant danger of becoming commoditized.

TI has shown the way for MCU manufacturers to remain relevant in this highly competitive market by providing high value-added solutions to our customers in the form of applications software running on powerful, control-oriented cores.

Most people don’t realize just how vast the field of motor control is. In fact, when you think about it, motor control is the biggest sandbox in engineering! It encompasses field theory, analog design, digital design, control theory, filter design, digital signal processing, power electronics, sensor design, EMI, heat transfer, mechanical dynamics, and embedded software engineering, all rolled up into one package.

Because motors are such a widespread application, questions about this complex technology are bound to come up! With this in mind, we would like to invite you to our Twitter chat covering all-things motors on Thursday, July 31, from 11:00 a.m. – 12:00 p.m. CT.

The Twitter chat will be an opportunity for you to ask any burning questions you may have about motors. My colleague, Mike Firth, and myself will do our very best to answer your questions and direct you to the best resources in the motor field. We’re also looking forward to getting some insight from you about what may be your biggest concerns or your opinion on how the technology is changing.

Join in the conversation by using the hashtag #TImotorHr and watch the @TXInstruments’ handle for questions and answers from Mike and me. I’ve also heard rumor that an exciting surprise will be announced at the end of the chat, so stay tuned!

Some of you may be asking, “Who will I be talking to on the other end of the Twitter connection?” Great question! One I would ask myself. To learn a little more about me and my colleague, Mike, keep reading:

Mike Firth

Mike Firth is the marketing manager for the Motor Driver Business Unit at Texas Instruments Incorporated. He is responsible for overseeing the marketing efforts of TI’s DRV8x and DRV10x motor drivers and DRV5x Hall sensors. With 20 years’ experience working in the IC industry, his professional experience includes a variety of positions in business development and product marketing.  Mike holds a BS in Engineering Physics from the University of Oklahoma. 

Dave Wilson

Dave Wilson is a senior engineer in the C2000 MCU group focusing on motor control applications. In his current assignment, Dave focuses on algorithm development and motor control systems simulation.  He has 35 years of experience working on projects ranging from nuclear pulse processing to artificial intelligence pattern recognition. He has designed motor control systems as simple as trigger controls for power tools, and as complex as a six-axis DSP servo stage controller for a scanning electron microscope. He is the author of several articles, patents, and conference papers related to motor control. Dave holds a BSEE from John Brown University and an MSEE from the University of Wisconsin.  His passions include hiking, camping, photography, guitar, target shooting, and, of course, rotating metal.

Looking forward to chatting with you during #TImotorHr!

HI,

We ran the induction motor in a closed loop. We can’t control RPM below 60 RPM.electrical angle going haywire in below 60 RPM.i adjust gains also. Is there any other method for controlling induction motor in Low RPM. is there Voltage feedback(U-V-W) required for smooth control on low RPM. Awaiting our valuable suggestion.

Thanks,

BIPIN PATIL. 

Hi.

I am wondering if there are any recommended hardware isolation to connect the

TMDSCNCD28377D & 4 - DRV8303 to drive 4 motors?.

I looked at the evaluation boards schematics but I did not find a clear answer.

I am considering Isolating the

1) digital PWMs

2) analog current sense

3) and power current circuits

Which to use galvanic isolation?

Which to share GND ?

any other consideration you could help me with...

Is it engulf to keep good pcb separation for all 3 types of voltages?

Thank you,

David.

P.S. I asked similar question without getting replies from TI's experienced experts.

So I would be very thankful if you could refer this question to them.

This presentation provides an introduction to InstaSPIN-FOC including PowerWarp, Auto-ID, and the FAST observer.  It also briefly discusses the MotorWare structure.

This presentation contains the Lab Exercises used in Dave Wilson's motor control seminar.

This presentation discusses feedback, feedforward, stability, PI controllers, PI tuning, and cascaded structures.

This presentation discusses the Field Oriented Control Process, and how it can be applied to PMSM, ACIM, and IPM motors.

This presentation discusses how to do Field Oriented Control without needing a speed or position sensor on the motor shaft.

This presentation provides an introduction to InstaSPIN-FOC including PowerWarp, Auto-ID, and the FAST observer.  It also briefly discusses the MotorWare structure.

This presentation contains the Lab Exercises used in Dave Wilson's motor control seminar.

Dave Wilson, Motion Products Evangelist, Texas Instruments

One of the favorite parts of my job at TI is going out into the field, meeting with our customers, and conducting motor control seminars.  It gives me the opportunity to see what is important to you, and to share with you the exciting developments at TI in this growing field.  The title for my 2014 seminar series is “Teaching Old Motors New Tricks”.  While motor topologies have remained relatively unchanged over the past century, control techniques by comparison have experienced explosive growth.  This has been driven in large part by technology advancements in the semiconductor industry.  This year, my seminar focuses specifically on advancements in the control of motors, with an emphasis on field-oriented principles with brushless AC motors.

Recently I delivered this seminar as part of a 3-day training event in Dallas focusing on industrial control, with co-presenters Richard Poley and Ken Schachter.  The difference between this seminar and the countless others we have done together over the past 3 years is that Richard got the bright idea of video recording these presentations.

Have you ever watched a video of yourself doing something, especially presenting?  Try it some time.  It was gut wrenching!  All of the mannerisms that I hate, I realize that I do them.  To make it worse, I discovered that the bald spot on the back of my head is much bigger than I thought.  Plus, I’ve now decided that I need to lose some weight.  But if you can get past the presenter, I think the presentation itself could be very helpful if you are struggling to understand field oriented control, sensorless field oriented control, and specifically, “what is InstaSPIN-FOC?”  While a video recording doesn’t allow me to interact personally with our customers, it does allow me to reach many more of our customers.  You can find the entire one-day presentation split into 5 parts on our website.  I still plan to do seminars in person whenever I can get a group of about 20 or more willing to spend a day with me.  But in the meantime, consider these videos as a low-cost alternative to the live version.

So call your significant other, grab a drink and some popcorn, and enjoy the movie!  But please…be gentle.  :-)

Keep those motors spinning,

www.ti.com/motorblog

UPDATE  02-25-2014:  I forgot to mention that you can download the slides for these videos at my motor control resource page.  You can get the PPT versions here, and the PDF versions here.  -  DLW

I was recently invited to be the keynote speaker at a “Technology Day” event in Milwaukee, WI.  (If you have never attended one of these events, you should seriously consider it, as they provide an excellent venue for valuable interactive technology discussions between us and our customers.)    Seizing upon the opportunity, I chose to speak about a topic that is near and dear to my heart, and perhaps the greatest threat facing the microcontroller industry today.  I titled my speech “Will microcontrollers go the way of DRAMs?”  For those of us old enough to remember the DRAM saga, it was a fairy-tale story of a high-tech product with handsome margins and excellent growth potential.  But it didn’t end happily-ever-after, as DRAM margins began to erode, and the whole industry sank into the commodity space.  One by one, manufacturers dropped out when they realized they couldn’t use innovation as a competitive weapon, and the whole situation degenerated into all-out fab wars.  The problem was exacerbated when some unscrupulous DRAM manufacturers who were determined to own this market began dumping product below cost, thus hastening the inevitable end.

Could the microcontroller industry be headed toward a similar cataclysmic finale?  As George Santayana put it, “Those who cannot remember the past are condemned to repeat it.”  So, to understand where the microcontroller industry is going, we need to look at where it’s been.

The microcontroller had a quiet and humble nativity in the wee morning hours of July 4^th, 1971, when Gary Boone and his team at Texas Instruments got their first prototype of a “computer on a chip” to work.  Unfortunately, TI underestimated the full potential of this breakthrough, and for a couple of years, the TMS1000 was used exclusively in TI calculators.  The microcontroller world would be a quite different place today had TI not waited until 1974 to make this chip available to the general market.  By then, Intel had already established a dominant foothold in this fledgling market.

The first fifteen years of the microcontroller age saw relatively few suppliers jump into the fray.  If you wanted to join this exclusive country-club of MCU players, you had to pay the hefty entry fees, and not many could afford the dues.  Several barriers to entry included:

1.  Expensive silicon foundry and fabrication facilities.

2.  The priesthood of silicon mages who understood how to design MCU cores was small indeed, and those who could wield this magic were well compensated.

3.  Unlike other semiconductor products that were pretty much stand-alone, additional resources were required to support an MCU family with assemblers, monitors, debuggers, development systems, etc.

Put all of these pieces together, and an image begins to form of a product with a huge appetite for development dollars which could only be satiated by big companies with deep pockets and/or well-endowed investors.

Now fast-forward to present day.  The microcontroller market has matured into a global presence representing estimated annual revenue of $18B in 2015, split amongst 40 or so suppliers.  What happened to cause this explosive proliferation?  Let’s take a look at three main events which changed the microcontroller world forever...

1.  Owning a silicon fab was a very prized, but very expensive proposition.  Operating margins were directly linked to your ability to keep your fab running all the time at full capacity.  As a result, many MCU manufacturers who owned fabs started renting out spare fab capacity in order to maintain a predictable backlog of silicon starts.  Related to this effect, third-party fabs began to spring up all around the globe.  Even many of the “big guys” started outsourcing some of their fab requirements to lighten their asset costs.  Suddenly the first barrier was down, and smaller companies now had access to fabs to manufacture their own MCU products.

2.  As the uC/uP market matured, the mystique of core design began to dissipate.  Mature players in this market were looking to recoup early R&D costs by licensing older core technologies (like the 8051) to the general market.  But perhaps the most devastating body-blow to the elitism of proprietary cores was delivered by a British company named Acorn Computers.  In the late 80s they developed a core which they called the “Acorn RISC Machine”, and began licensing it to other companies, including Apple and DEC.  In 1990, Acorn Computers spun-off the core design team into a new business called “Acorn RISC Machines, Ltd”, or simply “ARM” for short.  Now, a non-proprietary core with an upwardly mobile migration path was generally available for a relatively small licensing fee.  This concept caught on like wildfire, and by 2005, 98% of all mobile phones contained at least one ARM processor.  The second barrier came down with a resounding “thud” that could be heard around the world.

3.  Even with the first two barriers down, playing in the MCU space was still an expensive proposition due to the huge overhead burden required for support products and services.  But it was inevitable that as the MCU industry matured, third party support services began to pop up everywhere.  If you have ever been to Austin TX, you know exactly what I’m talking about.  Guys on street corners carried cardboard signs that read “Will test silicon for food”.  Neon signs glowed softly in the night…“Bubba’s Barbecue and peripheral design services”.  (OK, maybe I’m exaggerating a little, but you get my point.)  At the end of the 90’s, I recall a conversation I had with a division manager for the semiconductor company I worked for at the time.  To paraphrase, he said, “Just about everything we do here can be outsourced.  With my connections, I’m sure I could start my own MCU company if I wanted to, and just outsource everything.  And if I can do it, I’m sure there’s a whole bunch of other people around here who can do it too!”  As I left his office that afternoon, I finally realized that all the barriers were down, and the MCU industry was turning into the Wild West.

In the next part of this blog, I will discuss the strategies taken by some of the entrenched MCU suppliers to remain competitive in the face of almost certain commoditization.

With more and more MCU suppliers pouring onto the battlefield, the entrenched players found themselves under siege.  Would MCUs be forced to surrender to the same fate that DRAMs did years earlier in the commodity wars?  With so much at stake, MCU suppliers were determined to not let this happen to them, and to not take this onslaught lying down.  After all, they still represented the dreadnoughts of the industry with big guns and even bigger R&D budgets.  Smaller MCU companies instinctively knew not to engage this fleet head-on, or be obliterated.  But they were becoming more successful and more emboldened at outflanking the bigger MCU battleships in the niche corners of the market where agility was more important than sheer firepower.  As a result, several strategies were initiated by the established MCU players to keep them ahead of the pack:

1.  Powerful New Cores:  To prove that the concept of the proprietary core was not dead, and to combat the plethora of different cores that were flooding the market, established MCU players developed application specific cores designed to excel at certain types of calculations.  Perhaps the most notable example of this is the C2000 core from Texas Instruments.  With its Harvard architecture, single-cycle multiply-accumulate capability, and new vector math instructions, it is a perfect fit for real-time control applications such as digital power, motor control, closed-loop control, etc.  Once a core has proliferated to the extent that the C2000 has, it starts to take on a life of its own, and becomes very difficult to uproot as an incumbent choice for new designs.

2.  Continuous fab process innovation:  Unlike power semiconductor products where price is dictated by how many acres of silicon are required to support a given power level, MCU costs are heavily impacted by Moore’s law, which eats away at revenues every year like a cancer from the inside out.  Last year Intel demonstrated a laptop containing a processor built using 14 nm geometries.  The semiconductor industry is forecasting 10 nm geometries for 2016, 7 nm for 2018, and 5 nm by 2020!  As geometries shrink, so do the prices, which is undeniably a good thing for the consumer.  But does shrinking fab geometries translate into a sustainable competitive advantage for the manufacturer?  This question is particularly relevant when you consider that many third-party fabs offer geometry capabilities that rival the proprietary fabs.  It’s kind of like steroids.  As long as you are the only one taking them, you have a competitive advantage.  But when everyone is taking them, it levels the playing field again.  While remaining engaged in the fab war is important, it does not represent a sustainable competitive solution.  If DRAMs have taught us nothing else, it should be that shrinking the geometry only provides a temporary “fix” to keep you ahead of your competitors.

 3.  Innovative New Peripherals:  Older MCUs were considered innovative if they simply incorporated the uP core with some memory, and maybe some GPIO.  But today’s powerful MCUs incorporate everything but the kitchen sink!  Reaching out into the system to gobble up support silicon and auxiliary functions is a common strategy for MCU designers.  But in order for this strategy to work effectively, you must have broad shoulders to support a large family of MCUs, since the integrated peripherals you need are different for different applications.  As a result, this strategy works well for larger MCU companies who can afford to do this.

Not only are there more peripherals, but the peripherals are becoming more powerful.  In some cases, the peripherals themselves contain independent processor cores, like the Control Law Accelerator (CLA) from TI.  For much of my career I designed MCU peripherals for the motor control industry.  I was convinced that the best way to establish a distinct competitive advantage was to add unique features to these peripherals.  But I was quickly disillusioned when I realized how short this distinction lasted before someone else had the same or comparable feature.  And if you patented your improvement, all it did in many cases was broadcast your idea so that competitors could develop a work-around solution with the same or similar functionality.  Don’t’ get me wrong…peripheral innovation is crucial, and I am very proud to work for a company that prizes its leadership position in peripheral development.  But as I look at the motor control MCU market, I am compelled to admit that the peripherals from different manufacturers are all very similar in their basic functions with only subtle differences.  Therefore, I would again argue that in and of itself, fancy peripherals are insufficient to keep MCU suppliers ahead of the competition.

But there is one more super-weapon yet to be unveiled which has the potential to keep MCU manufacturers out of the gaping jaws of commoditization for years to come.  It has already been deployed by various MCU companies with varying levels of success.  Can you guess what it is?  I will discuss this in my next and final blog on this topic.

In this series we have been discussing the challenges facing the microcontroller industry over the last few decades, and some of the steps taken by MCU companies to remain competitive in a market that is becoming more and more crowded.  Recently a few MCU manufacturers (including TI) have turned to software as a secret weapon to win this war.

While software is certainly no stranger to the MCU industry, it has until recently been relegated to a support role for the MCU itself.  For example, even though MCU compilers are sold as a separate product, they are intended to support the main money-making product, the MCU.  Reference design software is often free, and again designed to support silicon sales.  This subjugation is understandable considering that the MCU industry was born out of the silicon industry.  At TI for example, 96% of our revenue comes from the sale of silicon based products.  If that much of your revenue is linked to silicon, it is easy to develop a mindset that your product must therefore be silicon.  I would argue that this is not true.  In fact, I would argue that most companies today don’t understand the true nature of their product.  For example, if I were to ask you “what is your product?” what would you say?  I suppose you might respond by telling me what you manufacture.  But your real product is not what you manufacture, but what you sell.

(Are you confused yet?)

Simply put, your customer is buying a lot more from you than what you manufacture.  They are buying your reputation, your support, and most importantly, the unique set of skills, creativity, and IP brought to bear which breathes life into what you manufacture, thus making it unique.  So if you accept that definition, should MCU companies consider their product to be “fancy sand”, or something far far more?  At the last semiconductor company I worked for, I made the statement that “any MCU company who still thinks their product is silicon will be out of business within a decade”.  Needless to say, I wasn't the popular kid on campus anymore.  Despite being harsh and perhaps mildly overstated, this statement makes my point exactly.  I still believe the industry as a whole needs to embrace a broader mindset that silicon is just part of their product; and in many cases, just the wrapper for their product.

Which brings me back to software.  I believe that the surviving MCU companies of the next decade will recognize and embrace the importance of software as part of their product portfolio.  I am glad that TI management understands this very well, and is aggressively instituting this concept with products like InstaSPIN-FOC^TM.  For those of you who are unfamiliar with InstaSPIN-FOC, it is a powerful sensorless field oriented control algorithm used in motor control applications which is instantiated in ROM on select C2000 based products.  It’s a win-win proposition that solves an industry problem for our customers at a fraction of the cost it would take them to develop a comparable solution.  PLUS it allows TI to field a value-added non-commodity solution to the market.  You can find more information about InstaSPIN-FOC here.  Of course, embracing software as a product instead of a support mechanism comes with a unique set of challenges that require MCU manufacturers to change how they do business.  Here are a few examples…

1.  You can’t please all the people all the time.  This statement is doubly true when it comes to software.  Most engineers agree that C should be the language of choice for embedded software, but that’s pretty much where the agreement ends.  For InstaSPIN-FOC, TI has made a conscious decision to embrace an object-oriented approach which is documented in a 487 page User’s Manual.  The code that interfaces with InstaSPIN-FOC is contained in MotorWare^TM, which is TI’s new suite of software modules which adhere to our object-oriented coding standard.  But despite our best attempts to make MotorWare as easy to use as possible, we still get complaints that our software is too complicated, or is too structured, or ________(fill in the blank).  We recognize the challenge that this presents, and are continuously updating our training strategies and documentation in an effort to make our software easier to use.

2.  Some customers don’t trust the “black-box” approach.  As one who has a hard time trusting software tools and plug-in libraries, I can identify with this concern.  This has come up from time to time with InstaSPIN-FOC, but the number of instances I personally know of where we couldn't resolve this problem can be counted on one hand.  In many cases we can diffuse this issue by pointing out that if they are using our API libraries or IQ math routines (which are in ROM), then they have already been using a black-box approach.

This also means that whatever portions of your algorithm you chose to put in ROM must absolutely be tested through and through, because bugs in ROM code just confirm the black-box fears.  So far we have been very pleased with how robust and error-free the InstaSPIN-FOC ROM code has been.

3.  Some customers feel threatened by this approach.  When I sat down after delivering this speech in Milwaukee, I was immediately approached by an engineer who worked for a drives company who expressed this exact sentiment.  These customers typically fall into one of two categories:

a.  Engineers who feel you are doing THEIR job.  These are mostly software engineers responsible for writing the product code itself.  This can be a real problem, especially if their concerns are legitimate.  The last thing you want to do is alienate the very customers you are trying to help!  With InstaSPIN-FOC, engineers need to realize that it is NOT a complete motor drive solution.  Each module is designed to make your job easier, not replaceable.  Also, the structure of these modules is designed to allow you to use just as much or as little of the functionality as you want.

b.  Companies who worry that you are entering THEIR market.   For the case of TI and InstaSPIN-FOC, this is very easy to address.  I can unequivocally state that TI has no intention to enter the motor drives business.  We don’t have the expertise to navigate the complexities of this market, and would just as soon leave that to you, our customers.  We are content to offer pieces of the motor drive solution, but let our customers put them together.

4.  Marketing Approach.  MCU suppliers will need to be more flexible and adaptive with their marketing strategies.  For example, we have seen that certain segments of the market (like appliances, automotive, medical, hobby, etc.) have embraced InstaSPIN-FOC much more enthusiastically than we could have ever imagined!  But conversely, there has been less interest than expected from other segments, such as Industrial Drives.  This actually makes sense when you think about it.  The motor drives industry has already invested years of R&D to develop their own proprietary sensorless observers that are perhaps as good as (or maybe even better than) InstaSPIN-FOC in some cases.  So we have had to adapt our marketing tactics to serve our customers when and where it makes the most sense.

5.  Applications Support.  Finally, we have had to shift our applications support model from one that was almost exclusively silicon oriented, to one which also includes end application and software expertise.  This doesn't mean that we are reducing our hardware support capabilities, but it does mean that more software resources are being added.

__________________________

In conclusion, will MCUs go the way of DRAMS?  How do we as an industry keep from being sucked into the commodity black hole?

Should we continue to improve our fab processes?  Of course!

Should we integrate more peripherals?  Absolutely!

Should we continue to make our peripherals more powerful?  Again, the answer is yes.  But I am concerned that these actions alone do not represent a sustainable competitive strategy.  Unless we as an industry take bold steps to change how we perceive our products, I fear that we are in constant danger of becoming commoditized.

TI has shown the way for MCU manufacturers to remain relevant in this highly competitive market by providing high value-added solutions to our customers in the form of applications software running on powerful, control-oriented cores.

Most people don’t realize just how vast the field of motor control is. In fact, when you think about it, motor control is the biggest sandbox in engineering! It encompasses field theory, analog design, digital design, control theory, filter design, digital signal processing, power electronics, sensor design, EMI, heat transfer, mechanical dynamics, and embedded software engineering, all rolled up into one package.

Because motors are such a widespread application, questions about this complex technology are bound to come up! With this in mind, we would like to invite you to our Twitter chat covering all-things motors on Thursday, July 31, from 11:00 a.m. – 12:00 p.m. CT.

The Twitter chat will be an opportunity for you to ask any burning questions you may have about motors. My colleague, Mike Firth, and myself will do our very best to answer your questions and direct you to the best resources in the motor field. We’re also looking forward to getting some insight from you about what may be your biggest concerns or your opinion on how the technology is changing.

Join in the conversation by using the hashtag #TImotorHr and watch the @TXInstruments’ handle for questions and answers from Mike and me. I’ve also heard rumor that an exciting surprise will be announced at the end of the chat, so stay tuned!

Some of you may be asking, “Who will I be talking to on the other end of the Twitter connection?” Great question! One I would ask myself. To learn a little more about me and my colleague, Mike, keep reading:

Mike Firth

Mike Firth is the marketing manager for the Motor Driver Business Unit at Texas Instruments Incorporated. He is responsible for overseeing the marketing efforts of TI’s DRV8x and DRV10x motor drivers and DRV5x Hall sensors. With 20 years’ experience working in the IC industry, his professional experience includes a variety of positions in business development and product marketing.  Mike holds a BS in Engineering Physics from the University of Oklahoma. 

Dave Wilson

Dave Wilson is a senior engineer in the C2000 MCU group focusing on motor control applications. In his current assignment, Dave focuses on algorithm development and motor control systems simulation.  He has 35 years of experience working on projects ranging from nuclear pulse processing to artificial intelligence pattern recognition. He has designed motor control systems as simple as trigger controls for power tools, and as complex as a six-axis DSP servo stage controller for a scanning electron microscope. He is the author of several articles, patents, and conference papers related to motor control. Dave holds a BSEE from John Brown University and an MSEE from the University of Wisconsin.  His passions include hiking, camping, photography, guitar, target shooting, and, of course, rotating metal.

Looking forward to chatting with you during #TImotorHr!

Hello! 

I am new to TI DSPs and find learning and programming pretty tedious and difficult. I'm trying to control 3 phase inverters (6 switches - for IM and PM machines) and also 2 phase switching legs with varying duty cycles and phase shifts (for power converters) using suitable PWM signals on the TMS320F28335 Delfino microcontroller with the Peripheral Explorer c2000 board.

Three basic functions that I want to implement are

1. Changing the frequency of the PWM output using an ADC input from a potentiometer on the board connected to pin A0 of the control card

2. Changing the phase shift of PWM 2A and 2B wrt PWM 1A and 1B and 3A and 3B wrt. 1A and 1B (etc.) to a suitable value

3. Applying a suitable dead time so as not to short any switching legs

I have configured matlab to do this since I still have major problems with coding. I've also tried SIMCODER (PowerSim), but in this program, the provision to change the switching frequency of the PWM as an input from the ADC is not available. Also, even without using the switching frequency variation, SIMCODER has problems in creating a sinusoidally modulated PWM signal.

I have 3 basic questions

1. Does anyone have any suggestions about software other than PSIM and MATLAB which can do this easily, without the need to code and also to be able to see the simulation of the whole system with the micro.. in the loop, so to speak. 

2. Can anyone share a basic project with code (in CCS V5 - that actually works!) to achieve these functions for the ePWM module, so that I can get an idea of things.. even one properly configured PWM pair will do, I can edit the code from there. It's a bigger problem to write from scratch without any prior experience. Right now I've tried to write code a few times, but I'm not comfortable with the coding environment and it takes a lot of time to get it right. I'm not sure I'll ever be able to do it on my own. I use CCS5 with XDS 100V2 and control suite and a blackhawk emulator, but I don't particularly understand all of it in a high degree of detail

3. Does anyone have any comments about the pros and cons about using MATLAB (embedded coder) and PSIM (simcoder) or any other software..

It would also be a great help if anyone could tell me if there is a "simulator" for the TMS320F28335.. a program which could show me what the board will do - at the pins and the LEDs etc. when a certain .out file is uploaded onto it.

Many thanks!

HI,

We ran the induction motor in a closed loop. We can’t control RPM below 60 RPM.electrical angle going haywire in below 60 RPM.i adjust gains also. Is there any other method for controlling induction motor in Low RPM. is there Voltage feedback(U-V-W) required for smooth control on low RPM. Awaiting our valuable suggestion.

Thanks,

BIPIN PATIL.