Josh Jordan wrote:
> I am switching down from the sam7s64 to the sam7s321 I was wondering how
> to make arm-gcc support the sam7s321.  Thanks.

The GNU cross-compiler does support the controller since the ARM core is
the same as in the 7S64 so there is no need to "make support" for the
compiler itself. As far as I know the 7S321 is very similar to the
S64/S256 but does not offer all functions. So far I have not worked with
a 7S321 so just some general remarks:
- adjust the memory-sizes in the linker-script (LEN/LENGTH in MEMORY) so
the linker can check if the code does fit into the available (smaller)
memory
- if there are differences in the integreted peripherals (i.e.
clock-system, Pin assigments, functions available just in the "larger"
device) you have to modify the source ("driver"-code and maybe
startup/lowlevelinit). Atmel usualy provides some examples for other
toolsets (mostly for EWARM) which can be used as templates. The needed
modifications should be minimal if any.
- check manual, register-defintions-files and at91-library for
differences.

Works good just by changing the memory lengths.  Only problem is that
barebones USB takes up 28 of the 32k.

Josh Jordan wrote:
> Works good just by changing the memory lengths.  Only problem is that
> barebones USB takes up 28 of the 32k.

Can you provide a link to the 'bare bones' code you are using? Without
knowing what the code is, it is impossible to help or advise.

Clifford Slocombe wrote:
> Josh Jordan wrote:
>> Works good just by changing the memory lengths.  Only problem is that
>> barebones USB takes up 28 of the 32k.
>
> Can you provide a link to the 'bare bones' code you are using? Without
> knowing what the code is, it is impossible to help or advise.

Its not so much a problem but a comment about the 321.  The atmel
supplied cdc_enumerate.c only comes up to 10k but supporting it with a
version of printf makes it approach 32k.  I have to take out the printf
or use the 7s64.  The printf is just for testing/debugging the real
application transfers binary data.  I dont really have a link to the
code except to say that it includes cdc_enumerate.h, stdio.h, stdarg.h,
and string.h.

Josh Jordan wrote:
> Its not so much a problem but a comment about the 321.  The atmel
> supplied cdc_enumerate.c only comes up to 10k but supporting it with a
> version of printf makes it approach 32k.  I have to take out the printf
> or use the 7s64.  The printf is just for testing/debugging the real
> application transfers binary data.  I dont really have a link to the
> code except to say that it includes cdc_enumerate.h, stdio.h, stdarg.h,
> and string.h.

Hardly 'bare bones' then. printf() is large (and requires a significant
amount of stack as well), it supports formatted I/O for things such as
floating point which is unlikely to be needed but adds considerably to
teh weight. If you don't need formatted I/O at all, consider using
puts() instead.

If you do need formatted I/O use a 'cut-down' implementation such as
that provided here:
http://www.menie.org/georges/embedded/index.html#printf

Clifford

Clifford Slocombe wrote:

>
> If you do need formatted I/O use a 'cut-down' implementation such as
> that provided here:
> http://www.menie.org/georges/embedded/index.html#printf
>
> Clifford

I got my app down to 3k. thanks!  may end up using the 161?!