[Tinyos Core WG] AdcConfigure and struct return

[David Gay]

On 9/21/06, Vlado Handziski <handzisk at tkn.tu-berlin.de> wrote:
> On 9/21/06, David Gay <dgay42 at gmail.com> wrote:
> > The C spec specifies that a variable declared on the stack only lives
> > until the function exits. The compiler can assume this wherever it
> > wishes. Assuming that some particular quirk of some particular
> > implementation means your code will always work is stupid. Fix: write
> > "static const", not "const".
> >
> > For instance, I'd be rather surprised if msp430-gcc placed x in
> >
> >   void g(void) {
> >     struct { int a; } const x = { f() };
> >   }
> >
> > in flash. If you write static const, you'll at least get a compile-time
> error.
>
> I don't want to nitpick this, but the mspgcc manual says: "All global
> variables with the "const" attribute are allocated in the main ROM space".
> And I've always assumed that variables declared after implements{... are
> global.

Yes, they are. I was referring to local variables.

> > > Cool. Now we agree that it is not an issue of performance anymore, but
> of
> > > religion :)
> >
> > And I'm tired of fighting stupid religous wars. Write the TEP however
> > you wish, and find somebody to update the atm128 code. Probably Xbow
> > will do it.
>
> Was this the real problem?

The real problem is probably:
- I think the returning struct (or struct pointers) is not a good approach
- I don't think it brings any of the benefits you claim it does
- I don't like spending my time updating something I don't care that
much about (mica platforms) in a way which I think makes it worse.
Hence my last comment above.

> > > As I said, it has to do with history (we have always used structs on the
> > > msp430, from the very first implementation) and religion,
> >
> > I.e., you did it this way, so it must be the right way. So you'll
> > carefully define HIL so that only your way is acceptable, even though
> > it has no real advantage. Fine, go ahead. I'm tired of this whole
> > silly discussion about the purity of the way of particular ways of
> > expressing platform-dependent concepts.
>
> David, I am _proposing_ something. I've stated my arguments why I think it
> is a better top level interface then the existing HAL2 mess.
> You and I can disagree on the importance of  architectural concepts or if
> something is silly or not, but you can not deny the obvious benefits that
> the HAA brought to the project in terms of number of ported platforms. What
> I am getting tired of is pushing these "silly" architectural things against
> all the accumulated corporate interest in this less and less academic
> project.

Hmm, if you're detecting Intel corporate interest here, you're deeply
confused. If I stopped doing any work on this yesterday, my bosses
would be overjoyed. What I think is a waste of time is spending hours
debating the "proper" way of exposing something that is never going to
be fully portable (configuring an ADC).

> As long as we don't have a proper TEP voting procedure (like the +1, 0, -1,
> which I proposed on the same telecon together with the whole TEP concept)
> pushing a TEP out when there is no consensus is a war of attrition. The TEP
> is out, and the ball is in Phil's corner as WG leader.

And on whomever has interest in seeing their platform conform to the
TEPs (and hence be part of the TinyOS distribution).

> > > This being such a major issue, I invite once again all interested
> parties to
> > > participate in the HIL telecon next thursday. Hopefully we can come to
> some
> > > agreement.
> >
> > I'll skip - I've had too many "angels on the head of a pin"
> > discussions on this topic.
> >
> >
>
> Fine. Maybe we should just go back to good old  tinyos-1.x ways, when there
> were zero tinyos ports outside Berkeley on non-atmel platforms. I am not
> sure who is pushing his idea as the only "right way" here.

I believe the only disagreement here was whether a platform-dependent
interface is worse than a platform-dependent type. You seem to think
so, I think that distinction is stupid. But it's your baby, and your
definitions, and I'm tired of the subject.

David