RE: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4

[Eric Weddington]

> -----Original Message-----
> From:
> address@hidden
> [mailto:address@hidden
> org] On Behalf Of John Regehr
> Sent: Monday, October 15, 2007 12:42 PM
> To: David Gay
> Cc: Avr List Server
> Subject: Re: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4
>
> A little more information for the gcc3 / gcc4 discussion:
>
> - for complicated TinyOS codes we get plenty of internal
> compiler errors
>   from avr-gcc3 (the one distributed with TinyOS, I mean)
>
> - gcc3 has some abyssmally bad bugs regarding handling of
> volatiles that
>   seem to be fixed in gcc4
>
> - we have some good measurement infrastructure for AVR codes.
>  I'll try to
>   get one of my people to take the time to measure the CPU
> usage, code
>   size, and stack memory usage of some TinyOS applications
> under avr-gcc3
>   and avr-gcc4 and then I'll post a comparison here.  To the
> extent that
>   TinyOS applications are typical of interrupt-driven ATmega
> codes, this
>   may be of general interest.
>
> John Regehr

And just to add gasoline to the inferno:

One of the main features of NesC is its ability to combine all source code
modules and do cross-module optimization. This ability is now available in
GCC 4.x with the -combine and -fwhole-program switches. This brings up the
question about using NesC *at all* for TinyOS. Why can't TinyOS be recoded
in C? There are certainly more engineers knowledgeable in C. If TinyOS were
to be recoded in C, then:

- This would allow better commercialization of embedded sensor network
technology, mainly because the end-users designing applications do not have
to learn an obscure academic language in order to use it. There are at least
3 companies that I know of that base part of their sensor network technology
on TinyOS, that would suddenly have a more receptive market to their
technology because it uses a standard language.

- It would avoid fragmentation of the embedded sensor network academic
community (re MantisOS, University of Colorado, Boulder). A cohesive
community is one that is more able to go commercial.

- It would allow the adoption of newer toolchains, with fixed bugs, new
features, and more importantly newer devices. Atmel has an interest in
seeing the sensor network community adopt newer processors with more RAM
(for bigger applications), smaller flash (less cost), better power
management, and those with newer capabilities that make these networking
stacks easier to implement and use. And we have an interest in adding in
capabilities for new radios. We can't easily help if NesC continues to use,
and promote, a proprietary distribution of the AVR toolchain, and if TinyOS
uses NesC.

- It would also add even more people to the AVR toolchain community. As it
stands if someone asks a TinyOS question on the avr-gcc-list (like how this
thread gets started), we have to redirect them to the TinyOS group because
the underlying code. We have people (students, usually) submit bug reports
about uisp, and we keep repeating to them that uisp is no longer maintained,
please use avrdude. If TinyOS used the latest AVR GCC toolchain, then there
would be more people looking at the same set of toolchain bugs, and possibly
coming up with ways to fix them or work around them.

I've spoken with several stakeholders about this issue before (you know who
you are). Other than the sheer engineering time and effort involved, why
can't this be done? I see a lot of advantages for both sides of the fence.

Eric Weddington
Product Manager
Atmel