avr-libc-dev
[Top][All Lists]
Advanced

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

Re: [avr-libc-dev] New device support


From: Joerg Wunsch
Subject: Re: [avr-libc-dev] New device support
Date: Fri, 13 Jul 2007 23:55:20 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

As Eric Weddington wrote:

> There are new devices that need support:
> AT90PWM216
> AT90PWM316
> ATmega48P
> ATmega88P
> ATmega168P
> ATmega328P
> AT90PWM2B
> AT90PWM3B
> And possibly ATA6289, though I would have that as a lower priority.

Note that this issue came up because IAR recently announced support
for these AVRs.

> However, I have a policy proposal for avr-libc. Previously, there
> have been devices in sub-families where the device IO header file is
> minimal and it includes another header file for the sub-family.

The main reason for this is that IO header files were/are manually
created, and that recent AVRs always came as an entire new family with
basically the same features but different memory configurations.

> There will many more devices in the future and creation of the IO
> header files needs to be automated, and it will in fact, be
> automated in the near future. This means that the IO header file
> will have to be generated from the device XML file that is released
> from Atmel.

As I already wrote you in private mail, the key point here is that we
need advance access to the XML files for this to be practical.  So
far, all we've got was advance access to preliminary datasheets, so
the initial IO header file always had to be hand-crafted.

Using an Atmel-internal preliminary XML file as the initial source
might be an option (though it's not my preferred one as I'd like to
strictly distinguish between the job and the opensource work),
provided we are granted the right to store our information derived
from that XML file within our CVS.

I'd like to remind everyone that Ted Roth already started parts of
that, in the xml/ subdirectory.  As we are not allowed to store the
Atmel XML file directly but have been granted the right to extract
arbitrary information from it and store it, Ted started a converter
tool to establish an avr-libc-internal XML file from the Atmel one.
That one can then be stored in CVS, and can be used to craft our IO
header file from.

Eric, don't spend too much time into that yet, there's someone here
in Dresden that can contribute some time to that job.

> This has several
> implications:

> - One IO header file per device, ONLY.

Not necessarily, the tools could be intelligent enough to collapse
similar file into the existing structure.  In theory, that's no longer
needed if we can really fully automate the generation of the IO header
files, but I see maintainability issues with that: every time Atmel
renames something in the XML file, we'd lose the old name and be faced
with compatibility issues.  Thus I think it's more practical to
generate the initial IO header from XML but maintain it manually then.

> - Backwards comptability will be taken care of. If Atmel has a
> change to the XML file, then not only will the generated IO header
> file have the new definitions, but the old ones should still be
> available for backwards comptability. This has to be taken care of
> in the source XML file, so this can be automated.

OK, you're seeing that issue, too...  It would be an option to handle
that within our intermediate XML files.

> - This also means that these IO header files should not be hand
> modified in the future.

Which I think is a second step.  If all of the above works out well,
I'm fine with that.  Note that there are some (at least one) AVRs
which Atmel denies in AVR Studio they ever existed, so there's no XML
file for it.  OK, we can perhaps derive our own one for that old
bugger.

> IIRC, currently we have a Python script within avr-libc to convert
> the XML device file from AVR Studio to an IO header file. I don't
> know if this script is up-to-date.

It's not really up-to-date.

> However, I am leaning away from using this Python script. In the
> future, I would very much like to use XSLT transforms and using the
> XMLStarlet command line tool within Makefiles to do the conversions.

Given the rather scattered XML structure, I'm afraid that won't really
do it.  I've been discussing it with Reinhard here, and leaving his
bias for Python aside, Python still has a number of advantages.  Note
only that XSLT is really awful (it's not a programming language as
such, so even for seemingly simple programming jobs like formatting an
output line across possible continuation lines, you're bending over
your back), but the major issue with it is that Python is much better
debuggable.  There are other things to handle where XSLT is probably
at its wit's end, like summarizing two registers as 16-bit pseudo
registers.

I've got another issue here:

Currently, neither the XML files nor the IO header files support the
notion of a sub register: consider for example the timer B control
register.  The lower three bits for each of them are handled as three
distinct bits although they actually form a 3-bit sub register where
all three bits together could be handled together, and could even be
given symbolic names for their constants.

So this raises the question of how to handle sub registers in future.
Leave the XML part of that game out by now (I think there will be
something in the future, and as a first step, we could probably add
logic to the converter to detect the known cases), and concentrate on
the IO header file.  Our traditional way of leaving the entire bit
handling to the user (``Programming 101''...) is no longer really
applicable here.  Given that users have been asking for symbolic
register access anyway, I'm all in favour of a bit-field solution for
this.  So, for the example of TCCR0B of an ATmega1281, we could do
something like

union tccr0b {
        uint8_t byte;
        struct {
                uint8_t cs0: 3;
                uint8_t wgm02: 1;
                uint8_t : 2;
                uint8_t foc0b: 1;
                uint8_t foc0a: 1;
        } bits;
};

enum cs0_val {
        CS0_NOCLK,
        CS0_1,
        CS0_8,
        CS0_64,
        CS0_256,
        CS0_1024,
        CS0_EXT_FALLING_EDGE,
        CS0_EXT_RISING_EDGE,
};

The question now is, what to chose for the name of TCCR0B when it's
defined as the union/bitfield sketched out above?  If we call that
TCCR0B, the old way of handling TCCR0B like

        TCCR0B = _BV(CS00) | _BV(CS02);

would be rewritten as

        TCCR0B.byte = _BV(CS00) | _BV(CS02);

We could probably switch between the old "flat byte" and the new
structured way using a pre-defined (by the user) macro like
_COMPAT_IO_NAMES.  Still, I think this will upset many users, and
I wouldn't prefer it.

So I'd rather like to ask for alternate proposals.  The shortest one I
could imagine would be to add an underscore for the structured names,
so the structured access would look like

        TCCR0B_.bits.cs0 = CS0_1024;

Another way would be to append _struct:

        TCCR0B_struct.bits.cs0 = CS0_1024;

Looks a bit better readable (IMHO) but is much longer.

> We also have a challenge for the future. Adding device support
> across the whole toolchain needs to be easier. Currently we have to
> touch several tables in binutils, gcc, and avr-libc. Joerg, I know
> that we have previously discussed changing this in the past, with
> Ted Roth.

Yes, but we didn't come to a good conclusion.  Ideally, both GCC and
binutils could use an external file for that, but that doesn't fit
into their current structure at all.  Let's do the above first, I'd
say.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/





reply via email to

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