Unfortunately the device I am connecting to does not support hardware flow control. I had thought about connecting the TTL Rx from the MAX3238 level converter I am using to both the UART0 Rx and a GPIO pin configured for interrupt, however connecting to the I/O pin (whether it is enabled or not) seems to stop signals reaching the Rx of the UART.

Think I will have to investigate gaining access to the UART1 pins somehow, as I am only using the USB for programming.



Thanks again,

Andrew




Chris Pettus wrote:
Does your UART device support flow control RTS/CTS or DSR/DTR?
If it does you could use some general purpose IO pins to implement the flow control from the mote side. Also the GPIO pins can be configured for interrupt operation so you would not have to constantly poll the device. There is a method I have been working on for using the I2C mode and UART mode at the same time. Whenever busarbitration releases the bus I make sure that the UART interrupts are still enabled but do not take control of the bus until I receive a byte and the HPLUART.get() event fires. Since the I2C operates in master/slave mode it will take control of the bus, change the mode, send/receive data, change the mode back to what it was before and release the bus. I just have to make sure the receive interrupt for the UART is re-enabled after the release. However, this does not work for SPI mode since the interrupt flag register in the MSP430 is the same for both modes. Chris

On 2/27/06, *Andrew Jamieson* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:

    Hi

    Following from other posts, I have got the UART and SPI on the Tmote
    working happily together using the BusArbitration module - I can
    happily
    send data over the UART without affecting the radio.  However, the
    device I am interfacing to via the UART sends data asynchronously, and
    obviously when I switch the USART back to SPI mode for radio comms, any
    incoming UART bytes are missed.

    Anyone have any ideas how the radio and the UART can be serviced without
    continually polling between the two in the hope that data from both can
    be caught in time?  This procedure works to a point, but is pretty
    inefficient and also seems to cause a null byte to be sent over the UART
    every time it is stopped via USARTControl.disableUART().


    Thanks for any help,

    Andrew
    _______________________________________________
    Tinyos-help mailing list
    [email protected]
    <mailto:[email protected]>
    https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
    <https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help>



_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help

Reply via email to