[Tinyos-2.0wg] Meeting: August 2

[Jonathan Hui]

Phil Buonadonna, David Culler, Prabal Dutta, Vlado Handziski, Jan Hauer, 
Jonathan Hui, Kevin Klues, Philip Levis, Gilman Tolle,

Scribe: Jonathan Hui

Status Updates:

- PL: Collection workshop on Monday. Tried to hash out a
   protocol. Pretty successful, looks like there will be a tep or
   two. High level, there are going to be two protocols (i) ad-hoc and
   continuous (ii) something DSDV-like, for loop-free.

- PL: Change to AM packet, everything seems great.

- PD: The getPayload() command creates a hidden dependency. Can't
   decouple header ordering from packet processing ordering. No way to
   know where the header information exists, separate from the data
   path.

- PL: getPayload() was put in because it's always needed. Don't need
   to wire in two interfaces all the time. This issue seems kind of
   subtle, can Prabal write it up and send it over email?

- PD: Sure.

- JH: I checked in an initial implementation of I2C, Vlado has some
   proposed USART changes for configuration.

- VH: Will merge everything on the devel branch.

- DC: Say briefly what the impact of the changes will be? Will it
   require changes on other platforms?

- VH: Will require changes to other platforms. Bus needs to be
   reconfigured when the bus is acquired. The reconfigure event is used
   to do this. Increases overhead since there is need to reconfigure
   bus each time. If there does not need to be any reconfiguration, can
   use a different arbiter.

- PL: Overhead is just writing to 6-8 registers.

- DC: So it is a performance impact on all the platforms, but its safer?

- VH: If we anticipate multiple users of the USART, then any
   configuration must be done while it is in reset mode. We have
   discussed internally about some optimization approaches. For
   example, if you know the old and new user are the same, then don't
   call unconfigure/reconfigure. Problem comes in with power manager
   since it comes in between the users and might require
   reconfiguration of the device.

- DC: The other obvious case is where there is only one user. On the
   other platforms, do we have multiple users?

- KK: There is a NullArbiter for cases where there is only one user.

- DC: Is it the case that we have multiple components using this? or
   on some of them you have only one.

- PL: On the micaz, the radio has a dedicated SPI.

- DC: The sharing on the msp gives rise to this.

- PL: In order to follow the msp430 specification, then you have to do
   this to configure the bus correctly.

- DC: Whenever that bus is not dedicated. Sounds good, removes one
   more reason not to do tinyos-2.x


- DC: FYI, Atmel has a dev kit that is effectively a mote, potentially
   interesting to this group because it is another a radio and more
   importantly moves to the Atmega1281. Other groups have been looking
   at the 1281 and seems pretty important for the core.

- PL: Would be good to look at that. Would need a version of gcc that
   works.

Bug Tracking/Branches/Experimental/Contrib

- PL: Summary: Should be a mailing list tinyos-bugs which developers
   are subscribed to. Bugs are entered into sourceforge by developers
   from the mailing list. Contrib should have a top level module
   tinyos-2.x-contrib with same open policy as tinyos-1.x. Should have
   a tinyos-2.x/experimental for a work area so that lots of branches
   are not required. Henri volunteered to be the first caretaker of
   contrib.

- VH: Do we want to revisit the chips directory? Chips without
   categorization can be confusing for new uesrs.

- DC: I don't know if its worth adding the extra level. What if
   there's a chip that has both mcu and radio, or one that has an
   internal sensor. Then the taxonomy won't fall cleanly.

- PD: I tend to categorize by manufacturer and not by type of chip. I
   also agree with DC.

- VH: For me, categories like mcu/radio is helpful, but I can see DC's
   concern.

- PL: Maybe each chip should just have a readme.

- PD: How about a single readme in the chips directory that gets
   updated whenever new chips are put in?

- VH: Problem is when a user asks what radio tinyos supports, then
   they have to go into chips and look through all those chips.

- PL: I think that's true, but doesn't have to be documented by a
   source tree structure.

- PL: Sounds like this may require some serious changes.

- DC: Documentation is a great way for people to figure things
   out. The problem with stylistic things is that you never figure
   things out.

- VH: We need to converge, same problem with sensors, should it have
   its own directory?

- DC: One concrete proposal is that the sensorboards should pull
   things out of chips just like platforms.

Source Addresses in AM Packets

- PL: What does the serial stack do? How do you do bridging? Should it
   set the source address and set the group?

- GT: What's the problem with writing the bridge below AM?

- PL: Need to look at the serial stack to see if it does something
   funny.

- VH: Can have the same platform independent stuff just like active
   messages for those that have source and not source.

Packet Metadata

- PL: No real interfaces to access packet metadata.

- PD: May not need to agree on metadata, just on the type of the
   metadata.

- VH: How useful is this from the current method of getMetadata? I
   think that Phil is looking for a higher level like getRssi().

- PL: Exactly, we don't have interfaces to do that right now.

- PL: The key here is should there be an interface that provides RSSI?

- VH: Not all radios provide RSSI, what do we do if we make it
   required for all radios to provide RSSI?

- PL: The interesting thing is do you look at the lowest common
   denominator? Or is it worthwhile to fudge that a bit? If you
   consider the complete set then the intersection will be zero.

- VH: Is there required functionality that we can say is required for
   tinyos? Similar to the external oscillator?

- PL: Is RSSI such a thing?

- VH: I am willing to say that it is, but then what is the metric
   there? Should it just be dBm?

- DC: I think RSSI is a pretty important one.

- GT: I think RSSI is important enough that we should require it, but
   if we look at other metadata, then we need to look at the details.

- DC: I think we have a better chance here coming up with a set of
   attributes than sensor boards. It is not independent of link (wired
   vs. wireless, 15.4 vs. bluetooth, etc). In some sense, systems are
   never totally platform independent.

- PL: Seems to me that something like RSSI is likely and could be on
   the fence, but then timestamps are tough once we get into things
   like time base. But without timestamps in the interface is fairly
   limiting.

- GT: It might be fair to say "just use the HAL."

- DC: That's where we are now, I don't believe there are any issues of
   porting things like VU time sync onto a HAL is difficult, it's just
   if you can do it in a platform independent way or not.

- PL: What about timestamps on TDA?

- VH: We have protocols that use 32-bit timestamps. I think that it is
   useful, but cannot make the claim that it needs to be there all the
   time. Should specify that the hooks are there, and if someone wants
   to use it, then connect to the hooks.

- JH: There was discussion on this a couple of months ago, we should
   to back and bring up that discussion again.

Deluge

- PD: Bottom half of it is on my plate. Haven't touched it since new
   storage interfaces were checked in.

- PL: Where is the top half?

- PD: Last we talked, it's on net2's plate.

- PL: Okay, I should let them know, there is no discussion on bulk
   dissemination in net2 right now.


Wrapup

- PL: Continue ADC discussion over email. I'm going to look into the
   serial stuff, bring pack up emails on packet metadata, Prabal will
   sending something out with cobbling data path and send path.


--
Jonathan Hui
jhui at archrock.com

Philip Levis wrote:
> Wednesday, August 2, 2006 11:00 AM US Pacific Time
> Bridge: 4, Passcode: 2182349
> 
> Numbers:
>   US: 1-916-356-2663 or 1-888-875-9370 (non-Intel)
>   UK: +44 1793 402663
>   Denmark: +45 4527 5090
> 
> Agenda:
>   Status
>     - net2 workshop
>     - AMPacket
>     - MSP430 I2C/bus
>   Consensus on bugs/branches/experimental/contrib
>   SerialActiveMessageC
>     - Transparent protocol bridging
>   Packet metadata
>     - HAL/HIL
>   Deluge
>     - Status/timeline
>   TEP 101: ADCs
> 
> Phil
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at Mail.Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>