Author Topic: Yet another "Getting Started With ARM" post...  (Read 3037 times)

0 Members and 1 Guest are viewing this topic.

Offline nigelwright7557

  • Frequent Contributor
  • **
  • Posts: 286
  • Country: gb
    • Murton-Pike Systems
Re: Yet another "Getting Started With ARM" post...
« Reply #50 on: June 06, 2020, 08:46:47 pm »
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.
PCBCAD51/PCBCAD360/PCBCAD720 PCB design software https://www.murtonpikesystems.co.uk
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 19924
  • Country: nl
    • NCT Developments
Re: Yet another "Getting Started With ARM" post...
« Reply #51 on: June 06, 2020, 10:16:27 pm »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Online techman-001

  • Frequent Contributor
  • **
  • Posts: 659
  • Country: au
  • Electronics technician for the last 47 years
    • Mecrisp Stellaris Unofficial UserDoc
Re: Yet another "Getting Started With ARM" post...
« Reply #52 on: June 06, 2020, 11:15:49 pm »
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.

Offline ETITsynthesizer

  • Contributor
  • Posts: 39
Re: Yet another "Getting Started With ARM" post...
« Reply #53 on: June 12, 2020, 02:57:51 pm »
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.
 

Offline AkiTaiyo

  • Contributor
  • Posts: 5
  • Country: gb
Re: Yet another "Getting Started With ARM" post...
« Reply #54 on: June 26, 2020, 08:28:15 am »
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! 
 

Offline Bassman59

  • Super Contributor
  • ***
  • Posts: 1581
  • Country: us
  • Yes, I do this for a living
Re: Yet another "Getting Started With ARM" post...
« Reply #55 on: June 26, 2020, 05:55:46 pm »
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.
 

Offline nigelwright7557

  • Frequent Contributor
  • **
  • Posts: 286
  • Country: gb
    • Murton-Pike Systems
Re: Yet another "Getting Started With ARM" post...
« Reply #56 on: October 18, 2020, 03:48:23 am »
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.
PCBCAD51/PCBCAD360/PCBCAD720 PCB design software https://www.murtonpikesystems.co.uk
 

Online HB9EVI

  • Frequent Contributor
  • **
  • Posts: 426
  • Country: ch
Re: Yet another "Getting Started With ARM" post...
« Reply #57 on: October 18, 2020, 11:28:45 am »
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.
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5551
  • Country: fr
Re: Yet another "Getting Started With ARM" post...
« Reply #58 on: October 18, 2020, 03:14:57 pm »
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. ;D
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6794
  • Country: us
    • Personal site
Re: Yet another "Getting Started With ARM" post...
« Reply #59 on: October 18, 2020, 06:07:25 pm »
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.
Alex
 

Offline SiliconWizard

  • Super Contributor
  • ***
  • Posts: 5551
  • Country: fr
Re: Yet another "Getting Started With ARM" post...
« Reply #60 on: October 18, 2020, 06:53:13 pm »
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.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 6794
  • Country: us
    • Personal site
Re: Yet another "Getting Started With ARM" post...
« Reply #61 on: October 18, 2020, 07:13:38 pm »
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.
Alex
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf