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

[John Regehr]

Eric I'm not an authority on this topic but here are my two cents:

- nesC adds plenty of value beyond facilitating inlining, for example the 
  component model, support for concurrency, generic components, network 
  types, etc.

- I see no reason why nesC/TinyOS cannot use the latest and greatest AVR 
  toolchain.  Probably it's mainly a matter of the TinyOS maintainers 
  finding time for toolchain work.  Also note that some TinyOS/nesC ports 
  like msp430 are hopelessly mired in gcc3 for the foreseeable future.

- David has spent a fair amount of effort on C interoperability for nesC 
  programs.

- nesC isn't that obscure, I think it can parse all of C.

John Regehr



On Mon, 15 Oct 2007, Eric Weddington wrote:

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