Why the switch from Atmel to NXP?

Status
Not open for further replies.

jrsmiley

Member
Sorry if this has been asked and answered before. I did several searches of the forums and didn't find anything related to this.

Paul, do you mind sharing your thinking about why you switched from Atmel to NXP? I've got dev boards from ST, Atmel, and NXP for learning purposes and I'm still coming up to speed on all of the differences, but nothing jumps out at me as an obvious reason for the switch. It meant more work for you since you had to write an entirely new Arduino core, which would have been a bit less arduous if you'd stuck with Atmel when making the switch from AVR to ARM. Just curious really.
 
Granted Atmel's Cortex M4 family tops out at 120MHz, but ST's go to 180MHz same as NXP. I'm betting there's more to it.
 
I didn't switch to NXP. I switched to Freescale. They were later acquired by NXP, and now NXP is in the process of being acquired by Qualcomm.

This decision was made in late 2011. Much has changed since then. At the time, NXP and Luminary Micro (since then acquired by Texas Instruments) were the main 32 bit microcontroller alternatives. Atmel had several ARM chips, but the powerful ones were flash-less parts using external buses, and older ARM7TDMI. I don't recall exactly what ST had back then, but it certainly wasn't the Cortex-M parts they now offer. The choice at the time was really between NXP, Freescale and Luminary Micro.

Cost was a huge factor. At the time, even the lower spec parts were priced similarly or higher than the K66 chip we're now using on Teensy 3.6. Nearly all the attractive ARM chips were quite expensive. Perhaps Freescale felt their HC08 parts were fading from the market? They had already released the first crop of 100 MHz Kinetis chips in that price range, and were planning to broaden the Kinetis line to lower end chips.

DMA and M4's DSP extensions were also a huge draw. Back then, pretty much none of the microcontrollers had DMA. Freescale and NXP were first with M4, but NXP only offered it on their very high end. Freescale made a decision to use M4 for all Kinetis (remember, this was 2011... Cortex M0+ didn't even exist then). Nobody else was even talking about offering DMA on their less expensive ARM microcontrollers. It was one of those "product differentiation" features.

But Freescale made a different decision, based on the idea that offering a similar peripheral feature set across a very wide range would in the long term allow software to be ported. Unlike all the others who offered quite different peripherals on the low end vs high end, at least on the M4's offered and planned in 2011 & 2012, they kept it very uniform. Freescale decided to distinguish their chips mostly by clock speed (even though they're all the same process capable of the same clock rates) and memory size. The availability of a lower cost part (which let Teensy achieve similar prices to most 8 bit boards of that day) with powerful DMA was the main draw.

I had dreamed of making the audio library for a very long time, and so many other things leveraging more powerful peripherals with DMA. Freescale's M4 chips with were the very first opportunity. It's easy to look at today's market and not realize that lower cost Cortex-M4 parts, like the ones Onehorse is using, are quite new. Much has changed over the last several years. In the not too distant future, it may even seem perplexing why I chose a Qualcomm part....
 
It's probably also worth noting none of Atmel's 32 bit chips share peripherals in common with 8 bit AVR. Even their newer XMega AVR chips don't. Using an Atmel part would have required writing a whole new core library.

Of course, Arduino has stayed with Atmel. They've written not 1 but 2 completely new & distinct core libraries, because those newer chips aren't at all compatible with AVR, nor even with each other!
 
Thanks for the quick reply, Paul. I was one of OneHorse's Kickstarter backers for the STM32L4-based LadyBug and Butterfly. From a quick read of the code for Arduino AVR and SAMD cores as well as your Teensy3 core, I get the sense that writing a core from scratch for the STM32L4 for OneHorse's boards is something not to be taken on lightly. I'm still amazed at how little commonality there is between different vendor's versions of the same Coretex Mx family. What good is a common instruction set if the code isn't portable between vendors and everyone uses a different set of peripherals? I don't see CMSIS and mbed being much help beyond the beginner stage as they only expose the least common denominator, are inefficient, and buggy. I notice you wrote your core at the register level, which is where I'm leaning now which means I need to pick a vendor, family, and chip and stick with it. It's all for fun, so no skin lost if I make a bad choice, but just getting to the point where I know enough to make a choice has been a challenge.
 
Interestingly, Arudino is coming out with an STM32F4-based board called the STAR Otto, so we'll be seeing an STM32F4 core from them soon. I had seen the Otto on the .org page, but you can't buy it and with the .cc / .org remix, I thought they were shelving that idea. However, Federico was talking about it at CES just last week, so I guess they're going ahead with it.

Good to see them finally embrace the M4 even if the Otto is targeted at 3D printing.

And then there's the Primo - another M4 board, this time from Nordic, - which he says will replace the Uno. The Primo also comes in a "core" version, which is kind of cool. Again, you can't actually buy any of this stuff, so it's hard to tell what they'll end up doing. They introduced the MKR1000, started a "series" of videos on YouTube about five months ago consisting of a single video staring Federico and then it seems to have fizzled, to be replaced by the MKRZero, which isn't a "board" but a "module". Go figure.

Is there an M7 Teensy in our near future?
 
Last edited:
Then I think you're wish is granted with the Primo. According to Federico just last week, the Primo will eventually replace the Uno.
Well, I'm sure everybody that releases a new board, hopes it will replace the Uno. But I suspect market fragmentation means there will be no clear cut winner.
 
According to Federico just last week, the Primo will eventually replace the Uno.

Musto and Arduino.org are going to have to do a much, much better job on software & library support and community building if they want to have any chance of displacing Uno.
 
Last edited:
Yes, I should have been clearer... something that actually is usable. Arduino does not have a stellar history in this regard, especially when it ventures out of the 8-bit AVR world. I can't leave the teensy world cause stuff actually works, which is HUGE.
But I really want integrated BLE with low-power abilities, with libraries that work. I know that's a lot to ask, but it would be awesome.
 
... I don't see CMSIS and mbed being much help beyond the beginner stage ... .

I'm going to take back this part of my prior post. I've spent the past week trying to learn enough about CMSIS and mbed to make an informed decision about whether I want to spend my time learning a particular chip architecture and program at the register level or work at a higher level of abstraction. I'm doing this for the fun and I love both electronics and software, so both have their attractions. The more I dig, the murkier it gets. Everyone (ARM, ST, NXP, Microchip/Atmel, TI and every other chip maker plus loads of third parties) has their own development ecosystem they want to peddle. However, one thing I can say for certain is that CMSIS is not for beginners and mbed has more depth than I thought at first.
 
Musto and Arduino.org are going to have to do a much, much better job on software & library support and community building if they want to have any chance of displacing Uno.

They seem to be flailing around a lot. They start down one path and toot their horns and then they might abandon that path and head down multiple others. For example, the MKR1000 seems all but abandoned and now they're going on (and on) about STAR Otto and Primo. Both of which are pretty interesting, but they announced these products back in May 2016 and they're still not here. I took a peek at their github dev branch for the STM32F4 (Otto) and they haven't made an update in six months! (https://github.com/arduino-org/Arduino/tree/stm32f4). What are we to make of that? SparkFun just announced their partnership with Arduino to sell the Otto an Primo, stating it will be available "later this year". (http://www.prweb.com/releases/2017/01/prweb13970070.htm)
 
Last edited:
I've heard good things about mbed. I'd like to know what the downsides are.

mbed makes a great first impression. You plug in the mbed-enabled board, it opens as a mass storage device with a link to the mbed site for that board. You follow the link, register, and get instant access to a web-based IDE that's pretty nice. You can easily browse your code and the source from any libraries you've imported (there are many). It even has code completion and version control. You can compile and it will automatically download a .bin file to your computer which you can then drag-and-drop onto the mass storage device and it will install and run your program.

You can have multiple boards registered from different Cortex lines and different vendors. Want to port the program you wrote for your STM32 Nucleo M0-based board to an NXP Kinetis K64? Select a different board by clicking a button in the IDE. It will open a window with all of the boards you have registered. Just pick one and click "compile". For simple programs like Blinky, this all works great. How well it works for more complex programs is something I'd like to know myself.

Where things start to get a little rough around the edges is when you want to use a hardware debugger (either on the board itself or via an external probe). They have a nice doc that walks you thorough exporting the mbed project to a variety of desktop IDEs, but when I tried it, I ran into problems with missing header files. I'm sure I will get past this with a bit more effort, but hardware debug is clearly not one of mbed's strong points.

If you've got a beefy enough ARM processor and memory, you can use the mbed OS. I tried a few simple example programs and they worked fine. Again, how well this works beyond the examples they provide is something I would like to know more about myself (and will be digging into as time permits).

Then there's the whole mbed Cloud thing which isn't available to the public yet. It all sounds great, especially if you're into IoT, but it's a work in progress. In time, it could be quite something if the chip vendors get on board. Right now STM and NXP have good presence, but Atmel has almost none and Nordic has none at all (although there are quite a few other vendors that do).

Also worth mentioning:
1. mbed OS has dependencies on CMSIS. Whether this is a good thing or a bad thing is something I'm still trying to figure out.
2. Many of the mbed docs point you toward Keil MDK, which only runs on Windows and is also owned by ARM. Like everyone else, they're trying to get you to commit to their ecosystem and I'm wary of doing this.

Question for Paul:
What is your preferred ARM IDE/toolchain, if any?
 
Last edited:
OK yes, I've strayed *wayyy* off topic, but I've just run across a resource that some of you may find useful.

"Fast and Effective Embedded Systems Design: Applying the ARM mbed"

It's a book about using mbed, is in its second edition, has a copyright of 2017, and has an entire chapter devoted to weaning you off of embed and going bare metal or just mixing in bare metal with mbed as desired. I was impressed that a book about embed would have such a chapter. They're clearly not being paid by ARM to sell mbed.
 
Arduino.

My goal is to bring powerful hardware capabilities to beginners. Today Arduino is pretty much the only realistic way to serve the needs of novices.

Concur. Am certain that your product line enjoys many 'professional' implementations; but those of that use Teensy stuff in industry are big boys and girls and can take care of ourselves, where absolute tool-chain control is very important.

Serving novices with competence and patience and respect is a winner for your business model.

Will there be a T3.x lib for the Illudium Q-36 Explosive Space Modulator?
 
Arduino.

My goal is to bring powerful hardware capabilities to beginners. Today Arduino is pretty much the only realistic way to serve the needs of novices.

Which does not prevent those who know what they are doing, to do it differently.
Anyhow, even if my own applications are developed using eclipse, in cases where I wanted to do a quick test of a new algorithm, I switch to Arduino and do my one-pager (mostly in setup).
 
... they're going on (and on) about STAR Otto and Primo. Both of which are pretty interesting, but they announced these products back in May 2016 and they're still not here. I took a peek at their github dev branch for the STM32F4 (Otto) and they haven't made an update in six months! (https://github.com/arduino-org/Arduino/tree/stm32f4).

Re: star otto

Still nothing new from Arduino on star otto, but the MCU performance should be about the same as the T3.6. MBED has a ST-Discovery-F469NI based on otto's MCU, so you could do some testing. Here are some coremarkish results
otto.pngottoa.png
The mbed ARM CC compiler (-O3) produces slightly faster code than Teensyduino gcc (-O2). The mbed board has a jumper where you can measure just the current to the MCU. MCU has DSI hardware for fast LCD support, and the otto has wifi chip. mbed notes that USB doesn't work at 180mhz, and their default clock is 168MHz, though i ran simple benchmarks at 180mhz.

Other anecdotal performance numbers at https://github.com/manitou48/DUEZoo/blob/master/perf.txt
 
Last edited:
Status
Not open for further replies.
Back
Top