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

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