FAQ:General

From GNU 68HC11/HC12
Jump to: navigation, search

Contents

I have installed everything, what do I do now?

It is suggested to start with a simple example. The GNU Development Chain comes alone and does not have any example packaged with it.

However, you can get the GNU Embedded Libraries which contain a number of utility libraries and several examples. GEL is available at:

[http://gel.sourceforge.net]

You can also compile this small program, which does nothing useful (just to show out the procedure):

unsigned short fact(unsigned short a)
{
  if (a)
    return a * fact (a - 1);
  else
    return 1;
}
int main()
{
  return fact (5) - fact (4);
}

You must compile it with the following command:

  m6811-elf-gcc -o prog.elf prog.c -mshort -g -Os

And you can execute or debug it with the GNU Debugger as follows:

  m6811-elf-gdb prog.elf
  <i>(gdb)</i> target sim
  <i>(gdb)</i> load
  <i>(gdb)</i> b main
  <i>(gdb)</i> run
  <i>(gdb)</i> step
  ...

Is S19 format supported?

Yes.

S19 and Intel Hex records are supported for many many years by the GNU Binutils. They are not the native format because they do not provide all the information that a linker and a debugger need (symbols, relocation, debug information).

It is recommended to let the GNU linker generate the default ELF file and use m6811-elf-objcopy to convert ELF into S19. The ELF file is required by the GNU debugger as it contains the symbolic debug information. The GNU Binutils also provide others tools (nm, size, readelf, objdump) that analyze and can give useful information about a binary program. Most of this information loast when the ELF file is translated in S19.

Why is release 2.x based on gcc 3.0.4 ?

Releases 2.0, 2.1, 2.1.1 and 2.2 are based on the GNU compiler 3.0.4 even though more recent version of the compiler exist (such as 3.1, 3.2 and 3.3). This is because the Release 2.x are intensively validated and the 3.0.4 compiler has been fixed to ensure correct code generation. It took me arround 6 months of work to achieve this.

The 3.1 and 3.2 have several problems that were not yet identified and that require a *lot* of time to fix and solve. Getting the same stability with 3.1 or 3.2 would have required another 6 months of work for me (in my spare time).

Finaly, I prefer to distribute a stable and robust version in which you can trust rather than a more recent compiler less tested and with known generation problems.

Release 3.0 will probably be based on the GNU compiler 3.3 as recent validation with it (on 28 July, 2003) showed good results.

What is ELF?

ELF is a standard binary format to represent object files and programs. What you have to know about ELF is that:

  • It splits the program in several parts called sections.

There is a section for the code (.text), a section for the initialized data (.data), a section for uninitialized data (.bss) and many other sections (debug, symbols, relocations, init code, vectors, ...)

  • When an ELF file contains relocations it is a relocatable

object file and the sections (code, data) can be mapped at any address by the linker. When such object file is disassembled by m6811-elf-objdump it appears as though it starts at address 0.

  • The linker is responsible for collecting the ELF object files and

creating the final program. During this pass, it can merge the sections as well as create new sections. It also uses the relocations to fixup the final addresses of the program.

  • The GNU debugger needs the ELF file in order to have access to

the symbol table as well as the debugging information.

  • The m6811-elf-objcopy tool may be used to convert the ELF

binary format in either S19, Intel Hex, or plain binary image.

Is my processor or board supported?

The GNU Developpement Chain supports all variants of 68HC11, 68HC12 and 68HCS12 micro-controllers.

There is no dependency on any board. This means you can use the tool chain to develop on any board based on a 68HC11, 68HC12 or 68HCS12.

When you develop for a particular board, you must write a memory.x file which describes the memory (RAM and ROM) of the board.

If your board has particular external IOs, you may have to write the support to access and control your specific devices. This can be done in C quite easily. For this you may have to look at the tutorial on the following page:

[http://www.gnu-m68hc11.org/doc/guide.html]

It explains how to start and what is the content of memory.x.

Personal tools