Atmel / Microchip ARM development - Page 1
Forum section: electronics / general

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 27, 2019, 10:30:09 am
content: 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?

author: dietert1
author_rank: Super Contributor
timestamp: May 27, 2019, 12:22:42 pm
content: 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

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 27, 2019, 12:39:39 pm
content: Quote from: dietert1 on May 27, 2019, 12:22:42 pmI'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?

author: dietert1
author_rank: Super Contributor
timestamp: May 27, 2019, 02:38:16 pm
content: As far as i remember the free tools (AtmelStudio 7.0 at that time) were absolutely useful.Regards, Dieter

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 27, 2019, 03:13:01 pm
content: Quote from: dietert1 on May 27, 2019, 02:38:16 pmThansks 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.

author: mark03
author_rank: Frequent Contributor
timestamp: May 27, 2019, 04:26:36 pm
content: 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.

author: ogden
author_rank: Super Contributor
timestamp: May 27, 2019, 04:30:19 pm
content: Quote from: ZeroResistance on May 27, 2019, 03:13:01 pmFrom 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 twoMake 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

author: dietert1
author_rank: Super Contributor
timestamp: May 27, 2019, 04:54:31 pm
content: 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

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 27, 2019, 06:21:44 pm
content: Quote from: dietert1 on May 27, 2019, 04:54:31 pmIs 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.

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 27, 2019, 06:23:45 pm
content: Quote from: mark03 on May 27, 2019, 04:26:36 pmFor "quality of written documentation", It would be interesting to hear the views of the audience here.

author: dietert1
author_rank: Super Contributor
timestamp: May 27, 2019, 06:42:50 pm
content: 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, DieterPS: 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 27, 2019, 08:39:09 pm
content: Quote from: ZeroResistance on May 27, 2019, 06:23:45 pmI 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.

author: L1L1
author_rank: Regular Contributor
timestamp: May 28, 2019, 07:18:12 am
content: Quote from: ZeroResistance on May 27, 2019, 06:23:45 pmI use both SAM chips and STM32 chips, sometimes on the same board , 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.https://www.omzlo.com/articles/canzero

author: richardman
author_rank: Frequent Contributor
timestamp: May 28, 2019, 09:00:13 am
content: 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.

author: bhave
author_rank: Contributor
timestamp: May 28, 2019, 02:37:05 pm
content: 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.

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 28, 2019, 04:07:40 pm
content: 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?

author: ataradov
author_rank: Super Contributor
timestamp: May 28, 2019, 04:12:22 pm
content: 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.

author: bhave
author_rank: Contributor
timestamp: May 28, 2019, 06:31:19 pm
content: 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).

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 28, 2019, 06:42:32 pm
content: Quote from: ataradov on May 28, 2019, 04:12:22 pmOk, however user mark03 wrote thisIMO 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.

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 28, 2019, 06:47:51 pm
content: Quote from: bhave on May 28, 2019, 06:31:19 pmI had used STM32CubeMX a bit, never knew STM-Studio though is that ST's own IDE for STM32 development?

author: ataradov
author_rank: Super Contributor
timestamp: May 28, 2019, 06:48:56 pm
content: Quote from: ZeroResistance on May 28, 2019, 06:42:32 pmI 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.

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 28, 2019, 07:42:22 pm
content: Quote from: ataradov on May 28, 2019, 06:48:56 pmIs "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.

author: ataradov
author_rank: Super Contributor
timestamp: May 28, 2019, 08:15:49 pm
content: Quote from: ZeroResistance on May 28, 2019, 07:42:22 pmHAL 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.

author: ogden
author_rank: Super Contributor
timestamp: May 28, 2019, 08:28:35 pm
content: Quote from: ataradov on May 28, 2019, 08:15:49 pmHAL (Hardware Abstraction Layer) is far from ST-specific (name).

author: ataradov
author_rank: Super Contributor
timestamp: May 28, 2019, 09:00:08 pm
content: Quote from: ogden on May 28, 2019, 08:28:35 pmI'm aware of the general use. But in the context of this conversation HAL is the name for the set of libraries from ST.

author: techman-001
author_rank: Frequent Contributor
timestamp: May 28, 2019, 10:53:04 pm
content: Quote from: ZeroResistance on May 27, 2019, 06:23:45 pmWhen 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.

author: westfw
author_rank: Super Contributor
timestamp: May 29, 2019, 07:28:52 am
content: QuoteThat 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...

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 29, 2019, 10:30:28 am
content: 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?

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 29, 2019, 11:31:58 am
content: Quote from: westfw on May 29, 2019, 07:28:52 amAFAIK, 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.

author: asmi
author_rank: Super Contributor
timestamp: May 29, 2019, 11:33:49 am
content: I used ATSAM4N with great success and never had any issues (that were not of my own doing).

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 29, 2019, 11:35:39 am
content: Quote from: asmi on May 29, 2019, 11:33:49 amOk, that sound's good, can you talk a bit about what tools you use?

author: asmi
author_rank: Super Contributor
timestamp: May 29, 2019, 11:58:07 am
content: Quote from: ZeroResistance on May 29, 2019, 11:35:39 amI 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.

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 29, 2019, 12:19:00 pm
content: Quote from: asmi on May 29, 2019, 11:58:07 amOk and the chip was used in a production environment? Were you using Atmel std. peripheral libs or just register access?

author: asmi
author_rank: Super Contributor
timestamp: May 29, 2019, 12:34:51 pm
content: Quote from: ZeroResistance on May 29, 2019, 12:19:00 pmThere 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.

author: mark03
author_rank: Frequent Contributor
timestamp: May 29, 2019, 05:12:18 pm
content: 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  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.

author: asmi
author_rank: Super Contributor
timestamp: May 29, 2019, 06:52:14 pm
content: Quote from: mark03 on May 29, 2019, 05:12:18 pmNot 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.

author: mark03
author_rank: Frequent Contributor
timestamp: May 29, 2019, 07:42:30 pm
content: Quote from: techman-001 on May 28, 2019, 10:53:04 pmI 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.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 school4) 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.

author: nctnico
author_rank: Super Contributor
timestamp: May 29, 2019, 08:45:02 pm
content: 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.

author: techman-001
author_rank: Frequent Contributor
timestamp: May 30, 2019, 12:02:00 am
content: Quote from: mark03 on May 29, 2019, 07:42:30 pmIn 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.

author: westfw
author_rank: Super Contributor
timestamp: May 30, 2019, 03:58:55 am
content: 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.

author: L1L1
author_rank: Regular Contributor
timestamp: May 30, 2019, 07:00:40 am
content: Quote from: westfw on May 30, 2019, 03:58:55 amSorry 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

author: Siwastaja
author_rank: Super Contributor
timestamp: May 30, 2019, 03:28:42 pm
content: Quote from: L1L1 on May 30, 2019, 07:00:40 amIssues 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 thethoughtsthe 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 ofnot updating documentationeven 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 devicesactuallywork, 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 correcteddirectlywhenever an issue is found.

author: techman-001
author_rank: Frequent Contributor
timestamp: May 30, 2019, 04:26:04 pm
content: Quote from: Siwastaja on May 30, 2019, 03:28:42 pmWell 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 whatactually 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.

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 31, 2019, 07:02:29 am
content: Quote from: techman-001 on May 30, 2019, 04:26:04 pmWhat 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?

author: techman-001
author_rank: Frequent Contributor
timestamp: May 31, 2019, 07:53:23 am
content: Quote from: ZeroResistance on May 31, 2019, 07:02:29 am

author: ZeroResistance
author_rank: Frequent Contributor
timestamp: May 31, 2019, 10:47:33 am
content: Quote from: techman-001 on May 31, 2019, 07:53:23 amGood 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?

author: techman-001
author_rank: Frequent Contributor
timestamp: May 31, 2019, 11:21:03 am
content: Quote from: ZeroResistance on May 31, 2019, 10:47:33 am