hi,
i am interfacing PIC microcontroller with Xbee OEM module.
i have questions here, hopefully someone can help to explain. thanks.
i will like to know, what will happen if i de-assert RTS/ hold the serial transmitting out from xbee to microcontroller if a byte haven’t complete to transfer. the transmit will ends only after the complete byte is received?
how many bytes of buffer are available at DO buffer? if i hold the the transmit out from DO buffer for too long will it cause the following received API package lost some bytes? and cause the microcontroller to receive incomplete API package? microcontroller will keep waiting for the bytes that is lost. Or the xbee will not load the API package into the buffer, if it sees that there is not enough bytes of remaining buffer available.
If RTS is being used by your micro-controller and the RTS feature is enabled on the Xbee module, then data will remain in the serial buffer of the module when RTS is de-asserted. If additional data is still being recevied (through the antenna) by the module then the buffer will continue to fill - risking a potential buffer overflow where data would be lost. The buffer size is 200 bytes. You must be careful when using RTS flow control as to not lose data due to a buffer overrun.
Further to Jay’s comment: the answer to your first question is that the transmission of a byte will never be interrupted by the RTS signal. You can rely on that for serial communications in general, not just for the XBee.
As a note of caution, don’t expect that de-asserting RTS will stop the data flow instantly. Your PIC could still receive another byte or two after the de-assertion, due to buffering at the byte level. So if you use RTS you need to allow for this.
If you do de-assert RTS for too long, then as you suggest you will lose some data and your PIC will see an incomplete packet. Whether that matters depends on your application. For instance, if it’s a data logger for environmental information you might be willing to lose the occasional packet. In that sort of case you wouldn’t need to take so much care over not filling the buffer, but you’d have the problem of knowing which bytes to discard in order to recognise the start of the next packet (the 0x7e byte). That would be a reason to use API mode 2, because mode 2 escapes the 0x7e byte anywhere other than at the start of a packet.
If RTS is being used by your micro-controller and the RTS feature is enabled on the Xbee module, then data will remain in the serial buffer of the module when RTS is de-asserted. If additional data is still being recevied (through the antenna) by the module then the buffer will continue to fill - risking a potential buffer overflow where data would be lost. The buffer size is 200 bytes. You must be careful when using RTS flow control as to not lose data due to a buffer overrun.
Please check your terminology/jargon…
“RTS” is an output signal from the transmitting device.
“CTS” is an input to the transmitting device. It originates in the receiving device.
The sending device asserts RTS and waits for CTS to go true. It sends at will until CTS goes false. The sending device stops within an undefined, but conventionally few number of bits or bytes, until CTS returns to true.
There are common uses of DTR and DCD too, but these are normally used only for dial-up type modems.
The role of sending and receiving device, and the directions are given by the names DCE and DTE, where DCD is (was) a modem, and DTE was a “terminal”, or PC.
@stevech: I agree with you about what the EIA specs say, but I don’t believe that’s the way these lines are implemented for the XBee. The situation you describe allows for flow control in one direction, whereas the XBee uses RTS and CTS independently for bi-directional flow control. Page 10 of the Digimesh product manual describes the logic, and it doesn’t say anything about being EIA-compliant as far as I can see.
If RTS is being used by your micro-controller and the RTS feature is enabled on the Xbee module, then data will remain in the serial buffer of the module when RTS is de-asserted. If additional data is still being recevied (through the antenna) by the module then the buffer will continue to fill - risking a potential buffer overflow where data would be lost. The buffer size is 200 bytes. You must be careful when using RTS flow control as to not lose data due to a buffer overrun." is correct. You must be careful when using RTS flow control as you can cause a buffer overrun if you are using RTS to prevent data from flowing while receiving data over the RF port.