Atmel / Microchip ARM development

[ZeroResistance]

I haven't heard good reviews for Atmel / Microchip SAM series ARM chips on Eevblog,
the conclusion I reached after reading a lot of threads here are that although the Atmel ARM chips are good concerning the peripheral and power consumption but their standard development environment especially is not up to the mark.

How is the experience with external IDE's like Keil uVision or IAR do we still have to depend on Atmels libraries / dev tools if we use these IDE's?

[dietert1]

About two years ago we got a SAM XMINI starter board and some low pin count chips for prototypes. As far as i remember i was surprised with the free tools. The libraries seemed to be very well organized. Especially when i think about STM32 support, which has become very complex over the years.

Isn't it fantastic that nowadays one dollar buys a 32 bit Microcontroller with several built-in clock generators and several peripherals - all in SO-14?

Regards, Dieter

[ZeroResistance]

About two years ago we got a SAM XMINI starter board and some low pin count chips for prototypes. As far as i remember i was surprised with the free tools. The libraries seemed to be very well organized. Especially when i think about STM32 support, which has become very complex over the years.

Isn't it fantastic that nowadays one dollar buys a 32 bit Microcontroller with several built-in clock generators and several peripherals - all in SO-14?

Regards, Dieter

I'm sorry I didn't quite get what you wanted to express. Were you happy with the SAM chip's development experience have to moved on now to some other brand or do you still use Atmel?

[dietert1]

As far as i remember the free tools (AtmelStudio 7.0 at that time) were absolutely useful.

Regards, Dieter

[ZeroResistance]

As far as i remember the free tools (AtmelStudio 7.0 at that time) were absolutely useful.

Regards, Dieter

Thansks for the feedback, I hope to receive some updated reviews about the current scenario, you seem to have positive feedback however I have yet to hear positive reviews regarding the current development environment of Atmel.
If from what I hear is true, I would like to hear reviews of Atmel SAM development with Keil uVision, IAR etc.
I want to take a decision on STM32F4 vs ATSAM4S.
I see that the program memory / SRAM / pricing of the ATSAM4S is quite good.

[mark03]

IMO choosing an MCU family based on the vendor-supplied tools and code is a bit like choosing a car based on the entertainment system.  If this is for commercial development, there are plenty of well supported toolchains out there---IAR for example.  If it's for personal use, you can set up your own Eclipse-based environment, or use the vendor's if you like it.  As for the vendor-supplied drivers and what-not, they are all useful for hacking something together quickly, but I can't think of a single one I would want in my production code, given a choice.  (In fairness, sometimes you don't have a choice... but they all suck, nonetheless.)

Pick your MCU family based on (1) the hardware's suitability for your application; (2) the quality of the written documentation; (3) cost (but only if this is commercial development); and later on (4) your familiarity with that chip family based on past projects.

[ogden]

I want to take a decision on STM32F4 vs ATSAM4S.

From development point of view they do not differ much, especially using 3rd party tools. Hobbyists tend to use STM32's more than ATSAM's, most likely due to slightly lower initial devboard/jtag costs some time ago, maybe today as well(?). Some say that Atmel have better documentation and support. I say your mileage in this regard may vary. In short: both are good, you can't be wrong picking any of two 

Make sure to carefully compare not only configuration/peripheral specification, but electrical/timing specs as well. You may find unexpected differences. Just example: typical pull-up/pull-down resistance Atmel: 100kOhm, ST: 40kOhm

[dietert1]

The STM32 family is interesting insofar as they offer extremely powerful MCUs, like the F7 series with double precision FPU.
Their support software has become complicated. As far as i remember several years ago they introduced a different hardware abstraction layer, obsoleting lots of previous examples. Rather confusing for a starter. But their chips are really very good. As far as i remember they are market leaders.

If you have been using Keil or IAR before, you can be sure their support of the ATMEL/Microchip Cortices is very similar and you can combine the free support libraries with your IDE.

And yes: All those chips are complex enough to spend a man-year or so before getting anywhere close to a professional product. Those Youtube demos where you get something after half an hour, that's too stupid. My first Cortex M4 project was a Kinetis chip. They had a very nice forum and everything went well, but it took time.

Regards, Dieter

[ZeroResistance]

And yes: All those chips are complex enough to spend a man-year or so before getting anywhere close to a professional product. Those Youtube demos where you get something after half an hour, that's too stupid. My first Cortex M4 project was a Kinetis chip. They had a very nice forum and everything went well, but it took time.
Regards, Dieter

Is the development time for a Cortex M4 / M7 processor related to the number and or type of peripheral you would be using in your application, or are there other factors affecting that.

[ZeroResistance]

Pick your MCU family based on (1) the hardware's suitability for your application; (2) the quality of the written documentation; (3) cost (but only if this is commercial development); and later on (4) your familiarity with that chip family based on past projects.

For "quality of written documentation", It would be interesting to hear the views of the audience here.

[dietert1]

It's just the complexity of the chip. And you need to get a "feeling" in order to understand documentation typical of a certain make.
The SAMS4 datasheet amounts to 1269 pages, plus another 500 pages or more of support software documentation, so you just need time to understand all this plus some software experiments with a starter kit.
If you don't - for example you buy a prefabricated support library and flash operating system - you will have to understand the docs of that one. In my experience (medical instrumentation) even a minor detail like incomplete configuration of a crystal oscillator can spoil an otherwise perfect project.

Regards, Dieter

PS: Large parts of the Cortex system architecture is not contained in the datasheet, but in some more generic documents available from ARM. So if you are new to Cortex, you will need to read there, too.

[nctnico]

Pick your MCU family based on (1) the hardware's suitability for your application; (2) the quality of the written documentation; (3) cost (but only if this is commercial development); and later on (4) your familiarity with that chip family based on past projects.

For "quality of written documentation", It would be interesting to hear the views of the audience here.

I don't use anything from Atmel or Microchip in my designs. Too much fine-print, false claims and less than optimal design choices in the products. For example: if Atmel prints that a device works at 1.8V it won't work reliably at 1.8V in a real circuit.

[L1L1]

Pick your MCU family based on (1) the hardware's suitability for your application; (2) the quality of the written documentation; (3) cost (but only if this is commercial development); and later on (4) your familiarity with that chip family based on past projects.

For "quality of written documentation", It would be interesting to hear the views of the audience here.

I use both SAM chips and STM32 chips, sometimes on the same board [1], using CMSIS libraries. I think that if you consider documentation to encompass both the datasheets and the library code, the STM32 family is much better than the Microchip SAM family. In fact, in some areas, the documentation for the SAM chips is abysmal (e.g. try figuring out the CAN bus on the SAMC21).

The datasheets of the STM32 are not perfect, but they often provide a decent "step-by-step" description of what's needed to activate a functionality or peripheral. But the nice thing about the STM32 is that the source code of their "LL" (Low Level HAL) libraries is quite readable, and contains clear comments that can really help you understand how do stuff on their chips.

[1] https://www.omzlo.com/articles/canzero

[richardman]

One major problem with Atmel's ARM chips are/were that they put their support libraries inside their walled garden. I think things are better now though. So far, I have not been able to get a standalone non-Atmel Studio toolset program working yet. I have located the libraries outside of AS's walled garden, but the blinking LED does not blink. I expect it to be just a matter of time though. Anyway, once the libs can be separated from AS7, then it should be just a matter of reading the datasheet and writing code.

[bhave]

I use the ATSAMD and ATSAME series from Microchip.  I am not sure the general register level documentation is much better or worse than my experience with the ST Micro MCUs.  I tend to avoid the vendor supplied libraries and frameworks unless I need to use something like USB or Ethernet, so I cannot comment on the setup or documentation for those. 

As for the vendor supplied development software, Atmel/Microchip is in a transition from Atmel Studio to Mplab X.  It looks like eventually all Microchip MCUs will be developed using Mplab X.  Both Studio and Mplab have their pluses and minuses.  The interesting thing about moving all Microchip MCU development to Mplab is that a single software suite and debugging tool allows access to an enormous selection of MCUs.  I do find that I like Eclipse based development software a little better, but it is easy enough to set up a vendor agnostic ARM development environment using Eclipse if you want to go that route.

As with any MCU, the BIG difference is the peripherals.  The SAMD, SAME, SAML, and SAMC MCUs have an extremely flexible (and complicated) clocking configuration that allows a lot of granularity in peripheral speeds.  I also find the TCC and SERCOM peripherals really nice to work with.  It seems like Microchip is trying to keep the same general peripheral lineup throughout their newer generation of Cortex MCUs, which is nice as well.

[ZeroResistance]

Reading the post's so far I gather that there are mixed responses on the documentation part of Atmel vs ST.
I am hoping to hear experience of SAM series with 3rd party IDE's like IAR, Keil, do we still have to depend on vendor supplied libs if we use these 3rd party IDE's?

[ataradov]

You never HAVE to depend on any libraries. But if you want to use vendor libraries, then yes, you have to use Atmel code. IAR people don't write their own libraries. Well, sometimes they do write things, but whether a specific device or a feature will be supported is a hit or miss, and they still rely of vendor code a lot.

[bhave]

I have used Keil a bit, but to be honest, the experience using vendor based development environments has always been better for me.  It used to be a plus to pay once and be able to choose from a selection of MCUs supported by the development environment instead of getting locked into a specific vendor.  I think the allure of Keil and IAR has worn off a bit now that all the major vendors provide free environments (unless you want or need paid support, some sort of special safety rating, or the extra optimization the IAR compiler can give you).

[ZeroResistance]

You never HAVE to depend on any libraries. But if you want to use vendor libraries, then yes, you have to use Atmel code. IAR people don't write their own libraries. Well, sometimes they do write things, but whether a specific device or a feature will be supported is a hit or miss, and they still rely of vendor code a lot.

Ok, however user mark03 wrote this
IMO choosing an MCU family based on the vendor-supplied tools and code is a bit like choosing a car based on the entertainment system.  If this is for commercial development, there are plenty of well supported toolchains out there---IAR for example.
So I'm just trying to understand what does "well supported toolchain" mean.

[ZeroResistance]

I have used Keil a bit, but to be honest, the experience using vendor based development environments has always been better for me.  It used to be a plus to pay once and be able to choose from a selection of MCUs supported by the development environment instead of getting locked into a specific vendor.  I think the allure of Keil and IAR has worn off a bit now that all the major vendors provide free environments (unless you want or need paid support, some sort of special safety rating, or the extra optimization the IAR compiler can give you).

I had used STM32CubeMX a bit, never knew STM-Studio though is that ST's own IDE for STM32 development?

[ataradov]

So I'm just trying to understand what does "well supported toolchain" mean.

I really don't know what it means here.

I agree that choosing MCU vendor based on the supplied code is not very smart move in general. It all depends on your style. Can you live without needing a "framework" to get even the most basic things working? If so, then go with whatever.

If you are absolutely glued to the reference systems and code, then go with the vendor tools. They will have the best coverage of supported devices and features.

[ZeroResistance]

I agree that choosing MCU vendor based on the supplied code is not very smart move in general. It all depends on your style. Can you live without needing a "framework" to get even the most basic things working? If so, then go with whatever.

If you are absolutely glued to the reference systems and code, then go with the vendor tools. They will have the best coverage of supported devices and features.

Is "vendor supplied code"  the HAL supplied by the vendor, or are we referring to something else here. Because I guess  that was what I had used the last instance when I was testing the STM32F4 discovery board.

[ataradov]

Is "vendor supplied code"  the HAL supplied by the vendor, or are we referring to something else here. Because I guess  that was what I had used the last instance when I was testing the STM32F4 discovery board.

HAL is ST-specific name, but yes, this.

It should also be noted that vendor code is portable between the IDEs anyway. You just get the best experience on the vendor tools, but it all will work across the tools.

For example Atmel Start (one of Microchip/Atmel frameworks) can generate project files for Atmel Studio, MPLAB X, Keil, IAR, and just plain Makefiles that should work everywhere.

[ogden]

HAL is ST-specific name, but yes, this.

HAL (Hardware Abstraction Layer) is far from ST-specific (name).

[ataradov]

HAL (Hardware Abstraction Layer) is far from ST-specific (name).

I'm aware of the general use. But in the context of this conversation HAL is the name for the set of libraries from ST.