Transfer learnings between vendors (ARM Microcontrollers) - Page 1
Forum section: electronics / general

author: plastygrove
author_rank: Contributor
timestamp: January 03, 2018, 12:02:36 pm
content: Hi all -I bought an STM32 nucleo board 2 years ago and barely did anything more than the Hello World. I decided to dig it out and learn more on how to use it.The way I see it, STM wants me to use STM32CubeMX and HAL as much as I can. However, I want to learn to use it the hard way by reading the reference manual and writing directly to the registers in C as explained in the reference manual.I checked out the datasheet of one of theAVRAtmel ARM microcontrollers and it seems like the register names are completely different.I haven't done a deep dive in the AVR sheet, but suppose I take my time and learn the STM32 implementation and say a few years later I want to switch toPICMicrochip orAVRAtmel ARM implementations, how difficult will it be to switch? Will it be as bad as learning from scratch? I'm guessing it won't be as bad as if I use HAL for all my projects, but hopefully it will be easier to switch. Ex: Write I2C/SPI/USB onAVR'sAtmel's ARM hardware if I'm comfortable doing it on STM's ARM hardware?Apologies if this is a dumb question.Thanks!

author: dgtl
author_rank: Regular Contributor
timestamp: January 03, 2018, 12:23:37 pm
content: In case of ARM, the Cortex-M microcontrollers have common processor core, debug interface, interrupt controller (NVIC) and systick timer. The rest of the peripherals are added by uc vendors. There are some exceptions (ie multiple vendors use USB OTG core licensed from Synopsys), but usually the peripherals are developed in-house and are unique to that vendor. So moving within the same manufacturers microcontrollers, the peripherals are similar, but otherwise not.In case of switching vendors, is is usually easier to keep the same architecture (ARM Cortex-M). The difference between ie PIC and AVR is greater than ST ARM and NXP ARM. You already know how how the CPU operates, how to debug it, the interrupt controller works etc. Especially expect a larger step when moving from 8-bit controllers with very simple peripherals to 32-bit controllers with much more complex peripherals, DMAs etc.About the complexity of moving between manufacturers... If you know how the UART works, then it is not too difficult to move to another vendors UART. The operational principle is still the same and the register interface to expect from it is usually quite similar. Things get more difficult if you intend to use DMA and other advanced functionality. To make porting easier, it is wise to write your software in layers. Then you can swap the closest to hardware layer (that encapsulates all register accesses) and the rest of the code does not need to be changed.Using STM32: in my opinion, the HAL is horrible piece of code. I'm using CubeMX only for pin-planning (it makes it easier to find combinations of input muxing so that all required peripherals can be connected up - in case of larger controllers same peripheral connection can be muxed to different pins on the case). After that, I go bare-metal and write my own hardware layer. In case of STM32, I've used already most of the peripherals, so it is just porting hardware layer code written for earlier projects. The HAL can be used as a reference, just look into it how ST wrote the registers.

author: plastygrove
author_rank: Contributor
timestamp: January 03, 2018, 12:48:38 pm
content: Quote from: blueskull on January 03, 2018, 12:06:18 pmAh sorry about that - corrected my post. Agreed on complexity, that's partly the reason I haven't done anything past 2 years and I consider myself fairly comfortable with both PIC and AVR 8-bit uCs. I find myself at a loss when something with HAL doesn't work. As I dig into the library to try and debug, it gets hard to understand without referring back to the manual.Quote from: dgtl on January 03, 2018, 12:23:37 pmComing from PICs and AVRs, I was not aware of this. So pretty much all the peripherals and how they interact with the core are built by the vendors themselves.Quote from: dgtl on January 03, 2018, 12:23:37 pmI haven't used HAL enough to form an opinion on it's merits and de-merits. But I did see a lot of folks posting unfavourable reviews about STM's software libraries, so I am inclined to believe them. Have you ever tried using Atmel or any other vendor's ARM chips?

author: martinayotte
author_rank: Regular Contributor
timestamp: January 03, 2018, 01:47:16 pm
content: You can take a look at the stm32duino framework ...

author: andersm
author_rank: Super Contributor
timestamp: January 03, 2018, 02:03:27 pm
content: If you stay away from vendor-provided IDEs, then your tools and knowledge of how to use them will transfer as well.

author: plastygrove
author_rank: Contributor
timestamp: January 03, 2018, 02:23:44 pm
content: Quote from: martinayotte on January 03, 2018, 01:47:16 pmThat's a good idea - I could maybe also check out their library to see their implementation of the peripherals.Quote from: andersm on January 03, 2018, 02:03:27 pmAgreed on that. I was just wondering if it would be as easy as swap out one register for another and change the set/reset bit positions. But looks like it won't be that easy.

author: mac.6
author_rank: Regular Contributor
timestamp: January 03, 2018, 03:47:31 pm
content: the ARM core themselves will be identical (as long as they are same familly of course). In fact most vendors stick to the CMSIS specification from arm, so everything accessing ARM core subsystem use it.Everything around the core will be different: different bus topology, different memories, different clock trees, different peripheral. So not portable between vendor.Doing everything bare metal will not help you porting your code between vendors, unless you make and maintain your own HAL. There is some opensource HAL projects but I never used them (like libopenCM3).Be sure to use at least vendor tools to generate pinmux/clock init files, these are tedious to do by hand.

author: NorthGuy
author_rank: Super Contributor
timestamp: January 03, 2018, 05:20:40 pm
content: It depends on how and what you learn.If you learn principles and develop problem solving skills, it'll stay with you forever and will be helpful with any future platform you want to use.If you memorize register names, it'll become obsolete and useless sooner or later and it won't transfer to other platforms.If you put things together in a frankensteiny kind of way, you'll learn nothing, so there's nothing to transfer.

author: nctnico
author_rank: Super Contributor
timestamp: January 03, 2018, 05:23:01 pm
content: Quote from: plastygrove on January 03, 2018, 12:02:36 pmNo it isn't. Basically you can't take anything you learn from one vendor to another because most of the knowledge you'll need is about the peripherals. Sometimes even microcontrollers from one vendor are completely different (the ones from ST for example which is why they offer the HAL). I can only recommend to try a few ARM controllers from different vendors and see what suits you. My personal preference are the ARM microcontroller from NXP (LPC series) because they keep the peripherals mostly the same across the entire range so code is extremely portable between devices. As a consequence it is very rare for me to use the same microcontroller in two projects.

author: Brutte
author_rank: Frequent Contributor
timestamp: January 03, 2018, 07:18:13 pm
content: Quote from: plastygrove on January 03, 2018, 02:23:44 pmSure, it is possible but that would limit the functionality of such library to the intersection (common part) of all uCs included. For example vendor A has uCs with IOs with configurable pullups only, some other vendor B sells uCs with both, pullups and pulldowns. How do you imagine a library that services both families?

author: plastygrove
author_rank: Contributor
timestamp: January 04, 2018, 12:17:40 am
content: Quote from: mac.6 on January 03, 2018, 03:47:31 pmMakes sense, I have only skimmed through the clock config section and there's so much to read and understand.Quote from: NorthGuy on January 03, 2018, 05:20:40 pmAgreed on the principles. I guess if I go by the reference manual, I will eventually memorize register names.Quote from: nctnico on January 03, 2018, 05:23:01 pmWow seriously? I only have the stm32f411 and I was hoping it would at least be slightly similar between the different M-series microcontrollers. Thanks for the suggestion on the LPC series, I'll check it out.Quote from: Brutte on January 03, 2018, 07:18:13 pmThat's a fair point. I figured that with the competition going around now in this line, feature parity is very essential between companies if they want to compete. I figured if I stayed at the same price range (say ~8-10$/chip) and the same series (say M4 Cortex), memory and speed considerations aside, they are likely to have similar features.