ARM starting platform

[alin_im]

Hey guys ,

I am a freshly graduate student and I want to spent my free time by programming some ARMs to improve my coding skills.

I was thinking of purchasing one of those 2 boards: STM32L476G-DISCO or NXP FRDM-KL46Z. What do think or recommand ?

I wanted a platform that is compatible with mbed.com because I want to start with that and the progress to IAR or GCC.

The STM board is a much powerful Cortex M4 instead of a M0+, but at this point I do not think it matters because I do not have a project in mind which requires features that M4 has and M0+ hasn't. I just want to start working with ARM 32 bit micros and "master" the interrupts and timers and communication protocols (SPI, I2C and UART especially).

In the past I just worked with Atmel and Microchip 8 bit micros (about 3 years of experience).

Regards,
Alin

[MosherIV]

Hi

The  Disco is not mbed compatible (or was not the last time I looked, I noticed that they disconntinued the one I have and launched a new version)

Try this one
https://developer.mbed.org/platforms/ST-Nucleo-F401RE/

Mbed is nice in that it has lots of developed drivers and easier to start framework but that also means it sheilds you from getting to know the ins and outs of CortexM development, such as the CMSIS.
mbed is better for developing projects quickly

I would highly recommend IAR because it is all integrated and just works. You will have to understand the processor or you will not get far, but do not worry there are lots of examples and support out there.
gnu tools are a real pain, you have to spend time figuring out how to set them up and then get them to talk to the debugger etc etc. Precisely why linux heads love the damm thing
IAR just lets you start and get in with coding!

[mac.6]

Both ST and NXP/kinetis provides integrated IDE around eclipse/gcc, they just work out of the box. They also provides tools for easy setup, and quite frankly start with them until you understand well clocking, muxing and so on.
ST has STM32cubeMX, Kinetis has KDS and PEX, online/offline pintool (and soon clock).
Best thing to do is download IDE/SDK/Tools for both and play with them a little bit (no need for board). Compile a simple project/example and make your choice.

[dannyf]

If you want mbed compatibility, get a mbed comparable board. In the stm32 world that means nucleo boards, which is generally cheaper, more powerful and comes with arduino headers.

In terms of development system, I like coide (pre 2.0).

BTW there isn't much unique about arm from a C coding perspective - the core is practically transparent from a C programmers perspective.

[alin_im]

Hi

The  Disco is not mbed compatible (or was not the last time I looked, I noticed that they disconntinued the one I have and launched a new version)

Try this one
https://developer.mbed.org/platforms/ST-Nucleo-F401RE/

Mbed is nice in that it has lots of developed drivers and easier to start framework but that also means it sheilds you from getting to know the ins and outs of CortexM development, such as the CMSIS.
mbed is better for developing projects quickly

I would highly recommend IAR because it is all integrated and just works. You will have to understand the processor or you will not get far, but do not worry there are lots of examples and support out there.
gnu tools are a real pain, you have to spend time figuring out how to set them up and then get them to talk to the debugger etc etc. Precisely why linux heads love the damm thing
IAR just lets you start and get in with coding!

Thank you for the reply.

The Disco is compatible with mbed: https://developer.mbed.org/platforms/ST-Discovery-L476VG/

I will have a look at IAR but I know that the free version has 32kB limit (16kB for M0+) and lets say I am not the best programmer in terms of code optimization, but I think this will force me to be.

Do you recommend other platforms at this price (20 euros) ?

[MosherIV]

integrated IDE around eclipse/gcc 

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!
That is precisly what I am recommending you do not do.
I have used
Code worrier - slow and cumbersome,
Atollic - slow and cumbersome,
VxWorks Workbench

Hate all of them with a passion
www.ihateeclipse.com

With ALL Eclipse embedded integrations, you cannot tell when debugging if the micro has locked up on or if Eclipse has just decided to go off and do some studpid useless background task!

[alin_im]

If you want mbed compatibility, get a mbed comparable board. In the stm32 world that means nucleo boards, which is generally cheaper, more powerful and comes with arduino headers.

In terms of development system, I like coide (pre 2.0).

BTW there isn't much unique about arm from a C coding perspective - the core is practically transparent from a C programmers perspective.

I know about the nucleo but i find the discovery boards better because of the already build in sensors and LCD without the require of external circuity for some I2C comms and also I have not worked with LCDs that does not have a Hitachi interface and I would love to write a library on my own.

[langwadt]

If you want mbed compatibility, get a mbed comparable board. In the stm32 world that means nucleo boards, which is generally cheaper, more powerful and comes with arduino headers.

In terms of development system, I like coide (pre 2.0).

BTW there isn't much unique about arm from a C coding perspective - the core is practically transparent from a C programmers perspective.

I gave up on coide, 2.0 was utter useless and it only run on windows

System Workbench (www.openstm32.org) just works

[MosherIV]

The Disco is compatible with mbed: https://developer.mbed.org/platforms/ST-Discovery-L476VG/

I will have a look at IAR but I know that the free version has 32kB limit and lets say I am not the best programmer in terms of code optimization, but I think this will force me to be.

Do you recommend other platforms at this price (20 euros) ?

Yep, thanks checked after posting my reply. As I said, when I bought my Disco board a few years back it was not mbed compliant.

I use IAR for simple stuff at home, code size will not be a problem unless you are doing a big project or if you get the Disco graphical stuff. There is em:blocks as an alternative, have downloaded it but not tried it yet. Looks like Eclipse but not actually Eclipse (I avoid anything Eclipse on embedded if possible but some places of work force me to use it )

All the smaller, simpler Nucleo boards (M0+, M0, M3, M4) are around €20. They vary depending on whether you want low power or more processing power, or have different peripherals eg not all boards have DACs
Only the M7 and large IO count ST boards are more than €20

[janoc]

If you want mbed compatibility, get a mbed comparable board. In the stm32 world that means nucleo boards, which is generally cheaper, more powerful and comes with arduino headers.

I would say that if you want mBed, get one of the official mBed boards (i.e. not STM32 ones but LPC1768 or similar). The support for the ST boards is hit and miss, with a lot of peripherals missing or not supported well (timers, USB, ...)

integrated IDE around eclipse/gcc 

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!
That is precisly what I am recommending you do not do.
I have used
Code worrier - slow and cumbersome,
Atollic - slow and cumbersome,
VxWorks Workbench

Hate all of them with a passion
www.ihateeclipse.com

With ALL Eclipse embedded integrations, you cannot tell when debugging if the micro has locked up on or if Eclipse has just decided to go off and do some studpid useless background task!

That's really helpful and constructive. 

BTW, never had issues with the debugging in Eclipse or Eclipse locking up in at least the last two years (Neon, Mars releases). Eclipse can hang if you have a really large (= hundreds of megabytes) codebase, then the indexer (Intellisense for microsofties) will conk out, otherwise no issues. However, I am using stock Eclipse with CDT, not the variously bodged up and abused vendor implementations (ST's SW4STM32, LPCXpresso, ...)

[rstofer]

I have NEVER gotten GDB to work on any platform, with any JTAG dongle.  NOT EVER!

So, I don't even bother.  If the plan is to start with an mbed compatible board, you might as well use the online mbed compiler and a whole lot of printf() statements.  You can write a lot of code with the stuff that's provided.  If you use the original mbed LPC1768, you can include networking in your projects by adding just a MAGJACK.  The toolchain works on a lot of the other mbed compatible platforms as well.

In the STM32F4 world, some of the boards are mbed compatible (listed at the web site) and you can use the online toolchain.  Again, with a lot of printf()s.

You can also use STM32F ST-Link to program the board and make a connection to GDB.  Once again, I haven't gotten it to work but, according to the chosen few, it does work.

You can certainly use Eclipse as an IDE without using GDB or even with it, if you can get it to work.  I just downloaded Eclipse Neon with the GNUARM plug-in and it works very well.  It really is intended to target the STM boards but it will do the others if it is set up right.

As to GDB?  Well, if you don't put bugs IN your program, you won't have to get them OUT of your program.  I did all he single stepping I ever want to do back in the days of the 8085.  What a colossal waste of time!

Unless things have changed, the IAR toolchain isn't free or unrestricted.  One thing about the GNU toolchain, you aren't limited to only a few hundred lines of code or a couple of K of object code.

I'm not sure what to think about STs automagic setup program, STM32CubeMX.  It seems pretty nice and it generates a lot of code plus a nice report BUT...  If I build my project off of their code, what happens when I have to add one more gadget?  I get a whole new framework and I somehow have to move my code into theirs.  DIFF, I suppose.  Either that or I have to initially copy their code into mine and then, somehow, do that over again.  One way of the other, I expect to lose my edits.  I better get it right the first time!

The other thing that is disappointing with the boards listed at mbed is that they all use a lot of the peripheral pins that I would rather use for something else.  I need 3 full blown USARTS with flow control, I need two SPI channels with NSS and, I would consider using their onboard Ethernet.  I spent most of yesterday looking for a board that had these peripherals.  Not a chance!  In every case, some onboard peripheral jammed up the configuration.

If I were looking for 'simple', I would start with the original 'mbed' (LPC1768) with the project board as a base and use the online toolchain (plus a bunch of printf()s.

[Sal Ammoniac]

NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!

With ALL Eclipse embedded integrations, you cannot tell when debugging if the micro has locked up on or if Eclipse has just decided to go off and do some studpid useless background task!

Nonsense. I've used Eclipse extensively to develop for and debug on ARM Cortexes and I've never once had Eclipse "lock up". Do you have some specific evidence, or are you relaying anecdotal tales? Perhaps the Eclipse-based tool you've used wasn't configured correctly.

IMO most of the hate directed at Eclipse is due to vendors taking the base Eclipse and integrating every piece of plug-in garbage they can find in some lame attempt to make it more useful. All of those dodgy plug-ins just serve to make Eclipse slow and unstable. I use the bare cones Eclipse with only the CDT add-ons and it's both fast and stable.

[rstofer]

I can already hear the snickering re: my recommendation to start with the online toolchain.  Consider this:  I can work on my code from any networked computer, anywhere in the world.  I have a gaggle of computers and I have some kind of toolchain on all of them.  But unless my code is on my NAS, I can't reach it.  Even then, I don't have a hole through my firewall so I can't reach it from outside the house.

Yup!  That online thing has a real future!

And the mbed people provided the network stack so I could work on my application instead of reinventing the wheel.

[Sal Ammoniac]

I have NEVER gotten GDB to work on any platform, with any JTAG dongle.  NOT EVER!

Hmmmm... I've gotten GDB to work just fine with Eclipse/CDT on STM32F4, LPC1768, LPC43xx, Tiva C, Kinetis, and one or two others I'm forgetting at the moment. It's not difficult, especially if you use a quality JTAG such as a Segger J-Link. Use a cheap piece of Chinese clone crap and all bets are off, however.

[alin_im]

What do you think about the NXP board

https://developer.mbed.org/platforms/FRDM-KL46Z/ mbed site specs

http://www.nxp.com/products/software-and-tools/hardware-development-tools/freedom-development-boards/freedom-development-platform-for-kinetis-kl3x-and-kl4x-mcus:FRDM-KL46Z  NXP specs

[dannyf]

"I have NEVER gotten GDB to work on any platform, with any JTAG dongle.  NOT EVER"

Whne something that extreme happens to you consistently, the fault is likely with you.

For the record, I have never unable to get gdb to work.

[rstofer]

"I have NEVER gotten GDB to work on any platform, with any JTAG dongle.  NOT EVER"

Whne something that extreme happens to you consistently, the fault is likely with you.

For the record, I have never unable to get gdb to work.

In the early years of OpenOCD, getting a setup to work was akin to magic.  This was back, say, 10 years ago.  Give or take...
I haven't tried since and probably never will again.  But, yes, it's my fault...  There were simply too many parameters and far too many combinations...

I did have success with Rowley's Cross Connect and their CrossWorks platform.  At the time, I was working with NXP ARM7-TDMIs and the alternative to JTAG was serial programming.  I still don't recall doing any single stepping.

If I ever get to a point where I can't get my code to run and I am truly desperate, I might try again.

[dannyf]

If I ever get to a point where I can't get my code to run and I am truly desperate, I might try again.

For your own sake, I think you should hope it happening sooner rather than later.

[rstofer]

If I ever get to a point where I can't get my code to run and I am truly desperate, I might try again.

For your own sake, I think you should hope it happening sooner rather than later.

Why?  I don't care for single-stepping and even though I am migrating toward the STM32F4 boards with ST-Link, I seem to get my stuff to work with just simple printf() statements.  My strategy for bringing up a new board is to get the clocks running well enough to bring up a UART.  I add in a few conversion strings from "The C Programming Language" and go from there.

Before Vivado came along, all I had to debug FPGAs was a logic analyzer with only 32 channels and not nearly enough pins on the board.  Somehow, without an internal logic probe and simulator, I was able to get major projects to run.  There's a heck of a lot less visibility inside an FPGA than there is on a uC.

Until I can't get things done, I'll just keep on doing it the way I am.  It works for me even though there are others who really like JTAG.

[ebclr]

Best option

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

[ebclr]

Another interesting option

http://www.ti.com/ww/en/launchpad/launchpads-connected-ek-tm4c1294xl.html#tabs

[newbrain]

On IDEs/dev environment...pick your poison 
Several other threads where more or less the same questions are asked and discussed are active, and searching the forum will find many more.
I personally find that debugging (breakpoints, conditional bp, watches etc.) can be sometimes be very useful, and never had any major problems with pre-packaged environments (yes, even with Eclipse based ones), mostly OpenOCD based (but I also tried things like Blackmagic, that worked also).
One good feature (not exclusive) of the IDE I use is direct "live" manipulation of the peripheral registers, with named fields and flags: set a BP, and change the outputs or read event flags "in medias res".

Best option

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

Nice board (I have one), with one caveat: it's sometimes a problem to find pins that do not conflict with the bonanza of on-board peripherals (LCD, touch, SDRAM, MEMS...).
Nucleo boards (-32 -64 or -144) are, on the other hand almost barebone and give almost complete unshared access to the IO pins.

One advantage of STM32 is that most IOs are 5V tolerant in contrast with, say, TI 432, or the mentioned Kinetis AFAICS.
That eases up connection to sensors, I2C and all the "legacy" 5V based stuff (Arduino shields, even!).

[mac.6]

Kinetis K64 are 5v tolerant on digital I/O pins. KL46 are not. Check datasheet for info on max values.

[rstofer]

Best option

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

Nice board (I have one), with one caveat: it's sometimes a problem to find pins that do not conflict with the bonanza of on-board peripherals (LCD, touch, SDRAM, MEMS...).
Nucleo boards (-32 -64 or -144) are, on the other hand almost barebone and give almost complete unshared access to the IO pins.

One advantage of STM32 is that most IOs are 5V tolerant in contrast with, say, TI 432, or the mentioned Kinetis AFAICS.
That eases up connection to sensors, I2C and all the "legacy" 5V based stuff (Arduino shields, even!).

That 429 chip has at least 8 USARTs and once installed on the DISC1 board, NONE of them are fully featured with CTS/RTS.  Sure, I can do it with GPIOs but...
USART4,7,8,3 & 6 are excluded, USART 1 & 5 can run but no CTS/RTS and USART2 can't run in asynchronous mode.  Eight USARTS and only 2 available and they are crippled!  OTOH I can manage to come up with two fully featured SPI ports.

That's a nice feature of STM32CubeMX - you can check the pinout before you buy the board!

My imaginary project needs 3 fully featured USARTs, 2 fully featured SPIs and possibly Ethernet if I can convince myself that lwIP can handle multiple concurrent connections.  You would think that is a simple answer:  Yes, No...  Something like that...  I still can't find it written down anywhere.

[Kilrah]

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.

BTW:

That 429 chip has at least 8 USARTs and once installed on the DISC1 board, NONE of them are fully featured with CTS/RTS.

Dunno, but from a quick look why doesn't USART3 do the job?