[Tinyos-devel] Re: [Tinyos-2.0wg] Re: [nescc-devel] Upgrade

[David Gay]

On 5/12/06, Eric Weddington <eweddington at cso.atmel.com> wrote:
> > Note that this doesn't directly address two of the major issues which
> > led us to doing our own distribution:
> > - consistency of tool versions across supported platforms
> > - stability of particular tool versions
> >
> > As an example: the avr-gcc 3.4.5 in WinAVR doesn't appear to work for
> > TinyOS: the example app I compiled w/ mingw crashes after a little
> > while, but works fine with avr-gcc 3.4.3 on my Linux-based system - I
> > haven't confirmed that this is due to avr-gcc, but it appears like the
> > most likely first hypothesis...
>
> This is why I would prefer that NesC/TinyOS can work with standard
> distributions:
>
> - There is a known major compiler bug in avr-gcc 3.4.5. There is also a
> patch for it. This is now fixed in the latest release of WinAVR which
> has avr-gcc 3.4.6. Alernatively, you should be able to use a previous
> release of WinAVR that has avr-gcc 3.4.3, because WinAVR is hosted on
> SF, so anyone has access to older versions.
>
> - If you use standard avr-gcc distributions, then you no longer have to
> maintain your own separate distribution just for NesC/TinyOS. You can
> leverage other Open Source projects and other people's work. The
> end-user has the best advantage because they can use the same toolchain
> to build a regular AVR application (with WinAVR only), or they can
> easily switch to a NesC/TinyOS toolchain because WinAVR is already a
> subset of that toolchain.

I don't think my two sentence summary of the issue was sufficiently
clear, so let me explain in more detail. But first, I do think what
you're saying makes sense from an avr-on-windows user's perspective.
It just doesn't quite work from the
tinyos-for-many-platforms-and-processors perspective:

- We have to deal with multiple platforms (currently Linux and Cygwin)
and multiple architectures (currently AVR, MSP430, ARM, x86). The
availability of WinAVR doesn't help, as we still have to build the
same toolchain for cygwin and for Linux (*).

- The AVR tools are not stable enough, which means that we have to
pick a version and use it for a while before we can be reasonably sure
that it's stable enough (this is really the major effort involved in
distributing our own toolchain). Just as an example, avr-gcc 3.3.2
doesn't work with TinyOS 2.x, 3.3.y, for y>=3 doesn't build, and 3.4.5
has a problem as you point out above. Life is even more fun on the
msp430 side. Note that in places where gcc is stable (x86) across
most/all versions, and readily available, we don't do our own thing.
But when we do have to do our own thing on some platforms, it's
actually easier to do it for all platforms as it increases
consistency.

- There's also going to be a problem for our distribution if we
distribute nesC within WinAVR: people seem to find it annoying to have
to download/install tools for processors they aren't using (not sure
why, but they do seem to...). Providing nesC separately as well as
with WinAVR is just a recipe for confusion and inconsistency.

>
> There are already quite a number of users of WinAVR. If you make
> NesC/TinyOS more readily available to these *Windows* users, then you
> will end up with more people trying out these tools and possibly migrate
> to these solutions. This helps the entire community.

Definitely (see my initial comment).

David
*: Ultimately, we might find that cygwin users disappear, or that
using winavr within cygwin is fine. But that's not yet the case.