AVR-Chat

The native data in GCC is the int, which is two bytes on the AVR.  Even if
you declare a return value as a char, GCC will return an int.  If you use a
char as an input to a switch() statement it will be promoted to int before
all tests (IIRC - this might have changed).  Enums default to int unless you
add -fshort-enums to the compiler command line. etc, etc.

That doesn't explain the declarations.  They should still declare as char or
unsigned char so they can benefit from other compilers, or compiler changes.

In the map file, look at the last entry under .text: that is your code space
usage.  I don't understand the linker: although the sections are in order,
the symbols, within a file, are all mixed up.  Makes it challenging to
figure out how big a particular routine is.

If you are comfortable with C, then there is no reason to mess with BASCOM,
except for all the library support (instant LCD, instant 1 wire, etc).  I
only use BASCOM for prototyping and play work.  I use GCC (and asm) for
almost everything else.

Cheers!

-----Original Message-----
From: Adrian [mailto:adrian650@yahoo.com]
...
More importantly the BASCOM code was BIG. I didn't
look at the disassembly but it was using 70% of a 2313
just for the basic driver code - there's no way my
application would have got in too. GCC code is around
300 bytes (not words if I have read HEX file
correctly). Maybe they put in a bigger start-up
library?

On such a little device as the 2313 it is nice to be
able to access memory via arrays to implement string
functions simply and economically. BASIC hides that.

That brings me to the MAP. The STAMP has a really nice
graphic map to show program, constant and variable
consumption of resources. Can anyone explain how this
can be extracted from map file?

Whilst on resources, I've seen that a number of
example.c files define routines and variables as INT
even thoughnthey are clearly only 8 bits wide. Why
aren't they done as CHAR? Even if they are allocated
dynamically it's still taking more space than needed
and could add confusion if trying to force an INT into
a 8bit PORT.