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