UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 11th Apr 2024, 4:44 pm   #1
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default RS232 question

Modes, please move or delete if this isn't a question for the forum.

There's a lot of knowledgeable folks here and I'm hoping someone could help me with a question I have about RS232 signalling.

I have a PC with a usb-to-rs232 cable connecting to a PIC configured as a UART. For what it's worth, the cable is made by 'DriverGenius' and called a USB to serial adapter.
It sends and receives data fine at 115200 baud with no flow control, but I want to
be able to send large-ish chunks of data to the PIC without loss (it's part of
a project to create a EPROM programmer for strange devices like the 8755 which
most modern programmers appear unable to program). The idea is that the PIC receives
the data from the PC, generates addresses for the EPROM and then pulses the
program pin to its required voltage (25v for a 8755).

So I've looked at RTS/CTS as that is one of the options supported by the serial
terminal on the PC I'm using (something called 'Serial').

My understanding is that the PC is the DTE and the PIC uart is the DCE, in RS232 terminology. And the
connection between the RS232 19 pin D connector and the uart is simple enough:

DTE DCE
-----------
TX ---> RX (pin 3)
RX <--- TX (pin 2)
GND <--> GND (pin 5)
RTS ---> RTS (pin 7)
CTS <--- CTS (pin 8)

So at the PIC side the signals go thru a MAX232 to convert to TTL levels, and then
RTS goes to a pin configured as input and CTS to one configured as output. I'll not
go into more detail on TX and RX as they work fine. Note that RTS and CTS are active
low signals. Looking at the idle voltage levels, they are what I'd expect - TX/RX
are low i.e. 'mark' at around -7v and RTS/CTS are high i.e. logic low at around +7v.

Now I'd expect if the PC wants to send data to the PIC, it should pull RTS low (it's an
active low signal) which would signal the PIC that there's data to receive. When
the PIC is ready, the PIC pulls CTS low telling the PC to send the data.

Except it doesn't. RTS just sits high all the time.

The other way is fine - if the PIC is ready to send data it pulls CTS low and then
sends data. If it doesn't pull CTS low, the PC can't send data. Again RTS just sits high all the time rather than going low to say 'wait'.

Am I missing something?
Keith956 is offline   Reply With Quote
Old 11th Apr 2024, 6:31 pm   #2
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,320
Default Re: RS232 question

I think you can just ignore RTS and only drive CTS from the PIC to indicate when the PC should stop transmitting because the PIC is busy. Not all USB to serial adapters will respond quickly enough to stop transmitting when CTS indicates not ready.

Do you know which USB to serial chip is used in your adapter?
Mark1960 is offline   Reply With Quote
Old 11th Apr 2024, 6:40 pm   #3
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default Re: RS232 question

Quote:
Originally Posted by Mark1960 View Post
Do you know which USB to serial chip is used in your adapter?
Mark, thanks, I believe it's the Prolific PL2023. I did install the driver for that ship as suggested on the Prolific site. I'm actually using it with a Macbook as the PC.

Looking at the Prolific website, there appears to be different versions of this chip, I'm not sure which one is used in the serial link though.
Keith956 is offline   Reply With Quote
Old 11th Apr 2024, 6:51 pm   #4
paulsherwin
Moderator
 
paulsherwin's Avatar
 
Join Date: Jun 2003
Location: Oxford, UK
Posts: 28,278
Default Re: RS232 question

Quote:
Originally Posted by Mark1960 View Post
I think you can just ignore RTS and only drive CTS from the PIC to indicate when the PC should stop transmitting because the PIC is busy. Not all USB to serial adapters will respond quickly enough to stop transmitting when CTS indicates not ready.
I also think this is the case. Getting full modem control to work with RS232 has always been a bit of a nightmare, even before trying to do it through USB adaptors.
paulsherwin is offline   Reply With Quote
Old 11th Apr 2024, 7:00 pm   #5
G6Tanuki
Dekatron
 
G6Tanuki's Avatar
 
Join Date: Apr 2012
Location: Wiltshire, UK.
Posts: 14,158
Default Re: RS232 question

The USB to Serial converters I tried a decade and a half back when trying to use them for uploading frequency tables to older PMR radios made by the likes of Motorola, Simoco and Key were never really successful. I used to have an ancient 386 IBM PS/2 with a genuine RS232 serial port which I kept alive just to program radios, but it is long gone.
__________________
I'm the Operator of my Pocket Calculator. -Kraftwerk.
G6Tanuki is offline   Reply With Quote
Old 11th Apr 2024, 7:17 pm   #6
Dave Moll
Dekatron
 
Dave Moll's Avatar
 
Join Date: Feb 2005
Location: West Cumbria (CA13), UK
Posts: 6,165
Default Re: RS232 question

Quote:
Originally Posted by Keith956 View Post
My understanding is that the PC is the DTE and the PIC uart is the DCE, in RS232 terminology. And the
connection between the RS232 19 pin D connector and the uart is simple enough:

DTE DCE
-----------
TX ---> RX (pin 3)
RX <--- TX (pin 2)
GND <--> GND (pin 5)
RTS ---> RTS (pin 7)
CTS <--- CTS (pin 8)
If you are using RTS/CTS signalling, shouldn't the last two be:

RTS ---> CTS
CTS <--- RTS?
__________________
Mending is better than Ending (cf Brave New World by Aldous Huxley)
Dave Moll is offline   Reply With Quote
Old 11th Apr 2024, 7:21 pm   #7
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,807
Default Re: RS232 question

I don't know what class of PIC you are using (perhaps you could tell us) but on the ones I use most the TX / RX part is the only part handled semi-automatically by the inbuilt UART (or whatever Microchip likes to call it). If you want handshaking as well, normally it's up to your program to 'bit-bang' the RTS and CTS action. Maybe I'm behind the times.

Moreover, you should probably try to implement a receive buffer which, every time the UART signals it has received a character, you should place the received character into. Ideally, set up an interrupt which executes every time the UART has a new received character ready to be read out, reads the character, and places it into the buffer. Elsewhere in your main program loop you would look, periodically, to see if the buffer (not the UART) has at least one character waiting to be read out.

The buffer should look like a continuous circle of addresses with two pointers, call them HEAD and TAIL, which initially start at the same address in the buffer - meaning the buffer is empty.

Every time you fetch a new character from the UART you should insert it into the buffer at HEAD and increase the HEAD pointer by one. If that makes HEAD greater than the highest address in the circular buffer, make HEAD=0 to wrap back around to the lowest address in the buffer.

Every time you read a received character out from the buffer, you should read it from the buffer position pointed to by the TAIL pointer and increase TAIL by one. If that makes TAIL greater than the highest address in the buffer, make TAIL=0 to wrap back around to the lowest address in the buffer.

If HEAD catches up with TAIL, the buffer is full and that is the time to assert the RS232 'don't send any more' signal to the sender - arguably you should do it sooner, when HEAD gets to within maybe 10 steps behind TAIL, on the assumption that the sender may manage to send several more characters before it reacts to the 'don't send' signal.

If TAIL catches HEAD, the buffer is empty and there are no characters waiting to be fetched.

Edit: Yes, as per Dave Moll it should be RTS > CTS and CTS > RTS.
SiriusHardware is offline   Reply With Quote
Old 11th Apr 2024, 7:22 pm   #8
paulsherwin
Moderator
 
paulsherwin's Avatar
 
Join Date: Jun 2003
Location: Oxford, UK
Posts: 28,278
Default Re: RS232 question

Quite right Dave.
paulsherwin is offline   Reply With Quote
Old 11th Apr 2024, 7:40 pm   #9
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default Re: RS232 question

Quote:
Originally Posted by Dave Moll View Post
If you are using RTS/CTS signalling, shouldn't the last two be:

RTS ---> CTS
CTS <--- RTS?
I was under the impression that is for DTE-DTE communication, for DTE-DCE its as I showed. The source of that info was:

(link gives a 403 error, it appears to be censored (for goodness sake), search Microchip docs for 'Hardware Flow Control' and you should be able to find the page)

Unfortunately there's a lot of confusion about what a DTE and DCE actually are

However, I'm pretty sure I did try that arrangement, and it didn't work at all.
Keith956 is offline   Reply With Quote
Old 11th Apr 2024, 7:54 pm   #10
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default Re: RS232 question

Quote:
Originally Posted by SiriusHardware View Post
I don't know what class of PIC you are using (perhaps you could tell us) but on the ones I use most the TX / RX part is the only part handled semi-automatically by the inbuilt UART (or whatever Microchip likes to call it). If you want handshaking as well, normally it's up to your program to 'bit-bang' the RTS and CTS action. Maybe I'm behind the times.
No, you're spot on, the 18F4520 I'm using has TX/RX, you need a couple of ports to handle RTS/CTS and do the handshaking manually, sigh.

Quote:
Originally Posted by SiriusHardware View Post
Moreover, you should probably try to implement a receive buffer which, every time the UART signals it has received a character, you should place the received character into. Ideally, set up an interrupt which executes every time the UART has a new received character ready to be read out, reads the character, and places it into the buffer. Elsewhere in your main program loop you would look, periodically, to see if the buffer (not the UART) has at least one character waiting to be read out.

The buffer should look like a continuous circle of addresses with two pointers, call them HEAD and TAIL, which initially start at the same address in the buffer - meaning the buffer is empty.

Every time you fetch a new character from the UART you should insert it into the buffer at HEAD and increase the HEAD pointer by one. If that makes HEAD greater than the highest address in the circular buffer, make HEAD=0 to wrap back around to the lowest address in the buffer.

Every time you read a received character out from the buffer, you should read it from the buffer position pointed to by the TAIL pointer and increase TAIL by one. If that makes TAIL greater than the highest address in the buffer, make TAIL=0 to wrap back around to the lowest address in the buffer.
Yep, that's exactly what I'm doing. A high priority interrupt puts the received character into a buffer, in command mode when a CR is received then the contents of that buffer are checked for commands the PIC needs to recognise (like read from prom, write to prom etc)

Quote:
Originally Posted by SiriusHardware View Post
If HEAD catches up with TAIL, the buffer is full and that is the time to assert the RS232 'don't send any more' signal to the sender - arguably you should do it sooner, when HEAD gets to within maybe 10 steps behind TAIL, on the assumption that the sender may manage to send several more characters before it reacts to the 'don't send' signal.

If TAIL catches HEAD, the buffer is empty and there are no characters waiting to be fetched.
All of this works, except the sender (PC) is not issuing RTS before sending data, to be acknowledge and told when to send it (by CTS). The method you describe may work - I haven't got to the stage of sending enough data to need the handshake - but it doesn't seem right that RTS is not acting like it should (or to be more precise, doing anything at all), at least according to the Microchip description of how handshaking should work. Accordfing to that, the sender should assert RTS to indicate it's about to send data, and wait until CTS goes low.
Keith956 is offline   Reply With Quote
Old 11th Apr 2024, 8:44 pm   #11
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default Re: RS232 question

Quote:
Originally Posted by Dave Moll View Post
If you are using RTS/CTS signalling, shouldn't the last two be:

RTS ---> CTS
CTS <--- RTS?
Actually the right hand side should really read 'input to PIC' and 'output from PIC'. There is no RTS/CTS pin on the PIC, just input pins which can be read, and output pins that can be set.

The real issue is that RTS, from the PC to the PIC, always stays at ~ +10v i.e. logic low. Maybe that's intentional, but if so it means there is no handshaking.
Keith956 is offline   Reply With Quote
Old 11th Apr 2024, 8:54 pm   #12
kalee20
Dekatron
 
Join Date: Feb 2007
Location: Lynton, N. Devon, UK.
Posts: 7,138
Default Re: RS232 question

Is it not the case that DTR and DSR have to do their thing first - to let the main computer know it's connected to something, before RTS (and the reply, CTS) will be activated?

(I last did RS232 comms about 20 years ago, and it was a one-off exercise!)
kalee20 is offline   Reply With Quote
Old 11th Apr 2024, 8:57 pm   #13
Trigon.
Hexode
 
Trigon.'s Avatar
 
Join Date: Jun 2018
Location: Buckinghamshire, UK.
Posts: 406
Default Re: RS232 question

A rather more comprehensive description than the Microchip one:-

https://en.wikipedia.org/wiki/RS-232#RTS,_CTS,_and_RTR

Particularly:-
Quote:
In this scheme, commonly called "RTS/CTS flow control" or "RTS/CTS handshaking" (though the technically correct name would be "RTR/CTS"), the DTE asserts RTS whenever it is ready to receive data from the DCE, and the DCE asserts CTS whenever it is ready to receive data from the DTE. Unlike the original use of RTS and CTS with half-duplex modems, these two signals operate independently from one another. This is an example of hardware flow control. However, "hardware flow control" in the description of the options available on an RS-232-equipped device does not always mean RTS/CTS handshaking.
Cheers
Trigon. is offline   Reply With Quote
Old 11th Apr 2024, 9:07 pm   #14
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default Re: RS232 question

Quote:
Originally Posted by kalee20 View Post
Is it not the case that DTR and DSR have to do their thing first - to let the main computer know it's connected to something, before RTS (and the reply, CTS) will be activated?
I wonder. I haven't looked at DTR/DSR yet, had assumed that RTS/CTS was enough. I'll take a look tomorrow.
Keith956 is offline   Reply With Quote
Old 11th Apr 2024, 9:09 pm   #15
paulsherwin
Moderator
 
paulsherwin's Avatar
 
Join Date: Jun 2003
Location: Oxford, UK
Posts: 28,278
Default Re: RS232 question

This is bringing back old memories of wrestling with RS232 stuff. Everybody trying to sort this out has my sympathy.

The underlying problem is that almost everybody implemented RS232 differently, particularly if there wasn't an actual modem involved.
paulsherwin is offline   Reply With Quote
Old 11th Apr 2024, 9:23 pm   #16
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,320
Default Re: RS232 question

For Keith’s application it would simplify the hardware to use one of the common ft232 or ch340 breakout board with ttl input and output levels direct to the pic instead of going through an RS232 level shifter on the board. Sometimes these breakout boards need a link added to connect cts.
Mark1960 is offline   Reply With Quote
Old 11th Apr 2024, 9:43 pm   #17
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default Re: RS232 question

Quote:
Originally Posted by Mark1960 View Post
For Keith’s application it would simplify the hardware to use one of the common ft232 or ch340 breakout board with ttl input and output levels direct to the pic instead of going through an RS232 level shifter on the board. Sometimes these breakout boards need a link added to connect cts.
That's a good idea. I think I've got a Waveshare ft232 board I've never used somewhere. More things to try tomorrow.
Keith956 is offline   Reply With Quote
Old 11th Apr 2024, 9:45 pm   #18
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default Re: RS232 question

Quote:
Originally Posted by paulsherwin View Post
This is bringing back old memories of wrestling with RS232 stuff. Everybody trying to sort this out has my sympathy.

The underlying problem is that almost everybody implemented RS232 differently, particularly if there wasn't an actual modem involved.
Yes Paul, one takes USB for granted now but in a past getting things to talk to each other could be a nightmare... remember those breakout boxes so you could swizzle rs232 pins to get things to work?
Keith956 is offline   Reply With Quote
Old 12th Apr 2024, 2:53 am   #19
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,496
Default Re: RS232 question

Quote:
Originally Posted by Keith956 View Post
Quote:
Originally Posted by Mark1960 View Post
For Keith’s application it would simplify the hardware to use one of the common ft232 or ch340 breakout board with ttl input and output levels direct to the pic instead of going through an RS232 level shifter on the board. Sometimes these breakout boards need a link added to connect cts.
That's a good idea. I think I've got a Waveshare ft232 board I've never used somewhere. More things to try tomorrow.
Yes, Strictly speaking RS232 is a standard that defines use of +/- (3 to 15)V levels (as well as all the various Asynchronous Serial parts) of the protocol. And pre-dates the now quite common use of 'TTL etc UART-levels' with Async-Serial (which originated when microprocessor system were being used on RS232, and the Async-serial UART etc IC's could only handle low-current 5V-levels - requiring line-driver IC's to interface to proper RS232-levels 'COM' ports).
As the line-drivers designed for this were inverting, then 'UART' levels are also inverted relative to RS232 ones, with data lines idling at 5V on UART'S rather than -12V etc on RS232. (IIRC Asynchronous Serial Idles at a 'Mark' rather than a 'Space', but a 'Mark' on (inverted) RS232 is a negative voltage)

I seem to recall that the original MAX232 wouldn't work at high data-rates that later (and allowing mostly smaller value capacitors) MAX232A etc could - although the standard version would work upto at least 115,200 IIRC.


Back in the old days of using RS232 on printers etc, the Data Terminal Ready (DTR) input to the DTE (that names are referenced to) was usually used by printers to pause further data transmission to these until its buffer had printed enough for space to now be available.
And DTR (along with DSR in other direction) is for 'Flow-Control' rather than 'Handshaking' that RTS/CTS were intended for - but not often used.


Unfortunately, most 'FTDI' UART-level leads only provide TxD & RxD lines. And you have to buy a more complex lead (like their MPSSE, that does all kinds of protocols), or use one of their PCB-Mount modules with all the pins accessible.

I don't think Prolific did UART-level leads, and got a bit of a bad reputation for
deliberately not supporting their older devices in later drivers as an attempt at discouraging the widespread cloning of those in China - But this also meant that perfectly legitimate Prolific IC's in older devices wouldn't work unless you trawled the 'net for an old driver.
FTDI also messed-up with a (Windows update?) driver, that mistakenly thought genuine FTDI IC's were counterfeit and over-wrote their USB VID/PID, so 'bricking' these!

Silicon Labs (SiLabs) devices don't tend to have any of this (and were available a year ago, when everywhere had sold-out of FTDI IC's, with them even closing their Webshop / samples qty requesting and them only offering to sell you a few after many questions on your product development).
- But I think you can only get (quite cheap) Eval boards from them, rather than ready-made 'UART-level to wires / connector' leads.

The v.cheap CH340 WEMS.CC etc 'TTL' UART-Levels modules do provide DTR on their 6-pin connector to the target system. And a solder-blob link to select another pin between either RTS (default?) or CTS.
They also have a solder-blob link (usually left completely open, as supplied, so need to make this connection for it to work) to select 5V or 3.3V levels.


Back in the 90's there were often 3rd party providers of Comms Library routines to support Async etc Serial. GreenLeaf would sell you these for MSDOS etc. programs, written under 'C'
But I'm not sure what is now used (Maybe recent compilers already have this)

Last edited by ortek_service; 12th Apr 2024 at 3:03 am.
ortek_service is offline   Reply With Quote
Old 12th Apr 2024, 7:23 am   #20
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 759
Default Re: RS232 question

Quote:
Originally Posted by ortek_service View Post
I don't think Prolific did UART-level leads, and got a bit of a bad reputation for
deliberately not supporting their older devices in later drivers as an attempt at discouraging the widespread cloning of those in China - But this also meant that perfectly legitimate Prolific IC's in older devices wouldn't work unless you trawled the 'net for an old driver.
Yes the K150 ICSP programmer - which is still being sold - uses the old Prolific chip, and the current driver for them doesn't support Windows 8 onwards. There is a hacked driver that does work, but you have to stop Windows from trying to update the driver to the new one. Been there...

Quote:
Originally Posted by ortek_service View Post
Back in the 90's there were often 3rd party providers of Comms Library routines to support Async etc Serial. GreenLeaf would sell you these for MSDOS etc. programs, written under 'C'
But I'm not sure what is now used (Maybe recent compilers already have this)
I was going to use the QSerialPort class - part of the Qt C++ GUI toolkit. Mainly because I've used Qt for some 25 years now, although I've never tried serial comms using that library. But intially I was using a terminal just to get the PIC side working.
Keith956 is offline   Reply With Quote
Reply

Thread Tools



All times are GMT +1. The time now is 3:03 am.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2024, vBulletin Solutions, Inc.
Copyright ©2002 - 2023, Paul Stenning.