AVR Compiler Recommendations

In article , Paul Curtis writes

My apologies... I was thinking ARM.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Hi Paul,

We stopped buying "commercial" compilers 5 years ago, after we were unable to sort out dongle problems (and permanently lost the ability to compile our own source code!).

Yours is the first commercial "compiler" (development system) that I have even *considered* buying since then.

We primarily use arm-gcc with newlib. This works great for current projects. But for some of the new small ARM microcontrollers coming out now, newlib is probably not ideal. Something like avr-libc would be great but there does not seem to be anything like that as far as I can tell.

So,

- what copy protection is there with your product?

- is the library source code made available (e.g. can you step through it in the debugger or perhaps compile it with different options etc).

- do you have any numbers for the amount of code and data space consumed by the larger functions (e.g. printf, malloc).

Feel free to answer by email if you don't want to say on usenet (although I bet others would be interested too!).

--

John Devereux

newlib is quite big, I grant you.

We license per developer and you activate your product using the keys we provide you. A developer can activate the software wherever they feel comfortable, on a laptop, desktop, home PC, lab PC, or any combination thereof. We also do not license per platform so if you need to use Windows and Linux versions of our software you can, you don't need two licenses.

This is available on request, yes.

Depends upon how you wish to compile this stuff. We have a number of standard formatters which support varying options such as integer widths (16/32/64) and floating point or not, width and precision specifiers, and character classes for scanf. You configure what you want in the IDE and the IDE takes care of linking in the right library. We also offer hosted I/O which means for debugging there is no printf formatter on the target (great for small devices).

Here are some numbers for the program...

void main(void) { printf("1=%d", 1); }

...with a simple null putchar and in debug build:

32-bit int, no width/precision, no fp: 1,340 bytes 32-bit int, with width/precision, no fp: 2,148 bytes 64-bit int, no width/precision, no fp: 1,732 bytes 64-bit int, with width/precision, no fp: 2,704 bytes 64-bit int, with width/precision, 64-bit float I/O: 9,772 bytes

They possibly could be.

-- Paul.

Thanks for the response.

I have been playing with Newlib over the weekend... Basically I had to replace (or avoid) the printf and malloc families of functions. Which I am sure is a good idea anyway, for small devices. Also, if you use any of the library functions that have state, then a "reentrancy" data structure is linked in which is an additional few hundred bytes of RAM.

However, if you avoid these then everything is quite efficient! My test programs are coming out at a few k total, with nothing obviously redundant in the object file.

Great, thank you.

--

John Devereux

I find the reentrancy data a pain for small programs which don't require have to be thread-safe. The idea itself is not bad - it means that each thread can have its own copy of errno, stdin, etc. These are all collected together within a structure, with a single global pointer to the current set. The disadvantage is that if you use any element of this structure, the whole structure is linked in to ram. I don't know any way to avoid this other than replacing or avoiding functions using this structure. Obviously for large programs it makes little difference.

Yes, this is precisely what I found. Luckily for me it appears that, printf and malloc aside, the functions that need the reent structure are ones that I never seem to use anyway. Things like strtok, multibyte and wide character support, locales. I am sure they have a place in larger programs.

What I did was replace malloc+friends with a trivial allocate-only version that only gets called during initialisation.

Then I found a public domain minimal (integer) printf that is ideal for my purposes, and now it is integrated into my project I can also easily adapt it to e.g. add my own conversion specifiers.

--

John Devereux

I'm not a fan of malloc or printf myself - at least, not on small systems when a few hundred bytes of RAM are important. The only time this has been a problem for me was making use of the time and date conversion routines in a program meant to run with 2K of RAM.

What I have ended up with has very little RAM penalty. Of course there is some stack use during execution, but not much.

My "printf"-style function is quite useful for generating the display (there is a tiny gui). And I wanted some kind of a "malloc" so that my library routines are able to allocate their own workspace. They only do this once during startup, so there is no problem with memory leaks, indeterminism or heap fragmentation.

--

John Devereux

Apart from errno, I do not see much need for reentrancy for the other functions. It should be quite easy to concentrate any (l)user interface things, such as printf etc. into the null task, thus, avoiding most of the reentrancy problems anyway.

Paul