The Sinclair QL Forum

martyn_hill wrote: My question is how the SER_BUFF port, ouput_size[,input_size] interacts with the default 81 byte buffer(s) that the standard QDOS SERial port driver creates at open-time. The QPC Keywords manual describes the SER_BUFF command, but doesn't make reference to the 81-byte buffer of old-school QDOS.

QPC2 Manual wrote:Unlike the basic SMSQ serial port drivers, the SMSQ/E serial port drivers are dynamically buffered.
There is therefore no need to use the PRT device.

Martin_Head wrote:Does the USB to Serial microcontroller device/software handle RS232 handshaking, hardware Ready/Busy, or XON/XOFF?

Can it buffer data if QPC2 is says it's busy, or does it just pass the data through regardless?

If it does not halt the data, then you would loose data. Which increasing the serial buffers would get around, as QPC2 is less likely to go busy.

The FT245R, FT2232C (in FIFO mode) and FT245BM chips use their own handshaking as an integral part of its design, by proper use of the TXE# line. The FT232R, FT2232C (in UART mode) and FT232BM chips can use RTS/CTS, DTR/DSR hardware or XOn/XOff software handshaking. It is highly recommended that some form of handshaking be used.

There are 4 methods of flow control that can be programmed for the FT232BM device.

1. None - this may result in data loss at high speeds
2. RTS/CTS - 2 wire handshake. The device will transmit if CTS is active and will drop RTS if it cannot receive any more.
3. DTR/DSR - 2 wire handshake. The device will transmit if DSR is active and will drop DTR if it cannot receive any more.
4. XON/XOFF - flow control is done by sending or receiving special characters. One is XOn (transmit on) the other is XOff (transmit off). They are individually programmable to any value.

It is strongly encouraged that flow control is used because it is impossible to ensure that the FTDI driver will always be scheduled. The chip can buffer up to 384 bytes of data. Windows can 'starve' the driver program of time if it is doing other things. The most obvious example of this is moving an application around the screen with the mouse by grabbing its task bar. This will result in a lot of graphics activity and data loss will occur if receiving data at 115200 baud (as an example) with no handshaking. If the data rate is low or data loss is acceptable then flow control may be omitted.

tofro wrote:

Martin_Head wrote:Does the USB to Serial microcontroller device/software handle RS232 handshaking, hardware Ready/Busy, or XON/XOFF?

Can it buffer data if QPC2 is says it's busy, or does it just pass the data through regardless?

If it does not halt the data, then you would loose data. Which increasing the serial buffers would get around, as QPC2 is less likely to go busy.

Martin,

that's somewhat of a grey area: Some do some don't. Some do RTS/CTS, some DTR/DSR, some both.

Cheap Chinese adapters normally do less, some don't even have proper +/- 12V signal levels. This doesn't actually mean more expensive ones will do better, sometimes they're just only more expensive... (And you might have heard that some of the FTDI drivers disable cheap cloned chips)

I have yet to see an USB/RS-232 converter that would actually advertise what in that area it is willing to support. So, it's hard to see what you want when browsing a shop or Amazon. If at all, you'll find it in the review comments.

One of the vendors that is willing to give some more information is FTDI, the leading RS-232-to-USB adapter chip producer. They say the following for their chips:

The FT245R, FT2232C (in FIFO mode) and FT245BM chips use their own handshaking as an integral part of its design, by proper use of the TXE# line. The FT232R, FT2232C (in UART mode) and FT232BM chips can use RTS/CTS, DTR/DSR hardware or XOn/XOff software handshaking. It is highly recommended that some form of handshaking be used.

There are 4 methods of flow control that can be programmed for the FT232BM device.

1. None - this may result in data loss at high speeds
2. RTS/CTS - 2 wire handshake. The device will transmit if CTS is active and will drop RTS if it cannot receive any more.
3. DTR/DSR - 2 wire handshake. The device will transmit if DSR is active and will drop DTR if it cannot receive any more.
4. XON/XOFF - flow control is done by sending or receiving special characters. One is XOn (transmit on) the other is XOff (transmit off). They are individually programmable to any value.

It is strongly encouraged that flow control is used because it is impossible to ensure that the FTDI driver will always be scheduled. The chip can buffer up to 384 bytes of data. Windows can 'starve' the driver program of time if it is doing other things. The most obvious example of this is moving an application around the screen with the mouse by grabbing its task bar. This will result in a lot of graphics activity and data loss will occur if receiving data at 115200 baud (as an example) with no handshaking. If the data rate is low or data loss is acceptable then flow control may be omitted.

X-ON/X-OFF should actually work with any adapter as these characters are transmitted "in the payload" and don't need any external circuitry - but with a longer than instant delay.
And as you see, there's quite a bit of buffering involved in various places: The application, driver, and the adapter itself. So it's extremey hard to say how many characters you need to live with on the receiving end once you've told the other end to hold back...

martyn_hill wrote:Hi everyone

As part of the QLUB adapter project (QL LAN via a USB/SERial port & microcontroller - see elsewhere in the forum for more details), I am exploring how best to leverage the serial-buffers option in SMSQ/E (on QPC specifically.)

For the QLUB project, I appear to need to extend the SERial buffer beyond the (old) default of 81 bytes to ensure messages are not split when transmitted via the virtual COM/USB port to the microcontroller and the SER_BUFF procedure seems to achieve this nicely when running my SBASIC test 'wrapper.'

I'm in the process of re-creating the SBASIC routines as assembler, so as to then integrate with a modified version of the QLAN NET driver (asm) code.

My question is how the SER_BUFF port, ouput_size[,input_size] interacts with the default 81 byte buffer(s) that the standard QDOS SERial port driver creates at open-time. The QPC Keywords manual describes the SER_BUFF command, but doesn't make reference to the 81-byte buffer of old-school QDOS.

tofro wrote:Bottom line: Better go for a converter vendor that credibly claims they are using an FTDI chip, and try to verify that before you buy.