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