avrdude-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [avrdude-dev] Atmel's XML part description files


From: Erik Walthinsen
Subject: Re: [avrdude-dev] Atmel's XML part description files
Date: Fri, 11 Feb 2005 14:51:43 -0800
User-agent: Debian Thunderbird 1.0 (X11/20050116)

E. Weddington wrote:
Do NOT do Window's native XML libs. The Windows version of avrdude is built with Cygwin, which has access to libxml2 and other Unix/Linux libs.
Yeah, I wasn't planning on it. Never gonna do any more Windoze coding even if my life *does* depend on it. 3 months of Visual Bleck and "Real" SDK is enough. That's why I mentioned libxml2 as having no dependencies. avrdude is already using bison/flex, so it's only a lateral dependency move.

What do you want to find? Others can look too, or if it's not there, we can certainly add it locally
Lemme see if I can build up a list of what I can see or not see:

(stk500*... prefix ice_settings. stripped for page width reasons)

avrdude.conf            XML
stk500_devcode          .stk500.deviceid
avr910_devcode          ?
pagel                   ?
bs2                     ?
chip_erase_delay        .stk500_v2.ispchiperase.erasedelay
pgm_enable bitmask      ?
chip_erase bitmask      ?

eeprom:
  size                  memory.eeprom
  min_write_delay       ?
  max_write_delay       ?
  readback_p1           .stk500_v2.ispprogrameeprom.pollval1
  readback_p2           .stk500_v2.ispprogrameeprom.pollval2
  read bitmask          ?
  write bitmask         ?
                        programming.eeprompagesize

flash:
  paged                 yes
  size                  memory.prog_flash
  page_size             programming.flashpagesize
  num_pages             (do the math?)
  min_write_delay       ?
  max_write_delay       ?
  readback_p1           .stk500_v2.ispprogramflash.pollval1
  readback_p2           .stk500_v2.ispprogramflash.pollval2
  read_lo bitmask       ?
  read_hi bitmask       ?
  loadpage_lo bitmask   ?
  loadpage_hi bitmask   ?
  writepage bitmask     ?

fuses,lock:
  size                  yes
  min_write_delay       ?
  max_write_delay       ?
  read bitmask          ??programming.ispinterface.fusereadmask??
  write bitmask         ??programming.ispinterface.fusewritemask??
                        Detailed bit descriptions

calibration:
  size                  (either present or not, always 1 byte afaict)
  read bitmask          ?

signature:
  size                  (always 3 bytes? maybe at89/atrf/atpwm differ?)
  read bitmask          ?
                        Signature bytes


So, as you can see there appears to be a lot of stuff not represented in the XML, which sucks. And there's a whole lot of info that *is* in the XML that would be great to have available in avrdude.

So, it looks as if we're going to have to (for multiple independent reasons) develop our own DTD and XML files that contain a mix of data coming from both the Atmel XML files and existing avrdude.conf data, datasheets, and trial&error.

In looking at the various things necessary to make binutils and gcc also support various chips, I found at least one but with chips listed as the wrong architecture (I think the atmega48/88/168 were listed as siblings of the atmega8, which they are not afaict). If we're going to build an XML descriptor file (whether used directly by avrdude/etc or parsed out into C), the number of fields necessary solely for binutils/gcc seems rather tiny and therefore could easily be added to this DTD. This would allow someone to trivially write a script that can generate the relevant sections of files for binutils/gcc from *our* master files as needed.

In addition, generating the io*.h files in avr-libc from the XMl descriptions doesn't look to be that hard, and could even go further and provide SFR bit unions a la CodeWarrior without any maintenance pain. They'd just have to be generated once by a maintainer from the official XML files and imported into CVS.

Creating our own master dataset (any maybe merging with Atmel if they wisen up about licensing) would make both adding and maintaining support of existing and new chips across all the tools a lot easier I think. Currently you have to tweak binutils, gcc, avr-libc, and avrdude separately, some with their own internal naming schemes (Atmel has perfectly good official names for their chips IMO), and hope that you get it all just right...




reply via email to

[Prev in Thread] Current Thread [Next in Thread]