Starting with ARMs micros.

[firewalker]

Triggered by >this< thread I had a look for free ARM toolchains (gcc) set up, IDE e.t.c.

Tbh I was expecting (knowing gcc tools for ARM is there) something like the AVR micros setup witch is trivial (for both Win32 and GNU/Linux). It seems like that setting up an environment for a particular ARM micro on GNU/Linux is more difficult.

Is an IDE like Keil (proprietary, 32kb limit free version, win32 only), CrossWorks (proprietary, gcc based, no free version), IAR (proprietary, 32kb limit free version) the way to start with ARM micros?

Alexander.

[ColinB]

I use sourcery code bench lite: a free GCC tool chain, and make files , and gvim. Or Eclipse CDT if you want an IDE.

[firewalker]

I found some Yagarto build scripts (for GNU/Linux). I didn;t tried it though.

http://www.yagarto.de/
http://sourceforge.net/projects/yagarto/

Alexander.

[phil_jp1]

I think it is better to start with commercial IDE, get a little bit of practice (or at least get some code to work there) and then move to some opensource toolchains. Because if to start from opensource toolchains off the bat - you'll be dealing with toolchain/IDE integration problems and would not know whether it is something wrong with your code, or is it something else.

[firewalker]

I use sourcery code bench lite: a free GCC tool chain, and make files , and gvim. Or Eclipse CDT if you want an IDE.

After setting up your environment... How do you proceed? You will need some target specific stuff (header files e.t.c.), yes? Lets say you want to play around with the NXP's DIP-28 LPC1114FN28 chip, or the TI's cheap (for now) StellarisEK-LM4F120XL board.

I am intentionally asking so many details (that may sound stupid to someone experienced) but I believe it will help others less experienced users.

Alexander.

[poorchava]

open source toolchains have one significant flaw: they are set back in relation to commercial stuff.

I'm also starting with ARMs (very slowly - general lack of free time). NXP and ST have cheap evaluation boards which contain on-board debugger. I think all of those offer possibility of separating the debugger from the rest of board in order to use it as standalone adapter.

I'm currently waiting for my LPC Xpresso to arrive (some unexpected leadtime). LPC Xpresso with LPC1114 (cortex m0) costs simething liek $30 for the board with mcu and debugger. You can buy a larger 'mother-board' for all LPC Xpresso modules, which contains stuff like buttons, leds, lcd and the like. It costs something like $60 (at least here in Poland)

ST offers STM32FxxxDiscovery. I think these boards begin at $15 or something.

And of course there is Stellaris Launchpad for which i'm really waiting.

LPC Xpresso has it's own and -according to opinions of users - quite functional IDE, but I think other commercial IDEs also support it (Atollic?)
STM32 Discovery boards are supposed to work with IAR, Keil and Atollic, but I had some unpleasant experiences in the pst, where on-board STLinkV2 wouldn't cooperate with neither Keil nor IAR. I finally got Keil to work by replacing some dll's with older versions, but i guess that's not the way it's supposed to work.

I think most of the commercial packages also support various FTDI-based JTAG adapters such as Turtelizer, JTAG-lock-pick (http://www.distortec.com/), Olimex stuff. I think also BusBlaster and BusPirate can be made to work like that.

[andyg]

CooCox CoIDE is also a nice IDE to use (works with ARM GCC), it's free to use no code size limit. Works well with STM32 discovery boards, which are also cheap as chips.

[shebu18]

http://www.mikroe.com/mikromedia/stm32-m4/
Mikromedia with STM32 M4 (STM32F407VGT6) for 100$. it has a touchscreen and sd card reader, audio accelerometer, batery connector.
I looked at this for some time. You can also try the MicroC for ARM and the Visual TFT software from them. I know you have some limits and it is not cheep.






LE: Found this on ebay: http://www.ebay.de/itm/NXP-OM13000-BOARD-LPCXPRESSO-LPC1769-1-Stuck-/310435447312?pt=Wissenschaftliche_Ger%C3%A4te&hash=item4847650210

[ElektroQuark]

I am intentionally asking so many details (that may sound stupid to someone experienced) but I believe it will help others less experienced users.

Yep, we need a step by step guide for dummies here.

[hans]

LPC Xpresso has it's own and -according to opinions of users - quite functional IDE, but I think other commercial IDEs also support it (Atollic?)
STM32 Discovery boards are supposed to work with IAR, Keil and Atollic, but I had some unpleasant experiences in the pst, where on-board STLinkV2 wouldn't cooperate with neither Keil nor IAR. I finally got Keil to work by replacing some dll's with older versions, but i guess that's not the way it's supposed to work.

I think most of the commercial packages also support various FTDI-based JTAG adapters such as Turtelizer, JTAG-lock-pick (http://www.distortec.com/), Olimex stuff. I think also BusBlaster and BusPirate can be made to work like that.

LPC Xpresso is paired up with CodeRed which has it's proprietary debugger. This debugger will only work with their IDE. If you start a debug session, the debugger will be programmed (USB bootloader) and run. If you exit the IDE it will break itself.
The IDE is usable. It even contains semihosting so you don't need a FTDI cable for a debug UART. However, my first experience with LPCxpresso wasn't 'very smooth'. But it works, sort a.

Most commercial tools only run on Windows, just like most other professional PCB CAD tools.

I would go with Coocox, it's really useful. If you want to spend money on a debugger,  I guess you can go with a FTDI cable. I have never tried this combination though.
I know from experience that IAR doesn't like the combination with Olimex programmers (some are FTDI cables, some are custom)> Especially the J-link clone is horrible on Windows Vista/7. I had to repower the programmer (plugging in/out USB) everytime I wanted to start a new debug session. Pretty poor.
There is also something like GDB server or something. I never got it to work flawlessly. This was both in IAR.

J-LINK EDU is also an alternative. It's only 50 euro's and supports all devices, it's fast and supports unlimited HW breakpoints. Then again, most boards contain onboard debuggers, which is sufficient for starters.

ST provides devboards with ST-Link onboard, which can be used off board as a SWD debugger for STM32 devices. The STM32 discovery boards are great value.. it breaks out all the pins (labelled), the STM32F4 even has some demo devices on it (accelero, some sound stuff), onboard debugger for <20 euro's. You are not bound to an IDE; CooCox works, just like many others.

I'm not very impressed by NXP's effort in the market. The CodeRed debugger isn't the best (ST-Link is far superior). You're bound to their toolset, which is very frustrating.

[ju1ce]

I bought a "Cygni" dev board (TI Cortex M3) but haven't really had the time to play with it. The documentation does seem impressive, it works with open source tools and JTAG.

http://teholabs.com/docs/cygni:overview

[free_electron]

The cut and dry solution is to buy a devkit from ST. they are dirt cheap , come with debuggers and you plunk on the IAR or Keil IDE.
both these IDE support all the devkits form ST with libraries and plenty of samples.

The advantage is that you don't need to muck about with compiler settings , linker settings , init code etc. The IDE takes care of all that.

The ARM processor itself is easy, it's the peripherals and , most notably : the setup. These processors ave so many different power states, clock oscillator capabilities , pll's and other stuff that needs initialization that you are better off with a commercial IDE. you simply tell : this clockspeed, use this source and the ide set's all the bits in the right registers.

you can then look at that generated startup code , see how it works and use that if you later move to open-sauce things ( not that i recommend those ... the Great-Crap-Compiler doesn't come close to what the commercial compilers can produce. Especially the Keil compilers .. since these are made by the people that make the core itself. The ultimate is RVDS (soon to be called DS for Development Studio) from Keil but that is out of reach for most of us due to its price tag. DS comes equipped with source profilers and meshes with several hardware debuggers that allow for realtime code monitoring.)

but we digress. where was i (prior to bashing gcc crud) .. ah yes.
when you move away from the codesize limited demo's ( because you don't want to shell out money for them ) you can use the startup code to get going.
That is the key advantage of the 'packaged' development system: they get you up on your feet very quickly. you can dig in the nitty-gritty later.

[andersm]

TI's Stellaris boards also have integrated debugger interfaces, and can be used to debug other Stellaris boards (I suspect they can be used as generic JTAG/SWD interfaces with eg. OpenOCD, but haven't tried). In the old Luminary days every kit also had some kind of display, but I don't know if that's true anymore.

[westfw]

Is an IDE like [various proprietary choices] the way to start with ARM micros?

Yes, I think so.  The one provided by your eval board provider.  That way you get the peripheral definitions and debugger support that go with that particular chip/board/environment.  It'll be a while before one can plunk an arm chip on a protoboard and be off and moving...

I would suspect that at some point you can start subbing in gnu tools to get around size limitations, if you must.

I'm looking forward to the Arduino-based ARM tools, based on the way the PIC32 Arduino-like boards went.  If nothing else, Arduino does a good job of narrowing down the bits needed to support a small subset of available capabilities.

[gxti]

I've had zero problems using gcc and GNU binutils with the STM32 peripheral library (STM32F1 and STM32F4). The trouble comes with the programming/debugging interface (openocd) -- it mostly works with swd but things are still a little wonky. The vendor-supplied IDE is going to excel at programming and debugging that vendor's parts.

[andyturk]

... the Great-Crap-Compiler doesn't come close to what the commercial compilers can produce. Especially the Keil compilers ...

I've read similar comments elsewhere on the web, but honestly, I haven't seen many (any?) convincing studies that prove the point. It seems like GCC's support for ARM has been changing a lot over the past few years, and many of the negatives are now historical artifacts.

Oh, and IDEs are for wimps. ;-)

[48X24X48X]

After initially started with IDE move (Codelite), I ended up using the command prompt only.
Understanding the make files helps a lot in this case. The IDE just looks too complex for my liking.

[firewalker]

I've read similar comments elsewhere on the web, but honestly, I haven't seen many (any?) convincing studies that prove the point. It seems like GCC's support for ARM has been changing a lot over the past few years, and many of the negatives are now historical artifacts.

Oh, and IDEs are for wimps. ;-)

If I understand correctly (the last two days I started looking at ARM), ARM actually pays developers to produce the Code Sourcery. I don't believe GCC for ARM is crap. Not as good as other compilers yes.

Alexander.

[nctnico]

I've seen a study somewhere which shows that ARM's own compiler produces code which is a few percent smaller and faster than GCC. The problem is that compiler vendors prohibit users from benchmarking their compilers against competitors and publishing the results. Keil used to have a page on their website comparing their compiler with GCC. They forgot to tell that they tested their own compiler with full optimisation and gcc with no optimisation at all. That page was erased when someone retested and discovered Keil's compiler was actually pretty crappy.

Another problem with testing is that most tests (including wetstone and drystone tests) also depend on how efficient the C library is. So even though a compiler may be worse than gcc, gcc may look slower while it isn't. All in all it is difficult to create a test which just tests the compiler. If you put a lot of benchmarks side to side you'll see that in general GCC is just as good as high end commercial compilers. Besides that there are many commercial compiler vendors which sell you gcc with their C library and IDE.

[firewalker]

I've read similar comments elsewhere on the web, but honestly, I haven't seen many (any?) convincing studies that prove the point. It seems like GCC's support for ARM has been changing a lot over the past few years, and many of the negatives are now historical artifacts.

Oh, and IDEs are for wimps. ;-)

If I understand correctly (the last two days I started looking at ARM), ARM actually pays developers to produce the Code Sourcery. I don't believe GCC for ARM is crap. Not as good as other compilers... Yes.

Alexander.

[bingo600]

I just stumbled across this toolchain (are those guyzz ARM)  ... See How2Build pdf

https://launchpad.net/gcc-arm-embedded
https://launchpad.net/gcc-arm-embedded/4.6/4.6-2012-q2-update/+download/How-to-build-toolchain.pdf
https://launchpad.net/gcc-arm-embedded/4.6/4.6-2012-q2-update/+download/readme.txt

I'm confused ...... 

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

But the above page hints that they are ARM , and the first page in the pdf says ARM ltd.
I'm in doubt ?

But the compiler seems to be well documented , and they have an active supportforum.

I'll definately do some size testing against codesourcery-lite.

Hmmm.... reread the readme.txt , did i spot RDI-support (semihosting librdimon.a), that would be nice if RDI debugging is possible (from a J-Link point of view).


/Bingo

[free_electron]

While many vendors use GCC as the core compiler they modify the libraries and create a new optimizer... and that's where the money is... The real tools use a closed compiler that is designed for a particular core.

That is the problem with GCC. it tries to be too many things. it can compile for this core, for that core and for 75 other cores... but it is optimized for none of it. GCC also assumes the machine is heavily register based. Try compiling for a core that doesn'tt have registers ( only an accumulator , b register and a flags register )  and gcc starts prodcuing absolute garbage becasue it has to depend on a runtime library to 'emulate' registers.

Granted ,this point is moot for AVR and ARM as these are register based cores. Try an 8051 and it goes to snot ( actually the 'c' language is heavily depending on register based architectures as it was designed on such an architecture. ) and the only way around is using dedicated compiler.

There is another bit of trickery... cores like ARM have debugging features and certain trace registers that are not publicly known. the ARM supplied compiler (RVDS) may make use of these in cooperation with the debugger. ARM may licence this technology or discole this only to specific partners like Keil or IAR. this is not going to be found in GCC .... so GCC is at a disadvantage.

As for benchmakring. the only thing i can say there is my customers use asics with multiple ARM cores in them and they use RVDS. they have tried GCC ( actually some of their engineers develop test code using GCC but when it comes to production release : it has to go through RVDS and be fully profiled.  RVDS and the other commercial IDE's are much more than a compiler. compilation is only one aspect of code development. There is the whole tracing , debugging ( nonintruive and realtime if possible ) conundrum as well...
that's why companies like AMerican Arium , Nohau , Lauterbach,  Greenhills et al are still in business...

[bingo600]

I don't disagree that RVDS or Keil or IAR might produce better code.
And the cost of those tools including a Lauterbach for debuging , is peanuts for for multi billion companys.

But for me as a hobbyist  GCC is doing a very nice job , and i can only recommend it to other people on a "normal" budget.

Ps: I'd prob select sdcc if i needed to generate 8051 code , it's also free.

/Bingo

[free_electron]

oh absolutely. gcc is fine for a lot of things. if you only need a compiler.

As soon as you want source code tracing , interactive debug , watchpoints , interrupt tracint and other things then a compiler doesn't do anyhing. That's where you need the IDE which integrates code editing , compilation , inverse assembly and the binding to the JTAG or other debug channels.
And some IDE's use eclipse and GCC as front and backend and provide some other magical glue. Want it more integrated you will have to start looking at heavily custom environments.

[senso]

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

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

[firewalker]

What board would you suggest for a beginner? Having in mind GNU/Linux perhaps.

Alexander.

[mrflibble]

The stm32f4-discovery has nice price/performance. Lots of peripherals on there for the money. I have two of those and really like them. The only drawback being that you'll need some patience to set up the toolchain under linux.

[jerry507]

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.

The caveat to any statement like this is that open source people rarely care what best practices are, they're stubborn enough to do things just their own way. Real change in the OOS community comes about when something new comes along and a bunch of new people enter the community, or when old people die off and take their ridiculousness with them.

I should try to get gcc and gdb working on that stellaris launchpad board when it arrives. I can't realistically justify charging a customer for that learning experience, so I have to do it at home

[nctnico]

The advantage of that is that gcc+gdb works on a very wide variety of platforms so acquiring that knowledge is sure to serve you in the future :-)

[ptricks]

What board would you suggest for a beginner? Having in mind GNU/Linux perhaps.

Alexander.

I would steer beginners interested in doing small projects towards NXP based boards. The reason is that the NXP processors are better documented, have much more user friendly guides and a larger community of hobbyist. The software side is well supported in commercial and free compilers.

If you look here you can see lots of tools including things like RTOS.
http://www.lpcware.com/

The IDE they recommend is also free to use and works on linux and windows. No jtag is needed since the board comes with one and you can detach that part of the board and use that jtag with other devices.
About $19 USD to get started
http://www.mouser.com/ProductDetail/NXP/OM13014598/?qs=%2fha2pyFadujrwYJlp6DWmVh5iNpMY%252b%2fNHQbKmEiCLkVZqXX2XYgklQ%3d%3d

[firewalker]

Yes NXP seems to be a good choice.

Alexander