RS232 loopback test

Hi folks,

I'm using a StarTech USB-RS232 adaptor. I have plugged the USB end to my computer, leaving the RS232 end. I would like to know if I can wire the TX and RX pins of the RS232 to send a series of pulses and receive them . The configuration I've made is as follows:

s = serial('COM24');
s.BaudRate = 38400;
s.Flowcontrol = 'none';
s.Stopbits = 1;
s.Parity = 'none';

How can I send those pulses and receive them using the RS232 end?

Thanks in advance

Answer 1

[Walter Roberson]

In theory, Yes, that should work. You might need to put a resistor on the ground pin: on RS232, the ground pin cannot be left floating.

[Lask]

Hey Walter, thanks for your answer. So, once I understand the wiring process. How could I write to the RS 232 and read from it at the same time? I mean, I know I can use fwrite and fwrite, but how would I do it simultaneously?

[Walter Roberson]

First you need to understand that if you use RS232 then the RX and TX lines cannot be used to transfer arbitrary pulse streams: it is strictly required that the start-bit + 6 to 10 bits + stop-bit protocol be used on the RX and TX lines.

The common RS232 lines that you can in theory set independently are DTR (Data Terminal Ready) and RTS (Request to Send). There is no standard about how quickly those can be changed -- which also means there is no standard about how slowly you need to change them to be certain that the other end has seen the change.

Changing either of these lines from the MATLAB level is not all that fast: you have to make set() calls that drop into the driver that has to figure out what is happening and set the appropriate hardware control register.

Secondly, you need to understand that it is impossible for USB to transit and receive simultaneously. USB is a strict master/slave relationship in which the master sends signals saying "Device #329432, tell me whether you have any data for me; don't send the data, just tell me whether you have data". And then it is the device's turn to use the shared serial bus, using the same transmit and receive lines that the master used. The master does that for all of the devices it knows about, decides on the priorities of devices in order to meet any time reservations that have been made, and eventually says "Device #329432, now you can send me a packet of data", at which point device #329432 gets to hog the shared serial bus. It is not possible for the host to transmit data during the same time slot that the other device is transmitting: the USB controller on the device is responsible for queuing the data until it is granted permission to transmit it.

Thirdly, if you were using direct RS232, then the general procedure is that to transmit, the host queues a small number of bytes of data at the chip and the chip monitors the signal conditions (whether it is already busy, whether hardware flow control is inhibiting transmissions) and when the transmit is free, starts clocking out bits, with the physical transmission handled at the chip level, unmonitored by the CPU. In some set-ups, emptying the transmit queue (or nearly so) might lead the chip to signal an interrupt request so that the CPU knows to move more data out of memory into the on-chip queue.

While the chip is idle or while it is clocking out bits to transmit, the chip is also available to clock in bits. When a validly formed character / byte has been received, the chip moves the byte into its queue; if enough bytes have accumulated then the chip will notify that an interrupt is requested, so that the CPU knows to move the data out of the hardware queue into appropriate memory.

In the above discussions, I spoke of queues. There have been some quite sophisticated serial transmit systems for high speed work -- but a bare-bones device might only have a queue of one received byte plus space for the bits being currently clocked in.

The received bytes sit around in the on-chip hardware queue until the CPU decides it is good and ready to service the interrupt (or poll to see if data is ready.) If the on-chip queue would overflow with new data, the new data is dropped; depending on the chip settings, the chip might also take other actions such as dropping CTS (clear to send) so that the transmitting system can figure out that it needs to stop transmitting.

Because of these internal queues and the indeterminate time before the CPU gets around to servicing the interrupt, it might be anywhere between nano-seconds and a small number of seconds between the time that a looped-back bit is ready for processing by the application.

In short: if the idea was to use USB to RS232 in order to exchange somewhat-synchronized individual pulses, then you will not be able to make this work.