[Tinyos-devel] tmote P3.6 / P3.7 direction

[Vlado Handziski]

As David said, the only solution is to monitor the interrupt on P1.2 and
track the state (low-to-high for USB connect and high-to-low for USB
disconnect). The case of the node being reset while connected to the USB
might be more tricky, depending on the timing. This needs to be checked on
scope.

Vlado

On Thu, Jul 3, 2008 at 10:46 PM, Andreas Köpke <koepke at tkn.tu-berlin.de>
wrote:

> I guess we are loosing track of the problem: whenever the tmote is
> attached to USB it should configure the pins differently. This is
> completely independent from the presence of a serial stack. So the
> answer is: no, tying the pin configuration to the presence of serial
> stack does not solve the problem. Yes, the presence of a serial stack is
> a good indicator, but the problem would re-appear whenever "close to
> deployment" tests are made (which in general do disable the serial
> stack), preventing a successful reprogramming of the tmotes later on.
> I'm looking forward to a solution as the tmotes in our testbed do have
> this problem, too.
>
> Thanks for figuring the culprit, Andreas
>
> Am Donnerstag, den 03.07.2008, 10:59 -0700 schrieb David Moss:
> > What Phil's saying is the PlatformC file gets setup regardless of
> > whether or not the serial stack is in the system.  In the case where
> > the serial stack is not compiled in, then PlatformC will set the pins
> > up properly so there's no conflict (assumes the no-USB connected
> > case).  Then, when the serial stack is present, the PlatformC's
> > settings get overridden so the pins are setup correctly to use USB.
> >
> >
> >
> > -David
> >
> >
> >
> >
> > ______________________________________________________________________
> > From:geoffrey.werner.allen at gmail.com<From%3Ageoffrey.werner.allen at gmail.com>
> > [mailto:geoffrey.werner.allen at gmail.com] On Behalf Of Geoffrey
> > Werner-Allen
> > Sent: Thursday, July 03, 2008 10:52 AM
> > To: Philip Levis
> > Cc: David Moss; tinyos-devel at millennium.berkeley.edu
> > Subject: Re: [Tinyos-devel] tmote P3.6 / P3.7 direction
> >
> >
> >
> >
> > My understanding was that the problem was being caused by the lack of
> > a serial stack when USB is present.  If the application does not use
> > the serial port how do the pins get set up properly, since the "no
> > serial stack" defaults are what creates the conflict with the buffer.
> > Am I missing something?
> >
> > -gwa-
> >
> > geoffrey werner-allen :: 617.694.7261 :: www.eecs.harvard.edu/~werner<http://www.eecs.harvard.edu/%7Ewerner>
> >
> > On Thu, Jul 3, 2008 at 12:37 PM, Philip Levis <pal at cs.stanford.edu>
> > wrote:
> >
> >
> > On Jul 2, 2008, at 5:48 PM, David Moss wrote:
> >
> > There's nothing wrong with your proposal - except I read the line of
> > emails
> > in reverse order, missing the serial stack proposal in the first
> > place.  :)
> >
> > So if the serial stack takes care of it, is there a way to do the
> > flippage
> > in a platform independent manner?  Maybe through the tmote platform's
> > PlatformSerial StdControl.start()/stop()?  Or are you thinking of a
> > different way
> >
> >
> >
> >
> > My assumption was that PlatformInit (PlatformC) would set the pins up
> > for when there is no serial stack, and then the serial stack would
> > configure them for its own use in a SoftwareInit, and the serial
> > stack's command call graph would eventually hit the UART HPL. Would
> > this work?
> >
> > Phil
> >
> >
> >
> >
> >
> > _______________________________________________
> > Tinyos-devel mailing list
> > Tinyos-devel at millennium.berkeley.edu
> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
> _______________________________________________
> Tinyos-devel mailing list
> Tinyos-devel at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20080704/13a4f41e/attachment.htm