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

[Joerg Wunsch]

As Eric Weddington wrote:

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

That's my concern: we need to be allowed to do this by the time we
start working on supporting a new device, rather than by the time a
version of AVR Studio has been released that finally support it, too.
Experience from the past shows that occasionally, AVR Studio is very
late in that.

> > > - 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 additional time required might be minimal.  Just consider that you
specify all the XML files belonging to one AVR family on the
command-line, and the script then determines which things are
different.  I still believe it makes things better human-readable, and
that's what we should also be concerned about (provided it doesn't
take an exaggerate amount of time to add that functionality to the
converter, of course).

> However we do have an issue with the amount of *time* it takes to
> generate the IO header file by hand, ...

No, I didn't mean to resort to manually crafting the files.

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

Well, the XSLT stuff that's around in our trees has merely been
attempts, or proof-of-concept stuff from me so far.  I did want to get
a feeling for XSLT, but I'm still not really convinced about it.
Btw., I did make an initial proof-of-concept XSLT "style sheet" to
convert the XML to header files, mainly in order to demonstrate to
Reinhard it's doable, but this implementation rather let me realize
the Python version is really the better way to go. ;-)

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

We can talk off-line about who is going to implement it, but I'd first
like to get all avr-libc developers to agree on the result, i.e. we
first need a spec for it.  Bob Paddock already mentioned the MISRA
concerns, but I'd like to get more opinions from other developers as
well.

One thing that came to mind is that the choice of using struct and
enum names that are in the application name space might not be
optimal.  In particular when thinking about C++, the above "struct
tccr0b" example would establish a global type name tccr0b (whereas in
C, it would only create a type name "struct tccr0b"), which might
collide with existing applications and their use of the name tccr0b
e.g. for a temporary variable holding the contents of that register.

So here's the next attempt on an example:

union __tccr0b {
        unsigned int byte;
        struct {
                unsigned int cs0: 3;
                unsigned int wgm02: 1;
                unsigned int : 2;
                unsigned int foc0b: 1;
                unsigned int 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,
};

This would still leave the CS0_* enum constants exposed globally in C,
but I hope that's not a big issue.

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

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)