Author Topic: Transfer learnings between vendors (ARM Microcontrollers)  (Read 2368 times)

0 Members and 1 Guest are viewing this topic.

Offline plastygroveTopic starter

  • Contributor
  • Posts: 39
Transfer learnings between vendors (ARM Microcontrollers)
« on: January 03, 2018, 12:02:36 pm »
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 the AVR Atmel 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 to PIC Microchip or AVR Atmel 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 on AVR's Atmel's ARM hardware if I'm comfortable doing it on STM's ARM hardware?

Apologies if this is a dumb question.

Thanks!
« Last Edit: January 03, 2018, 12:23:35 pm by plastygrove »
 

Offline dgtl

  • Regular Contributor
  • *
  • Posts: 183
  • Country: ee
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #1 on: January 03, 2018, 12:23:37 pm »
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.
 

Offline plastygroveTopic starter

  • Contributor
  • Posts: 39
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #2 on: January 03, 2018, 12:48:38 pm »
AVR is the name of a CPU architecture. There is no such things as AVR ARM. I guess you meant Atmel SAM ARM chips.

I would not recommend to do the hard way -- ARM chips are too complicated, way more than 8-bitters. Your code will be hard to maintain unless you are paid to develop the driver, otherwise, just use the provided drivers.

Ah 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 :(.


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.

Coming 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.

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.
I 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?
 

Offline martinayotte

  • Regular Contributor
  • *
  • Posts: 64
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #3 on: January 03, 2018, 01:47:16 pm »
You can take a look at the stm32duino framework ...
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #4 on: January 03, 2018, 02:03:27 pm »
If you stay away from vendor-provided IDEs, then your tools and knowledge of how to use them will transfer as well.
 
The following users thanked this post: Siwastaja

Offline plastygroveTopic starter

  • Contributor
  • Posts: 39
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #5 on: January 03, 2018, 02:23:44 pm »
You can take a look at the stm32duino framework ...

That's a good idea - I could maybe also check out their library to see their implementation of the peripherals.

If you stay away from vendor-provided IDEs, then your tools and knowledge of how to use them will transfer as well.

Agreed 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.
 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 225
  • Country: fr
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #6 on: January 03, 2018, 03:47:31 pm »
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.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3137
  • Country: ca
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #7 on: January 03, 2018, 05:20:40 pm »
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.

 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #8 on: January 03, 2018, 05:23:01 pm »
Apologies if this is a dumb question.
No 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.
« Last Edit: January 03, 2018, 08:36:50 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline Brutte

  • Frequent Contributor
  • **
  • Posts: 614
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #9 on: January 03, 2018, 07:18:13 pm »
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.
Sure, 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?

 
 

Offline plastygroveTopic starter

  • Contributor
  • Posts: 39
Re: Transfer learnings between vendors (ARM Microcontrollers)
« Reply #10 on: January 04, 2018, 12:17:40 am »
Be sure to use at least vendor tools to generate pinmux/clock init files, these are tedious to do by hand.

Makes sense, I have only skimmed through the clock config section and there's so much to read and understand.

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.

Agreed on the principles. I guess if I go by the reference manual, I will eventually memorize register names :).

No 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.

Wow 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.

Sure, 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?

That'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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf