ARM development software

TheDirty:
I can see why they say you like to argue nonsensically.

you too.

Converting all your code to GCC is not trivial.

it depends on how the code is written. I often port code across mcu platforms and have had no problem with that.

Why would you start with a development tool that you can’t continue to use?

because you needs may change.

Your assertion that hobbyists using ARM chips do not go over 32k is frankly ridiculous and silly.

your assertion that I asserted that is ridiculous and silly. I was merely saying that it has not been an issue with ME. i cannot speak for others.

My embedded ethernet project is over 32k and I’ve just really started with this…

then the free versions of keil / iar are not for you. it is just that obvious.

but that doesn’t mean that they are not for others. our needs are diverse and what works for me may not work for you and what don’t work for you may work for me. you will just have to recognize that.

inventore123:
+1 for GCC

when I started with arm, i did some study on the various ides and one thing that worried me then was the code quality of the gcc compiler and its “ever-changing” nature. they seem to be less mature and create (more?) bloated code in the end.

My last ARM project was an mp3 player and the code was 175KB, because it had:

I believe the limitation is to the code section but not the size of the .hex file (ie code + data). I have compiled a small program with large bitmap (>32k) with no program in keil - haven’t tried it on a real mcu so i couldn’t tell if it actually worked but the compiler didn’t complain about it.

edit: i wanted to add that I was wrong above the last point. if the code includes a large piece of data that is linked into the .hex file, the linker in the free demo version will complain about its size. if your code has a large piece of data but does not reference it (as i did), the compiler will not include the data piece in the .hex file and the linker will thus not complain.

hope it clarifies.

also, you can run GCC from within Keil so you get the best of both worlds: free and unlimited GCC compiler and a great gui from Keil.

inventore123:
My last ARM project was an mp3 player and the code was 175KB, because it had:

  • 35KB of bitmap colour images stored to flash (even those alone would break the code limit!)

  • self-designed RTOS

  • FAT32 read/write library

  • part of the C and C++ standard library

  • many lines of code for GUI drawing, and application code

\

For reference: My current unfinished project is 4,700 lines of C code and compiles to much less than 32KB of flash in thumb mode and a 30% or so more in ARM mode. This includes the app, a cooperative task scheduler (single stack, multiple finite state machines instead of a preemptive RTOS), and a dual serial port buffered interrupt driver. And periodic timer.

As to RAM use, I am very careful to not declare static RAM buffers willy-nilly as PC people do. Tasks use no RAM if they are dormant.

With debugging on, it’s much larger.

one thing that worried me then was the code quality of the gcc compiler and its “ever-changing” nature. they seem to be less mature and create (more?) bloated code in the end.

It's ever changing because it is constantly improved. That's a good thing, not a bad one.

also, you can run GCC from within Keil so you get the best of both worlds: free and unlimited GCC compiler and a great gui from Keil.

That's good, i didn't know it was possible. But so you were more worried by the GCC's ease of use than of it's code quality ;)

For reference: My current unfinished project is 4,700 lines of C code and compiles to much less than 32KB

Well, let's take 175KB and remove the 35KB of images, which is 140KB

Then consider that I have:

  • 20,000 lines of C++ code, with classes, templates, virtual functions and exceptions

(this is considering the preemptive RTOS, GUI library, filesystem library and application code)

  • malloc/free, new/delete

  • printf/sprintf with floating point support

  • fopen, fclose, fread, fwrite from C standard library (that call low level filesystem library)

  • other C standard library functions

  • floating point math

  • from C++ standard library

This is all ARM code, no thumb, no interworking.

To me it still seems an acceptable code size.

And by the way, the cpu is an LPC2138 with 500KB of flash, so what’s the point in shrinking so much the code? The nice thing of ARM is that they have lots of flash 8)

stevech, you haven’t said what compiler are you using

inventore123:
It’s ever changing because it is constantly improved. That’s a good thing, not a bad one.

it depends. to me, the compilers / ides are a tool i use to achieve my goal. i don’t want to constantly learn about my tools.

But so you were more worried by the GCC’s ease of use than of it’s code quality :wink:

its code quality is my worry. as to its ease of use, well, gcc itself is just command line and has no ease of use to speak of. it is the ides on top of it that has the concept of ease of use.

stevech, you haven’t said what compiler are you using

he seems to suggest that he like iar earlier in the thread.

GCC is NOT just a command line compiler. WINARM, WINAVR, YAGARTO are IDEs. Rowley too, since it’s GCC based.

But, in terms of support, stability, contractual recourse if there is a show-stopping bug in the tools, and shorter learning curve, a commercial compiler is always prudent. And these factors are why there are companies selling such.

IMO, the code quality from IAR and Keil is probably insignificantly different. Ease of use, documentation, debugger/JTAG support quite similar. ImageCraft has a lower cost commercial compiler. After try-before-buy, I chose IAR and J-Link, with the dongle license scheme. Very pleased.

stevech:
GCC is NOT just a command line compiler. WINARM, WINAVR, YAGARTO are IDEs. Rowley too, since it’s GCC based.

gcc the compiler / linker / utility / etc. (toolchain) is command-line based.

the IDEs (winarm, yagarto, keil uvision, etc.) provide a gui to the commandline programs.

it is the same set-up with PICC (commandline compiler) and hi-tide (gui) / mplab (gui), etc.

millwood:

stevech:
GCC is NOT just a command line compiler. WINARM, WINAVR, YAGARTO are IDEs. Rowley too, since it’s GCC based.

gcc the compiler / linker / utility / etc. (toolchain) is command-line based.

The fact that gcc is both a command-line compiler AND can be accessed from an IDE is a bonus. Whereas IDEs are indispensible during the initial coding phase of development, command-line compilers can be very useful for non-interactive batch-builds during the maintenance / release phases e.g. if you are supporting several different targets with your application.

For that very reason although our Armaide Oberon-07 development system has a fully integrated compiler and linker, a separate command-line compiler and linker were also developed.

Not having a batch operation command line compiler is a major show stopper.

GCC is in no way scary. GDB is a great debugger. Its just what kool-aid you like swallowing, and I am very much in the UNIX tools arena.

cfb:
The fact that gcc is both a command-line compiler AND can be accessed from an IDE is a bonus.

sure. I was simply pointing out that gcc itself is a command line thing.

as to a bonus, yes, it can be benefitial to have a command line compiler. but it can also be detrimental to have to use a command line compiler. those of us who suffered through Lattice C, or Algol or Fortran on PDP11/VAX should know what a welcome it was to use Turbo Pascal or Turbo C’s IDEs.

it was just so much easier to debug in an IDE.

Having a command line compiler is good for many things.

It is good for the GCC developers themselves that can concentrate in optimizing code generation without being distracted by GUI design.

It is good for users because they can do batch builds, as you pointed out.

But it is also good because users can choose the IDE they want, using GCC as a backend.

I’ve seen GCC used with many IDEs, like Eclipse, Dev-Cpp, Code::blocks, Avr-studio, plain makefiles and the shell…

I currently use arm-elf-gcc with Netbeans, on a Linux system, because I like the way code completion works in Netbeans. This is not a common chioce, but works well.

It’s this kind of flexibility that I like, together with being able to use GCC on Windows, Linux, Mac OSX. And to compile for x86, ARM, AVR, MSP430 and may other processors. And to write my code in C, C++, Fortran, ADA (even if I’ve currently only used C and C++).

This is why GCC has always been my compiler of choice.

I think no other compiler can do these things. :slight_smile:

inventore123:
Having a command line compiler is good for many things.

It is good for the GCC developers themselves that can concentrate in optimizing code generation without being distracted by GUI design.

Why discuss the needs of the tiny few compiler developers in the context of IDEs? That is, what’s convenient for tool MAKERS isn’t of much importance to tool USERS.

I remember way back when X11/Motif came out. A died in the wool shell programmer I knew refused to touch a mouse. Said it was a distraction.

inventore123:
I think no other compiler can do these things. :slight_smile:

maybe because the demand isn’t enough to motivate a commercial effort for that.

stevech:
I remember way back when X11/Motif came out. A died in the wool shell programmer I knew refused to touch a mouse. Said it was a distraction.

I resisted windows for the longest time, until I had to migrate and now I am happy with Windows and wouldn’t go back to DOS.

maybe because the demand isn’t enough to motivate a commercial effort for that.

Luckiliy open source compilers exists. Otherwise people wouldn't have all those features GCC has.

The good thing of open source software is not only that the source is available so you can understand how programs work, and not only that they are free, but also that open source tools can exist for which there isn’t enough demand to motivate a commercial effort.

If and when you will need a software that falls in that category, you’ll be pleased of the existence of open source tools.

I think this goes back to stevech’s comments (not trying to put words in his mouth). most people are interested to use compilers / ides as a tool to achieve their goals. so it adds no or little value for them to have the ability to understand how the tools work, or to produce a highly tailored tool for themselves.

the same reason we drive cars without knowing every intricacy about electronics, mechanics, transmission, etc. that go into our cars, or our computers, etc.

different people have different priorities, and I guess that’s why different compiler vendors, including GCC, thrive.

millwood:
different people have different priorities, and I guess that’s why different compiler vendors, including GCC, thrive.

GCC thrives because people give generously of their time to create and sustain it. This is to the benefit of, mainly, students. I discourage my employer from relying on it professionally for liability reasons… no recourse for remedies. Sadly, same applies to a few product companies like Microsoft, as they are indifferent about standards-compliance and effective quality assurance; Thus due to their government-permitted monopoly, they go the road called “Without Competition, There Is No Excellence”.

do you really think that liability issue is real? I haven’t seen the real licensing agreement in all of those commercial compilers but I would think if the lawyers at Keil / ARM / IAR / etc. are any good, they would have put disclaimers and reps / warranties to limit their liabilities to probably nothing more than your purchase price.

as to Microsoft, I have a rather positive view of those folks. Without them, a lot of what we take for granted wouldn’t have been possible, at least in the time frame they were made possible to us. but that’s another topic for another day.

Suppliers of compilers (and other software) generally disclaim all liability in their license terms.

Leon