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

[Eric Weddington]

> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of Joerg Wunsch
> Sent: Friday, July 13, 2007 3:55 PM
> To: address@hidden
> Subject: Re: [avr-libc-dev] New device support
>
> 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.

Yes and no. This issue has been on my list before that.


> > 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

Fortunately, it's not a "might be", it *will* be.


> (though it's not my preferred one as I'd like to
> strictly distinguish between the job and the opensource work),

My job is the open source work, so this is preferable for me.

> provided we are granted the right to store our information derived
> from that XML file within our CVS.

We will. It's just a matter of timing.

> 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.

On his own time? Or via his contract work? (More below obviously)

>
> > 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.

*Could* be intelligent enough, yes. But it takes more time to do it that way
with no additional benefit for the work. The XML part description files are
1 file per device so it makes more sense to have a *simple* convertor and
have 1 IO header file per device. There is no issue with the space that the
IO file uses up, either in the avr-libc CVS, or on user's hard drive.
However we do have an issue with the amount of *time* it takes to generate
the IO header file by hand, especially with the number of devices that we
are supporting and the number of new devices that we will support in the
future. We can save time by making the convertor "dumb" and only have it
generate 1 IO header file per device.


>  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.

I agree that having the generated IO header file be backwards maintainable
would work for new devices. We may have to hand maintain the existing the IO
header files, until such IO header files are ported over to the new system
over time.



> > - 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 agree that XSLT is not a programming language and I've seen similar
issues. I don't know whether it's good or bad, but some work has already
been done for an XSLT convertor for some devices. There is Ted's Python
convertor in avr-libc CVS. I don't know how I feel about having multiple
systems.


> 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.

We need to talk off-line in a very big way about all of this. Let me know
what your schedule is for Monday afternoon so I can give you a call at work.



> 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.

Agreed. But I would encourage you and the other developers (Hi Anatoly!) to
start thinking about what we can do with binutils/gcc.

Eric Weddington