[Tinyos-devel] RE: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs
regehr at cs.utah.edu
Mon Oct 15 14:30:59 PDT 2007
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
- 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
- nesC isn't that obscure, I think it can parse all of C.
On Mon, 15 Oct 2007, Eric Weddington wrote:
> > -----Original Message-----
> > From:
> > avr-gcc-list-bounces+eweddington=cso.atmel.com at nongnu.org
> > [mailto:avr-gcc-list-bounces+eweddington=cso.atmel.com at nongnu.
> > 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
More information about the Tinyos-devel