Starting with ARMs micros.

[ptricks]

Pick up one the raspberry pi boards for $25 USD , it is very capable and cheap and a great way to learn about ARM micros.

http://www.raspberrypi.org/

[nctnico]

But thats no an hobby, and many people(like me) cant afford even the 150€ Rowley compiler to blink some leds in the weekends, so gcc is pretty fine for me, and for a lot more hobbists.
IF i was designing some ultra vital embedded gizmo, my company should shovel the thousands needed to have good tools, but I'am an hobbist so gcc it is..

Rowley's ARM compiler is GCC... So that is €150 for something you can get for free and you'll need to spend another $300 on their JTAG dongle. Better get GCC from Codesourcery, Eclipse CDT, OpenOCD and a $15 USB JTAG dongle from Ebay. The only extra time spend is finding an online tutorial on how to set it up.

[T4P]

Pick up one the raspberry pi boards for $25 USD , it is very capable and cheap and a great way to learn about ARM micros.

http://www.raspberrypi.org/

A good way to become a codemonkey  Just throw in all the confusing libraries to run the damn 700MHz CPU and have your code so slow a well written M4 will eat it for lunch,
after all that's not a  uC but a uP so it uses linux as it's operating environment mostly, if you want to avoid writing/using all the damn libraries just to blink some LEDs
so that's a way NOT to learn about ARM micros

I know that ARM hired Codesourcery to develop (enhance)  arm-gcc , but i don't know the status after Codesourcery was bought by Mentor , but why should ARM stop paying the same people (now at Mentor).

If you ever used anything from Mentor you will know why 

[free_electron]

But thats no an hobby, and many people(like me) cant afford even the 150€ Rowley compiler

Ah, yes there is that aspect too. But there are gratis toolchains. Iar gives you a 32k limited version. There is coocox , atollic and some others that have gratis versions.

Or , if it must be totally gratis you need to follow ntcnico's advice : download a bunch of free stuff and spend time learning how to set it up and make it work together. So you can make you blinky light.
Time is also expensive , even as a hobby. There's only 24 hours a day. If i need to spend 8 hours setting up the environment to blink an led.. Where as i can download a 32k version that installs in minutes and has my led blinking 2 minutes later ... I go that way. My goal is to blink an led, not learning how to config eclipse or all the command line arguments of gcc.

But, that's me. I want screwdrivers, not a metal stick and blob of plastic and instructions on how to make those into a screwdriver. It may be cheaper than buying a screwdriver , but the time spent on making the screwdriver could have been spent on putting the screw in( blink the led ) and do plenty of other things. If you don't care about that and like the experience of making the screwdriver, be my guest.

[andyturk]

... download a bunch of free stuff and spend time learning how to set it up and make it work together. So you can make you blinky light.

You were being flip, but that's actually good advice. Going through toolchain pain, figuring out which jumpers go where and all that is part of being proficient. Better to get that out of the way with blinky lights than later on when there are more things to go wrong.

Besides, it seems like half the people on this forum are building their own power supplies for fun... compiling one's own toolchain from source is just more of the same.

[senso]

In the Windows domain I would say that as a free toolchain, Coocox is the best, no limitations, comes with lots of examples, so it really is a 30 min download and in two minutes I can have my blinky rocking hard, and now with support for the STM M4 mcu's, it seems perfect for my uses, CodeSourcery doesnt support hardware floating point(at least it didn't some time ago), and Attolic, is a very limited Eclipse+Gcc combo that doesnt even report the build size you my code.

[jerry507]

Free Electron is giving you a very seasoned point of view. Time is money. I do contract design work so this is especially true. I would love to use GCC and OpenOCD or the like, but I can't justify the time spent. I actually give very few craps about code size and speed. MOST things don't need high speed code or care about 10-20% code size. The reality of code sizing is that the ROM tiers from manufacturers are widely spread and it's only a few cases where the savings will really bump you down a tier. That's my experience, YMMV.

I used a TI Stellaris processor for a project I just finished. NEVER AGAIN. Bad processor? Bad pricing? Nah, nothing like that. The IDE, Code Composer Studio, is a giant pile of crap. Crashed all the time, difficult debugger, not worth my time. I'll pay more for a compiler, and even buy an IDE, just to save the time and money. At 100$ a hour, it saves my customer money pretty quickly and saves my sanity even faster.

Until there is a smooth open source experience for ARM using gcc and the related toolchain bits, I don't see a point. Choose your toolchain (and your IDE!) well.

[ToBeFrank]

... download a bunch of free stuff and spend time learning how to set it up and make it work together. So you can make you blinky light.

You were being flip, but that's actually good advice. Going through toolchain pain, figuring out which jumpers go where and all that is part of being proficient. Better to get that out of the way with blinky lights than later on when there are more things to go wrong.

Besides, it seems like half the people on this forum are building their own power supplies for fun... compiling one's own toolchain from source is just more of the same.

I'm with free_electron. Even as a hobbyist, I'd rather spend my time actually developing my hardware and software. Not being able to compile and set up gcc and Eclipse, etc. hasn't hindered me in the slightest, nor would it help me. It's just wasted time better spent reading the uC datasheet or developing the firmware.

[Mechatrommer]

Time is also expensive...et al

would you exchange time with knowledge? you got a very valid point though. at my age i tended more towards your mentality, but it was different when i was young and had $0 money.

[andyturk]

I used a TI Stellaris processor for a project I just finished. NEVER AGAIN. Bad processor? Bad pricing? Nah, nothing like that. The IDE, Code Composer Studio, is a giant pile of crap.

I was using Stellaris stuff too (for a hobby project), but switched to STM32. That switch was made easier because I'd been using a GCC toolchain that supported both. The change was almost a non-issue was far as software is concerned.

It seems like most OEMs are still living in the '90s thinking that software lock-in (via development systems and proprietary libraries) are a competitive advantage. They should be treating compilers/debuggers/etc as a commodity and focus on the silicon. ARM figured this out when they bought Keil... Now the most highly regarded 8-bit compiler is owned by a competitive platform.

So every time Keil raises prices on their stuff, it gives 8051 folks another reason to switch to ARM for the next design. Very clever of them!

[nctnico]

You could argue that setting up Eclipse may take more time (which it doesn't) but the beautifull thing about Eclipse is that it is a true one-size-fits-all solution aimed at being the best IDE there is. I have been using Eclipse exclusively for developing code for MSP430, ARM, PIC, Coldfire, Linux ARM, Linux x86, Symbian, PHP and Windows professionally (=getting paid for coding) for the past 7 to 8 years. There is no way that using a different IDE for each platform is more time efficient. There is more to a project than blinking a LED. How about integration with code repositories? Merging other people's work into yours? Powerfull editing features? At some point you'll need a professional tool and most uC IDE's simply are not.

[free_electron]

You were being flip, but that's actually good advice. Going through toolchain pain, figuring out which jumpers go where and all that is part of being proficient. Better to get that out of the way with blinky lights than later on when there are more things to go wrong.

MY point is : as a beginner, first get the blinky light running. That confirms the usb port works, the download works and the compiler and linker are ok.
Then you can start fiddling with jumpers and compilation options. Start with a kniwn good system and learn from there on. And change only one thing at a time so you know how to go back to working.

you gotta crawl before you can get up and start walking. There is no point being thrown in the fire from the get go.
There is also nothing more frustrating trying to do something simple like blink an led and have to spendfirst 10 hours trying to get the programming environment to get rolling. You can always move to GCC and eclipse or other things later on.

See it this way : you want to get your drivers licence for the car and the course starts with a 4 year degree in sheetmetal work and how to assemble an engine... that takes the fun out if it very quickly... and it adds NOTHING to actually learning to drive the car. At this point all that stuff is ballast.

[andersm]

I used a TI Stellaris processor for a project I just finished. NEVER AGAIN. Bad processor? Bad pricing? Nah, nothing like that. The IDE, Code Composer Studio, is a giant pile of crap. Crashed all the time, difficult debugger, not worth my time.

Sooo... don't use CCS? Any compiler that supports Cortex-M3 will do, and if you need it you can just download StellarisWare from TI's website.

[Mechatrommer]

See it this way : you want to get your drivers licence for the car and the course starts with a 4 year degree in sheetmetal work and how to assemble an engine...

thinking about it your analogy quite flawed sorry to say , its just my 2cnts. there's a big gap difference between "designer" and "user". as someone else said, a good programmer (designer) knows pretty much all the workflow, from setting up the toolchain or even the command line gcc if he has to (or we?) down to debugging the program and make it run. but the problem is as you've stated it... time, time to do everything. be it to setup or to program, but thats just me. agree with nctnico et al, setting up coocox, netbeans, eclipse and attolic is not that bad at all from my tinkering with them on the surface. all those IDE are installed in my system right now, the only problem i'm yet to figure out what thing to program my ARM, i kind of lose taste with blinking led with it if i have to recommend on those gratis unlimited version ide, i choose CooCox, it seems to have cortex library preinstalled (just it seems to me) but i also do agree with you on using free eval as startup for learning. so both of you are right, so dont fight, it will just make thing worst contribute nothing to humanity

[westfw]

Going through toolchain pain

... is not a good starting point.  It's something you can do anytime, if you want the educational experience, or have become frustrated with the vendor-provided IDE, or NEED to get get support for some feature or larger code or third-party software or whatever.

But it's a pretty big barrier for "starting out", unless your particular area of interest IS "toolchain hacking."

[ptricks]

A good way to become a codemonkey  Just throw in all the confusing libraries to run the damn 700MHz CPU and have your code so slow a well written M4 will eat it for lunch,
after all that's not a  uC but a uP so it uses linux as it's operating environment mostly, if you want to avoid writing/using all the damn libraries just to blink some LEDs
so that's a way NOT to learn about ARM micros

 The difference between a uC and uP is next to zero now, the lines are blurred and will soon be gone completely.  One of the biggest obstacles beginners face is getting started, it is so bad with ARM devices that most beginners quit before they get to the blinking LED part. Unless you are getting a formal education in ARM devices , beginners need to see results to keep their interest. If it takes them hours to learn how to configure the processor, set up ports, and then all they get is a blinking LED they are just going to go back to using an arduino and forget about ARM. If you show them what ARM can do though, and get them hooked on the possibilities then you have someone who might start looking at some of the more intricate details of the architecture.   Anyone who has looked at ST ARM devices and the programming environment knows it isn't user friendly and so will scare off a large mass of people not willing to spend hours on data sheets.   

The pi boards may seem like something you just load programs on and use but it can go a lot deeper if the user is willing to learn it. You don't have to use it with linux, that is your choice, it can do anything the other ARM micros can do , it just has the capabilities to go up in performance if you need it, while smaller dev boards can't go up, you have to get a new board if you want more performance.  I don't own the pi myself, it isn't my target market as I work with ARM9 chips mainly, dismissing it just because it comes with a linux OS is naive because you are free to run anything you want on it, including just to blink an LED.

[Torrentula]

I am a hobbyist and I am using GCC without problems with the STM32F4 and the libs from ST now.
Setting the whole thing up can be really frustrating if you're not some Makefile/GCC guru. It took me a freakin' weekend to set the thing up so I put together a little guide on my website to save people the hassle.

I was fed up with GCC trying to get it to work at first but I had no choice because Atollic just didn't want to connect to the STM32...
Never tried Keil though, which, from what I have read here, seems to be very good.

[T4P]

That's odd ... the first IDE i used is Atollic then i took the elf files and converted into hex then uploaded the hex file with the ST-LINK utility
But i never used the GDB server integration on atollic so i don't know
http://www.kerrywong.com/2011/10/22/stm32f4-discovery-board/ i started off with this guide

Whatever that is, i use IAR now

[jerry507]

This is all talk of compilers. I don't care what compiler I'm using. That concern is many years in the past; there are so many that just work.

What is the biggest concern is debugging support. It's 2012, time to stop using the serial port and blinking leds to debug your code. I usually use vendor IDEs because I have deemed it to be too much trouble to set up a debugger using openocd or something else. That's based off a one time bad taste and might not be generally true.

So all of you gcc fans, how hard was it to get your DEBUGGER working?

[free_electron]

time to stop using the serial port and blinking leds to debug your code.

i second that. I want an environment that let's me set breakpoints, watch variables , modify the content of the variables and resume the run , trigger interrupts , watch io ports and registers and, if at all possible in real time and non-blocking so it does not impact the running code.
Being able to set a trap ( for example : if this registers or memory location content are equal to this : halt and show me where i am in my sourcecode. i need to know what portion mods this value) .

the ability to snoop around in memory is just tremendous. i have a system with cpu and fpga. the fpga has registers memory mapped in the ARM's main memory. using the ARM JTAG i am able to watch this , write to the fpga and verify the fpga is sending back the right information in the right spots. all without writing a singl line of code. i can debug the entire system, verify it works as expected and then write the HAL once , knowing it will be correct. all i needed was the Segger J-link and the segger Memprobe software ( comes with it ) this lets you snoop around anywhere in memory while the processor is running code. i can flick bits in there and see if my code reacts correctly . this way i can isolate code problems from hardware problems.

I upload the ARM code through the FPGA ( so there is a 'hardware' bootloader ) from a serial flash rom , straight into main memory ( the FPGA takes over tha address and data lines and holds the ARM in reset , then changes the bus multiplexer and arbiters around and let's the ARM run. )
getting this mechanism to run was a doddle. JTAg on fpga : perform the register operations. JTAG on ARM : read memory location and see if data arrived at the right spot. Not a single line of code involved. Everything was tested through the debuggers. Then write the software library and FPGA code. Compile, run and verify by simply dumping the memory using the JTAG. It took less than an hour to get this board in a bootable state.

Doing that with a text editor , command line compiler and a blinking led and a serial port is bonkers. Even for hobbyist use. a JTAG probe costs next to nothing (99$) and opens a whole new door. and most of the real probes are platform agnostic.

[T4P]

JTAG ... You can get a J-Link clone for only 10dollars+ ..

[andersm]

So all of you gcc fans, how hard was it to get your DEBUGGER working?

The version of OpenOCD I use disagreed with the version of GDB I use about how the Cortex-M3 registers were supposed to be reported. That took maybe 10-15 minutes of Googling and an XML file to solve, other than that it was very straightforward. My JTAG interface (a €30 FTDI dongle) is well supported, so I could just use the supplied configuration files directly.

[Mechatrommer]

I want an environment that let's me set breakpoints, watch variables , modify the content of the variables and resume the run , trigger interrupts , watch io ports and registers and, if at all possible in real time and non-blocking so it does not impact the running code.

setting and viewing pin value (interrupt, IO, bus values) in interactive manner or in stimuli file (like avr studio) created in timeline or interactive manner. avr studio has this but i believe i need to understand robot language to edit the stimuli file.

[mrflibble]

MY point is : as a beginner, first get the blinky light running. That confirms the usb port works, the download works and the compiler and linker are ok.
Then you can start fiddling with jumpers and compilation options. Start with a kniwn good system and learn from there on. And change only one thing at a time so you know how to go back to working.

Couldn't agree more. Get a known to work situation first, and that can be as boring as some blinkenlights. Once you have that, then you slowly start changing this and that.

For the STM32F4 I started out with gcc + Makefiles, and st-link for flashing + gdb for debugging. That worked reasonably well, but at that point in the learning curve I'd rather have an IDE to get things done a bit faster. Sooooo took a look at eclipse etc, and ended up rebooting to windoze and installing Atollic. That wasn't so bad. I mean, after rebooting I got to shoot me some zombies so all in all that worked out well. Oh yes, and Atollic worked fine too. What I liked about it were the provided sample projects. Nothing fancy, but handy to get started.

After getting a feel for how to mess about on the STM32F4 I decided to give the eclipse install fest another go. So now I use eclipse + regular arm-none-eabi-gcc + stlink under linux and that works just fine.

Oh yes, and ST's provided support as is: crap-onnastick, but that goes without saying. But oh well, nice hardware.

And my lesson learned for getting a toolchain for an ST product: next time pre-emptively give up hope of getting a decent open source based toolchain working in a reasonable amount of time. Just install the free edition of windows based toolchain from vendor <toss-coin>, play around with that first, and only when that works think about some open source toolchain or other.

[nctnico]

I once visited a seminar with a bunch of seasoned embedded programmers. It turned out half of them used JTAG debuggers and the other half used a command line interpreter and a scope.