Dialog Semiconductor to acquire Atmel for $4.6B
dialog-semiconductor.com
dialog-semiconductor.com
Around that time, Atmel changed management and refocused the company (selling off their memory lines, other fringe products and their fabs) to be a primarily microcontroller company, but it was a bit too late and they found themselves behind. It's been a while since I worked with 8 bit micros, but the word is that their AVR series is not really innovative anymore.
Seems like Atmel is back on its feet though with great new Cortex-F7 processors (I think they have the industry speed record at 300mhz and some other benefits).
I haven't looked at the graphs, but $4.6bn is kind of a valuation low point considering their last 10 years or so. They probably understood that they're too small to survive by themselves, especially as how complicated microcontrollers are becoming. I don't think microcontrollers are such a fantastic business - talking to my friends at component distribution like Avnet and Arrow, they make a lot more money on some passive components (like power) than on micros, and for a long time some companies have been allegedly selling microcontrollers at a loss, just to get the designs.
I'm constantly reading about how the 8-bit market is still doing well, despite the emergence of ARM. Even though the AVR hasn't really innovated much, it has picked up a lot of peripherals and low power modes which has kept the AVRs from being strictly in the bargain basement MCU market. I don't think there has been much innovation in the 8-bit market, but the AVRs have a really good programming model, especially compared to the 8-bit PICs. I don't know if that's enough to give AVRs a shot at new designs, but they're one of the best 8-bit options today, IMHO.
Most of the designs I know, migrate away from 8 bits and into 32 bit. The Cortex M0 is great. While designing with 8 bit is somewhat of an upgrade dead-end, if you design a product with an ST Cortex-M0, you can pretty easily go up their Cortex family ladder while retaining a lot of compatibility on both the board and firmware levels (ST is particularly good at that, which is why its my default recommendation when designing a new product - I can explain why if anyone is interested). The denser 8 bit parts are really expensive anyway - I suspect its because manufacturers know its mostly "locked in" customers that need more flash or I/O for an existing design and need a more capable, near drop-in replacement.
I also vastly prefer AVRs to PICs, but AVRs were kinda where I started my embedded programming career so I guess I just reflect on them fondly.
As to why do I like ST:
1. They are very easy to design boards for. Each IO pin on the Cortex micros maps to up to 16 different internal functions. That gives amazing flexibility from the board design perspective.
2. They have fantastic long term migration paths. You can directly go from Cortex-M3 to Cortex-M4 to Cortex-M7, while, in many cases, retaining package compatibility.
3. They have very good design validation. Their errata sheets are quite shorter than what I remember working with other manufacturers.
4. They have a huge amount of useful IO, such as timers (I have one design using over 15 timer channels) and a quite flexible and powerful ADC architecture.
5. They probably have the widest selection of Cortex microcontrollers in the industry.
There are downsides, too; I generally find their peripherals less advanced than Atmel's (regular CAN instead of CAN-FD, USB inferior to Atmel's, I2C that's really sucky and prone to errors, slower clock and no dual precision FPU on the new F7 family). There was also some story with ST's 2MB flash parts, being not really usable - but I'm not sure what was that about.
Overall you can't go wrong with ST. The long term migration ability and board design flexibility are well worth the downsides.
Coming from an AVR, you're immediately going to get way more memory, much higher clock frequencies, ARM CMSIS libraries (fun if you have any math/DSP going on) and more industry standard tools.
Is that fixable via software? if not , is it worth the risk ?
I was really surprised by that when I first encountered it; I2C is something rudimentary.
Their eratta sheets are shorter but I've run into a number of problems that I've worked around with help from their engineers and a year later I still couodnt find any notes on them. I'm guessing they underreport edge case silicon bugs like almost all silicon manufacturers.
My last project used a STM32F437 with 100 mbit ethernet, just about saturating the connection at 80mbits while maxing out the processor to interleave the bits of all incoming data and bit banging every GPIO unused by peripherals to control 30k individually adressable LEDs at 45 fps which is just incredible for a $7-10 microcontroller. Then after a few weeks of field testing we identified half a dozen problems all resulting in nondeterministic failures of the DMA or MAC peripheral requiring a hard reset. I think the most problematic one, DMA1 or DMA2 stalling when they tick within 10-20 cycles of each other, is the only one that was added to the errata and still plagues the STM32F4x7 parts.
That said if you care about part swapability, developer productivity, and need a very powerful ARM that you're not pushing to the edge, the STM32 line of chips is a great choice.
I've not seen anything that can be called "consumer electronics" that contained Atmel made '51, while I've seen some such things with AVR's (probably most often with mega169). In various low-volume industrial stuff there are heaps of Atmel made '51s, but only reason for that is familiarity (and to lesser extent AVR-compatible ISP).
Another thing is that Atmel is prone to supply chain problems. In our case it meant that we had redesigned the same device three times, first design was based on mega8, which in late 2010 we found was completely unavailable in any non-prototype quantities, thus we found that our distributor had cheap inventory of AT89C2051 and went with that (with all the development pains that are inherent in non-ISP '51) and on last major revision we went with MSP430 (G2253 IIRC) and didn't have to change anything due to supply problems for 3 years.
In any case I believe that for many uses of Atmel microcontrollers the familiarity and avaiability (like mega8 being fifth of the price of PIC16F84 in unit quantities in ~2007) were the major selling points.
Then we found the STM32F lines and got chips that were dramatically, objectively superior to the AVR32 chips in literally every way, for about $3/piece.
I still feel like I must have missed something for there to have been such a gap, but the project went great.
So, I think there may have been more to it than marketing pitch about portability.
So why aren't companies rushing to build 40nm commodity mcu's like infineon did ? it should cost almost nothing to make an mcu that way.
As a microcontroller user, I care about two features: RAM and price.
Really. That's it. I'll eat the engineering to switch lines if I can hold my price but double my RAM.
I don't care about frequency--everything is fast enough. I care a bit about flash, but I'm almost never flash limited. If you don't have enough of the peripherals I need I won't buy, but everybody has a ton of peripherals since transistors are cheap. And everybody's tool chains suck equally so there is no advantage to be gathered there.
Not as much as you would think.
Battery life in the embedded space is mostly defined by how much you can stay off and what your leakages are rather than what your active current is--since you can quite often just stay asleep a little longer.
Most of these microcontrollers are in the same range for leakage and are at the point where you have to start considering other leakage sources on the board (capacitors for example).
It's Amdahl's Law in action: the big contributors have all been smacked down pretty much as far as they can (sure, you might get 10% here or there ... but it's going to be real work now) so now getting overall performance isn't so easy.
If someone really wanted to get my attention with their microcontroller, they should produce a combined BLE/WiFi chip where the WiFi can be run off of a coin cell battery like BLE (that would mean something like 2mW transmit power rather than 200mW).
High-bandwidth signals require more power to travel a given distance, low-bandwidth signals go farther on less power but transmit less information. Intuitively this is why you can go worldwide with CW (Morse code) on just a few watts of power, while a SSB signal on the same frequency doesn't go far at all. But I think you can mathematically support this by playing with the bandwidth+power terms of the Shannon-Hartley theorem.
If we want to transmit a given amount of data per time unit, there are two natural extremes. We can either transmit it at the average data rate necessary, or we can race-to-sleep by blasting it out as fast as possible. I'm not sure which is more efficient given that SNR is inside the log2 of the S-H theorem, it depends on the relationship between SNR and bandwidth as you spread a given quantity of RF power thinner and thinner. Based on the log2 I would think this is an inverse-square kind of thing, making it an equivalent tradeoff.
Showerthoughts: because of the Inverse Square Law, it's probably more efficient to make a mesh of multiple small hops than a single long shot. As the spacing of the mesh decreases to zero, you end up with a wire.
Also, check out the ESP8266 chip, it doesn't have a BTLE onboard but it does handle the "SOC with low-power wifi" thing.
I know all about it. Still won't run on a coin cell.
Nobody will build a 2mW WiFi chip until Apple forces somebody to build it. Then EVERYBODY will rush to build it. Then EVERYBODY-1 will go bankrupt when Apple doesn't use their chip.
It's the Zen of Hardware.
However, for most projects I see, people don't care much. A better efficiency in a car is good, but a few microwatts can't compete with double the RAM in this context.
Lots of electronics projects are not battery dependent, and engineers care more about reliability, development ease and speed and flexibility. I surely like the idea of not reimplementing a firmware ten years from now by just upgrading the micro controller, instead of dealing with a whole new set peripheral drivers.
As an embedded firmware developer for 18 years, I've seen every project has its own constraints, just like most engineering. Design constraints on microcontrollers include: power, clock speed, FPU, number of digital GPIO, number of analog GPIO, quality of IDE and debugger, price, package size, available operating systems, longevity of part, volatile and non-volatile memory, quality of compilers, peripherals and so on.
IME, Atmel had a great 8-bit series with good documentation and few bugs that scaled from 8-pins to 40 very well. With analog inputs and PWM output, they were well-equiped to do analog input->processing->output tasks. They really blew it when they moved to 32-bit as others have said. They weren't very fast, changed all the peripherals around and didn't improve on the clumsy fuse system. ARM M ("M"->embedded) Cores like stm32f4, Freescale Kinetix, etc. have all but obliterated Atmel.
Finally differentiation in the Cortex family includes ethernet (F27/F29), Front-side Memory Controller, FPU, low-power (STM32L0), extreme low power (MSP432), low-price (STM32F0) and so on.
No argument.
> Design constraints on microcontrollers include: power, clock speed, FPU, number of digital GPIO, number of analog GPIO, quality of IDE and debugger, price, package size, available operating systems, longevity of part, volatile and non-volatile memory, quality of compilers, peripherals and so on.
True. But most of the embedded work I have been dealing with over the last 5? years seems to be very different from prior. In the last 5 years, choice of microcontroller moved from contentious to almost an afterthought: 8-bit, 16-bit, 32-bit? Motorola/Atmel/Microchip/ST/Renesas? gcc vs proprietary? Sufficient frequency? GPIB/RS-232/USB? All gone.
I get asked about memory and footprint (BGA/CSP is starting to become popular ... bangs head on wall) and that's about it. Even cost just doesn't come up much anymore--I don't know if its that things are cheap enough or that everybody now actually knows what microcontrollers cost.
Pretty much things seem to be splitting into two bands: internal memory only (M0, M3/M4 class--generally an RTOS) and external memory (A-class+, runs Linux). And, given some of the higher end M-series, I suspect Linux is going to hit there shortly.
Lots of people want data about business processes and throwing some coin cell sized boards with BLE and sensors into a product as it goes from start to end customer can be enlightening ... sometimes too much so for some businesses :). The real trick is having the infrastructure and team to receive and analyze the data (which we do now that we've done it enough).
Industrial automation is in the mix. A lot of that has been moving from combinations of IEEE-488, RS-232, USB or other non-differential links to CAN and Ethernet. Customers are often amazed how many fewer problems they have when they use a connection that is actually electrically differential.
It's gotten to the point that when I hear "reliability issues" I look for USB and just wipe it out. Generally there will be a network of PC's connected via USB to "random industrial machine X" or, worse, PC->USB Adapter->RS-232/IEE-488/etc. (to be fair--the old systems with actual RS-232 ports or IEEE-488 cards generally worked fine as they had more than enough signal overhead and shielding to deal with industrial electrical spikes--it's the USB interface that disconnects and causes Windows to crap its pants).
A replace of a bunch of those with something with a CAN interface generally fixes industrial problems. I finally sat down and wrote my own CANOpen stack because I was using it so frequently.
Medical and bio is an occasional, but that hasn't been such a big mover for me lately. The people who cut checks and the people who actually know what their problems are are too far apart in the hierarchy right now. My big problem in bio is that I could do quite a bit using full-custom VLSI to go to ultra low power functionality, but nobody wants to pay for that. So, I'll continue to use off-the-shelf microcontrollers and FPGA's and use way too much power.
Most of my grief these days isn't electrical. It's mechanical. I used 3D printers and silcone molds a lot. Very messy and annoying to work with, but it saves us having to cut molds for injection molding.
I can 3D print a lot of parts for the cost of even a single injection mold. And my margins aren't so tight that I need the cost savings. And I can change the part if something is wrong. And I don't have to scream at the mold maker when (not if) he screws my mold up.
To be fair, this isn't really an issue unless your device grounds are likely to have more than a couple of volts difference due to spikes. And that happens very rarely in the home or office.
In industrial settings, however, that's not true.
Will nothing change? Will Atmel's (or is it Dialog's ?) micro-controllers will become even more power efficient?
Though if Dialog is power management IC company, maybe Atmel's microcontrollers or Atmel based boards will have better power management features and/or be more power efficient?
At the company I work for, we've replaced all the Atmega chips in our products with the STM32F0 series chips for lower-end requirements and with STM32F4 series for higher end stuff, because they have more grunt and generally have more peripherals, and are similar prices.
I have personally developed Bluetooth stack using the GCC tools for the MSP430 using the CC246x Bluetooth modules and it was a blast.
So you have a lot of options with free tool chains. I personally use only free toolchains on linux. It is the best development setup and you have a lot of options for debugging and tool development.