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

[Eric Weddington]

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

Sorry, I wasn't referring to anything that late. There will be a time where
we can have access to the XML file, before the chip is released, and very
probably long before a release of AVR Studio, where a derived work, such as
a IO header file, can be made public and put into a public CVS repository.
The timing issue is the release, from marketing, on when that information
can be made public. And I will take care of 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.

Anything above zero still won't buy us any additional benefit.

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

The definitions will still be the same whether it is 1 header per device, or
whether there will be common definitions in a separate file, *and* those
definitions will still be human readable. The act of putting common
definitions in a separate file doesn't automatically make it more human
readable. In fact, I've always found it to be annoying because I will want
to look up something in a header file and I open up the file for the
specific device just to find out that it hardly has anything in it and I
have to go open yet another file to find the definitions that I was looking
for.


> > 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 wasn't referring to the stuff in avr-libc. There is existing work right
now for *future* devices. This is one of the things that I need to talk to
you about.

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

Can you describe your reasoning?


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

Your proposal for these types of additions is one of the other things that I
need to talk about with you and sync up with other thoughts as well. If it's
ok, I'd like to postpone discussion on this part until after we talk on
Monday.

Thanks
Eric Weddington