Author Topic: Atmel / Microchip ARM development  (Read 6504 times)

0 Members and 1 Guest are viewing this topic.

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Atmel / Microchip ARM development
« on: May 27, 2019, 10:30:09 am »
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?


« Last Edit: May 27, 2019, 03:15:14 pm by ZeroResistance »
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2073
  • Country: br
    • CADT Homepage
Re: Atmel / Microchip ARM development
« Reply #1 on: May 27, 2019, 12:22:42 pm »
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
« Last Edit: May 27, 2019, 12:30:16 pm by dietert1 »
 
The following users thanked this post: ZeroResistance

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #2 on: May 27, 2019, 12:39:39 pm »
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?
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2073
  • Country: br
    • CADT Homepage
Re: Atmel / Microchip ARM development
« Reply #3 on: May 27, 2019, 02:38:16 pm »
As far as i remember the free tools (AtmelStudio 7.0 at that time) were absolutely useful.

Regards, Dieter
 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #4 on: May 27, 2019, 03:13:01 pm »
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.
 

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 711
  • Country: us
Re: Atmel / Microchip ARM development
« Reply #5 on: May 27, 2019, 04:26:36 pm »
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.
 
The following users thanked this post: Siwastaja, ogden, NivagSwerdna, ZeroResistance

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: Atmel / Microchip ARM development
« Reply #6 on: May 27, 2019, 04:30:19 pm »
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
 
The following users thanked this post: ZeroResistance

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2073
  • Country: br
    • CADT Homepage
Re: Atmel / Microchip ARM development
« Reply #7 on: May 27, 2019, 04:54:31 pm »
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
 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #8 on: May 27, 2019, 06:21:44 pm »
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.
 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #9 on: May 27, 2019, 06:23:45 pm »
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.
 

Offline dietert1

  • Super Contributor
  • ***
  • Posts: 2073
  • Country: br
    • CADT Homepage
Re: Atmel / Microchip ARM development
« Reply #10 on: May 27, 2019, 06:42:50 pm »
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.
« Last Edit: May 27, 2019, 06:46:35 pm by dietert1 »
 
The following users thanked this post: ZeroResistance

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Atmel / Microchip ARM development
« Reply #11 on: May 27, 2019, 08:39:09 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline L1L1

  • Regular Contributor
  • *
  • Posts: 52
  • Country: gr
Re: Atmel / Microchip ARM development
« Reply #12 on: May 28, 2019, 07:18:12 am »
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
 
The following users thanked this post: ZeroResistance

Offline richardman

  • Frequent Contributor
  • **
  • Posts: 427
  • Country: us
Re: Atmel / Microchip ARM development
« Reply #13 on: May 28, 2019, 09:00:13 am »
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.
// richard http://imagecraft.com/
JumpStart C++ for Cortex (compiler/IDE/debugger): the fastest easiest way to get productive on Cortex-M.
Smart.IO: phone App for embedded systems with no app or wireless coding
 

Offline bhave

  • Contributor
  • Posts: 20
  • Country: us
Re: Atmel / Microchip ARM development
« Reply #14 on: May 28, 2019, 02:37:05 pm »
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.
 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #15 on: May 28, 2019, 04:07:40 pm »
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?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11262
  • Country: us
    • Personal site
Re: Atmel / Microchip ARM development
« Reply #16 on: May 28, 2019, 04:12:22 pm »
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.
Alex
 

Offline bhave

  • Contributor
  • Posts: 20
  • Country: us
Re: Atmel / Microchip ARM development
« Reply #17 on: May 28, 2019, 06:31:19 pm »
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).
 
The following users thanked this post: ZeroResistance

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #18 on: May 28, 2019, 06:42:32 pm »
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.
 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #19 on: May 28, 2019, 06:47:51 pm »
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?
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11262
  • Country: us
    • Personal site
Re: Atmel / Microchip ARM development
« Reply #20 on: May 28, 2019, 06:48:56 pm »
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.
Alex
 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #21 on: May 28, 2019, 07:42:22 pm »


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.
 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11262
  • Country: us
    • Personal site
Re: Atmel / Microchip ARM development
« Reply #22 on: May 28, 2019, 08:15:49 pm »
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.
Alex
 

Offline ogden

  • Super Contributor
  • ***
  • Posts: 3731
  • Country: lv
Re: Atmel / Microchip ARM development
« Reply #23 on: May 28, 2019, 08:28:35 pm »
HAL is ST-specific name, but yes, this.

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

 

Online ataradov

  • Super Contributor
  • ***
  • Posts: 11262
  • Country: us
    • Personal site
Re: Atmel / Microchip ARM development
« Reply #24 on: May 28, 2019, 09:00:08 pm »
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.
Alex
 
The following users thanked this post: ogden

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Atmel / Microchip ARM development
« Reply #25 on: May 28, 2019, 10:53:04 pm »
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.

When I first started with STM32xx in 2016 I was warned by friends that the STM documentation is massive, disorganized, voluminous and takes years to read.
It's certainly voluminous, but that's a consequence of the amazing capability of the series. How long would it take you to write a manual describing 37 Peripherals,   413 Registers and    3044 bitfields ? and that's just for a lowly STM32F0xx! Writing error free documentation for these MCU's is a massive task.

After a few months of flailing around I started to get a grip on the STM and ARM document system and now it's my preferred documentation, personally I now prefer it to any other I've seen for any other MCU . I find the usual 4 or 5 documents for every STM32xx comprehensive and easy to read, usually going for the "technical reference" first.

I have this to say to STM for their documentation ... "Bloody good job STM, keep up the good work"

Also don't forget ARM's CMSIS-SVD, I doubt I could use STM32xx MCU's effectively without it.
 
The following users thanked this post: ZeroResistance

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: Atmel / Microchip ARM development
« Reply #26 on: May 29, 2019, 07:28:52 am »
Quote
I'm just trying to understand what does "well supported toolchain" mean.
That usually means that you can easily write the code that you want to write - the stuff that you expect to set your product apart from your competitors, but can rely on vendor provided code  (or easily licensed OSSW) for the pieces that you really don't want to write and consider "generic"  (USB and networking code are common examples of the latter.  No one really wants to write an IP/TCP stack (except IP stack vendors!), but that doesn't mean that I want to use an opaque implementation that requires a specific RTOS and only works with the on-chip Ethernet MAC and some specific PHY chip...
 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #27 on: May 29, 2019, 10:30:28 am »
Ok so there is CMSIS then there is HAL and may me libraries like USB, Ethernet etc. (Don't know what that falls under)... So where does Atmel go wrong in all this?
 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #28 on: May 29, 2019, 11:31:58 am »
Quote
I'm just trying to understand what does "well supported toolchain" mean.
That usually means that you can easily write the code that you want to write - the stuff that you expect to set your product apart from your competitors, but can rely on vendor provided code  (or easily licensed OSSW) for the pieces that you really don't want to write and consider "generic"  (USB and networking code are common examples of the latter.  No one really wants to write an IP/TCP stack (except IP stack vendors!), but that doesn't mean that I want to use an opaque implementation that requires a specific RTOS and only works with the on-chip Ethernet MAC and some specific PHY chip...

AFAIK, CMSIS, HAL and STD Peripheral libs are the 3 modes of programming, now how does IAR, Keil fit into this and how different are they compared to the Vendor IDE.
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: Atmel / Microchip ARM development
« Reply #29 on: May 29, 2019, 11:33:49 am »
I used ATSAM4N with great success and never had any issues (that were not of my own doing).

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #30 on: May 29, 2019, 11:35:39 am »
I used ATSAM4N with great success and never had any issues (that were not of my own doing).
Ok, that sound's good, can you talk a bit about what tools you use?
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: Atmel / Microchip ARM development
« Reply #31 on: May 29, 2019, 11:58:07 am »
Ok, that sound's good, can you talk a bit about what tools you use?
I used Atmel Studio. It's based on Visual Studio, and since I used that IDE professionally for many years, I felt right at home with it. It was a clean-sheet design with a custom board right from the get go, used Atmel ICE for ICP and debugging. Was really happy and comfortable with setup, but I will admit a lot of it was probably my familiarity with IDE. Because I got so comfortable with the toolchain, even now whenever I need an MCU, Atmel/Microchip ARM part is always at the top of the list of parts I consider using.

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #32 on: May 29, 2019, 12:19:00 pm »
Ok, that sound's good, can you talk a bit about what tools you use?
I used Atmel Studio. It's based on Visual Studio, and since I used that IDE professionally for many years, I felt right at home with it. It was a clean-sheet design with a custom board right from the get go, used Atmel ICE for ICP and debugging. Was really happy and comfortable with setup, but I will admit a lot of it was probably my familiarity with IDE. Because I got so comfortable with the toolchain, even now whenever I need an MCU, Atmel/Microchip ARM part is always at the top of the list of parts I consider using.
Ok and the chip was used in a production environment? Were you using Atmel std. peripheral libs or just register access?
 

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: Atmel / Microchip ARM development
« Reply #33 on: May 29, 2019, 12:34:51 pm »
Ok and the chip was used in a production environment? Were you using Atmel std. peripheral libs or just register access?
There were several projects (another one was using one of their CM0+ chips - can't remember exact PN now), and I used a little bit of both. Used CMSIS lib for fixed-point FFT (forgot what it's called), direct registers for fast IO (as my IO required precise timing, so I had to put in just right amount of NOPs between register accesses to achieve the waveform I wanted, and making sure compiler doesn't get any ideas about tossing these NOPs away), used their libraries for DMA, SPI and UART, also ported Atmel's driver for ATWINC1500 that was originally written for ATSAM4S (just few changes required as the driver had a dedicated HAL layer so porting was fairly painless).
I found their documentation to be very good (if you're not intimidated by multi-thousand-pages-long datasheets), so even if something didn't quite work as expected, it was very easy to get into debugger and check all registers to see what is going on, IDE provided registers decoding so I didn't have to reference datasheet quite that often, and I totally feel like if I had to, I could totally write all the code without using any of their libraries. Documentation for these libraries sometimes is not very good, but the actual code is very easy to read and understand (if you read a datasheet and know how HW is supposed to work). The only really confusing part was getting a startup right - like setting all clocks to what I needed them to be - this is one thing that ST got very right IMHO with their CubeMX code generator.
 
The following users thanked this post: ZeroResistance

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 711
  • Country: us
Re: Atmel / Microchip ARM development
« Reply #34 on: May 29, 2019, 05:12:18 pm »
If we really want to be pedantic, ST's HAL is now obsolete, replaced by "CubeMX" (which is about as bad in terms of code quality and bloat).

When I referred to the "toolchain" above, I was using the word in the traditional computing (or possibly Unix?) sense, meaning the set of tools required to convert source code into an executable: compiler, assembler, linker.  For C this also includes a "C library" and a "math library" which is where functions like printf() and sin() are actually implemented.  So the toolchain *does* include libraries... but only for the language features, nothing having to do with the hardware.

For virtually all of the vendors (except Atmel/Microchip?), their free development environment is based on the gcc toolchain.  If you spend $$ on IAR, you'd be using their toolchain instead.  It is claimed that the expensive compilers can produce smaller or faster code, although there is little objective data to support or refute this.  But some organizations like to spend the money anyway if for no other reason than peace of mind that they can get support if something breaks.  (This may also be a debatable assertion!)

Layered on top of the toolchain is the IDE (integrated development environment), the user interface and eye candy that most people rely on nowadays when writing code.  This may be Eclipse, an enormously bloated, slow, but extremely capable environment loved and hated by many, or the IAR IDE, or something else.  But you could just as well write code with a simple text editor and use command-line tools like makefiles.  One of the most productive and capable SW engineers I ever worked with swore by vim.  So, whatever floats your boat.

Like @ataradov said, you don't need to use *any* vendor libraries to develop with their parts.  It's strictly optional (and if you take my advice, discouraged).  But the vendors *do* provide a handful of important header files based on a standard called CMSIS.  Among other things, they define all of the registers and register fields so you can write things like TIM3->CR |= TIM_CR_EN in your code, to set the enable bit on timer #3.  If you go into the source code of the vendor libraries, like ST HAL or Cube or whatever they're calling it this week, you'll see that they are written using the same CMSIS register definitions.  They [ostensibly] make your life easier by providing a somewhat higher-level API than the register interface, although I contend you'll be happier doing that part yourself.
« Last Edit: May 29, 2019, 05:15:05 pm by mark03 »
 
The following users thanked this post: Siwastaja, ZeroResistance

Offline asmi

  • Super Contributor
  • ***
  • Posts: 2733
  • Country: ca
Re: Atmel / Microchip ARM development
« Reply #35 on: May 29, 2019, 06:52:14 pm »
For virtually all of the vendors (except Atmel/Microchip?), their free development environment is based on the gcc toolchain.
Not sure about "native" Microchip tools, but Atmel Studio uses gcc too. It's just wrapped in IDE fairly well so you don't normally have to deal with (nor care about) the actual backend they use directly.

Offline mark03

  • Frequent Contributor
  • **
  • Posts: 711
  • Country: us
Re: Atmel / Microchip ARM development
« Reply #36 on: May 29, 2019, 07:42:30 pm »
For "quality of written documentation", It would be interesting to hear the views of the audience here.

When I first started with STM32xx in 2016 I was warned by friends that the STM documentation is massive, disorganized, voluminous and takes years to read.
It's certainly voluminous, but that's a consequence of the amazing capability of the series. How long would it take you to write a manual describing 37 Peripherals,   413 Registers and    3044 bitfields ? and that's just for a lowly STM32F0xx! Writing error free documentation for these MCU's is a massive task.

After a few months of flailing around I started to get a grip on the STM and ARM document system and now it's my preferred documentation, personally I now prefer it to any other I've seen for any other MCU . I find the usual 4 or 5 documents for every STM32xx comprehensive and easy to read, usually going for the "technical reference" first.

I have this to say to STM for their documentation ... "Bloody good job STM, keep up the good work"

I confess, documentation is a sore spot for me.  I "grew up" in embedded design during the 90s when chips were far less complex.  Documentation is undoubtedly a much larger task nowadays than 30 years ago, but documentation isn't the only chip-design task which scales with complexity, so I don't see how mfgs get a pass here.  My contention is that documentation hasn't really kept up.  90% of my work is with STM32, and IMO their documentation is about as good, or maybe better, than their competitors'.  The problem is that *nobody* has great documentation.

Just now I fetched a couple of old (print) databooks:  The Dallas Semiconductor "Soft Microcontroller" (a flash-like non-volatile 8051 before flash was available), and the Motorola DSP56000 family manual.  I was going for the Motorola 68000 family manuals but I must have thrown them out already.  But anyway, it's mostly the era, not the particular vendor or part, that matters.  Pick up any one of these books, thumb to a page of dense prose, and start reading.  In most cases it will be clearer, more concise, and less ambiguous than what we have available for contemporary parts.  This is not mere pedantry or old-age grumpiness!  Many times I will read a paragraph in an STM32 Reference Manual, go back and read it again, and still not be 100% sure what the author is trying to say.  This makes my development effort measurably less efficient.  Besides ambiguity, another symptom of poor writing is wordiness, so as impressive as those thousands of pages of documentation are, you'd probably have 5% fewer pages (wild guess) if they were actually written well. :box:

I chalk this up to several trends:

1) I suspect semi mfgs have not hired tech writers in proportion to the amount of documentation they produce.  Much of ST's documentation is clearly written by ESL people, and while I have great admiration for those who speak multiple languages fluently (compared to my pitiful ~ 1.17 languages), tech writer is not a career I would expect for a non-native speaker.  As an example, the DFSDM chapter in the STM32L4 Reference is written by someone from India, whereas other sections of the same manual have obvious China-isms.

2) English is the first language of vastly fewer engineers in the 21st century than it was in the 20th.

3) Of those who do speak/write English as a first language, English proficiency has steadily fallen.  All you have to do is compare the written output of college freshmen in the US over time.  The change is dramatic!  See also: engineering graduates whining about all of the "useless" liberal-arts courses they were required to take in school :palm:

4) Semi mfgs have convinced themselves that their crappy libraries (CubeMX etc) are actually the preferred way for engineers to use their products, therefore they probably believe the detailed documentation is less important.  Already in areas outside MCU-land, we see chips where the mfg requires use of their own driver software, while register-level documentation is only available under NDA or not at all.

Some of these are not bad things.  For example, the increasing dominance of India and China in the tech sector has certainly accelerated innovation, and I imagine that outstrips any "documentation tax" that we pay as a consequence.  But it should still be pointed out, and I wish mfgs paid more attention to the quality of their documentation.  Unfortunately, one of the consequences of #3 is that native speakers' reading comprehension has also decreased, and many of them are in management, so the decision makers are increasingly blind to the problem.
« Last Edit: May 29, 2019, 07:47:04 pm by mark03 »
 
The following users thanked this post: ZeroResistance

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26907
  • Country: nl
    • NCT Developments
Re: Atmel / Microchip ARM development
« Reply #37 on: May 29, 2019, 08:45:02 pm »
Well.. you don't get what you don't pay for. ST isn't the benchmark when it comes to good datasheets but nevertheless people want to use ST's ARM processors to save a few pennies. However there are manufacturers with much better datasheets and more consistent product lines but you'll pay more for their products.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Atmel / Microchip ARM development
« Reply #38 on: May 30, 2019, 12:02:00 am »
For "quality of written documentation", It would be interesting to hear the views of the audience here.

When I first started with STM32xx in 2016 I was warned by friends that the STM documentation is massive, disorganized, voluminous and takes years to read.
It's certainly voluminous, but that's a consequence of the amazing capability of the series. How long would it take you to write a manual describing 37 Peripherals,   413 Registers and    3044 bitfields ? and that's just for a lowly STM32F0xx! Writing error free documentation for these MCU's is a massive task.

After a few months of flailing around I started to get a grip on the STM and ARM document system and now it's my preferred documentation, personally I now prefer it to any other I've seen for any other MCU . I find the usual 4 or 5 documents for every STM32xx comprehensive and easy to read, usually going for the "technical reference" first.

I have this to say to STM for their documentation ... "Bloody good job STM, keep up the good work"
Quote
I confess, documentation is a sore spot for me.  I "grew up" in embedded design during the 90s when chips were far less complex.  Documentation is undoubtedly a much larger task nowadays than 30 years ago, but documentation isn't the only chip-design task which scales with complexity, so I don't see how mfgs get a pass here.  My contention is that documentation hasn't really kept up.  90% of my work is with STM32, and IMO their documentation is about as good, or maybe better, than their competitors'.  The problem is that *nobody* has great documentation.

Just now I fetched a couple of old (print) databooks:  The Dallas Semiconductor "Soft Microcontroller" (a flash-like non-volatile 8051 before flash was available), and the Motorola DSP56000 family manual.  I was going for the Motorola 68000 family manuals but I must have thrown them out already.  But anyway, it's mostly the era, not the particular vendor or part, that matters.  Pick up any one of these books, thumb to a page of dense prose, and start reading.  In most cases it will be clearer, more concise, and less ambiguous than what we have available for contemporary parts.  This is not mere pedantry or old-age grumpiness!  Many times I will read a paragraph in an STM32 Reference Manual, go back and read it again, and still not be 100% sure what the author is trying to say.  This makes my development effort measurably less efficient.  Besides ambiguity, another symptom of poor writing is wordiness, so as impressive as those thousands of pages of documentation are, you'd probably have 5% fewer pages (wild guess) if they were actually written well. :box:
Oh yeah! I had the Motorola 6800 design (bible) it was huge and so well written, everything a designer needed to work with that chip. I loaned it to a friend and never got it back, that's how good it was.

Quote
I chalk this up to several trends:

1) I suspect semi mfgs have not hired tech writers in proportion to the amount of documentation they produce.  Much of ST's documentation is clearly written by ESL people, and while I have great admiration for those who speak multiple languages fluently (compared to my pitiful ~ 1.17 languages), tech writer is not a career I would expect for a non-native speaker.  As an example, the DFSDM chapter in the STM32L4 Reference is written by someone from India, whereas other sections of the same manual have obvious China-isms.
I think you are right, I suspect most of the Discovery/Nucleo Board schematics were drawn by Interns. I have been writing and reading schematics approaching half a century and I've never seen such hard to comprehend schematics as these.

Quote
2) English is the first language of vastly fewer engineers in the 21st century than it was in the 20th.

3) Of those who do speak/write English as a first language, English proficiency has steadily fallen.  All you have to do is compare the written output of college freshmen in the US over time.  The change is dramatic!  See also: engineering graduates whining about all of the "useless" liberal-arts courses they were required to take in school :palm:

4) Semi mfgs have convinced themselves that their crappy libraries (CubeMX etc) are actually the preferred way for engineers to use their products, therefore they probably believe the detailed documentation is less important.  Already in areas outside MCU-land, we see chips where the mfg requires use of their own driver software, while register-level documentation is only available under NDA or not at all.
They may have reasons for 4). For example I see a huge number of posts by users exclaiming that reading a 1000 page MCU technical reference  is in some way onerous. For me, reading a 1000 page tech document is akin to eating 1000 icecreams or going out on 1000 dates with Uma Thurman.

Doesn't anyone read the 1,225 page  novel War and Peace any more ?

Quote
Some of these are not bad things.  For example, the increasing dominance of India and China in the tech sector has certainly accelerated innovation, and I imagine that outstrips any "documentation tax" that we pay as a consequence.  But it should still be pointed out, and I wish mfgs paid more attention to the quality of their documentation.  Unfortunately, one of the consequences of #3 is that native speakers' reading comprehension has also decreased, and many of them are in management, so the decision makers are increasingly blind to the problem.

In the days when I had the outstanding Motorola Tech manuals, if one wanted a assembler, one paid LOT$ for one and I didn't have the money, so we made machine code development setups with seven segment displays and hex keypads. I did finally get a secondhand SWTP machine and a awesome 6800 assembler and my coding life was as smooth as silk for years.

My point being that we seem to have exchanged awesome documentation and no development tools for a ton of free development tools and 'adequate' documentation ?
Personally I'll take the latter anyday, and figure out the documentation myself as long as it meets a certain standard, and for me STM does meet that minimum requirement.

You make excellent sense to me.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4199
  • Country: us
Re: Atmel / Microchip ARM development
« Reply #39 on: May 30, 2019, 03:58:55 am »
Sometimes, you settle for "complete and accurate" datasheets and technical info (and "findable"!), even if they're not "good" (whatever  that means) in some explanatory fashion.

ST and Atmel are both prettty good.   Espressif: not so much (but getting better?)  FTDIChip: pretty awful (if you sell a processor, I really want to see the instruction architecture described.)
I used to have issues with ARM microcontroller Documentation - "Luminary Micro does not document the CM3 architecture, see the ARM Manuals."  "The Cortex M3 supports the ARM7TDMI instruction set except for ....  ARM7TDMI is like the ARM32 instruction set plus ....", but either it's gotten a lot better, or I've gotten better at finding the right manuals.
 

Offline L1L1

  • Regular Contributor
  • *
  • Posts: 52
  • Country: gr
Re: Atmel / Microchip ARM development
« Reply #40 on: May 30, 2019, 07:00:40 am »
ST and Atmel are both pretty good.

Sorry but, if you want to understand an MCU at register level, some Atmel (Microchip) datasheets are quite poor.

Just in the past few hours, I have banged my head against walls with their datasheets.

Consider this gem from the SAMD21 datasheet, regarding the I2C: "The core clock
(GCLK_SERCOMx_CORE) is required to clock the SERCOM while operating as a master, while the slow clock
(GCLK_SERCOM_SLOW) is required only for certain functions.
" This plainly suggests that if you are operating in slave mode, you don't need the "core clock", but their very own libraries don't follow that interpretation. In addition, they will not tell you what "certain functions" they are referring to with the "slow clock".

Or another one. The SAMD10 datasheet has a big table that clearly shows that some pins of the SAMD10C can map to SERCOM2. But in reality, the SAMD10C only has SERCOM0 and SERCOM1 as suggested in another table in the datasheet. 

Or a more recent datasheet. Take the SAMC21 CAN bus description and read it one evening if you have trouble finding sleep. Not only are the explanations confusing and bouncing back all over the place, but they completely omit some information altogether. The only way to find that information is to read the source code of the HAL library, which is like peeling a thick onion with knife  :)
 
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 8173
  • Country: fi
Re: Atmel / Microchip ARM development
« Reply #41 on: May 30, 2019, 03:28:42 pm »
Consider this gem from the SAMD21 datasheet, regarding the I2C: "The core clock
(GCLK_SERCOMx_CORE) is required to clock the SERCOM while operating as a master, while the slow clock
(GCLK_SERCOM_SLOW) is required only for certain functions.
" This plainly suggests that if you are operating in slave mode, you don't need the "core clock", but their very own libraries don't follow that interpretation. In addition, they will not tell you what "certain functions" they are referring to with the "slow clock".

Issues like this are very common on all manufacturers I guess. I see it a lot on STM32 reference manuals. The issue is, documenting such complex devices requires almost "autistic" skill of being exact, and using unambiguous words and sentences, but they can't do that, the documentation is too chatty, yet they "require" that you must follow it exactly.

When I read such documentation, I know I'm supposed to follow it literally, yet it's ambiguous, or worse, just plain wrong when taken literally. Often the specified configuration sequences, that can be many pages long for a trivial-to-use peripheral, contain meaningless extra steps to confuse you - like requiring you to set each configuration bit of a register as a separate operation, in a specific order, while in reality a simple write will do.

Instead of following the manual carefully and exactly, you are better off guessing the thoughts the silicon designer had. Often when the documentation shows behavior which is hard to design and use, in reality, the product works in a naturally expected way, but the documentation is just wrong.

Having a look at the official hardware abstraction libraries often helps; OTOH, sometimes they do unintended or excess operations as well. Often it's a day of headbanging on the reference manual, 100 lines of code in HAL, but actually requires just 5 lines when you figure out how all the pieces of the puzzle fit.

This is all understandable giving the complexity of the products, and the size of the product portfolio, and the pace they keep introducing new ones. We need to live with this. My biggest pet peeve actually is that the manufacturers appear to have decided about a principle of not updating documentation even when we are well past the printed era. For a complex MCU, there is 4000 pages of manual, with 400 pages of errata, most of which just documents how the devices actually work, while the reference manual describes what they had internally planned but didn't make. This makes absolutely zero sense; the end users have zero interest in the original design ideology, they want a description of the product they buy, and that should be in a single manual which is corrected directly whenever an issue is found.
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Atmel / Microchip ARM development
« Reply #42 on: May 30, 2019, 04:26:04 pm »
Consider this gem from the SAMD21 datasheet, regarding the I2C: "The core clock
(GCLK_SERCOMx_CORE) is required to clock the SERCOM while operating as a master, while the slow clock
(GCLK_SERCOM_SLOW) is required only for certain functions.
" This plainly suggests that if you are operating in slave mode, you don't need the "core clock", but their very own libraries don't follow that interpretation. In addition, they will not tell you what "certain functions" they are referring to with the "slow clock".

Issues like this are very common on all manufacturers I guess. I see it a lot on STM32 reference manuals. The issue is, documenting such complex devices requires almost "autistic" skill of being exact, and using unambiguous words and sentences, but they can't do that, the documentation is too chatty, yet they "require" that you must follow it exactly.

When I read such documentation, I know I'm supposed to follow it literally, yet it's ambiguous, or worse, just plain wrong when taken literally. Often the specified configuration sequences, that can be many pages long for a trivial-to-use peripheral, contain meaningless extra steps to confuse you - like requiring you to set each configuration bit of a register as a separate operation, in a specific order, while in reality a simple write will do.
<snip>

Well said!

This is one of the reasons I went to Forth with STM32xx, I can read the technical documentation, become confused with seemingly ambiguous descriptions and rather than work on a headache I can try live experiments in near real time to see what actually happens. It's funny how many times after I do this and see what happens that the documentation suddenly makes sense.

Or in one case, a program that required a bunch of register configs just would not run, so I made up a "assert" Word and soon discovered I was unable to change the contents of one particular register. Further investigation revealed that I'd missed the note that there was a "lock" register which had to be manipulated before I could change the problem register contents.

I do absolutely everything manually, the only 'libraries' I have are my own but I love this journey of hands on discovery with STM32, it's all bare metal for me.

 

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #43 on: May 31, 2019, 07:02:29 am »

This is one of the reasons I went to Forth with STM32xx,

What are the pros / cons of using Forth over regular C/C++.
And it would be helpful if your share you what kind of tools you use for development? Do you use Forth for production level projects or just for hobby / diy?
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Atmel / Microchip ARM development
« Reply #44 on: May 31, 2019, 07:53:23 am »

This is one of the reasons I went to Forth with STM32xx,

Quote
What are the pros / cons of using Forth over regular C/C++.
I'm a electronics technician and have used C since around 1997, but only for relatively simple industrial projects, such as level detectors which I designed, sold, and produced myself. In 1976 when I started doing embedded, it was all machine code or Assembler.

I've never used C++ and don't imagine I ever will.

Pros / cons of using Forth ? there isn't enough room on Dave's server for that kind of discussion!  :blah:

Forth was invented by Charles Moore in 1968 on an IBM 1130 to control telescopes in an observatory.
Forth is a program that once flashed into your MCU allows you to immediately write and test programs, read Registers, toggle GPIO pins, read the A-D and much, much more. No compiler is needed as it is built into Forth. All you need is a serial terminal to talk to the MCU in Forth. You could say Forth is like Basic, MicroPython, eLua, eLISP but it's much smaller and much faster than those other HLL interactive languages.

Forth for instance runs in 19KB on a STM32F0 (Cortex-M0). A realistic Flash size is 64KB, and what I normally use.

My Forth Documentation website:
https://mecrisp-stellaris-folkdoc.sourceforge.io/quickstart.html

Quote
And it would be helpful if your share you what kind of tools you use for development?


Because Forth is interactive it only requires a serial terminal for development, either on the workbench on a PC or connected to a prototype in the field with a android tablet.

I use my own tools basically a very fast terminal controlled remotely via a IDE editor much like you'd use to develop C code, except when you click on "make" your C code is compiled, and mine rapidly uploads the source to the MCU where it runs ... mostly ;-)

Color coded errors are displayed as they occur in the terminal part of my IDE as the source streams up to the MCU.

I make use of my own XML processor to auto-generate all the memory mapped Forth Words and register bitfields I need, a bit like the C header files. I use CMSIS-SVD for this purpose.
Here is a short video I made to demonstrate my IDE: https://www.youtube.com/watch?v=kDi-Nlz3-QA. It won't win any Oscars.

Quote
Do you use Forth for production level projects or just for hobby / diy?
It has only been at hobby level the last 5 years while I learnt Forth and STM32F0. I've been out of the embedded design field since 2001, however I've finished a working prototype Forth controller which is in testing at the moment and will definitely go into limited production soon.

At this point I have no real interest in doing any embedded development in C as Forth has proven itself capable of doing everything I need.
 
 
The following users thanked this post: ZeroResistance

Offline ZeroResistanceTopic starter

  • Frequent Contributor
  • **
  • Posts: 585
  • Country: gb
Re: Atmel / Microchip ARM development
« Reply #45 on: May 31, 2019, 10:47:33 am »
This is one of the reasons I went to Forth with STM32xx,
Good info and thanks for sharing!
Can Forth be used for production environments? what kind of learning curve is one looking at?
So do you use something like Color Forth from Charles Moore on the STM32?
How does your IDE compare to SwiftX?
 

Offline techman-001

  • Frequent Contributor
  • **
  • !
  • Posts: 748
  • Country: au
  • Electronics technician for the last 50 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Atmel / Microchip ARM development
« Reply #46 on: May 31, 2019, 11:21:03 am »
This is one of the reasons I went to Forth with STM32xx,
Quote
Good info and thanks for sharing!
You're welcome!

Quote
Can Forth be used for production environments?

It can be used for anything, one doesn't so much 'program in Forth' as 'solve domain specific problems with Forth'.

Quote
what kind of learning curve is one looking at?
I can't really say, I still regard myself as a Forth beginner after 5 years. If one has spent decades with C, Forth may seem the most ridiculous and hard to understand language ever invented.

Quote
So do you use something like Color Forth from Charles Moore on the STM32?
No, the colors on my system are just ANSI escape codes driven by the Forth compiler error system. I've looked at Color Forth articles and decided it's not for me.

Quote
How does your IDE compare to SwiftX?
I imagine it's nothing like SwiftX, which is made by Forth.inc who are a commercial organization. Forth.inc consists of Forth experts and ambassadors such as Dr Elizabeth Rather who have been with Forth for decades or from the very beginning.  My simple IDE wouldn't be in the same universe, let alone in the same league!

If you're considering Forth for serious commercial use, it would be a no brainer to consider Forth.inc's Swiftx.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf