Re: [avr-libc-dev] RFC: Database for device properties.?

[Björn Haase]

Uwe Fechner wrote on Freitag, 21. April 2006 18:41 :
> Björn Haase wrote:
> >  In this case, however, I'd like to
> > suggest to try to find a format that could be edited by some sort of GUI.
> >
> > Any suggestions would be appreciated.
> >
> > Bjoern
>
> I think, xml is the format of choice.
>
> I made the same suggestion some time ago in the avr-freaks forum.
>
> At that time, I thought it would be a good idea, to evaluate the
> xml-database at runtime,
> and I was told that this would be too slow.
>
> But a code generator generating C code from an xml file should be the
> best solution.
>
> I have wrote some code-generators (xml to C) at work, using Borland Delphi.
>
> For editing xml-files there are many good solutions, e.g. emacs or
> oxygen or ...
>
> There is something like xml-forms, too.
>
> One problem is, that we cannot redistribute the xml device definition
> file from atmel
> without their permission (Jörn asked them for a permission and they said
> no.)

> Therefore it might be a good idea, to create an own format, that can be
> filled from
> the atmel xml file (well, to 95%) with a little converter.

What I was thinking about is maybe kind of a different information that we 
should collect. (In fact, I don't know which kind of information is included 
in atmels xml files.) I'not so much thinking about the register definitions 
that would go into the device specific header but rather other information 
as, e.g. , defined in the following structures:


#define AVR_FLASH  (0x000000)
#define AVR_RAM    (0x800000)
#define AVR_EEPROM (0x810000)

/* Information on the instruction set.  */
typedef struct {
 int has_lpm:1;   /* lpm  */
 int has_lpmx:1;  /* lpm Rd,Z[+].  */
 int has_sram:1;  /* ld, st, push, pop, ...  */
 int has_jmp:1;   /* has_jmp implies existence of "far" call insn.  */
 int has_mul:1;   /* mul, fmul, ... supported.  */

 int has_elpm:1;  /* Device has >64k program memory (ELPM).  */
 int has_elpmx:1; /* Device has ELPM Rd,Z[+].  */

 int has_spm:1;   /* Device can program itself.  */
 int has_brk:1;   /* Device has on-chip debug.  */
 int has_eind:1;  /* Device has >128k program memory.  */

 int has_movw:1;  /* movw  */
 int has_adiw:1;    /* adiw  */
} avr_insn_set_description_t;

/* Information on peripherals that influence the build process of at least 
part of the toolchain (right now mainly eeprom).  */
typedef struct {
  int has_eeprom_erase_only:1; /* 1 for the newer devices */
  int has_EEARH:1;
 
  unsigned int addr_EEAR; 
  unsigned int addr_EECR;
  unsigned int addr_EEDR;

  /* Supposed to hold a string like "1C1D1E" used by avr-libc.  */
  char *eeprom_reg_locations;
} avr_peripherals_description_t;


/* Structure that contains all of the information on an individual device.  */

typedef struct {
 /* The name that is passed on the command line with the -mmcu option of gcc.
    E.g. atmega128.  */
 char *name;

 /* The name of the crt file including the .o suffix.  */
 char *crt_filename;

 /* A string gcc will pass to the linker for this device.  */
 char *link_spec;

 /* A string gcc will pass to the linker for this device.  */
 char *lib_spec;

 /* Information on the device memory.  */ 
 unsigned int ram_start; /* memory-space bit (0x800000) should be set.  */ 
 unsigned int ram_size;
 
 unsigned int eeprom_start; /* memory-space bits (0x810000) should be set.  */ 
 unsigned int eeprom_size;

 unsigned int progmem_start;
 unsigned int progmem_size;
 unsigned int progmem_wrap_around;

 avr_insn_set_description_t ins_info;
 avr_peripherals_description_t per_info;
} avr_device_identifier_t;

> If people here agree, that this is a good solution, I could make a
> suggestion for an
> xml format (dtd).
what triggered the question for me was, that now before one starts to add a 
new family number for the >128k devices, one might try to resolve the issue 
properly so that the linker will also recognize memory overflows, etc. .

Yours,

Bjoern.