ARM starting platform

[westfw]

I think that if you get a STM32f103 Nucleo board ( http://www.st.com/content/st_com/en/products/evaluation-tools/product-evaluation-tools/mcu-eval-tools/stm32-mcu-eval-tools/stm32-mcu-nucleo/nucleo-f103rb.html ) (cheap: about $10) you will wind up with a choice of Arduino (via http://stm32duino.com/ ), MBed, and of course vendor-provided and traditional development environments.  (also, as one of the older STM32f CM3 boards, you'll have a choice of several different generations of ST peripheral libraries, plus some examples here and there on bare metal programming (even in assembler, if you're  so inclined!))

The TI Tiva Launchpad boards support Arduino (well, "Energia" - a lookalike) and traditional tools.  The MSP432 is especially interesting because the Energia support includes multitasking via TI-RTOS.  ("Interest" does not necessarily mean "good.")

As for development environments for ARM boards in general, it's probably best to start with the environment provided by the vendor.  They'll tend to have the most up-to-date instructions, despite other flaws.  *ALL* Environments have flaws; if you're a beginner it's probably more important to jump in and get wet rather than trying to do a lot of research trying to find the "best" environment.  If you hit a stumbling block with a particular environment, you can get a much better answer on a specific question "who does XXX better than the YYY IDE?"

[ebclr]

Based on your post I would suggest two boards

https://www.mbed.com/en/development/hardware/boards/st/disco_f429zi/

or

https://www.mbed.com/en/development/hardware/boards/siliconlabs/efm32giantgecko/

Both are a very nice board with display and sensors and mbed compatible, one is more low power for battery things, another is more brute force

[nctnico]

I see a lot of people recommending ST due to price but how compatible are the peripherals nowadays? The last time I looked at ST they where a complete mess where each controller had totally different peripherals which makes it extremely hard to share peripheral related code between one controller and the other.

[tatus1969]

ST (and others) made some effort in harmonizing peripheral interfaces, have a look at CMSIS. Adds some overhead - for example setting a GPIO output does not assemble to a single instruction - but todays micros are fast enough in my opinion. And you are free to hard code critical parts anyway.

I have good experience with STM32 family, lots of code examples, and a support team that quickly responded to my problems. Better than with Atmel. NXP was also good on support.

[dannyf]

have a look at CMSIS. Adds some overhead

The CMSIS start-up code has no run-time overhead.

- for example setting a GPIO output does not assemble to a single instruction

CMSIS doesn't touch on GPIO. and you can code it as a single instruction execution if the chip supports it.

[MosherIV]

ST (and others) made some effort in harmonizing peripheral interfaces, have a look at CMSIS

The CMSIS was mandated by ARM for configuring the core processor (ie the ARM core). There has been NO attempt by any chip vendor to harmonise peripheral interfaces, this is contary to the chip vendors goals - to boot sales of their devices by locking users into their peripherals.

[ebclr]

The mbed platform abstract all those pheriferic setup, You can change boards and a very little code need to be changed does not matter if is ST NXP or any other board that is on the list, if is to the list the abstraction layer is already done and for you all will be the same you only need to relate pins and names

[tatus1969]

ST (and others) made some effort in harmonizing peripheral interfaces, have a look at CMSIS

The CMSIS was mandated by ARM for configuring the core processor (ie the ARM core). There has been NO attempt by any chip vendor to harmonise peripheral interfaces, this is contary to the chip vendors goals - to boot sales of their devices by locking users into their peripherals.

Ah, you are right, I got that wrong from STs peripheral library explanations. They state that it is CMSIS compliant, but they only mean that the CMSIS core code is included there.

[ez24]

To OP:


A couple of "beginner" STM32 books and etc.  (by beginner they mean to STM32s not MCUs)

https://leanpub.com/mastering-stm32   

currently at 632 pages and uses free tools for all 3 OS


and this site has a custom learning board and a book (custom compiler and Windows OS)

https://imagecraft.com/

both authors told me the STM32 is TOO difficult for a MCU beginner to learn,  like me.  But may be ok for you.

[rstofer]

both authors told me the STM32 is TOO difficult for a MCU beginner to learn,  like me.  But may be ok for you.

They are probably right!  I had enough problems getting up to speed on the STM32 board I bought a few years ago that I just put it aside and moved to the original mbed (LPC1768) and I had a ton of experience with uCs and programming.

There are 3 issues:
1) Embedded programming is complicated - it just is!
2) The toolchains have a tall and steep learning curve
3) The devices have a taller and steeper learning curve

OTOH, I can't see backing up to a PIC but I still like the Arduino for prototyping something really quick.

If you seriously want to do ARM programming, knock off all the toolchain selection stuff and use the online tool at mbed.org.  It's dead simple to get started, there's nothing to install, most of the startup code is 'hidden' (as in you probably don't need to know for a couple of years) and the toolchain works on a range of boards.  You get to have the results a lot sooner with a much flatter and shorter learning curve.  And there are a lot of pre-canned projects you can simply import and use.

Leave the STM32 stuff (using other toolchains) for later.  You can still use any of the mbed compatible STM32F boards, no problem, but you just skip past a whole lot of nonsense.

In a year or so, revisit the issue but I'll bet you stay with the mbed approach.

[dannyf]

I had enough problems getting up to speed on the STM32 board

Two things that beinggers typically struggle:

1) setting up a project: this is generally toolchain specific but they follow a set pattern: include cmsis / start-up files, and various libraries, set up include path / directories, set up library directories, set up compiler flags, set up debugger, set up retarget / scatter files / initialization file, etc. While they are toolchain specific, there is a high degree of similarities from one toolchain to another. So once you have it mastered on one toolchain, that knowledge is applicable to a different toolchain.

I have a set of "getting started on ..." blog posts across multiple chips and toolchains and you can see that they are highly similar;

2) chip / peripheral specific: getting a peripheral going on a chip is highly specific to that chip or library so there is not a high degree of synergy here. No alternative other than to tough it out, practice and practice more.

[janoc]

both authors told me the STM32 is TOO difficult for a MCU beginner to learn,  like me.  But may be ok for you.

They are probably right!  I had enough problems getting up to speed on the STM32 board I bought a few years ago that I just put it aside and moved to the original mbed (LPC1768) and I had a ton of experience with uCs and programming.

I concur - if you are a newbie only getting into MCU programming, then starting with ARM straight away is learning to run before you have learned to walk. Those MCUs are complex!

In that case I would suggest sticking to an 8bit micro for a while longer so that you learn the ropes first. Even that could be overwhelming enough already when you don't have 5+ registers to configure to just blink a LED like on ARMs.

STM32 micros are powerful, but with power comes complexity. The Cortex M core is not too bad by itself, but if you were used to something like AVR or a PIC where a peripheral is typically controlled by two or three registers, you are in for a rude shock.

The reference datasheet for the smallest F0 series chips is around 1000 pages already. For example, on STM32F042 (a small USB-enabled micro), each GPIO port is controlled by ~11 registers + additional registers controlling power to the port, interrupts, DMA, clock ... Fortunately you don't have to configure all that every time, most often the power on defaults are sane for the common situations, but still. Compare that with about 3 registers you have for GPIO port on AVRs or PICs.  And that is GPIO - a fairly simple thing. You don't want to see stuff like timers or I2C ...

The various libraries (HAL, STDPeriph, mBed, ...) abstract this away and hide it behind layers of code. On the other hand, when the function you need is not handled by the library or the chip is misbehaving because of a library bug, you are going to have fun ...

[ebclr]

It's complex to know deeper, but extremely simple to do 98% of the regular applications, don't reinvent the well, use the modern tools

https://developer.mbed.org/getting-started/

[rstofer]

It's complex to know deeper, but extremely simple to do 98% of the regular applications, don't reinvent the well, use the modern tools

https://developer.mbed.org/getting-started/

As I am faced with getting my grandson up to speed on microcontrollers, I have been looking around my bench to see which device would be easiest.  I see only two choices:  Arduino or mbed.  If the objective is to get something working in the shortest amount of time, these two platforms will get it done.  If a side goal is to use ARM, well, that leaves mbed.  I like the original LPC1768 board but the newer STM boards seem to work quite well and come with various peripherals that might be useful.

There's time later on to delve into the complexities of the various chips.  Immediate gratification is the current goal.

[ebclr]

St are very good, many modles many option, LPC the same, freedom boards all are fine, Gecko boards best for battery operated systems, just jump in one , I have all and, it's everything very similar

[rstofer]

Anther thing that's been touched on briefly:  It is false economy to go to eBay and buy the cheapest possible board with no peripherals whatsoever and no current support for the chip.  Worse yet if it doesn't include on-board USB programming capability.

It's going to take literally hundreds of hours of typing to become proficient.  If having a fully featured development board (at least some switches, LEDs and maybe 7 segment displays), how much time will be saved?  Not to mention that there are usually quite a few sample projects for the more fully featured boards.

Given that all of Digilent's current offerings have USB programming and no requirement for an external JTAG dongle (and now they also implement a serial port over the same USB programming stream), there's just no reason to go to eBay scrounging for the cheapest thing around.  Spend the money on a decent board with reasonable peripherals and built in programming like the Digilent BASYS3.  It has a current production ARTIX 7 chip, programming support and a host of peripherals.

http://store.digilentinc.com/basys-3-artix-7-fpga-trainer-board-recommended-for-introductory-users/

Arty is another choice but it doesn't have its own peripherals.  It is looking for 'shields' to stack on top.  Still, an option...

http://store.digilentinc.com/arty-board-artix-7-fpga-development-board-for-makers-and-hobbyists/

Sure, I bought the CMOD A7 version a couple of weeks ago but it is for a specific project where I know exactly where I am headed.  I'm going to marry it up with an mbed to handle TCP/IP IO and run a CPU in the FPGA.  Both the mbed and CMOD 7 have similar form factors so I can mount them both on a motherboard and things will work out well.

http://store.digilentinc.com/cmod-a7-breadboardable-artix-7-fpga-module/

The USB programming gadget also works with the Vivado Internal Logic Analyzer so you get in-circuit debugging capability.  Very nice!  But I suppose it works with a JTAG dongle as well.  I don't care to test it...

[janoc]

As I am faced with getting my grandson up to speed on microcontrollers, I have been looking around my bench to see which device would be easiest.  I see only two choices:  Arduino or mbed.  If the objective is to get something working in the shortest amount of time, these two platforms will get it done.  If a side goal is to use ARM, well, that leaves mbed.  I like the original LPC1768 board but the newer STM boards seem to work quite well and come with various peripherals that might be useful.

There's time later on to delve into the complexities of the various chips.  Immediate gratification is the current goal.

I wrote this once already, but here it is again - if you want to use mBed, stick with LPC1768, especially if you are new to the ecosystem and don't know the various idiosyncrasies yet.

STM32 support in mBed is hit and miss, many peripherals are not supported and the ones which are supported are often substantially incomplete. That ST slaps "mBed compatible" sticker on their Nucleos or Discovery boards doesn't mean that it is actually usable. E.g. the STM32F042 and 030 Nucleos were sold for months as mBed compatible, despite mBed not having any support whatsoever for them. 042 has USB but no support for it from mBed - and no ETA or anything neither. Support for things like timers is a complete joke. Etc etc ... In such case mBed will be getting more in your way than actually making your life easier.

[ebclr]

You forgot that , at anytime you can export from mbed to any major compiler plataform, and from there you can do anything you want outside mbed world, By the way mbed comes from ARM company the ones that makes the basic IP for any arm on the market.

The mbed classes cover the majority of regular arm I/O, and also have a community of developers including the semis producer, with several add on's libraries .

Does not have any single reason to at least know the mbed plataform.

[rstofer]

And you don't have to use the mbed libraries just to use the toolchain.  My first project required an interrupt driven SPI slave and no such code was available.  It took 10 lines of code to set up SPI and 3 lines of code to set up the NVIC interrupt controller.  It is possible, over time, to replace all of the device specific code if that's what a person wants to do.  When there was only one board, replacing the code might have made sense.  Now that the same code base will presumably work on a variety of boards, creating new device specific code might not be a good idea.  As long as the necessary code exists.

[tatus1969]

Well, guess you've got to make choices when you design a board, and those are heavily oriented by the day's trends... haven't seen a UART used with CTS/RTS in a decade or 2.
but from a quick look why doesn't USART3 do the job?

Think of applications like RS485 or half-duplex radio modems, where you need flow control and/or transceiver direction control. Many modern UARTs can be configured for the latter.

[ebclr]

You can use USB otg and FT4232H

[rstofer]

You forgot that , at anytime you can export from mbed to any major compiler plataform, and from there you can do anything you want outside mbed world, By the way mbed comes from ARM company the ones that makes the basic IP for any arm on the market.

The mbed classes cover the majority of regular arm I/O, and also have a community of developers including the semis producer, with several add on's libraries .

Does not have any single reason to at least know the mbed plataform.

And the export includes all of the library code.  Essentially, you walk away with all of ARM's code, free!  License issues being a separate matter and generally not a concern for hobbyists.  No, I haven't read the EULAs...

[westfw]

I have been looking around my bench to see which device would be easiest.  I see only two choices:  Arduino or mbed.

supporting, between them, something like 20 to 50 different chips/boards, and at least 4 core architectures? (ARM, AVR, MSP430, PIC32)

If a side goal is to use ARM, well, that leaves mbed.

And Arduino Zero, Arduino Due, Arduino MKR1000, assorted sparkfun and adafruit SAMD21 board with Arduino support, plus Energia on TI ARM chips (3 or 4 different "LaunchPad" ARM boards), plus "stmduino."  :-)

[rstofer]

I have been looking around my bench to see which device would be easiest.  I see only two choices:  Arduino or mbed.

supporting, between them, something like 20 to 50 different chips/boards, and at least 4 core architectures? (ARM, AVR, MSP430, PIC32)

If a side goal is to use ARM, well, that leaves mbed.

And Arduino Zero, Arduino Due, Arduino MKR1000, assorted sparkfun and adafruit SAMD21 board with Arduino support, plus Energia on TI ARM chips (3 or 4 different "LaunchPad" ARM boards), plus "stmduino."  :-)

All true, of course.  But I was talking about boards and platforms with a very low learning curve.  Things where the platform provided all the startup code and the user only had to program their application using predefined things like pins and USARTs.  Essentially zero configuration code.

There are dozens and dozens of platforms.  There are only two that I would consider having my grandson start with.  Arduino (probably Uno) and mbed (LPC1768)

[Kilrah]

I think his point is that Arduino is not just good for the Uno nor even AVR boards, nor is mbed limited to the LPC1768 - i.e. these tools allow you to program just as easily on much more featured platforms.

For example instead of your Arduino Uno you might want to get an ESP8266 board instead, it'll be able to do all the Uno does just the same way, plus 10x more so that when you're bored of blinking LEDs (i.e. quickly, given the simplicity) you can start playing with a webserver.