[Tinyos-devel] Sent again... Proposal for setBaud in HplMsp430Usart.nc

[Vlado Handziski]

I am out of office and can not comment in depth, but there was a time when
the HAL hat a SetBaud command, but it was removed (it did not reset the
USART, leading to problems, etc, search the mailing list for the
discussion/read the CVS log) on purpose in order to collect all
configuration commands that have to be done under reset USART condition at
one place - in the configure upcalls. Since the reset has secondary effects,
I still think that the best solution to your problem is to use the current
infrastructure and use the configure interface with different configurations
without releasing the ownership.

Vlado



On Wed, Jun 4, 2008 at 7:53 AM, Eric Decker <cire831 at gmail.com> wrote:

> I've sent this out in May but haven't received any comments so am thinking it got lost in translation.  Kevin said to send it again so here it is...
>
>
> Background:  The MamMark marine tag is close to a TelosB platform.  One of
> the differences is the addition of a GPS, direct connect serial port, Radio,
> and SD (mass storage) all sitting on USART 1.
> Primarily the GPS runs at 115200 using the SiRF binary protocol.  Under
> certain circumstances (we run out of power, we have a solar cell so it can
> come back) the GPS will revert to NMEA at 4800.
>
> Bottom line is I need to change baud rate.  I could have two different
> configurations (although the only difference is the UBR and UMCTL fields)
> and rearbitrate but that seems cumbersome.  Another way is to call the UART
> configurator directly with the different configuration.   But that too seems
> odd when all I want to do is hit the UBR and UMCTL registers.with a
> different configuration (somewhat wasteful).
>
> I could call Usart.setUbr and Usart.setMctl directly but there is a problem
> with this.  It turns out that just changing the registers doesn't actually
> change what the h/w does.  For the change to take effect the USART has to be
> reset (SWRST -> 1 -> 0).  This also has the side effect of disabling
> interrupts for the USART (IEx is modified).  In other words if setUbr and/or
> setUmctl are used you definitely had better know what the chip is going to
> do (a reasonable assumption given the low level wacking).  Using the
> sequence setUbr, setMctl, resetUsart(TRUE), resetUsart(FALSE) doesn't work
> because resetUsart(TRUE) loses any mode bits previously set (it forces U1CTL
> = SWRST).
>
> So what I'd propose is the following:
>
> 1) add setBaud(uint16_t ubr, uint8_t umctl) to the interface.
>
> 2) Usart.setBaud does the following:
>
>   async command void Usart.setBaud(uint16_t ubr, uint8_t umctl) {
>     atomic {
>       U1CTL |= SWRST;
>       U1BR0 =  ubr & 0x00FF;
>       U1BR1 =  (ubr >> 8) & 0x00FF;
>       U1MCTL = umctl;
>       CLR_FLAG(U1CTL, SWRST);
>     }
>   }
>
> It encapsulates the chip needing a reset with out changing any of its modes.
>  (Usart.resetUsart(TRUE) explicitly sets U1CTL = SWRST which wipes the
> mode).
>
> Note the caller of Usart.setBaud needs to call Usart.enableIntr to reenable
> for whatever they are doing if desired.
>
> If setBaud is added I would deprecate setUbr and setMctl.  setBaud is easier
> to use.
>
> I know there are approaches using the existing Msp430 core to make this
> work.  I think this is cleaner and easier to use.  So I thought I'd put it
> out there.
>
> thoughts,
>
> eric
>
> --
> Eric B. Decker
> Senior (over 50 :-) Researcher
> Autonomous Systems Lab
> Jack Baskin School of Engineering
> UCSC
>
> _______________________________________________
> 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/20080604/138750aa/attachment-0001.htm