Yet another "Getting Started With ARM" post...

[ignilux]

Hi, all-

I've been programming bare metal C on 8-bit ATmega, ATtiny, and PIC MCUs for the past 5 years or so, and have become very comfortable with the workflow, i.e. efficient scanning of the datasheet, set a handful of registers for a given peripheral, and write the program. Despite my enduring love for the 8-bit-ers, it's become increasingly apparent that I need to familiarize myself with the ARM Cortex-M family. However, every time I try I find the whole process quite discouraging.

It seems that what makes the architecture great (many manufacturers to choose from, tons of different peripherals available, etc) also makes it easy to get lost. For example, I picked up an NXP LPC54114 dev board a while back. There are diehard endorsements across the web of different software from Keil, IAR, Eclipse, stfu use emacs, etc. Well, NXP wants you to install their IDE, and their SDK. Fine, I'll do that. The SDK has a fairly hefty API, with functions that do a lot of register setting, peripheral configuration, etc. It also includes a number of CMSIS libraries, which initially looked like a great concept but it soon becomes clear that it isn't nearly as portable as it should be. The board itself includes a "Link 2" debug probe, but many will tell you to pick up a Black Magic Probe or J-Link EDU.

So now we have multiple compilers, multiple C library implementations,  many IDEs, three overlapping ways to write the code (SDK, CMSIS, register manipulation), and three ways to debug and program. I love having options, but I'm so used to having a cut-and-dry toolset that I'm rather overwhelmed. The worst part is that everywhere you look for help, all you find is tutorials about the SDK, mbed, FreeRTOS, proprietary vendor tools, etc. That, or a generic tutorial that gets WAY too entrenched in the ISA without anything practical. Contrast that with the 8-bit micros, where almost all of the information out there pertains to bitwise operations on registers in C.

Enough complaining. My question is this:
Is there any toolchain that will provide a workflow similar to that in MPLAB or Atmel Studio 7? I don't want 10k of program memory eaten up by vendor bloatware, but on the other hand I quite enjoy some level of abstraction in terms of SFR macros, etc. After all, I'd just use assembly if I was anti-abstraction. I'm not looking for an "Arduino solution", but I don't want to have to write my own reset vector with inline assembly. I hope this makes sense, and thanks for your time.

[ataradov]

You never have to write in assembly with ARM (Cortex-M specifically). Even reset handler is written in C and is typically just a few trivial lines of code.

If you just want the basic stuff out of the box, then use GCC and header files and startup code from the CMSIS package for the device. This is vendor and device independent part.

If you want peripheral libraries, then you would have to use vendor libraries, so it depends on the MCU you select.

All other tolls (programmer) are doing the same stuff, so it does not really matter what you pick as long as there is software for it for your OS.

[ignilux]

Thanks for your reply. Would the vendor libraries come from the SDK? I'm thinking of using either Eclipse or VS Code as an IDE, since they are both readily adaptable to other parts, families, languages, etc.

[ataradov]

That depends on the vendor. Some have just a straightforward download of a ZIP file, others have dedicated configuration tools that you can't avoid if you want to use their code.

[ignilux]

That seems to be the case. Looks like NXP has the former. Good thing, since one primary motivation here is avoiding proprietary tools and processes, such that I don't have to relearn another quirky IDE and debugger every time I move to a new ARM vendor.

[Doctorandus_P]

I am in the same boat as you.
I started using the AVR controllers about 10 years from before "arduino" existed and never understood why anyone would put up with such a piece of *&^%$#@! Especially the Java garbage they call an "ide".

Then I was looking for an "upgrade". Those 320x240 pixel TFT's from China are fun, but the AVR's do not have enough upmph to drive them comfortably. With the cheap ARM controllers (about same price as AVR) you get so much more for free:

* Much more MHz. (Thumb instructions seem to give Cortex-M about the same performance/MHz as AVR's. 32bit is not 4x faster then 8 bit, but 72MHz sure is a lot faster)
* Multiple ISR levels.
* Fractional baudrate generators.
* Motor timers for generating 3-phase PWM.
* Quadrature counters in hardware for the timers.
* More RAM / Flash.

I'm also a sort of cheapskate and I bought a bunch of "Blue Pills" and separate STM32F103C8T6 chips for even less money. ( I think about EUR1.2 each). With this combination I have both chips to put on self designed PCB's and simple development boards for quick prototypes, breadboards and one-off projects.
This chip is one of the oldest and apparently has some hardware bugs which makes me apprehensive to really dive into it's internals.

"Black Magic Probe" apparently also works with this chip, but I just bought a few "ST-Link V2" programmers for about EUR3 each. For those kind of prices I really do not care if I have to buy a separate programmer for each uC family. STM32 also has some other advantages. For example the DPS5005 power supplies use an STM32F100 (and "openDPS" is available as example software), so that is a good start for custom power supply firmware. For about EUR 20 you can also buy cheap PLC's form China (Search for FX2N). These boards have a pretty decent power supply (common mode filter, big elco's SMPS) and robust I/O (Optocouplers, Relay or Transistor outputs) These can be repurposed as excellent development boards for the STM32 family. You can also get TFT Lcd's with an STM32 on the back of them, so again, just put custom firmware in existing hardware.

The "Blue Pill" boards are also popular for hobbyists. Long before "arduino" i've written my own libraries for HD44780 I2C, UART, etc, and this takes a lot of time. I do not have much love for the whole "arduino" framework. It was never designed to be "useful" in complex applications. It also was not even intended as an educational tool. There is quite some usable code in the arduino framework itself though. Therefore it does seem a reasonable path to fork the arduino thing, remove all auto instantiated objects and the horrible "digitalWrite()". Then you can just link in the libraries you actually need. Also, by reading through code written by others (especially if it's well written) you learn some tricks you had not thought of yourself. I think that extracting useful libraries from "stm32duino" (stm32 fork for arduino) is less work than writing libraries from scratch. Same may be true for mbed. Mbed seems to want to fill up the whole uC with libraries and not leave any code for applications. Such fameworks are also written with not much thought in code efficiency. They are just stacked on top of lower level libraries such as CMSIS. It looks like a horrible mes to try to understand it all.

Because the "Blue Pill" is popular it's easy to find example projects for it. I currently have a CNC machine which runs on a STM32 port of GRBL. I've also tested an USB to 3 UART bridge with an example project from github for the STM32. My linux box sees all 3 ports, and loop back works if I put a wire between Tx of one port and connect it to Rx of the same or another port.

I very much enjoyed the STM32 tutorials from "PandaFruits"
http://pandafruits.com/stm32_primer/stm32_primer_hardware.php
It handles the very bare bones low level stuff to get going with C, such as writing your own linker scripts. It's a very concise and well written tutorial. It's just a few short pages with loads of info. If you're interested in low-level stuff and don't know much about it (yet) then it is worth reading it even if your main interest is in the LPC uC's.

Then there are also some other frameworks.
LibOpenCM3 may be interesting, but I have not looked into it yet.

Then there are also some projects that use C++ Templates. This stuff is a bit over my head unfortunately. It seems wonderful if you can use well written libraries based on templates, but they have a bad name for debugability. Some projects based on C++ Templates are:
* Kvasir
* bmptk
* XPCC

Here a video from the young Davey Jones:


Some other links I found worth saving:
http://www.stm32duino.com/viewtopic.php?f=42&t=4460&p=51937#p51937
https://jeelabs.org/projects/jeeh/
https://jeelabs.org/2018/getting-started-bp/

[uer166]

You never have to write in assembly with ARM (Cortex-M specifically). Even reset handler is written in C and is typically just a few trivial lines of code.

See, I keep reading this here, and yet in my experience (ST in this case), everything is still crt0 or whatever it's called. I did have to edit the reset handler assembly to copy some code to TCM.

[ataradov]

See, I keep reading this here, and yet in my experience (ST in this case), everything is still crt0 or whatever it's called. I did have to edit the reset handler assembly to copy some code to TCM.

Well, they are free to do so, but you don't have to. Never and for anything.

IAR and Keil also have their startup code in assembly. This is some legacy stuff and their insecurities. Nothing more.

All Atmel/Microchip code is in pure C and works fine, including with TCM.

[uer166]

Sure, but that statement is misleading at best. If one use Keil or IAR or STM32Cube, the startup code is all assembly. Of course you don't have to use it, but nobody will write their own reset handlers from scratch, especially not new people.

Your statement may be true specifically for Atmel/Microchip, bit that's a cherry-pick IMO.

[ataradov]

The statement was about the core. ARM spent a lot of effort to make sure their core is fully programmable with C.

If you are using someone's code, you are bound to deal with BS like that.

There is nothing hard about startup code, even new people can figure it out if they look at actually good examples.

The goal of frameworks writers is to lock you into their ecosystem, so the less portable the code is, the better it is for them. You need to recognize that pattern and avoid it when possible.

[Doctorandus_P]

The goal of frameworks writers is to lock you into their ecosystem, so the less portable the code is, the better it is for them. You need to recognize that pattern and avoid it when possible.

I've also bumped into this with ARM, and found it quite annoying.
I know I'm just a hobby programmer.
The first uC program I wrote in C was for the AT90S2313 somewhere in the late '90s or early 2000. Back then it was not very common to have a C compiler and lot's of people were still assembly only. Back then with GCC in the AVR you just started with int main( void){ }. There was no need to fiddle with startup code or linker scripts. It took me years to even realize these existed.

With those companies that try to force you into some IDE they indeed try to hide any decent info. You even have to search for the compiler they use, although gcc-arm-none-eabi has a big chance. Instead of just #defines for register names for the STM32 you get several different base adresses and offsets just to make stuff more complicated.

With my (limited) level of knowledge it's hard to judge and verify if the linker scripts and startup code that I found for my particular processor works the GCC compiler version I have installed.

With AVR-GCC you just tell the compiler for which variant of the AVR family you want to compile and it handles all the details for startup code and Linker scripts.

Do any of the vendors of ARM chips do something similar?
Or are they all trying to lure you into their underground dungeons with their mystery   wizards and "enhanced" ide's?

[ataradov]

Well, the linker scripts are necessary even in AVR world if you are doing bootloaders, or things more complicated than just simple code. You can avoid then for a long time, but sooner or later you will have to deal with them.

It is a really BAD idea to have the compiler know about your chip. The compiler only needs to know the architecture of the core. It does not need to know about the peripherals. One reason - your version of the registers would tied to the compiler. For AVR it was not a huge problem, since the number of registers was very limited and all the errors were more or less debugged. There are plenty of errors in ARM header files.

Linker scripts are not hard, and you will do yourself a great favor by spending a day and figuring them out. Again, don't look at universal swiss-army-knife scripts. Look at minimal reasonable versions. My typical standard linker script is ~50 lines and it covers almost all use cases I have. And once you write it, you just move it from project to project, from device to device.

[ignilux]

The goal of frameworks writers is to lock you into their ecosystem, so the less portable the code is, the better it is for them. You need to recognize that pattern and avoid it when possible.

Exactly what I'm trying to avoid, and why I'm interested in using a vanilla Eclipse / GCC / OpenOCD (maybe J-Link in the future) toolchain. Continuing with the reset handling example, it's not that I don't understand what's happening or that I can't figure it out. Instead, it just feels a little unnecessarily laborious to have to tell a microcontroller to turn it's clock on.

I very much enjoyed the STM32 tutorials from "PandaFruits"

I'll check that out, thanks. I won't be using STM32 since I'm allergic to shit datasheets, but good info nonetheless 

Then there are also some projects that use C++ Templates

Be careful when using the STL or other dynamic allocation in an embedded context.

Linker scripts are not hard, and you will do yourself a great favor by spending a day and figuring them out.

Any examples of good, concise scripts?

[ataradov]

Any examples of good, concise scripts?

Here is my typical script https://github.com/ataradov/mcu-starter-projects/tree/master/samd21/linker

And the whole project is an example of a simple, but complete ARM project.

In the startup code (https://github.com/ataradov/mcu-starter-projects/blob/master/samd21/startup_samd21.c) reset handler is only 10 lines of C code. Not sure why anyone would want to touch assembly at that point.

[westfw]

It also includes a number of CMSIS libraries, which initially looked like a great concept but it soon becomes clear that it isn't nearly as portable as it should be.

CMSIS is (or used to be - they keep changing things) divided into several parts:CMSIS-CORE defines common function definitions and stuff for dealing with the ARM parts of chips - SysTick. NVIC, Core registers, etc.  This prevents different vendors from having different names for the same thing (cli(), disable_interrupts(), etc.)  It should be very portable, and is IMO a good thing.Another part (CMSIS-SVD?) is (more or less) defining a standard style for peripheral definitions.  Arrays of Structures mapped onto memory addresses and a somewhat standardized naming scheme.  Also a reasonable thing, although vendors seem to have found many ways to bend things (Atmel's ".reg" and ".bits" on every field, for instance, is something I haven't seen elsewhere.)  Also reasonable and portable (alas, manufacturers don't seem to be overly consistent across different FAMILIES of chip, so that's annoying (SAM3 "Pio" vs SAMD "PortGroup", for instance.)CMSIS-DAP is standardized access to debugger.  Good, but not necessarily optimal?CMSIS-DSP is standardized access to DSP capabilities of (for example) the CM4...Where you get into problems is with things like CMSIS-DRIVER and CMSIS-RTOS, where ARM starts pushing particular models of peripherals and operating system primitives that don't (IMO) match very well with vendor capabilities or many people's idea of how things should work.  (the USART driver standard doesn't include a "getc()", for example.  Sized buffer and calllback; eww...)  I think most vendors have ignored the CMSIS-DRIVER spec in favor of their own peripheral libraries.

So now we have multiple compilers, multiple C library implementations,  many IDEs, three overlapping ways to write the code (SDK, CMSIS, register manipulation), and three ways to debug and program.

To be fair, the only reason that you didn't notice similar problems with AVR and PIC was that you settled on both chips and IDE that you liked and stuck with them.  (that, and the datasheets were a lot shorter.)  You didn't go through the multiple C compilers for either one, each with (generally) their own IDEs (or not.)  Studio4, Studio7, MPLAB, MPLABX, IAR, Imagecraft, Mikro, CCS, HiTech, SDCC, Arduino ...  Or the Xmega/Mega0/Tiny0/Tiny1 dramatic departures from traditional AVRs, or ASF versions changes, or ...

With the previous AVR/PIC experience, why did you switch vendors?  In theory, you could keep using MPLABX or Studio...

[techman-001]

<snip>
 Another part (CMSIS-SVD?) is (more or less) defining a standard style for peripheral definitions.  Arrays of Structures mapped onto memory addresses and a somewhat standardized naming scheme.  Also a reasonable thing, although vendors seem to have found many ways to bend things (Atmel's ".reg" and ".bits" on every field, for instance, is something I haven't seen elsewhere.)
<snip>

The Cortex Microcontroller Software Interface Standard - System View Description format gets mentioned a lot here but in my observation most people don't really know what it is.

What CMSIS-SVD is:
- CMSIS-SVD files are developed and maintained by silicon vendors, not ARM.
- Formalizes the description of the system contained in Arm Cortex-M processor-based microcontrollers, in particular, the memory mapped registers of peripherals.
- The detail contained in system view descriptions is comparable to the data in device reference manuals.
- The information ranges from high level functional descriptions of a peripheral all the way down to the definition and purpose of an individual bit field in a memory mapped register.
- Simply a XML file waiting to be processed by XSLT to provide any transform you care to design.

What CMSIS-SVD isn't:
- Arrays of Structures mapped onto memory addresses. The C compile vendors do that when they transform the CMSIS-SVD XML file to a include file to suit their needs.

CMSIS-SVD allows any programming language to obtain customized memory mappings via XSLT.
- I use it to transform FORTH memory mapped registers and bitfields
- RUST people use it for the same purpose but customized to suit them. They have even written tools to convert Texas Instruments device specs to CMSIS-SVD. 
- LUA people would use it
-eLISP folks would also use it

To my technicians mind, CMSIS-SVD is another level above limited proprietary vendor created tools as used by Microchip and Atmel etc.

With CMSIS-SVD I can generate the exact stats for a microprocessor :-

Code: [Select]

MCU Peripherals Registers Register Bitfields
MSP430G2553 17 113 503
STM32F0xx 37 413 3044
STM32F303x 38 549 3857
STM32F103xx 53 722 4833
GD32F103 ? ? ? ( I need a svd )
STM32F103C8 33 466 3503
GD32VF103Cx 46 1074 7713
TM4C129x 65 2137 7347
STM32F7x7 93 2093 17051

[ignilux]

And the whole project is an example of a simple, but complete ARM project.

A quick scan through that repo clarifies quite a few things about the different files and how they relate, so thanks for that. I've been seeing extensive use of __attribute__ all over the place, so looks like I have some reading to do with respect to GCC.

CMSIS-CORE defines common function definitions... and is IMO a good thing.

I agree, that does look to be a useful and necessary function. Browsing through the CMSIS API reference makes it look like CORE is one of the most mature and complete parts of CMSIS, which makes sense. I'll be digging in to CMSIS-DSP at some point. That was one of my primary motivations for switching to ARM.

With respect to your comments about the Atmel / Microchip tools, those are certainly fair points. The dramatic departure from traditional AVR that you mentioned all started to happen around the time that Microchip acquired Atmel (though I'm aware that many of those changes were pre-merger), and is a big reason that I've moved away from Microchip. Atmel made great AVR chips, and Microchip makes great PICs. The forced combination of the two that resulted in things like AVR registers that we all knew and loved suddenly having ".bits" stuck on the end. Very little documentation for that too, since Microchip just assumes everyone knows how PIC does this.

When I was first picking out an ARM development board, I had no idea which vendor to choose. I settled on NXP by reading a handful of datasheets from different manufacturers. If there were glaring omissions (e.g. SiLabs likes to NOT tell you the value of the S/H capacitance in its ADCs), I moved on. NXP seemed to have complete, coherent documentation, so I picked them.

To my technicians mind, CMSIS-SVD is another level above limited proprietary vendor created tools

That actually sounds really useful! So are you at the mercy of the vendors for the availability and quality of the SVD files? I'm somewhat familiar with XSLT for things like transforming XML to HTML, but I had never heard it being used in this manner.

[ataradov]

I've been seeing extensive use of __attribute__ all over the place, so looks like I have some reading to do with respect to GCC.

There are two places where it is used:
1. __attribute__ ((used, section(".vectors"))). This is used to place "vectors" array into its own section and also mark it as "used", so that optimizing compiler does not remove it.

This is necessary so that liker could place this variable first in the memory, since that is the only hard requirement for placing anything. In the liker script this is done in this part:

Code: [Select]

  .text : ALIGN(4)
  {
    FILL(0xff)
    KEEP(*(.vectors))
    *(.text*)
    *(.rodata)
    *(.rodata.*)

2. #define DUMMY __attribute__ ((weak, alias ("irq_handler_dummy")))

This is not 100% necessary. It is just a nice thing to have. This way any interrupt handler that is not explicitly defined will be aliased to irq_handler_dummy. You can just define all of them to be the same function and avoid using this attribute. Although all modern compiler support weak functions, but the exact syntax may differ.

So are you at the mercy of the vendors for the availability and quality of the SVD files?

Yes, but given that literally every tool uses them now, it would be impossible for vendors to not publish reasonable SVD files. If they don't, they essentially exclude themselves from being used in IAR and Keil ecosystems at least. And that's a significant part of the market, so no one in their right mind would do that.

[techman-001]

To my technicians mind, CMSIS-SVD is another level above limited proprietary vendor created tools

That actually sounds really useful! So are you at the mercy of the vendors for the availability and quality of the SVD files? I'm somewhat familiar with XSLT for things like transforming XML to HTML, but I had never heard it being used in this manner.

You are at the mercy of the vendors for everything as usual, but that hasn't been a problem so far. CMSIS-SVD is a game changer. Even ATMEL use it for their Cortex-M MCU's.

For instance Texas Instruments don't use SVD's as they have their own system, but the Rust people convert the Ti format to CMSIS-SVD which only required a few small changes in my XSLT stylefile to transform them into the format I use with Forth. This enables me to generate everything I need for the MSP430 and the

This is Forth centric but shows what I do with SVD's.
https://mecrisp-stellaris-folkdoc.sourceforge.io/register-generator.html#svd2forth

I'm a keen STMicro user and a SVD for all of their MCU's are freely available from Keil as a 'pack' plus there are projects on Github containing lists of SVD's. Keil seem to have SVD's for every manufafturer of Cortex-M silicon available for free on their site.

I have generated transforms for NXP processors with the SVD's they make, so no problems there either.

[wilfred]

I recommend this Youtube channel which has a good quality presentation of ARM on the Texas Instrument Stellaris (later renamed TIVA C) launchpad devboards.

https://www.youtube.com/channel/UCMGXFEew8I6gzjg3tWen4Gw

The resource is free and launchpads are pretty cheap. As an educational introduction to the concepts it is something I found accessible and helpful.

You can move to another device later if necessary and the skills learned will help in that.

The first few videos don't need a devboard and checking those out will give a good guide to what is on offer for free.

If someone knows of something similar then please post.

[ataradov]

Even ATMEL use it for their Cortex-M MCU's.

Atmel was among the first companies to embrace lower levels of CMSIS standard. SVD files were supplied for all Cortex-M devices.

Atmel is the only company that shipped CMSIS-DAP compliant debuggers on the board.

[T3sl4co1l]

Then I was looking for an "upgrade". Those 320x240 pixel TFT's from China are fun, but the AVR's do not have enough upmph to drive them comfortably. With the cheap ARM controllers (about same price as AVR) you get so much more for free:

That's marginal at best yeah, especially if it's SPI.  (And if it's parallel, you have to bit-bang everything, which uses up a ton of GPIOs and doesn't usually optimize well by the compiler.)

* Much more MHz. (Thumb instructions seem to give Cortex-M about the same performance/MHz as AVR's. 32bit is not 4x faster then 8 bit, but 72MHz sure is a lot faster)
* Multiple ISR levels.
* Fractional baudrate generators.
* Motor timers for generating 3-phase PWM.
* Quadrature counters in hardware for the timers.
* More RAM / Flash.

FYI, the XMEGA (and probably some of the newer MEGAs?) does all of these things, save for clock, which is only a modest 32MHz; or maybe some are a bit faster now.

The performance per buck is pretty pitiful compared to ARMs, though.

There's a top-of-the-line XMEGA with a parallel memory bus interface, actually, which would do very well for memory mapped LCDs, extra SRAM (or DRAM or SDRAM) and other things, but it's also like $10 and... just, get the STM32F103, y'know, or something STM32F4 for industrial interfaces plus enough CPU to run Quake?


I'm.....eventually, going to move to STM32 something or other as a primary platform.  I've been happily using Code::Blocks with avr-gcc, which wasn't much trouble to get working, and is a fuckoff huge sight more compact than anyone's "studio" bullshit...  I expect, or hope, that that will be as simple as loading up whatever flavor of arm-gcc, and learning the libraries and interfaces.  It'll be annoying, confusing bullshit, it always is when learning a new toolchain; but eventually I'll do it.  Afraid I don't have any actual experience to help with yet.

Tim

[Dubbie]

ataradov, thanks very much for posting your example here.
So much people talk a lot about what they do and why it is the only/best way. But you can't beat actually reading some code.
It's nice to see how other people do things.

[westfw]

    What CMSIS-SVD isn't:
    - Arrays of Structures mapped onto memory addresses.

Ah... It looks like this has moved into CMSIS-Core:
https://arm-software.github.io/CMSIS_5/Core/html/device_h_pg.html
https://www.keil.com/pack/doc/cmsis/Core/html/group__peripheral__gr.html
It used to have its own section (CMSIS-DPAL, according to the old tutorials I've dug up.)

Atmel was among the first companies to embrace lower levels of CMSIS standard. SVD files were supplied for all Cortex-M devices.

Atmel actually has something very similar for their AVRs, in the form of their ".ATDF" files.

With respect to your comments about the Atmel / Microchip tools, those are certainly fair points. The dramatic departure from traditional AVR that you mentioned all started to happen around the time that Microchip acquired Atmel

Nah.  It started with the XMega chips ~2010; the acquisition wasn't until 2016.  (I don't see the .bits stuff, but that's when they started with structure-based peripheral registers.)

The forced combination of the two that resulted in things like AVR registers that we all knew and loved suddenly having ".bits" stuck on the end.

It seems to be going the other way.  The SAM "packs" for MPLABX (version 3.x, while the ones with Studio are 2.X) get rid of the .bits and .reg stuff.I don't see any instances of ".bits / .reg" in the PIC packs.I'm not sure whether to be happy that Microchip seems to be heading toward "commonality" of PIC/ARM, or appalled at the magnitude of the changes.  (you can always get the older PACK versions, at least theoretically.)

[ataradov]

Ah... It looks like this has moved into CMSIS-Core:

Was not this always the case? SVD is just the XML part. Resulting headers files were always different.

Atmel actually has something very similar for their AVRs, in the form of their ".ATDF" files.

There are ATDF files for ARM devices too. They are actually used by many (all?) Atmel tools as a primary source of information. Both are automatically generated from primary sources, so contain exactly the same information. ATDF contains a bit more, like information on memory partitioning, which SVD does not define.

I'm not sure whether to be happy that Microchip seems to be heading toward "commonality" of PIC/ARM, or appalled at the magnitude of the changes.  (you can always get the older PACK versions, at least theoretically.)

I definitely don't like it, but I'm not too worried. I can always generate my header files from the SVD files

[james_s]

I've been in this boat as well. I started using 8 bit AVRs a little over 20 years ago, for the longest time I pooh-poohed the Arduino thing but finally I decided to give it a go due to the vast number of libraries and extreme ease of making all sorts of random peripherals work. Then the device support continued to grow and now has become extremely impressive, however it's still hobbled by software that is absolute garbage. Still, I can pick up a nifty serial OLED, sensors, whatever and have it up and running in 5 minutes so I put up with the painfully awful IDE.

Several times I've decided to give ARM a try, bought a cheap dev board to play with, started mucking around trying to figure out what software to use and get that set up and each time I've sunk several hours into it then finally given up and pulled out the Arduino or the old bare AVR with Bascom and quickly built whatever I was trying to build. I really want to like the ARM platform and use it but the complexity and hassle ends up being more than I want to deal with for the simple projects I typically build. 

[ataradov]

You can't really compare AVR and ARM this way. AVRs have one supplier, and they mostly feel the same (excluding Xmegas) and have the same tools.

ARM has many vendors, so if your idea is to use vendor libraries, then you will have to learn many times. And then vendors constantly obsolete and rewrite their libraries, so you will have to deal with that too.

But if you approach this from just taking the device and doing your own programming, once you have the basic environment set up, all the devices are essentially the same. So one time effort pays off many times. It does take some time to figure it out, but all things considered it is not that hard.

For me personally at this point it is much more of a hassle to use AVR than ARM from a vendor I have never seen before.

[kamtar]

Don't try to think too much into the future and don't overcomplicate it for yourself.

Pick a vendor
 - if you are undecided go for ST as they are widely used in hobby projects and you can find a lot of tutorials but it doesn't matter that much, remember that majority of those ARM MCUs are really similar and stuff are done and designed in a similar way.

- Pick a dev. board and stick with official vendor IDE + libraries. ST is using eclipse + gcc, NXP/freescale is using eclipse + gcc. You can always make those eclipse IDEs work with any other arm vendor MCUs later.

 - different SDKs and libraries aren't really an issue. It's just C API when you understand how typical ARM periphs. work it will make sense and it's going to take you just few hours to learn new API. Also don't forget that some libraries are really lacking and you will have to in the end write some of your own implementations.

GCC has great support for ARM so there aren't really that many reasons to use anything different as your compiler unless you want to pay up some solid business money for fancy features.

[james_s]

I'll try it again at some point and see if I can get somewhere with it this time. I don't really need the power of an ARM in anything I've made so far but it does seem to be the direction everything is going.

It would be nice if someone could build an Arduino compatible IDE that isn't garbage. Something that works with most of the existing community libraries and code but not done in Java and with some real debugging capabilities. Maybe there's too much inherent baggage to make that work but it is enticing given the vast array of supported hardware, it's so incredibly easy to slap together something that just works with minimal effort, except when it doesn't work it can be a real pain.

[T3sl4co1l]

It appears there is a Code::Blocks Arduino variant, if you're curious?

Tim

[tmadness]

I've been in this boat as well. I started using 8 bit AVRs a little over 20 years ago, for the longest time I pooh-poohed the Arduino thing but finally I decided to give it a go due to the vast number of libraries and extreme ease of making all sorts of random peripherals work. Then the device support continued to grow and now has become extremely impressive, however it's still hobbled by software that is absolute garbage. Still, I can pick up a nifty serial OLED, sensors, whatever and have it up and running in 5 minutes so I put up with the painfully awful IDE.

Several times I've decided to give ARM a try, bought a cheap dev board to play with, started mucking around trying to figure out what software to use and get that set up and each time I've sunk several hours into it then finally given up and pulled out the Arduino or the old bare AVR with Bascom and quickly built whatever I was trying to build. I really want to like the ARM platform and use it but the complexity and hassle ends up being more than I want to deal with for the simple projects I typically build.

I recently had the same epiphany. I'm primarily a electrical engineer who uses micros as a tool in solving my problem. The Arduino core framework is just beautiful representation of open source collaboration. Now, not all cores are made equal, but there exist some really high quality cores and libraries. PJRC's Teensy is a amazing example, yes, its not the most efficient code but by good lord does it work for 90% of the use cases, its amazingly documented (dare i say better than most vendor libraries), and the 3.5 3.6 and 4.1 are some beafy mofos. At the end of the day my work gets done faster, simpler, and i can go back in and optimize the shit out the existing libraries if I need to. The only thing I miss is debugging support on the hardware level in the teensy family (not a problem if you use the chip and roll your own board).

BTW I use VSCode and Platform IO for development. its just leagues ahead of the Arduino IDE and a lot more faster than the eclipse based vendor IDEs that exist out there.

[nigelwright7557]

I have always been  a PIC man having been a PIC consultant for 13 years.
However I recently ventured into M7.
I found the data sheet extremely vague and unhelpful.
I also really struggled getting info on the programming port.
I found one and used that on my pcb.
I also managed to get a basic circuit for the M7 for my pcb.
The pcb came back and I built up a bare system with just an LED.
I used MPLAB X and Harmony to get some basic software.
The M7 programmed once and then I just had a flashing LED but couldnt program it again.
It turned out I had NRST on pin 6 of Microchip Snap programmer and it should be on pin 1.
So sorted that but M7 still wouldnt program.
I asked Microchip and they said it had bricked and needed a high on ERASE and a reset pulse.
That unbricked it but I couldnt flash the LED.
So into debug mode and single stepped.
It got through processor clock setup ok but crashed out when setting up PIO.
So on to Microchip again and they asked for circuit and my code.
That was about a week ago and still no reply.

I design USB scopes (mid speed) and wanted to know if the M7 could clock out data from a A2D fast enough to make the £10 it cost worthwhile.
Luckily I have other projects to be getting on with but Microchip are slow with help.

[westfw]

However I recently ventured into M7.

Into the deep end, eh?  Which chip?

I found the data sheet extremely vague and unhelpful.

ARM Chip datasheets almost exclusively have "refer to the ARM manual for documentation of the CPU and ARM peripherals."  That's somewhat understandable, since the ARM manual is another 800+ pages (and, alas, not well written for anyone new to the architecture.)  But annoying.
Some datasheets are just for the particular chip.  See the "chip-family reference manual" for details.  In the worst case, separate PDF for each peripheral.  :-(

I also really struggled getting info on the programming port.

There generally is no programming port.   There's a debug port that can be used for programming, and maybe a bootloader.Programming via the debug port is frequently done by loading sort-of-bootloader code into RAM and executing it.

So on to Microchip again and they asked for circuit and my code.
That was about a week ago and still no reply.

Vendors tend to suck at both beginner questions and very technical questions.  You'd be better off finding a user forum like EEVBLOG, Arduino, or AVRFreaks.  (I suspect you'd be more likely to get answers on Arduino or AVRFreaks Forums, even though neither one is supposed to be about Cortex-M7  :-) )

[ignilux]

So I've spent the past few days getting re-acquainted with doing things as generically ARM as possible, using CMSIS-CORE and -SVD as needed. After the revelation that many manufacturers use the same format of collecting peripheral registers in structs, and that accessing them is done with the standard abbreviated struct pointer dereferencing (SYSCON->SOME_REG_IN_SYSCON[0].SOME_MEMBER |= (1 << n); ), everything has become much more clear. The hardest part for me intellectually was separating the bells and whistles of the SDK from the standardized format of CMSIS. The (NXP, at least) SDK is handy, since it abstracts writing to registers by replacing those operations with functions, but it is much less portable. The NXP user manual does a nice job of giving a simple list of steps to configure the peripheral at the beginning of each chapter, with notes about the order in which things must be done. So to those who were in the same boat as myself, get familiar with CMSIS, and things will become clearer. I'll also second the recommendation for the Embedded Systems Programming Course from Miro Samek.

For a long time I, too, turned my nose up at Arduino. At some point I realized that it is simply a tool, and it can be used for the forces of good or the forces of evil. If you need some one-time utility hardware like an EEPROM programmer, you will get there faster and easier with an Arduino than by any other route. Sure, the code size might be huge, and it might run slower than it should, but you'll spend an hour or two instead of a weekend. It's no different than any other development board, in that it lets you get things done faster and easier, but you'd be foolish to use it in a finished product. Of course, I recently designed a bit of hardware for a finished product that includes a Teensy 4.0, but it's there for the fact that I won't be writing the firmware, and the person who will has limited experience writing C/C++ for embedded systems. As with the entirety of engineering, everything is a trade-off, and our job is to pick the best compromise for the constraints given.

[Siwastaja]

Hi, all-

I've been programming bare metal C on 8-bit ATmega, ATtiny, and PIC MCUs for the past 5 years or so, and have become very comfortable with the workflow, i.e. efficient scanning of the datasheet, set a handful of registers for a given peripheral, and write the program. Despite my enduring love for the 8-bit-ers, it's become increasingly apparent that I need to familiarize myself with the ARM Cortex-M family. However, every time I try I find the whole process quite discouraging.

Spot on.

I simply declined to do anything else than what I had been doing with Atmel or PIC MCUs, and that was a great success. You describe the process which works for AVRs and PICs - and guess what, it works for ARM Cortex-M microcontrollers equally well.

Of course, having more features, the documents are longer. Instead of a 400-page "datasheet", you might have a 200-page datasheet just for physical/electrical properties, plus a 2000-page "reference manual" which explains all the peripherals, plus a few hundred pages of CPU core documentation (rarely needed).

Being more complex, there are more traps. OTOH, you have likely experienced such traps already, this isn't going to change the game.

So the process is the same, and all your prior experience helps you.

It seems that what makes the architecture great (many manufacturers to choose from, tons of different peripherals available, etc) also makes it easy to get lost. For example, I picked up an NXP LPC54114 dev board a while back. There are diehard endorsements across the web of different software from Keil, IAR, Eclipse, stfu use emacs, etc. Well, NXP wants you to install their IDE, and their SDK. Fine, I'll do that. The SDK has a fairly hefty API, with functions that do a lot of register setting, peripheral configuration, etc. It also includes a number of CMSIS libraries, which initially looked like a great concept but it soon becomes clear that it isn't nearly as portable as it should be. The board itself includes a "Link 2" debug probe, but many will tell you to pick up a Black Magic Probe or J-Link EDU.

Note there is absolutely nothing in the architecture that dictates this. The ARM microcontroller architecture and typical MCU peripheral implementations actually tend to be quite sane and understandable, and easily worked with in C, from scratch, just reading the documentation.

I just looked for the .h files that define the register names in the reference manual, and that's it. Some manufacturers may require you to install some stupid software package just to extract the files. This sucks; alternatively, just google for the header files and you'll find copies hanging around the 'net.

Any way that programs a chip works. UART bootloader, or the integrated debug interface of the eval board you have.

So now we have multiple compilers,

Use GCC.

multiple C library implementations,

Nothing wrong with newlib, I think? Don't think about it too much, you'll find out if you need something else.

Get everything here:
https://launchpad.net/gcc-arm-embedded

many IDEs

No need to use any IDE. If you want to, then you obviously know what you want to use.

I currently use gedit to write code. Programmer's notepad, Notepad++ and so on come to mind on Windows.

three overlapping ways to write the code (SDK, CMSIS, register manipulation),

Do it like you did with AVR or PIC. Consider using libraries only with complex things (USB, TCP/IP...)

and three ways to debug and program.

I started with UART bootloader on STM32 and still mostly use it. No special hardware needed, an improvement over AVR.

Equivalent of "printf debugging", i.e., "turn on LED debugging" works fine and is scalable for complex/demanding projects where debug interfaces and IDE debug tools do not suffice anymore.

Yes, without a "debugger" you can't easily single-step through all code to see if it does what you think you wanted to do, but that's not a viable way to write code anyway, despite people doing that.

The worst part is that everywhere you look for help, all you find is tutorials about the SDK, mbed, FreeRTOS, proprietary vendor tools, etc.

It took some time for me to realize that all these tutorials exist because all such systems are so freaking difficult, hence the need for tutorials!

To do what you did with AVR/PIC, you don't need too many tutorials - a few code samples, like those given by ataradov, suffice. Basically, just follow the advice of ataradov.

Is there any toolchain that will provide a workflow similar to that in MPLAB or Atmel Studio 7? I don't want 10k of program memory eaten up by vendor bloatware, but on the other hand I quite enjoy some level of abstraction in terms of SFR macros, etc. After all, I'd just use assembly if I was anti-abstraction. I'm not looking for an "Arduino solution", but I don't want to have to write my own reset vector with inline assembly. I hope this makes sense, and thanks for your time.

Yes, I understand where you are coming from: for the standard AVR workflow, avr-gcc somehow autogenerated the startup code (or picked a correct file automatically), and was able to map the data and code to the correct memory addresses - i.e., choose a correct linker script -, all this happened behind my back, didn't have to think about it at all.

arm-gcc-none-eabi does not do this. So I need to supply startup code and a linker script. But, in the end, this won't ruin your day. Copy-paste the startup code and linker script, modify when needed - problem solved in a very pragmatic way. You still have the benefit of being able to look at them if you need to understand what happens under the hood - not to mention being able to modify them when you later find out you have special requirements and want to use the fancy features higher-end MCUs offer, such as core-coupled fast RAMs. The best part, what you learn here, is all applicable on all ARM MCUs, and not only ARM, it's basic computer science that has been relevant for decades, and will be relevant for decades to come. This is complete opposite to time wasted going through tutorials and learning how to install the trend IDE and trend framework of the year, only to learn the new trends the next year (or the next device you use).

[SiliconWizard]

I found the data sheet extremely vague and unhelpful.

ARM Chip datasheets almost exclusively have "refer to the ARM manual for documentation of the CPU and ARM peripherals."  That's somewhat understandable, since the ARM manual is another 800+ pages (and, alas, not well written for anyone new to the architecture.)  But annoying.
Some datasheets are just for the particular chip.  See the "chip-family reference manual" for details.  In the worst case, separate PDF for each peripheral.  :-(

That's the beauty and the pain of dealing with ARM-based MCUs. They can leverage the whole ARM ecosystem. Drawback for the user, on some level, is that you'll be expected to get enough knowledge about the ARM architecture and ecosystem itself. Individual MCU vendors are not going to bother duplicating existing and general information about ARM cores and related tools. The benefit is that once you've built enough such knowledge, you'll be able to reuse it for other ARM-based MCUs. So that's an investment.

Many users not willing to bother with the details will use the IDEs, code generators, libraries provided by each vendor and stick to that (even when that's a bit painful). Those willing to get further and more "baremetal" will have quite a few things to learn. Certainly more than with your basic, proprietary MCU such as pre-PIC32 PIC MCUs. And a significant chunk of this information will be found outside of the vendor's documentation.

[techman-001]

<snip>
 If you need some one-time utility hardware like an EEPROM programmer, you will get there faster and easier with an Arduino than by any other route.
<snip>

I have built many eprom programmers since 1974 including a 48 unit 2732 production programmer (1985), a GPL general purpose MCU and ROM burner (1999) and I believe that Forth on ARM is the easiest method by far for such a project.

One MCU, some transistors (for the EPROM high voltage switching) and I could have a unit up and running in a couple of hours, no libraries, no java IDE, no Arduino.

[james_s]

I have built many eprom programmers since 1974 including a 48 unit 2732 production programmer (1985), a GPL general purpose MCU and ROM burner (1999) and I believe that Forth on ARM is the easiest method by far for such a project.

One MCU, some transistors (for the EPROM high voltage switching) and I could have a unit up and running in a couple of hours, no libraries, no java IDE, no Arduino.

That's great, good for you, but how many hobbyists do you think could do that without extensive handholding? Forth? I played with it a few times on an old Sun workstation, seemed like an interesting language but I don't know anyone personally who has ever really used it. Obviously you are not the target audience of the Arduino platform. The advantage is the user community, libraries and documentation, it makes it easy for people who are NOT seasoned software developers to jump in and make something work. As I already mentioned, I've been using AVRs bare metal for over 20 years, obviously I know how to do it, but even I was eventually won over by the absolutely ridiculous ease of lashing up something that works with Arduino. It's like building something out of Legos or Erector set, it's not a slick production ready product but if you just need quick and easy it's fantastic. I remember spending many hours trying to make sense of Chinese datasheets for various widgets and figure out how to talk to them, now I just load up a library and off it goes, I can have it doing something in minutes.

I don't want to turn this thread into yet another Arduino vs everything else debate though.

[nigelwright7557]

However I recently ventured into M7.

Into the deep end, eh?  Which chip?

I found the data sheet extremely vague and unhelpful.

ARM Chip datasheets almost exclusively have "refer to the ARM manual for documentation of the CPU and ARM peripherals."  That's somewhat understandable, since the ARM manual is another 800+ pages (and, alas, not well written for anyone new to the architecture.)  But annoying.
Some datasheets are just for the particular chip.  See the "chip-family reference manual" for details.  In the worst case, separate PDF for each peripheral.  :-(

I also really struggled getting info on the programming port.

There generally is no programming port.   There's a debug port that can be used for programming, and maybe a bootloader.Programming via the debug port is frequently done by loading sort-of-bootloader code into RAM and executing it.

So on to Microchip again and they asked for circuit and my code.
That was about a week ago and still no reply.

Vendors tend to suck at both beginner questions and very technical questions.  You'd be better off finding a user forum like EEVBLOG, Arduino, or AVRFreaks.  (I suspect you'd be more likely to get answers on Arduino or AVRFreaks Forums, even though neither one is supposed to be about Cortex-M7  :-) )

I decided on the ATSAME70J21B. When  I originally sent my circuit to Microchip when I was having problems they said the A2D doesnt work on that model.
It says it does in the datasheet but Microchip said I should have read the errata sheet to find out all the bugs.

Microchip do manage to throw a spanner in works sometimes. I upgraded a project from pic32mx220 to pic32mx 274 using same pins but a faster PIC.
I built up the pcb and it wasnt working right. I found in the end Microchip had changed a GPIO pin to input only on that device. I couldnt find that information in the datasheet and also Harmony shows the pin as GPIO input or output ! So I was upset I had to add a wire to my pcb to another free pin.

[ataradov]

What specific errata says that ADC does not work on SAM E70? There are a couple erratas, but nothing that would render it unusable. A lot of people use it and it generally works.

[nigelwright7557]

That's great, good for you, but how many hobbyists do you think could do that without extensive handholding? Forth? I played with it a few times on an old Sun workstation, seemed like an interesting language but I don't know anyone personally who has ever really used it. Obviously you are not the target audience of the Arduino platform. The advantage is the user community, libraries and documentation, it makes it easy for people who are NOT seasoned software developers to jump in and make something work. As I already mentioned, I've been using AVRs bare metal for over 20 years, obviously I know how to do it, but even I was eventually won over by the absolutely ridiculous ease of lashing up something that works with Arduino. It's like building something out of Legos or Erector set, it's not a slick production ready product but if you just need quick and easy it's fantastic. I remember spending many hours trying to make sense of Chinese datasheets for various widgets and figure out how to talk to them, now I just load up a library and off it goes, I can have it doing something in minutes.

I don't want to turn this thread into yet another Arduino vs everything else debate though.

I have worked on PIC micro's since about 1985.
Pretty horrible beasts but cheap and plentiful.
I much preferred the Z80.
Some of the early ones were very basic.
As time has gone on the complexity has gone through the roof.
Some of the newer PIC32 series almost need a degree in chip design to understand them.
Early years A2D was fairly simple to setup and use.
Some of the new ones needs lots of register setting up with 32 bits of data.
Microchip Harmony does help quite a bit but you still need detailed understanding of the hardware.
What was once just a quick datasheet read is now a datasheet and many supporting pdf's to understand the hardware details.

[nigelwright7557]

What specific errata says that ADC does not work on SAM E70? There are a couple erratas, but nothing that would render it unusable. A lot of people use it and it generally works.

Apparently USB doesnt work on 64 pin devices. At least according to Microchip and the errata sheet.
I have changed my design to the 100 pin ATSAME70N19.

[ataradov]

Yes, USB HS does not work on 64-pin parts, since there is no VBG pin, which sets the bias current.

[techman-001]

I have built many eprom programmers since 1974 including a 48 unit 2732 production programmer (1985), a GPL general purpose MCU and ROM burner (1999) and I believe that Forth on ARM is the easiest method by far for such a project.

One MCU, some transistors (for the EPROM high voltage switching) and I could have a unit up and running in a couple of hours, no libraries, no java IDE, no Arduino.

That's great, good for you, but how many hobbyists do you think could do that without extensive handholding? Forth? I played with it a few times on an old Sun workstation, seemed like an interesting language but I don't know anyone personally who has ever really used it. Obviously you are not the target audience of the Arduino platform. The advantage is the user community, libraries and documentation, it makes it easy for people who are NOT seasoned software developers to jump in and make something work. As I already mentioned, I've been using AVRs bare metal for over 20 years, obviously I know how to do it, but even I was eventually won over by the absolutely ridiculous ease of lashing up something that works with Arduino. It's like building something out of Legos or Erector set, it's not a slick production ready product but if you just need quick and easy it's fantastic. I remember spending many hours trying to make sense of Chinese datasheets for various widgets and figure out how to talk to them, now I just load up a library and off it goes, I can have it doing something in minutes.

I don't want to turn this thread into yet another Arduino vs everything else debate though.

I believe that hobbyists are capable of anything, I don't see them as needing extensive hand-holding, I believe they can learn all by themselves.

I do however believe that any hobbyist who wants to learn real embedded needs to get far away from Arduino asap, and even if they're not interested in Forth, at least use GCC, libcm3 ( or whatever) and a editor.

[james_s]

I believe that hobbyists are capable of anything, I don't see them as needing extensive hand-holding, I believe they can learn all by themselves.

I do however believe that any hobbyist who wants to learn real embedded needs to get far away from Arduino asap, and even if they're not interested in Forth, at least use GCC, libcm3 ( or whatever) and a editor.

Good for you, but you have an extremely elitist attitude that comes off as very condescending. The advice to use Forth may have been sound in 1987 but I wouldn't put it on my resume today unless I was looking in a very specific niche. I suppose if they want to be a "real" software developer they should get a VAX and learn Cobol?

A hobbyist should use whatever works for them and allows them to build the stuff they want to build and have fun because that's what hobbies are all about. If they want to do "real embedded" they should learn C, it's the language used for embedded micros in every hardware company I've worked at. The hardware platform used for learning it is all but irrelevant, the language is fairly universal. The Arduino platform isn't targeted at professional embedded software developers, it's targeted at hobbyists, casual users and hardware types for whom coding is a means to an end. It's clearly not targeted at you but you shouldn't worry yourself over what others use. It has lowered the barrier of entry and enabled millions of people to get into microcontrollers with a minimal investment. Ultimately it's just another tool in my toolbox, it has its place.

[westfw]

Nothing wrong with newlib, I think?

Well, those used to avr-libc are likely to find it pretty bloated, even in its "nano" form.  And I think newlib is the famous example of "printf() pulls in malloc()" (I mean, it does, but I'm not sure it's the only version that does so...)


Also, lib-gcc for CM0 doesn't have optimized floating point code, so it uses the gcc default "C" version, which is big and slow.

[snarkysparky]

I always want to do bare metal setups.  So far have used SAMD parts.  How do vendors compare regarding data sheet quality ( mostly complete and understandable )  and access to code examples for bare metal setup. 

[nctnico]

Nothing wrong with newlib, I think?

Well, those used to avr-libc are likely to find it pretty bloated, even in its "nano" form.  And I think newlib is the famous example of "printf() pulls in malloc()" (I mean, it does, but I'm not sure it's the only version that does so...)

Newlib is quite bloated indeed. I'm still using the small C library which comes with the MSP430 GCC. I 'ported' (changed the make files) that to ARM about a decade ago.

[Siwastaja]

Bloatness of newlib does not prevent getting started with it if it happens to come as the default with the toolset you can easily download.

Replace it once you hit the limits.

I have never liked using printf() on MCUs. It's quite expensive, and the smaller versions tend to be crippled in some way or another, in which case I want to use simpler functions (itoa et al) which perform as expected, not in some limited way instead. So give me a full-featured, standard-compliant printf I can rely on, when you have the resources for it, otherwise no printf() at all, thanks.

If you are coming from AVR/PIC, especially if you worked with the smaller chips, it's very likely you are not used to using printf() anyway, for the obvious reasons.

I kind of locked to a home-brew class of itoa-like and some other string functions because I wrote them in a pinch due to an extremely stupid problem with newlib which I did not have time to debug properly, then just got so used to them that I still use them. I made them return a pointer to the created zero-termination character, so that strings can be easily appended, a feature not present in standard itoa class of functions.

[snarkysparky]

for debugging i wrote a routing that takes a 16 bit argument and outputs 16 pulses on a digital IO pin as fast as pin toggling allows.

A binary one is two write cycles and a binary zero is one write cycle.  I separate the nibbles by a few off pulses to enable reading the word off the scope.   zero bits are padded with an extra low cycle to keep all the rising edges in the same place.

runs in tens of us on a good processor and doesn't significantly impact other running code.

Only call it when some abnormal value is present usually.

[nigelwright7557]

for debugging i wrote a routing that takes a 16 bit argument and outputs 16 pulses on a digital IO pin as fast as pin toggling allows.

A binary one is two write cycles and a binary zero is one write cycle.  I separate the nibbles by a few off pulses to enable reading the word off the scope.   zero bits are padded with an extra low cycle to keep all the rising edges in the same place.

runs in tens of us on a good processor and doesn't significantly impact other running code.

Only call it when some abnormal value is present usually.

In my early years in programming  I had a little TTL to RS232 level changer so I could output ASCII to an old RS232 monitor we had.
It was great for displaying values of registers/variables as the program went along.
These days we have decent debuggers.

[nctnico]

Bloatness of newlib does not prevent getting started with it if it happens to come as the default with the toolset you can easily download.

Replace it once you hit the limits.

I have never liked using printf() on MCUs. It's quite expensive, and the smaller versions tend to be crippled in some way or another, in which case I want to use simpler functions (itoa et al) which perform as expected, not in some limited way instead. So give me a full-featured, standard-compliant printf I can rely on, when you have the resources for it, otherwise no printf() at all, thanks.

If you are coming from AVR/PIC, especially if you worked with the smaller chips, it's very likely you are not used to using printf() anyway, for the obvious reasons.

I kind of locked to a home-brew class of itoa-like and some other string functions because I wrote them in a pinch due to an extremely stupid problem with newlib which I did not have time to debug properly, then just got so used to them that I still use them. I made them return a pointer to the created zero-termination character, so that strings can be easily appended, a feature not present in standard itoa class of functions.

But in the end you likely pull in vprintf one way or another and self invented printing routines are always clunky (been there, done that). A much better solution is to have a vprintf which you can tailor to your needs. Remember C has its root in tiny systems so you can have minimal vprintf implementations without breaking any compatibility.

[techman-001]

I always want to do bare metal setups.  So far have used SAMD parts.  How do vendors compare regarding data sheet quality ( mostly complete and understandable )  and access to code examples for bare metal setup.

I find the STMicro parts PDF's highly readable. They usually have C examples for every peripheral at the end of the MCU technical manuals.

'Bare metal' ? to me a 'bare metal' example would be in Assembly Language, but few use it in their examples now.

[ETITsynthesizer]

if you use VS code it will just be like using emacs or vim. everything that is not IAR or Kiel is using GCC GNU arm 7 toolchain. code is not portable unless you are going from one gcc gnu arm toolchain to another one. almost all silicon vendors use eclipse + gcc gnu arm toolchain. the code is as portable as the libraries. take the libs with you when you move back to emacs. the reset startup sequence was actually really easy to understand. remember that as the reset sequence progresses further, it will diverge from a ARM standard to a proprietary silicon vendor procedure outlined in the datasheet or reference manual provided by the silicon vendor. all arm chips have a reset pin. all arm chips set the PC to 0 on reset. stack pointer is loaded from the PC. more stuff loaded from 0x00000004. after that there is no standard. ST uses hard pins pulled up or pulled down. other vendors do everything in software. some vendors have non-volatile registers like fuses on AVR. the 0x00000000 address is actually an alias but this is an accepted practice. you actually can't program flash at 0x00000000 because that is not where flash starts. 0x00000000 is an alias for the first word in flash. the processor has hard coded into the silicon the alias resolution. it can not be changed.

[AkiTaiyo]

I first moved from AVR/PIC to ARM on Atmels SAM series.  This was at the time before they had a well established ASF, or the popularity brought about by the Arduinos.  I initially found it to be a big learning curve.  I chose Atmel because I liked their datasheets for AtMega.  Most ARM Coretex-M chips seemed to have massively more complicated clock systems and workings, all that needed careful setting up before you even get to the point of flashing LEDs, it made the jump feel quite daunting. 
After reading though the datasheets several times, sometimes drawing little sketches of how things like oscillators are clock generators are attached to clock generators, and peripherals helped, especially when the datasheets didn't provide clear diagrams.  Still, after a day or so I was up and running with a bear metal LED flasher, with the MCU running at its full speed..
I then moved onto STM32, and found the datasheets to be written in a way that I couldn't get on with.  Coming from the way Atmel (used to) write their datasheets, the ST datasheets seemed unfamiliar and difficult to navigate in comparison.  The architecture of the STM32 is also a lot more complicated, and versatile.  Lots more options for clock routing etc, which at the time made it seem like such a heavy learning process, especially from AtMega/PIC type devices.  It didn’t help that at the time the free tools for STM32 were in a really mixed state.

More recently I’ve been doing a lot of development with Silicon Labs EFM32 micros.  Whilst they aren’t a popular choice, and by no means the cheapest.  I’ve found their datasheets, IDE and kits very easy to get going with.  They have a much more straightforward clock generation system and the IDE, and usually most systems are well illustrated or described in the datasheet.
When I get a new placement student to work with, I always start them getting something going with the EFM32.  The ones who haven’t had ARM experience say that it was surprisingly easy, and the ones that have (Usually STM32) say that it was much easier to get going with.

As a hobbyist starting out with ARM, pick a product family that looks like it’s designed to get going fast with.  Does the vendor provide free tools?  Is there a lot of community support?  Are those community channels often filled with people struggling to get simple things working? 
Often (but not always) the development environments provided by the IC vendor contain everything you should need to get something running, and are usually pre-configured to create suitable templates for linker files etc that will get the micro up and running as fast as possible.
As far as vendor provided IDEs I’ve used, these is my personal ranking of the major ones:
Simplicity Studio (for EFM32)
CubeIDE (for STM32) - This and TrueSudio have some damn fine debugging features.
TrueStudio (for STM32)
AVR studio (For Atmel AVR/SAM)
And a special mention for MPLabX, which is so bad it should be avoided at all costs..

I’ve attached a couple of guides I started writing for a local community makers group to get started with Atmel SAM micros.. They are by no means comprehensive, the first is mainly about some advantages of going ARM, and the second gets a simple blinky done in bare metal on a SAMD21.  The blinky guide was designed not to just give you the code but tell you how to use the datasheet to find the required information.  I haven’t really had the time to continue them further, or go back to them to make them better, so expect them to be full of mistakes and out of date information! 

[Bassman59]

More recently I’ve been doing a lot of development with Silicon Labs EFM32 micros.  Whilst they aren’t a popular choice, and by no means the cheapest.  I’ve found their datasheets, IDE and kits very easy to get going with.  They have a much more straightforward clock generation system and the IDE, and usually most systems are well illustrated or described in the datasheet.
When I get a new placement student to work with, I always start them getting something going with the EFM32.  The ones who haven’t had ARM experience say that it was surprisingly easy, and the ones that have (Usually STM32) say that it was much easier to get going with.

All of the above: YES.

[nigelwright7557]

I finally got to the bottom of my M7 needing a erase cycle before i could program it each time.
I had used one of the programming lines as an output and this messed with the programmer.
So I moved the pin function elsewhere and that fixed the problem.
I am used to PIC's where if you use series resistors you can dual function programming pins.

Finally got USB working on my atsame70n19.
Passes data from A2D through M7 through USB to PC fine.
Sadly  I couldnt get my PWM scope calibration pin working.
Again waiting for Microchip to tell me why it doesnt work.
Must be my fault as there is no mention of PWM problems in the errata sheet.
In the meantime using a programmable clock pin for A2D clock signal.

[HB9EVI]

I have never liked using printf() on MCUs. It's quite expensive, and the smaller versions tend to be crippled in some way or another, in which case I want to use simpler functions (itoa et al) which perform as expected, not in some limited way instead. So give me a full-featured, standard-compliant printf I can rely on, when you have the resources for it, otherwise no printf() at all, thanks.

If you are coming from AVR/PIC, especially if you worked with the smaller chips, it's very likely you are not used to using printf() anyway, for the obvious reasons.

I kind of locked to a home-brew class of itoa-like and some other string functions because I wrote them in a pinch due to an extremely stupid problem with newlib which I did not have time to debug properly, then just got so used to them that I still use them. I made them return a pointer to the created zero-termination character, so that strings can be easily appended, a feature not present in standard itoa class of functions.

+1

I do never use printf() et.al. functions; coming from AVR it was never a good idea to use them, so I followed that after switching to ARM. imho it's also still a good idea avoiding float/double at least on smaller ARMs, so representing fp numbers in integers, what isn't a big thing if you got already used to it on AVRs.

also I'd recomment to stay bare metal on ARM if you're familiar with it; personally I absolutely don't like all those Arduino oder STMs HAL kinda things; so why discussing about how bloaty newlib is, if on the other hand real bloated code like Arduino & co is being used.

[SiliconWizard]

Speaking of printf(), I dunno if anyone has significant experience with RISC-V development so far? When using printf() in C code for a baremetal environment (similar to an MCU), RV32IM target, it just adds 50 KBytes+ of extra code. That sounds nuts.

[ataradov]

Full printf without float support on ARM (Cortex-M0+) is 20 Kbytes, with soft float about 30-40 Kbyte.

RV code density should not be 2x worse than ARM, so I assume that is the library with the float support, in which case it is normal.

[SiliconWizard]

Full printf without float support on ARM (Cortex-M0+) is 20 Kbytes, with soft float about 30-40 Kbyte.

RV code density should not be 2x worse than ARM, so I assume that is the library with the float support, in which case it is normal.

Yes. That was without code compression. With RV32IMC I guess it should take much less.
Anyway, for people not knowing, just be aware of the cost of printf() in embedded code.
On a small MCU with limited flash (such as a Cortex-M0 with 32KB flash, which is not uncommon if you're looking for a "small" MCU), it will eat up most of your code space.

[ataradov]

Oh, yeah, RV32IMC would basically match CM0+. That's why I have a smaller implementation that I use when space is critical (https://github.com/ataradov/embedded/tree/master/snprintf).

I just did the tests. On CM0+ full code including supporting functions inserted by the compiler (like __aeabi_uldivmod, __udivmoddi4, __clzsi2) takes 1648 bytes. The code of my function itself (supporting functions may be already present in your code for other things anyway) is 1112 bytes.

The same code on RV32IMC is 3588 and 1272 accordingly. The library code is big because my libraries appear to be compiler in non-C mode, and I have no idea if it is possible to change that without rebuilding the compiler.

So the code size difference on the same code for RV32IMC and ARMv6m is about 14%. This matches my previous experiments too, on different types of code, I had up to 20% difference.

[nigelwright7557]

I have designed a few USB PC oscilloscopes using PIC micros.
Started off with PIC18 then later PIC32MX.
One problem was when upgrading to a faster PIC32 was a pin changing from i/o to input only which messed up a pcb.
Other than that no problems.

Just out of interest I decided to have a go with the ATSAME70. Bought one from RS Components as itr was advertised as doing USB. Great stuff.
After struggling with poor documentation from Microchip I eventually got one up and running.
Sadly couldnt get the USB to work.
Got in touch with Microchip who said 64 pin version doesnt do USB (USB pin missing) but the 100 pin one does !
SO new pcb and new chip.
I tried to get PWM working for a scope calibrate output. It just refused to work.
In the meantime I tried using programmable clock which stopped working above 12 MHz !
I got in touch with Microchip who despite me emailing a couple of times never came back to me.
I got in touch with ATMEL who just chased me back to Microchip.

So gave up and went back to PIC's.

[tmadness]

I had a similar story with stm32s H7., Coming from the f4 The peripherals on H7 are very complicated. I decided to cut my losses and come back to the H7 when I had the time to get to the part better.

[Siwastaja]

Out of curiosity, which peripherals on STM32H7 you find complex?

My observation is, simple stuff is still quite simple even in complex microcontrollers. Examples being UART, basic timers, PWM generation, ADC, DAC... They're all the same. Some may have extra features, but unless you need them, their config bits are just in reset default states.

Obviously, complex microcontrollers offer more complex peripherals but they are something not available at all in the simplest devices. Examples being USB, Ethernet, CAN...

This complexity does not affect you if you don't need said peripherals. If you do need them, then the simple controller is out of window anyway.

So don't get fooled by having a 4000-page long manual, and an astonishing number of features. Most are disabled by default and you don't need to even understand the features you don't need. As always with expensive/complicated MCUs, you end up utilizing maybe 5-20% of the available resources.

My finding is that if you compare some flagship STM32H7 to simple STM32F0 device, the largest difference in getting the led blinker yo work is, you need to concentrate on understanding the clock tree for a few minutes hours so you can configure the PLL and peripheral clock routing options so you get what you need. Typically some 5-10 lines of code, but it's something you could call "complex".

Compared to PIC/AVR, you have the additional burden of having to find some relevant enable bits all over the manual (clock enables, setting Alternate Functions on GPIO config...) which on PIC/AVR happen automatically from a single peripheral enable bit. Again, just a few lines of code, but something worth considering. But this extra complexity is already there with the simplest STM32F0.

[tmadness]

The F4 parts had simpler SPI and DMA peripherals. I don't doubt that the F7/H7 are usable. Its just that I I was overwhelmed by the difference, a lot of my peripheral code did not transfer and I did not have a timeline that let me explore the H7 in leisure.

[Siwastaja]

Oh, every STM32 has a slightly different SPI peripheral. It's because ST hasn't been able to make a functional SPI peripheral despite attempting that for over a decade, in dozens of different incarnations. They simply are unable to do it. The process is always same:
* Read the reference manual for an hour
* Configure the SPI (3 lines of code)
* Verify it doesn't work as it should
* Curse
* Read the reference manual for 10 hours
* Try everything
* Accept the fact ST still couldn't make it and circumvent the broken SPI peripheral in some creative way, such as triggering an EXTI interrupt from nCS signal that resets the SPI peripheral through RCC reset register.

But more complex? No, I think the SPIs have been slightly different but definitely not more complex. In trivial/basic cases, they are quite easy to use, and they all suck the same if you need something like the nSS hardware management.


But DMA? I have only seen two different DMAs, one in F0 series, and another one in everything else, including many in F2, F3, F4, F7, H7 series (H7 actually has, in addition to two "classic" DMAs, a third "basic DMA" which is the one borrowed from F0 series!). I'm not saying there isn't a third one, just that I haven't seen it. My DMA code has been portable between the mentioned (not F0) series. Not that it matters much - unless you are using some very special advanced DMA features (which STM32 series do not offer, so you probably aren't), DMA config is two memory addresses, data count, and a few trivial config bits. It shouldn't be a lot of "porting".

The new H7 series has long-awaited DMAMUX which greatly simplifies everything because now you can map any peripheral to any DMA channel, so you don't need to think about the old-style stupid connection matrix while designing BOM and PCB layout. Basically, this just replaced the old limited channel selection (0 .. 9) with a a wider one (0 .. 127) including all peripherals. Practically, instead of writing the channel number in part of DMA CR, you write the channel selection in DMAMUX CCR register.