[Tinyos Core WG] AdcConfigure and struct return

[Vlado Handziski]

On 9/21/06, Philip Levis <pal at cs.stanford.edu> wrote:
>
> On Sep 21, 2006, at 1:47 PM, Vlado Handziski wrote:
>
> >
> > 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.
>
> I think David's point was that while the mspgcc manual might promise
> that, other C compilers may not. I also assume that mspgcc doesn't
> promise to always do it in the future... Furthermore, not all gcc
> ports do so, and therefore you might be introducing a significant RAM
> cost.


I was never disputing the "static" thing. It turns out that mspgcc does not
need it. What I did not get from the first mail is where exactly I used a
local variable. As said, the code was just a quick test for me to see if
what we are proposing is really out of the question performance wise or not.

>
> > 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.
>
> I think that there is definitely some corporate pressure, but I'd be
> hard pressed to say that it has really been influencing decisions
> much. Rather, I think there's a growing feeling (which I personally
> share) that we need to start moving on. By that, I don't mean stop
> working on TinyOS. What I mean is finish parts so that we can build
> upwards. Ultimately, the goal of 2.0 is to build a better version of
> TinyOS to enable sensornet research. If it's never fully built, we
> have failed in that goal. Completing something that is 95% of perfect
> is infinitely better than not completing something that is perfect.
> Given that David is supposed to be moving away from his heavy coding
> (his boss says so), if something continues to be in committee he can
> no longer work on it.


This intrinsic tension between academia wanting to try new things and
industry wanting stability will have to be solved in some well defined
framework at the Alliance level, if we want to keep TinyOS interesting for
both communities in the future. Maybe it is not too early to start thinking
about a Red Hat Enterprise /Fedora Core approach.

>
> > 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.
>
> I think the issue here is less with the TEP and more with the level
> of change that it has undergone. It's one of the earliest ones, and
> has undergone numerous very major revisions. The most recent revision
> was just two months ago, with the re-introduction of the HIL. I'm led
> to agree with your comment a little while back ago that the changes
> have, for the most part, all been towards a clear and desirable goal.
> But from the perspective of people who are trying to write code that
> matches the TEP, (and I might be putting words in David's mouth here)
> I'm sure you can imagine that it might be frustrating.


It has been probably even more frustrating for Jan (and now I am putting
words in his mouth) to make 1000 changes to the TEP and to implement them
all. But this is a direct result of the "consensus building approach", the
complexity of the sub-system and the fact that so many other things depend
on it (sensors, sensorboards, etc.)

>
> > 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, for one, do not want to go back to that approach.
>
>
Good. I am counting this as +1 for TEP 2 :)

V;adp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20060922/04eb6ac1/attachment.htm