ATMEL Sam, coming from STM32Fx, how is the enviroment?

[jnz]

Ran into a project that might make sense to use a new Atmel SAM E5 chip, know nothing about Atmel's ARM line.

Can someone give me the five second run down on the current options for Atmel headers, code generators, environments?

• I left Microchip before Harmony, but tried it and hate it.
• Used STM32 with the Standard Peripheral Lib, and that was great.
• Hated Cube MX HAL at first but now I really don't mind it a ton (at least it works, usually).
• I'm going to use Keil on this project, maybe someday move to Segger Studio

• Is there a simple standard peripheral lib?
• Do you have to use their code generator HAL thing? Is it good?
• Is there a reason the Segger JLink, JLink Trace, or Keil would give me extra headache with the Atmel tools/code I'll need?
• Given that I haven't yet seen a firmware dump hack for Atmel, would anyone else rate them as a little more secure than NXP or STM?
• Does anyone have STAY AWAY warning for the new SAM series? Or any other important  comments on questions I might not know to ask?

Thanks guys!

[jnz]

Really? No one? With as much hate as their is for the STM HAL, and as much love in the hobbies community for Atmel, I really would have thought someone would have an opinion one way or another about the Atmel environment.

[shtirka]

The first port of call as far as Atmel Studio (the IDE) and Atmel ASF/START (an equivalent of ST HAL) are concerned your first port of call is https://www.microchip.com/mplab/avr-support. I have not used the Atmel Start personally, but I hear that it can be a bit limited as far as chip support and driver so youd be better off using the ASF thats supplied with the Atmel studio. Also there are no known "STAY AWAY" warnings that I am aware of - but then you would just have to read the errata section for the SAM E5 chip to see if there is anything of importance to you. I have only used Atmel ICE programmer/debugger so I cant speak for any alternative debuggers like the Segger ones - thats where others will probably fill in the gaps. I also believe that Keil also has certain support for Atmel chips - but have no idea if the E5 chip is supported.
You could also visit http://www.avrfreaks.net - thats where the majority of users (me included) of Atmel products tend to be

//Ilya

[shtirka]

The Atmel Studio is only available for Windows, but I know a lot of users on avrfreaks.net also use Linux and I have also seen people use OS X - they have their own toolchains installed so you may still be able to find answers if you are a non-Windows person

Ilya

[luiHS]

 
Some time ago I tried the Atmel SAM E70 (Cortex M7), and I did not like anything. Mainly, because of its Atmel Studio development environment, the ASF assistant and the few example sources they provide.

Before using an Atmel SAM, I would prefer an NXP Kinetis, and much better the new RT series from NXP, I am now testing the NXP RT1020, Cortex M7 500Mhz, and for now very well. The MCUXpresso development environment is very good, with many importable sample sources from its SDK, and a very good Config Tools wizard. The RT series of NXP is very cheap, even cheaper than many Cortex M4 from other manufacturers.

My suggestion, if you have not started the project yet, is that you try the RT1020 of NXP, with MCUXpresso, you will surely like it much more.

If you come from the STM32, it is not a good evolution to go to the Atmel SAM, for me it is just the opposite, they are taking steps back, almost as wrong as going to PIC32.

The ARM world is the ideal, of course, for me to choose between STM32 and NXP RT. There is also the Kinetis series from NXP, but they are expensive compared to the new RT, or even compared to the STM32.

[westfw]

 [SAME5x] - Adafruit is using the SAMD51 chip in their latest range of Arduino-like boards.  (The SAMe5 chips are similar to SAMd5 chips, except the E5 has ethernet and/or CAN?)  They've got QSPI flash, the Arduino core up, as well as "circuitPython", and between Adafruit and their userbase, so they're collecting quite a bit of information.  Watch their github SAMD-core repository (or not, if you have to avoid contamination.)

Is there a simple standard peripheral lib?

There is ASF - the Atmel Software Framework.  I find it awful and bloated; about the same as the STM SPL.  If you didn't mind SPL, you might not mind ASF.   I don't have any experience with the higher-level functions.

Do you have to use their code generator HAL thing? Is it good?

Of course you don't HAVE to use it.  I've only tried it a couple of times.  It seems to be online-only, and I didn't like it very much.  Parts of it aren't very intuitive (I'm not convinced that clock setup is any more obvious with the the GUI than with ASF, or that ASF is any better than figuring it out and doing it yourself.)  It'll put together a .zip collection of the hundreds of files that your project might be dependent on for you to download and use offline.  I guess that might make sense from a Source Code Version Control PoV, but I find it depressing.

Does anyone have STAY AWAY warning for the new SAM series? Or any other important  comments on questions I might not know to ask?

Beware "per pin interrupts."  While "any pin can generate an interrupt", the SAMD family at least as a limit on the total number of pin interrupts at 16, and for certain groups of pins, only one will actually generate an interrupt.
https://forums.adafruit.com/viewtopic.php?f=63&t=134385


Any SERCOM can run I2C, but not all hardware pins support the I2C hardware requirements.  https://forums.adafruit.com/viewtopic.php?f=63&t=139056#p687412  Apparently Atmel Start declines to configure I2C on the pins that don't have the HW support, even though the differences in HW will seldom make a difference.

CM0 is a sucky CPU (ok, not an Atmel problem.)  Simple RISXy expressions blow up into unexpectedly large bits of machine code because the M0 lacks some instruction encoding...

The SAMD51 errata has some pretty serious bugs in the A2D area, IIRC.

Don't forget to turn on the cache.  And if you're going to benefit from the floating point hardware, you'll need to use single-precision math functions and convince the compiler not to promote all your floats to doubles in expressions...


Don't assume that a peripheral on one SAM chip behaves identically the similarly named peripheral on a different SAM chip.  So far I've seen:

• "RTC" on SAMD10/etc can be clocked from a high-frequency GCLK.   On most SAMs it can only be clocked from a 32kHz low-power clock.
• UART SERCOM pad multiplexing can be different.  In particular, some chips support a pin configuration that can swap Rx and Tx by SW, and some don't.
• The SAMD5x chips (and perhaps others?) have multiple interrupts per SERCOM.  Others have a single interrupt that needs to be decoded in the ISR.
• GCLK configuration is dramatically different between SAMD2x and SAMD5x, despite similar "philosophy"

[Doctorandus_P]

Popularity of Atmel by hobbyists has nothing to do with atmel's 32 bit stuff.
Atmel itself also has not much love for Linux users, and the main/only reason that Linux user can use the AVR's is because of GCC and avrdude.

I switched from pic 16f84 to atmel at90s2313 a long time ago for the sole reason of a C compiler being available for that chip, which was not very common on those days.

The myriad of diffent internal peripherals ( quote from avrfreaks: "half arsed USI:) are also an annoyance, just as the myriad of different programming / debugging interfaces, for which atmel has not released specifications / protocols.

"Atmel Studio" is a clone of microsoft, which I have never used on my linux box.
Some time ago I wanted "something more powerfull" than an AVR, and looked into the Xmega's, but they were so different from the avr's that therw would be a significant learning curve, and therefore I eventually decided to ARM Cortex M3 (blue pill, STM32F103c8T6 and consorts, but still haven't done much with those).

You probably know Atmel is no more, it is bought by Microchip, and support for the old atmel chips is slowly beginning to appear in mplab. My guess is that "Atmel Studio" would be phased out in a few years time.

[jnz]

There is ASF - the Atmel Software Framework.  I find it awful and bloated; about the same as the STM SPL.  If you didn't mind SPL, you might not mind ASF.   I don't have any experience with the higher-level functions.

You mean ASF is like STM32 HAL or STM32 SPL?



EDIT:
...

Nevermind.... I just looked through the code. It's about as bad as STM32's HAL. It has nothing in common with STM's SPL.  One immediate annoyance is that to write a register, if you follow it through long enough, they don't write to a struct that's mapped to the correct memory, but call a function like reg_write(my_reg). Probably 10+ function calls to clear a timer. :\

First impression isn't great.

EDIT2: I'm not sure of anything now! ASF isn't Atmel Start, there seems to be a HAL and a "Low Level" / "Standard Peripheral Lib"

[funkathustra]

Atmel Studio, even in 2018, regularly has installation bugs in my experience. They're all things you can work around, but in an era of Eclipse-based IDEs that "just work" I was surprised at how many bizarre driver issues and edge-case bugs I have to work through on a fresh installation.

As I wrote about in my blog post, once you get it going, you'll find that the Visual Assist code-completion is vastly inferior to the Eclipse CDT-based stuff. It doesn't seem to evaluate preprocessor directives and regularly incorrectly scopes variables. I was surprised it was so bad.

And as for code generation with Atmel START, since you want a comparison to STM32CubeMX: I've worked with STM32CubeMX, I know STM32CubeMX; STM32CubeMX was a friend of mine. Trust me, Atmel START is no STM32CubeMX. It's simply awful, and will happily generate code that leaves your MCU waiting for a nonexistent PLL to stabilize, or memory-fault the core by accessing a peripheral that wasn't properly clock-gated.

ASF is the peripheral library that Atmel START works with. It is also awful. Lots of inefficient struct dereferencing and an overall bizarre API that tries to expose a file I/O pattern on things, if I remember correctly?

The Atmel ecosystem is frustrating because their ARM chips are really great; good power consumption, good peripherals, and good power consumption figures. I just wish they had a better development ecosystem.

Strangely, while Atmel is admired by hobbyists and indie devs prototyping up projects quickly, I think the STM32, Renesas, and Infineon XMC stuff is inherently much more suited to that segment of developer, simply because the IDEs are so much easier to use, cross-platform, and have good code-gen tools. I get why people went to Atmel 15 years ago, but it's less clear to me why they've stayed.

There are developers like @ataradov who do lower-level development with Makefiles and (quite elaborate) custom peripheral libraries, but for people who just need to get a part up and running quickly without doing a lot of copy-pasta between projects, I think you're going to find the Atmel stuff unsatisfying.

[jnz]

Hmm...

I'm seeing one issue of my confusion.

ASF3 silimar to STM Standard Peripheral Library (and I see what you mean about bizarre structing, nothing I'm too scared of, but it is interesting what they're doing system->hw->instance->register or something like that)

ASF4 requires START which is similar to the STM32CubeMX / HAL. I really don't like START at first glance. IDK. Seems to take a long time to compile the similar examples with ARMCC.

Hmmm... Yea, what I need is a very simple peripheral lib that makes sense. But I definitely don't have the time to write that for this project.

[james_s]

I've never had any luck at all with Atmel SAM chips, never could get them to program properly on the PCs that I've tried. Only series of microcontroller I've ever had that issue with, 3 or 4 different varieties of them. Came away unimpressed.

[jnz]

Ok, a little update. Used the Atmel START / ASF 4 for about two minutes and it seems to be at best bloated inside their enviroment - and outside of their enviroment seems to be nearly unusable. I can't figure out why but this does not seem to get along with ARMCC.

Strangely, while Atmel is admired by hobbyists and indie devs prototyping up projects quickly, I think the STM32, Renesas, and Infineon XMC stuff is inherently much more suited to that segment of developer, simply because the IDEs are so much easier to use, cross-platform, and have good code-gen tools. I get why people went to Atmel 15 years ago, but it's less clear to me why they've stayed.

And there it is. For this project it turns out I overlooked the Infineon XMC, but they have a cheap, available, perfect little chip for what I need. And their software.... EXCELLENT. Single function calls for important tasks, structures that match the registers, an IDE (DAVE) that can be used to set the project up then switch over to your IDE of choice if you want.... The real winner here is the software! Their XMC Peripheral Library is somehow some dying breed of excellent, compact, and clean drivers. Super impressed so far.

A few issues with little stuff that I'll work out, but in one day I'm way ahead of where I was with Atmel and now I don't need to code the peripheral libs myself.

FWIW... It is "possible" to use the ASF4 stuff on the Atmel at just the "HRI" level which is the lowest level of their HAL, it's not terribly dissimilar to directly modifying registers but still uses their hardware instance system, and it's entirely undocumented, not intended to be used directly, and it's auto generated so you wind up with functions like ASF_someperipheral_someregister_clear_somebitnumber(instance, mask); which is terribly annoying because at no point will I need to clear just the 30th bit of some register that's meant to be accessed by words/bytes.

Sorry Atmel, had your chance! Infineon wins this round.