[Tinyos-devel] Proposed UART Changes

Eric Decker cire831 at gmail.com
Fri Jun 26 13:02:03 PDT 2009


looks good.  more comments below.

On Fri, Jun 26, 2009 at 11:09 AM, Philip Levis <pal at cs.stanford.edu> wrote:

> Here's a first cut at a UartControl interface. I've also attached a full
> source file. Hopefully the comments give a sense of the semantics. Note that
> this interface causes state changes in other (receive/transmit) interfaces.
> We generally try to avoid this when possible, but there are times when the
> benefits outweigh the costs. I.e. tying them together would require unifying
> event handlers and configuration.
>
> 2 major changes: async operations and comments.
>
> Comments/feedback welcome.



First question that comes to mind is what is the required calls that must be
made for correct operation?

Is it as simple as calling UartControl.enableRx() and
UartControl.enableTx() and some reasonable
default behaviour will result?  What are the default settings?

Since UartControl.enableRx() enables interrupts ( a good thing), where
are these interrupts delivered?
How does one wire into the event signal path when we are using UartControl?


>
> interface UartControl {
>
>  /**
>   * Enables the UART receive path, such that
>   * the system will issue interrupts when it
>   * receives data.
>   */
>  async command error_t enableRx();
>
>  /**
>   * Disables the UART receive path. After
>   * this call returns, there will be no further
>   * receive interrupts until enableRx is called.
>   */
>  async command error_t disableRx();
>
>  /**
>   * Returns whether UART reception is enabled.
>   *
>   */
>  async command bool rxEnabled();
>
>
>  /**
>   * Enables the UART transmit path, such that
>   * the system is able to send bytes.
>   */
>  async command error_t enableTx();
>
>  /**
>   * Disables the UART transmit path. After
>   * this command returns, attempts to send
>   * bytes will return EOFF.
>   */
>  async command error_t disableTx();
>
>  /**
>   * Returns whether UART transmission is
>   * enabled.
>   */
>  async command bool txEnabled();
>
>  // TOS_UART_2400, TOS_UART_57600, etc.
>
>  /**
>   * Set the UART speed for both reception
>   * and transmission. This command should only
>   * be called when both reception and transmission
>   * are disabled. The speed should be an constant
>   * of the form TOS_UART_XX, where XX is the speed,
>   * such as TOS_UART_57600. Different platforms
>   * support different speeds.
>   */
>
>  async command error_t setSpeed(uart_speed_t spd);
>
>  /**
>   * Return the current UART speed.
>   */
>  async command uart_speed_t speed();
>
>  /**
>   * Set whether UART bytes have even parity bits,
>   * odd parity bits, or no parity bits. This command
>   * should only be called with both the receive
>   * and transmit paths are disabled.
>   */
>  // TOS_PARITY_NONE, TOS_PARITY_EVEN, TOS_PARITY_ODD, etc.
>  async command error_t setParity(uart_parity_t par);
>
>  /**
>   * Return the current parity setting.
>   */
>  async command uart_parity_t parity();
>
>  /**
>   * Enable stop bits. This command should only be called
>   * when both the receive and transmit paths are disabled.
>   */
>  async command error_t setStop();
>

Shouldn't there be a parameter for how many stop bits?

Typically, one can specify 1, 1.5, or 2 stop bits.  There is
no such thing as 0 stop bits so setNoStop should go away.  And it
is perfectly reasonable to limit the choices to 1 or 2 stop bits.


 /**
>   * Disable stop bits. This command should only be called
>   * when both the receive and transmit paths are disabled.
>   */
>  async command error_t setNoStop();
>
>  /**
>   * Returns whether stop bits are enabled.
>   */
>  async command bool stopBits();
> }
>
>
>
> Phil
>
>
>
>
>


-- 
Eric B. Decker
Senior (over 50 :-) Researcher
Autonomous Systems Lab
Jack Baskin School of Engineering
UCSC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090626/ba86c713/attachment.htm 


More information about the Tinyos-devel mailing list