EmbDev.net

Forum: ARM programming with GCC/GNU tools sam7s


Author: Josh Jordan (outerspace)
Posted on:

Rate this post
0 useful
not useful
I am switching down from the sam7s64 to the sam7s321 I was wondering how
to make arm-gcc support the sam7s321.  Thanks.

Author: Martin Thomas (mthomas) (Moderator)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Josh Jordan (outerspace)
Posted on:

Rate this post
0 useful
not useful
Works good just by changing the memory lengths.  Only problem is that
barebones USB takes up 28 of the 32k.

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Josh Jordan (outerspace)
Posted on:

Rate this post
0 useful
not useful
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.

Author: Clifford Slocombe (clifford)
Posted on:

Rate this post
0 useful
not useful
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

Author: Josh Jordan (outerspace)
Posted on:

Rate this post
0 useful
not useful
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?!

Reply

Entering an e-mail address is optional. If you want to receive reply notifications by e-mail, please log in.

Rules — please read before posting

  • Post long source code as attachment, not in the text
  • Posting advertisements is forbidden.

Formatting options

  • [c]C code[/c]
  • [avrasm]AVR assembler code[/avrasm]
  • [code]code in other languages, ASCII drawings[/code]
  • [math]formula (LaTeX syntax)[/math]




Bild automatisch verkleinern, falls nötig
Note: the original post is older than 6 months. Please don't ask any new questions in this thread, but start a new one.