Behaviour of SER_BUFF in QPC & SMSQ/E

[martyn_hill]

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.

Wading through the SMSQ/E sources for the SER_BUFF procedure doesn't reveal (to me) how the Serial buffers are implemented.

Thoughts? Marcel, perhaps ?

[johnh]

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.

I believe SER_BUFF is just the SBasic way of calling the corresponding extension (SERB) provided by the Ser_Par_Prt thing.

I don't know for sure, but I would guess that setting the buffer size for a port and opening a channel to that port are independent of each other, i.e. the buffer size could be set via SBasic (in a BOOT file, perhaps) and then the port opened via assembler (e.g. a comms program)...

John Hall

[martyn_hill]

Hi John

Thanks for that - that was my assumption as well - namely that any future channels opened to a given port would inherit the latest buffer-size settings - similar to the way BAUD works, for example.

Let's see if anyone else here can confirm or correct this understanding.

M.

[tofro]

To my knowledge, SER_BUF on QPC2 doesn't do anything.

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.

I derive that there is also no need to use the SER_BUF command.

The QPC2 manual (other than the generic SMSQ/E manual) doesn't even mention SER_BUF.

Your mileage might vary on other SMSQ/E machines, though.

Tobias

[martyn_hill]

Interesting....

Thanks Tobias. I'll look again at why I appeared to see problems communicating with the uC via Serial/USB on QPC2, without extending the buffer size using SER_BUFF.

It was an early-on observation, whilst still debugging the uC code, so maybe a red-herring...

[Martin_Head]

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.

[tofro]

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...

[tofro]

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...

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.

[mk79]

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.

Yes, there is no 81-byte buffer in SMS/E. As tofro quoted, by default the ports are dynamically buffered (in 512 byte increments), i.e. the buffers get as big as needed to hold all the data. Once you issue SER_BUFF, the port uses buffers of fixed size instead, but only after the next OPEN, I think.

In case of QPC2 there are also 512 byte buffers on the Windows side and 2kb buffers within QPC. These are always there, no matter how you configure SMSQ/E.

[mk79]

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.

At work we sometimes use these http://www.ni.com/de-de/support/model.usb-232.html. At 200€ for one serial port these are quite the bargain Some cheap adapters can lose characters occasionally, even in transmit direction. In one case ditching the flimsy USB cable that came with the (FTDI based) adapter for a better quality one actually helped, but a lot of hours went into debugging before that one was tried. Also there are counterfeit FTDI chips out there which are difficult to tell apart from the real thing. So your mileage may vary...

Marcel