[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Eric Weddington
Subject: RE: [Tinyos-devel] RE: [avr-gcc-list] Fwd: [Tinyos-help] TinyOs avr-gcc-4
Date: Wed, 17 Oct 2007 12:16:58 -0600

> -----Original Message-----
> From: John Regehr [mailto:address@hidden
> Sent: Wednesday, October 17, 2007 10:40 AM
> To: Eric Weddington
> Cc: 'Philip Levis'; 'David Gay'; 'Eric Gnoske'; 'Avr List
> Server'; 'TinyOS Development'; address@hidden
> Subject: RE: [Tinyos-devel] RE: [avr-gcc-list] Fwd:
> [Tinyos-help] TinyOs avr-gcc-4
> > can meet in the middle, where we all win. TinyOS is a great
> idea for sensor
> > networks. I'd like to be able join forces to promote it
> further. I don't see
> It seems likely that the toolchain problems can be made to go
> away with
> modest effort.
> Another step towards meeting in the middle could build on the "binary
> component" feature of nesC, which was designed to support
> interoperation
> with plain C.  If some interfaces can be agreed upon, then
> drivers for
> various devices can be written in C and reused in TinyOS,
> MantisOS, and
> SoS.  On the TinyOS side some wrappers would need to be
> written but this
> is easy.  Assuming that multiple sensornet operating systems
> exist and
> will continue to exist, this would seem to be the way
> forward.  Note that
> there are several more OSs for mote-class hardware beyond
> those that have
> been mentioned already.  Rewriting all drivers for all of
> these systems
> would seem to amount to nothing more than an employment act
> for graduate
> students :).


> If we're talking about reuse of application-level logic, as
> opposed to
> lower level components, then this would seem more difficult.

At this point drivers would be sufficient.

>From what I understand of your description above, it sounds very reasonable
to me.

Eric Weddington

reply via email to

[Prev in Thread] Current Thread [Next in Thread]