Poll

What compiler is better for ARM ?

Keil uVision
IAR Workbench

Author Topic: ARM starting platform  (Read 21320 times)

0 Members and 1 Guest are viewing this topic.

Offline alin_imTopic starter

  • Regular Contributor
  • *
  • Posts: 164
  • Country: gb
ARM starting platform
« on: July 20, 2016, 08:58:02 pm »
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
One man's 'magic' is another man's engineering. 'Supernatural' is a null word. - Robert A. Heinlein
 

Offline MosherIV

  • Super Contributor
  • ***
  • Posts: 1530
  • Country: gb
Re: ARM starting platform
« Reply #1 on: July 20, 2016, 09:10:05 pm »
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! :-+
 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 225
  • Country: fr
Re: ARM starting platform
« Reply #2 on: July 20, 2016, 09:25:23 pm »
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.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM starting platform
« Reply #3 on: July 20, 2016, 09:27:50 pm »
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline alin_imTopic starter

  • Regular Contributor
  • *
  • Posts: 164
  • Country: gb
Re: ARM starting platform
« Reply #4 on: July 20, 2016, 09:29:48 pm »
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) ?
« Last Edit: July 20, 2016, 09:41:06 pm by alin_im »
One man's 'magic' is another man's engineering. 'Supernatural' is a null word. - Robert A. Heinlein
 

Offline MosherIV

  • Super Contributor
  • ***
  • Posts: 1530
  • Country: gb
Re: ARM starting platform
« Reply #5 on: July 20, 2016, 09:34:09 pm »
Quote
integrated IDE around eclipse/gcc 
NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! :palm:
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! :palm:
 

Offline alin_imTopic starter

  • Regular Contributor
  • *
  • Posts: 164
  • Country: gb
Re: ARM starting platform
« Reply #6 on: July 20, 2016, 09:37:30 pm »
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.

One man's 'magic' is another man's engineering. 'Supernatural' is a null word. - Robert A. Heinlein
 

Online langwadt

  • Super Contributor
  • ***
  • Posts: 4391
  • Country: dk
Re: ARM starting platform
« Reply #7 on: July 20, 2016, 09:45:44 pm »
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


 

Offline MosherIV

  • Super Contributor
  • ***
  • Posts: 1530
  • Country: gb
Re: ARM starting platform
« Reply #8 on: July 20, 2016, 09:46:39 pm »
Quote
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 :box:)

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
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #9 on: July 20, 2016, 09:46:49 pm »
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, ...)

Quote
integrated IDE around eclipse/gcc 
NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! :palm:
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! :palm:

That's really helpful and constructive.  :palm:

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, ...)

 
The following users thanked this post: f1rmb

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #10 on: July 20, 2016, 09:53:09 pm »
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.
« Last Edit: July 20, 2016, 09:54:58 pm by rstofer »
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: ARM starting platform
« Reply #11 on: July 20, 2016, 09:58:01 pm »
Quote
NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! :palm:

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! :palm:

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.
Complexity is the number-one enemy of high-quality code.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #12 on: July 20, 2016, 10:01:19 pm »
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.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: ARM starting platform
« Reply #13 on: July 20, 2016, 10:01:50 pm »
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.
Complexity is the number-one enemy of high-quality code.
 

Offline alin_imTopic starter

  • Regular Contributor
  • *
  • Posts: 164
  • Country: gb
One man's 'magic' is another man's engineering. 'Supernatural' is a null word. - Robert A. Heinlein
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM starting platform
« Reply #15 on: July 20, 2016, 10:26:19 pm »
"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.
================================
https://dannyelectronics.wordpress.com/
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #16 on: July 21, 2016, 12:15:51 am »
"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.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM starting platform
« Reply #17 on: July 21, 2016, 12:30:50 am »
Quote
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.
================================
https://dannyelectronics.wordpress.com/
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #18 on: July 21, 2016, 03:51:54 am »
Quote
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.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #19 on: July 21, 2016, 04:00:50 am »
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #20 on: July 21, 2016, 04:03:40 am »
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1713
  • Country: se
Re: ARM starting platform
« Reply #21 on: July 21, 2016, 12:58:02 pm »
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!).

Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline mac.6

  • Regular Contributor
  • *
  • Posts: 225
  • Country: fr
Re: ARM starting platform
« Reply #22 on: July 21, 2016, 01:34:57 pm »
Kinetis K64 are 5v tolerant on digital I/O pins. KL46 are not. Check datasheet for info on max values.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #23 on: July 21, 2016, 02:18:20 pm »


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.

 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: ARM starting platform
« Reply #24 on: July 21, 2016, 02:59:15 pm »
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?
 

Online newbrain

  • Super Contributor
  • ***
  • Posts: 1713
  • Country: se
Re: ARM starting platform
« Reply #25 on: July 21, 2016, 04:26:33 pm »
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.
If you intend to use a off-the-shelf board,  have you considered this?
Ethernet, USB OTG, some leds and not much more...same MCU, detachable ST-Link 2.1.
Or even the F746 model, same price, but actually in stock at RS at least for Sweden?
Not as cheap as the smaller Nucleos, but still decent value.

Edit:
It seems that lwIP can support multiple TCP connections, from /.../.../opt.h:
Code: [Select]
/**
 * MEMP_NUM_TCP_PCB: the number of simultaneously active TCP connections.
 * (requires the LWIP_TCP option)
 */
#ifndef MEMP_NUM_TCP_PCB
#define MEMP_NUM_TCP_PCB                5
#endif

/**
 * MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP connections.
 * (requires the LWIP_TCP option)
 */
#ifndef MEMP_NUM_TCP_PCB_LISTEN
#define MEMP_NUM_TCP_PCB_LISTEN         8
#endif
But I have never used it (yet...).
« Last Edit: July 21, 2016, 04:45:53 pm by newbrain »
Nandemo wa shiranai wa yo, shitteru koto dake.
 

Offline Sal Ammoniac

  • Super Contributor
  • ***
  • Posts: 1662
  • Country: us
Re: ARM starting platform
« Reply #26 on: July 21, 2016, 05:00:48 pm »
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.

Right. You can dig a pretty big hole with a shovel too, but I'd rather use a backhoe.
Complexity is the number-one enemy of high-quality code.
 

Offline Aodhan145

  • Frequent Contributor
  • **
  • Posts: 403
  • Country: 00
Re: ARM starting platform
« Reply #27 on: July 21, 2016, 05:01:26 pm »
Quote
integrated IDE around eclipse/gcc 
NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO! :palm:
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! :palm:

TI's Code Composer Studio is very nice and I have had no problems but I run on a very powerful system. Maybe it is just your computer isn't powerful enough and thats why light weight ones run better.
 

Offline alin_imTopic starter

  • Regular Contributor
  • *
  • Posts: 164
  • Country: gb
Re: ARM starting platform
« Reply #28 on: July 21, 2016, 06:40:42 pm »
Do you think if I extend my price range to 40 - 50 euros I can find something superior like a full development board, something like Microchip Explorer 16, but for ARM ? I do not think at this price.

I am thinking that maybe it is ok to invest a little bit more expensive now but to have benefits in the long run, then buying now a 20 euros platform and change it after 6 months because I need something else.

I am a little bit confused at the moment with all the compilers and errors or limitations. I want something that is budget friendly, has no IDE problems, some sensors and LCD and it is based on ARM.

 
« Last Edit: July 21, 2016, 06:46:20 pm by alin_im »
One man's 'magic' is another man's engineering. 'Supernatural' is a null word. - Robert A. Heinlein
 

Offline MosherIV

  • Super Contributor
  • ***
  • Posts: 1530
  • Country: gb
Re: ARM starting platform
« Reply #29 on: July 21, 2016, 07:10:28 pm »
Quote
  Do you think if I extend my price range to 40 - 50 euros I can find something superior like a full development board, something like Microchip Explorer 16, but for ARM ? I do not think at this price.

I am thinking that maybe it is ok to invest a little bit more expensive now but to have benefits in the long run, then buying now a 20 euros platform and change it after 6 months because I need something else.

I am a little bit confused at the moment with all the compilers and errors or limitations. I want something that is budget friendly, has no IDE problems, some sensors and LCD and it is based on ARM.
No, your stated goal is to improve your coding skill. For learning to program, it does not really matter how much the boards cost, just that they are easy to use/develop on. Picking mbed compatible boards pretty much covers that. The more expensive boards are aimed at commercial companies that want to tailor the boards into early prototypes.

If on the other hand you have a specific project in mind, then you should work out the project requirments are and get a board that has as much as that project needs. In other word, what kind of peripherals will the project need? Work out which board has those peripherals and get that one.

Yes, sorry about all the debate on which tool is best. It is down to personal preference. There are a number of tools which should work without much setup effort. As a professional embedded software engineer, I do not have time to mess around with freeware tools that may do the job, I am interrested in tools that will work straight away and NOT waste my time. I have pretty bad experiences with commercial tools based around the open source Eclipse toolset hence I prefer not to use ANY tool that is Eclipse based, however that is not to say that all of them are bad or will not work.  I can tell you NOT to bother with the free version of Atollic, has the same code size limitations as IAR but with all the issues that put me off Eclipse. The code size limit should not be a problem if you are just doing tutorial projects, it will only be a problem if you are working on a medium to large project (you can get FreeRtos and some functiinality in the 32K!). I suggest you have a quick look at the web sites for the tools that you are interrested in, if you have used tools before in the past this may help you pick the tool which best fits with the one you used before. Otherwise, try one and see how you get on.

Make sure the tool you pick allows you to compile, download, debug, shows high level code and assembler with symbolic debugging, single step, examine and change variables and registers, examine memory and place break points.
« Last Edit: July 21, 2016, 07:13:19 pm by MosherIV »
 
The following users thanked this post: alin_im

Offline alin_imTopic starter

  • Regular Contributor
  • *
  • Posts: 164
  • Country: gb
Re: ARM starting platform
« Reply #30 on: July 21, 2016, 07:30:03 pm »
Quote
  Do you think if I extend my price range to 40 - 50 euros I can find something superior like a full development board, something like Microchip Explorer 16, but for ARM ? I do not think at this price.

I am thinking that maybe it is ok to invest a little bit more expensive now but to have benefits in the long run, then buying now a 20 euros platform and change it after 6 months because I need something else.

I am a little bit confused at the moment with all the compilers and errors or limitations. I want something that is budget friendly, has no IDE problems, some sensors and LCD and it is based on ARM.
No, your stated goal is to improve your coding skill. For learning to program, it does not really matter how much the boards cost, just that they are easy to use/develop on. Picking mbed compatible boards pretty much covers that. The more expensive boards are aimed at commercial companies that want to tailor the boards into early prototypes.

If on the other hand you have a specific project in mind, then you should work out the project requirments are and get a board that has as much as that project needs. In other word, what kind of peripherals will the project need? Work out which board has those peripherals and get that one.

Yes, sorry about all the debate on which tool is best. It is down to personal preference. There are a number of tools which should work without much setup effort. As a professional embedded software engineer, I do not have time to mess around with freeware tools that may do the job, I am interrested in tools that will work straight away and NOT waste my time. I have pretty bad experiences with commercial tools based around the open source Eclipse toolset hence I prefer not to use ANY tool that is Eclipse based, however that is not to say that all of them are bad or will not work.  I can tell you NOT to bother with the free version of Atollic, has the same code size limitations as IAR but with all the issues that put me off Eclipse. The code size limit should not be a problem if you are just doing tutorial projects, it will only be a problem if you are working on a medium to large project (you can get FreeRtos and some functiinality in the 32K!). I suggest you have a quick look at the web sites for the tools that you are interrested in, if you have used tools before in the past this may help you pick the tool which best fits with the one you used before. Otherwise, try one and see how you get on.

Make sure the tool you pick allows you to compile, download, debug, shows high level code and assembler with symbolic debugging, single step, examine and change variables and registers, examine memory and place break points.

Thank you very much for all the help and support. I will have another look on the boards and I think I will go with a one that is compatible with mbed and IAR.
One man's 'magic' is another man's engineering. 'Supernatural' is a null word. - Robert A. Heinlein
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #31 on: July 21, 2016, 08:14:34 pm »
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...

...

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.

All you need to do (assuming you have OpenOCD and gdb installed):

1) Create a file called openocd.cfg to save you typing parameters (this is using the ST32F042 Nucleo board with built-in STLink):
---- cut ---
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f0x.cfg]
---- cut ---

The interfaces and targets you can find either in the documentation or just look in the folder where OpenOCD was installed - there are interface and target subdirectories containing files for both the interfaces (dongles) and targets. If you want JTAG transport, just put jtag instead of hla_swd. OpenOCD ships with these files for many common devboards, including the Nucleos and Discoveries, so just look there and adapt one if you don't find a matching one.


2) Run openocd in this folder (I am on linux, adapt to your OS as needed):
$ openocd
Open On-Chip Debugger 0.9.0 (2015-05-26-21:40)
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 1000 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : Unable to match requested speed 1000 kHz, using 950 kHz
Info : clock speed 950 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v11 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.238497
Info : stm32f0x.cpu: hardware has 4 breakpoints, 2 watchpoints

3) And that's all - OpenOCD is talking to the board. Now you can either connect to OpenOCD by using telnet and use the command line interface to do things like flash the board, start/stop the cpu, use boundary scan or whatever. That's:

$ telnet localhost 4444
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
Open On-Chip Debugger
>

4) Now you can flash your micro (it is possible to do it from gdb too, though). Type at the OpenOCD prompt:

init
reset halt
flash write_image erase absolute-path-to-your-bin-file 0x08000000
verify_image erase absolute-path-to-your-bin-file 0x08000000
reset run

And that's it. Just make sure you are not trying to flash the .elf file. You must flash a raw binary, not elf. And use full path, because otherwise it is relative to the folder where you have started OpenOCD from.


Most often you don't want to use that, except maybe for programming from a script.
However, gdb is just as simple:

1) Build your code with debug symbols (-g flag for GCC, you will likely want -O0 to disable optimization too)

2) Run ARM (or whatever you are debugging) gdb:

$ arm-none-eabi-gdb my-code.elf
GNU gdb (GDB) 7.10
<... snipped a lot of blurb ...>
Reading symbols from my-code.elf ...done.
(gdb)

3) now type at the (gdb) prompt:
(gdb) target extended localhost:3333
Remote debugging using localhost:3333
reset_handler () at ../../cm3/vector.c:68
68              for (src = &_data_loadaddr, dest = &_data;

(gdb) monitor reset halt
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x080012e0 msp: 0x20001800

(gdb)

4) And that's all. The first (target) command connects gdb to OpenOCD which acts as a driver for the JTAG/SWD dongle talking to your target and the second (monitor) command resets and halts the target, so that  you are starting from a defined state and not from somewhere in the middle of the code wherever the CPU was when it was halted by OpenOCD/gdb.

I have these commands in my .gdbinit file, so I don't have to retype them. If you are using an IDE, you can usually specify commands like this in the dialog box where one configures GDB (e.g. Eclipse has it)

5) Now you can start debugging - type "tb main" to set temporary breakpoint on main and "run" to start the code. The "load" command will flash the binary to the target.

Btw, CTRL+x a (press ctrl and x together, release, then press a) will give you a text UI in case you are debugging from command line directly.

There is nothing mysterious about these tools. The only problem used to be OpenOCD's documentation, but that has improved a lot in the recent years.
« Last Edit: July 21, 2016, 08:26:27 pm by janoc »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: ARM starting platform
« Reply #32 on: July 21, 2016, 08:34:29 pm »
Make sure the tool you pick allows you to compile, download, debug, shows high level code and assembler with symbolic debugging, single step, examine and change variables and registers, examine memory and place break points.
I never used something like that in the last 20 years. It is very useful to check startup code but if you need to debug a working microcontroller application printfs and status commands showing statistics go much further because they can stay in the firmware and be used as a diagnostic tool as well. In general you can't stop a microcontroller program without interrupts pilling up and tearing everything to shreds once the debugger lets go. Also you can't do meaningfull debugging on optimised code because the relationship between a line in a source file and location in the binary is gone. However with optimisation off the program will run magnitudes slower and will be significantly bigger (will it fit in flash?). All in all there really isn't any use for a debugger on a microcontroller. The low level hardware stuff you debug using collecting runtime statistics and wiggling IO ports connected to a logic analyser/scope. The high level stuff you develop on a PC. This is also where the comb GCC+ Eclipse comes in strong. With Eclipse + GCC you can compile, debug and verify your code on a PC and then compile for your microcontroller without needing to changes due to C compiler specific extensions.
« Last Edit: July 21, 2016, 08:36:46 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #33 on: July 21, 2016, 08:36:46 pm »
nctnico, we all know you are superhuman and debuggers are for pussies, but most do prefer to have a debugger available. I also knew one programmer like that that never needed debugger and debugged everything with printfs and a pencil on paper printouts of the code. It took him days to discover what another developer solved in 10 minutes by calling a debugger.
« Last Edit: July 21, 2016, 08:38:46 pm by janoc »
 
The following users thanked this post: Bassman59

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #34 on: July 21, 2016, 08:58:18 pm »
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...

...

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.

All you need to do (assuming you have OpenOCD and gdb installed):

1) Create a file called openocd.cfg to save you typing parameters (this is using the ST32F042 Nucleo board with built-in STLink):
---- cut ---
source [find interface/stlink-v2-1.cfg]
transport select hla_swd
source [find target/stm32f0x.cfg]
---- cut ---

The interfaces and targets you can find either in the documentation or just look in the folder where OpenOCD was installed - there are interface and target subdirectories containing files for both the interfaces (dongles) and targets. If you want JTAG transport, just put jtag instead of hla_swd. OpenOCD ships with these files for many common devboards, including the Nucleos and Discoveries, so just look there and adapt one if you don't find a matching one.

...


Thanks for the tutorial!  Seriously!  I have cut the text to a file where I can study it later.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: ARM starting platform
« Reply #35 on: July 21, 2016, 09:10:27 pm »
nctnico, we all know you are superhuman and debuggers are for pussies, but most do prefer to have a debugger available. I also knew one programmer like that that never needed debugger and debugged everything with printfs and a pencil on paper printouts of the code. It took him days to discover what another developer solved in 10 minutes by calling a debugger.
Well you can use printf to dump a stacktrace if you want! I have that enabled for the hard and bus fault interrupts on ARM.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #36 on: July 21, 2016, 09:38:27 pm »
Thanks for the tutorial!  Seriously!  I have cut the text to a file where I can study it later.

Welcome. However, there are plenty of OpenOCD/gdb oriented tutorials online, ARM micros are more popular than ever, so people use it.

OpenOCD is an interesting tool for boundary scan via JTAG as well. It can talk to (some) CPLDs and FPGAs as well, so you can use e.g. Xilinx XC59xxXL series CPLD as both a piece of logic in your system and also as a probe to poke the bus or memory through JTAG without having to design in a dedicated interface - you have it for free in the system already.

I suggest also looking up some gdb tutorials and documentation, most people don't know that gdb can actually execute your code backwards as well - allowing you to step back from e.g. an error handler to where the problem has actually occurred. It doesn't work on all targets, but I believe ARM should be supported.


« Last Edit: July 21, 2016, 09:42:08 pm by janoc »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #37 on: July 21, 2016, 09:40:51 pm »
Well you can use printf to dump a stacktrace if you want! I have that enabled for the hard and bus fault interrupts on ARM.

I prefer to actually put a breakpoint in the handler and investigate the issue while the system is still alive with memory and registers intact than have to do it postmortem from a trace, if possible. Stacktraces have their place, but are far from the fastest way of debugging such issue.
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM starting platform
« Reply #38 on: July 21, 2016, 10:49:07 pm »
If you intend to make a living off of this experience, I would encourage you to take a look at keil or iar or both actually, especially for cm0 where unlimited versions of keil exist for stm32f0 chips.

You have to remember that the cores are pretty much transparent to a C programmer. So it really don't matter if you are training your teeth on a çm0 or a cm4 chip. The key is to understand basic steps to set up a project and learn good coding habit.

From that perspective, don't get too tied up in the details.
================================
https://dannyelectronics.wordpress.com/
 
The following users thanked this post: alin_im

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: ARM starting platform
« Reply #39 on: July 21, 2016, 10:51:10 pm »
Well you can use printf to dump a stacktrace if you want! I have that enabled for the hard and bus fault interrupts on ARM.
I prefer to actually put a breakpoint in the handler and investigate the issue while the system is still alive with memory and registers intact than have to do it postmortem from a trace, if possible. Stacktraces have their place, but are far from the fastest way of debugging such issue.
But what if a device produces a hard fault (99.9% caused by a pointer problem) suddenly or randomly? With the debugger disconnected or breakpoints set at a different address you'll miss the event and/or don't have any data to analyse. Having the hardfault handler print a trace (the last 16 items on the stack which includes the contents of the registers) has saved my bacon so many times already (usually when including 3rd party code) that it is a standard part of my firmware.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline jokkydee

  • Newbie
  • Posts: 9
  • Country: au
Re: ARM starting platform
« Reply #40 on: July 22, 2016, 02:34:55 am »
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.

I read a post from you earlier this year;

Just to clarify, I really like the look and feel of Eclipse. I like its window layout and I like its editor. I like just about everything about it except its performance. That's always the stumbling block for me. It just feels so sluggish and unresponsive after using something like CrossWorks.

It seems your opinion of Eclipse has changed quite dramatically since then. Does this mean you sorted out the performance issues?
 
The following users thanked this post: Kilrah

Offline zapta

  • Super Contributor
  • ***
  • Posts: 6189
  • Country: us
Re: ARM starting platform
« Reply #41 on: July 22, 2016, 03:18:17 am »

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) ?

I have had good experience with this board

http://www.embeddedartists.com/products/boards/lpc11u35_qsb.php

mbed compatible, single package install lpcxpresso IDE (free, eclipse based, mac, linux, windows), USB bootloader (easy firmware download, no software or special software required), simple design (easy to convert to your own custom designs).

Open source design of a similar board here https://github.com/zapta/arm/tree/master/pro-mini and it's trivial to use in your own custom PCBs https://github.com/zapta/arm/blob/master/pro-mini/board/arm-pro-mini-schematic.pdf 
 
The following users thanked this post: alin_im

Offline Canis Dirus Leidy

  • Regular Contributor
  • *
  • Posts: 214
  • Country: ru
Re: ARM starting platform
« Reply #42 on: July 22, 2016, 02:16:25 pm »
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).

I was thinking of purchasing one of those 2 boards: STM32L476G-DISCO or NXP FRDM-KL46Z. What do think or recommand ?
One of these cheap breadboard-friendly Chinese boards?
 
The following users thanked this post: alin_im

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM starting platform
« Reply #43 on: July 22, 2016, 03:07:08 pm »
Quote
One of these cheap breadboard-friendly Chinese boards?

I have used a ton of those boards. Best bang for your buck.
================================
https://dannyelectronics.wordpress.com/
 

Offline alin_imTopic starter

  • Regular Contributor
  • *
  • Posts: 164
  • Country: gb
Re: ARM starting platform
« Reply #44 on: July 22, 2016, 05:06:00 pm »
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).

I was thinking of purchasing one of those 2 boards: STM32L476G-DISCO or NXP FRDM-KL46Z. What do think or recommend ?
One of these cheap breadboard-friendly Chinese boards?

I want something with more functionality with sensors included to eliminate the hardware wiring and focus on the software. I find that NXP and STM are giving the best low cost platforms at this point. For future projects I will use only the uController but for the moment I want to learn to program better and more efficient.

Thank you for the suggestion though.
One man's 'magic' is another man's engineering. 'Supernatural' is a null word. - Robert A. Heinlein
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #45 on: July 22, 2016, 06:02:50 pm »
I was playing with my trusty old mbed LPC1768 (the original) along with the Application Board:
https://developer.mbed.org/components/mbed-Application-Board/
https://developer.mbed.org/platforms/mbed-LPC1768/

I only really wanted to use the Ethernet port but I did play around with the LCD and the accelerometer.  There is a ton of sample code in the Handbook:
https://developer.mbed.org/handbook/Homepage

Thirty lines of code to make a TCP server that I can connect to with PuTTy on a PC.  A really nice framework for such programs.
« Last Edit: July 22, 2016, 06:08:18 pm by rstofer »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #46 on: July 22, 2016, 07:18:43 pm »
But what if a device produces a hard fault (99.9% caused by a pointer problem) suddenly or randomly? With the debugger disconnected or breakpoints set at a different address you'll miss the event and/or don't have any data to analyse. Having the hardfault handler print a trace (the last 16 items on the stack which includes the contents of the registers) has saved my bacon so many times already (usually when including 3rd party code) that it is a standard part of my firmware.

 That's certainly one solution, however one I see more useful in the field on a deployed system than during development.

Another way of doing it is to use the record feature in gdb and reverse debugging. Have a look at this video:
http://undo.io/resources/presentations/cppcon-2015-greg-law-give-me-15-minutes-ill-change/

He is solving a similar problem - a semi-random crash. He puts a breakpoint in the exit handler, watchpoint on the memory location that is being changed and tells gdb to record the behaviour of the code. And then when the bug happens, he can just walk it back right to the code that has triggered it.

I haven't tried this with the hard fault handler on ARM, but don't see why it shouldn't work.
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: ARM starting platform
« Reply #47 on: July 22, 2016, 08:28:02 pm »
But what if a device produces a hard fault (99.9% caused by a pointer problem) suddenly or randomly? With the debugger disconnected or breakpoints set at a different address you'll miss the event and/or don't have any data to analyse. Having the hardfault handler print a trace (the last 16 items on the stack which includes the contents of the registers) has saved my bacon so many times already (usually when including 3rd party code) that it is a standard part of my firmware.

 That's certainly one solution, however one I see more useful in the field on a deployed system than during development.

Another way of doing it is to use the record feature in gdb and reverse debugging. Have a look at this video:
http://undo.io/resources/presentations/cppcon-2015-greg-law-give-me-15-minutes-ill-change/

He is solving a similar problem - a semi-random crash. He puts a breakpoint in the exit handler, watchpoint on the memory location that is being changed and tells gdb to record the behaviour of the code. And then when the bug happens, he can just walk it back right to the code that has triggered it.

I haven't tried this with the hard fault handler on ARM, but don't see why it shouldn't work.
I can't watch the video from where I'm now but I assume he's using the backtrace functionality of GDB. Because the amount of data pushed onto the stack for each function is known it is not difficult for a debugger to trace the execution back and determine the function's parameters. I use this often when I need to trace the origion of a problem but always for code running on a PC. However I don't see why this shouldn't work with an embedded target (as long as the stack didn't get corrupted).
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline alin_imTopic starter

  • Regular Contributor
  • *
  • Posts: 164
  • Country: gb
Re: ARM starting platform
« Reply #48 on: July 22, 2016, 10:31:39 pm »
I think I will go with the NXP FRDM-KL46Z because has everything I need at the moment and it is accessible in terms of price (about 15 -20 euros).

I have 2 offline compilers to choose from Keil and IAR what do you recommend ? What is most used in industry ?
One man's 'magic' is another man's engineering. 'Supernatural' is a null word. - Robert A. Heinlein
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #49 on: July 22, 2016, 10:46:38 pm »
I can't watch the video from where I'm now but I assume he's using the backtrace functionality of GDB. Because the amount of data pushed onto the stack for each function is known it is not difficult for a debugger to trace the execution back and determine the function's parameters. I use this often when I need to trace the origion of a problem but always for code running on a PC. However I don't see why this shouldn't work with an embedded target (as long as the stack didn't get corrupted).

You are assuming incorrectly. Backtrace is one thing, but won't help you any for a problem like he is solving - a stack smash.

He is using the reverse debugging feature of gdb - you record the execution of the code, gdb records changes to registers and such, and then you can step the code backwards. Here is a tutorial for that: https://www.sourceware.org/gdb/wiki/ProcessRecord/Tutorial

This certainly works on x86 native code and should work with Linux on ARM too, not sure whether native code on bare-metal ARM is supported.



 

Online westfw

  • Super Contributor
  • ***
  • Posts: 4195
  • Country: us
Re: ARM starting platform
« Reply #50 on: July 23, 2016, 05:43:42 am »
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?"
 
The following users thanked this post: alin_im

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #51 on: July 24, 2016, 10:45:22 am »
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


 
The following users thanked this post: alin_im

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 26751
  • Country: nl
    • NCT Developments
Re: ARM starting platform
« Reply #52 on: July 24, 2016, 11:08:08 am »
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.
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: ARM starting platform
« Reply #53 on: July 24, 2016, 11:18:41 am »
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.
« Last Edit: July 24, 2016, 11:21:53 am by tatus1969 »
We Are The Watt - Resistance Is Futile!
 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM starting platform
« Reply #54 on: July 24, 2016, 11:28:43 am »
Quote
have a look at CMSIS. Adds some overhead

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

Quote
- 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.
================================
https://dannyelectronics.wordpress.com/
 

Offline MosherIV

  • Super Contributor
  • ***
  • Posts: 1530
  • Country: gb
Re: ARM starting platform
« Reply #55 on: July 24, 2016, 11:34:19 am »
Quote
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.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #56 on: July 24, 2016, 11:41:43 am »
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
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: ARM starting platform
« Reply #57 on: July 24, 2016, 12:00:49 pm »
Quote
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.
We Are The Watt - Resistance Is Futile!
 

Offline ez24

  • Super Contributor
  • ***
  • Posts: 3082
  • Country: us
  • L.D.A.
Re: ARM starting platform
« Reply #58 on: July 24, 2016, 10:45:58 pm »
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.
YouTube and Website Electronic Resources ------>  https://www.eevblog.com/forum/other-blog-specific/a/msg1341166/#msg1341166
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #59 on: July 24, 2016, 11:28:33 pm »

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.

 

Offline dannyf

  • Super Contributor
  • ***
  • Posts: 8221
  • Country: 00
Re: ARM starting platform
« Reply #60 on: July 25, 2016, 12:18:26 am »
Quote
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.

================================
https://dannyelectronics.wordpress.com/
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #61 on: July 28, 2016, 01:34:08 pm »

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

 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #62 on: July 28, 2016, 01:38:01 pm »
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/
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #63 on: July 28, 2016, 01:54:49 pm »
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.
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #64 on: July 28, 2016, 02:13:50 pm »
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
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #65 on: July 28, 2016, 04:45:26 pm »
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...
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #66 on: July 28, 2016, 05:29:44 pm »
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.





« Last Edit: July 28, 2016, 05:34:41 pm by janoc »
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #67 on: July 28, 2016, 06:02:04 pm »
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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #68 on: July 28, 2016, 08:30:51 pm »
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.
 

Offline tatus1969

  • Super Contributor
  • ***
  • Posts: 1273
  • Country: de
  • Resistance is futile - We Are The Watt.
    • keenlab
Re: ARM starting platform
« Reply #69 on: July 29, 2016, 07:32:25 am »
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.
We Are The Watt - Resistance Is Futile!
 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #70 on: July 29, 2016, 09:50:16 am »
You can use USB otg and FT4232H
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #71 on: July 29, 2016, 01:57:58 pm »
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...
 

Online westfw

  • Super Contributor
  • ***
  • Posts: 4195
  • Country: us
Re: ARM starting platform
« Reply #72 on: July 29, 2016, 03:14:29 pm »
Quote
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)

Quote
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."  :-)
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #73 on: July 29, 2016, 03:28:51 pm »
Quote
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)

Quote
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)
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: ARM starting platform
« Reply #74 on: July 29, 2016, 04:23:41 pm »
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.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #75 on: July 29, 2016, 05:47:51 pm »
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.


Of course!  I have 3 of the STM32F boards sitting right here.  The mbed toolchain handles all of them.

Quote

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.

How odd you would bring that up.  I was just looking at the ESP8266 board (and concept) earlier this morning.  I'm not so sure that it is a board for a new user.  I didn't see it in the dropdown list of boards on the Arduino IDE.  Maybe I missed it...  Nevertheless, I couldn't find enough documentation to answer one simple question:  Can it have 4 concurrent connections?  I suppose right after that I would want to know about throughput.

As to Arduino, I use it strictly to knock together some simple examples.  The last time I used it, all I wanted was "Hello World!" out the serial port so I could test my Rigol DS1054Z serial decoder.  There is no platform out there that is faster for doing that kind of thing.
 

Offline Kilrah

  • Supporter
  • ****
  • Posts: 1852
  • Country: ch
Re: ARM starting platform
« Reply #76 on: July 29, 2016, 05:58:11 pm »
It's not in by default, but Arduino 1.6.4+ has a library manager - you just go in there and install the ESP8266 lib.

I bought 2 of this board, has a bunch of IO wired, the USB -> serial converter on board and battery power input/charger for mobile fun.

It took me half a day to find a basic webserver example, a WS2812 example written for Arduino that ran straight without mods, sample code for a graphic LCD that needed minor mods (the library is 3 years old), and to merge all of those into a single basic program. So yeah pretty easy, almost too much... Now need to actually make my application out of those.

No idea about multiple connections and I believe throughput is pretty low so you won't run a router or fileserver on it, but it's great to provide basic remote access/control capabilities.
« Last Edit: July 29, 2016, 05:59:59 pm by Kilrah »
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #77 on: July 29, 2016, 09:48:47 pm »
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.
...
Does not have any single reason to at least know the mbed plataform.

And you have completely missed my point. Yes, certainly you can do that. But why to add complexity to a problem that is complex enough already for no reason?

If you end up using mBed just to initialize the board + setup GPIO and have to use other frameworks (or resort to registers) for the rest, what's the point of mBed's overhead when you aren't using any of its advantages?

If all you want is some very basic stuff then mBed on STM32 will work. But anything beyond that is a pain. Sadly. On the NXP LPC1768 it works fine, though.
« Last Edit: July 29, 2016, 09:50:31 pm by janoc »
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 9886
  • Country: us
Re: ARM starting platform
« Reply #78 on: July 30, 2016, 12:52:12 am »

If you end up using mBed just to initialize the board + setup GPIO and have to use other frameworks (or resort to registers) for the rest, what's the point of mBed's overhead when you aren't using any of its advantages?


Maybe just mix-and-match.  I needed that interrupt driven SPI slave - mbed doesn't have it so I wrote it.  I also needed networking and mbed DID have it and that saved me a ton of coding.

You're right though, if all you want to do is blink an LED, you certainly don't need the mbed framework.  The toolchain is useful either way.
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #79 on: July 30, 2016, 10:42:02 am »
Maybe just mix-and-match.  I needed that interrupt driven SPI slave - mbed doesn't have it so I wrote it.  I also needed networking and mbed DID have it and that saved me a ton of coding.

You're right though, if all you want to do is blink an LED, you certainly don't need the mbed framework.  The toolchain is useful either way.

Yes, certainly - nothing wrong with the approach. That's not my point, though. I just wouldn't advocate something like that for a beginner when the exact CPU/devboard don't really matter and there are better options available where mBed supports more on-board hardware.

 

Offline ebclr

  • Super Contributor
  • ***
  • Posts: 2328
  • Country: 00
Re: ARM starting platform
« Reply #80 on: July 30, 2016, 02:48:08 pm »
The point of mbed is to use several different arm processor from different vendors and a unique device, that can be easily  replaced, You don't need to get deeper into datasheets finding register to initialize, is everything done on a transparent way. Besides that you can to the bare metal just in case you want that,  On the minimum is a free online KEIL compiler
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: ARM starting platform
« Reply #81 on: July 30, 2016, 02:49:40 pm »
The point of mbed is to use several different arm processor from different vendors and a unique device, that can be easily  replaced, You don't need to get deeper into datasheets finding register to initialize, is everything done on a transparent way. Besides that you can to the bare metal just in case you want that,  On the minimum is a free online KEIL compiler

Please, read what I wrote before you miss the point again and argue about something that is not even in dispute.

 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf