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 12th Apr 2024, 11:11 am   #21
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,490
Default Re: RS232 question

Quote:
Originally Posted by Keith956 View Post
>>

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

>>

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.
Yes, I bought a K150 (Clone) a number of years ago. And I was surprised it was still being sold. It seems the original Author of the firmware is no longer around, but DIY Electronics had managed to get someone to patch it, although it can't really be properly-updated without a re-write. I recall using some (HHD Free?) Serial Port Monitoring software, that still worked with USB-Serial converters, to see what Bytes were being sent as I seem to recall issues with later PC software not working with older firmware these often had.

I do also have a few Prolific RS232 cables, and eventually found an old Prolific driver that worked on these / still worked under Windows XP (that luckily doesn't try and update the drivers)


Realterm is one of the best Terminal programs for being able to control the Serial port's extra lines / showing their status, which can be useful for debugging.
ortek_service is offline   Reply With Quote
Old 12th Apr 2024, 12:13 pm   #22
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 753
Default Re: RS232 question

So this morning I've tried a FTDI cable, which translates USB to TTL level rs232 signal directly. And also a ft232 module that does the same. Both treat their RTS pins as outputs and CTS as inputs.

I've also tried a different terminal on the PC, that also claims hardware RTS/CTS support.

I don't see RTS active on any of the combinations I've tried, I'm wondering if there is a better method to comminucate from a USB cable.
Keith956 is offline   Reply With Quote
Old 12th Apr 2024, 1:49 pm   #23
paulsherwin
Moderator
 
paulsherwin's Avatar
 
Join Date: Jun 2003
Location: Oxford, UK
Posts: 28,159
Default Re: RS232 question

Can you not just use XON/XOFF flow control and dispense with all the hardware handshaking?
paulsherwin is offline   Reply With Quote
Old 12th Apr 2024, 3:12 pm   #24
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,317
Default Re: RS232 question

For RTS/CTS handshaking the RTS indicates the terminal on your PC is ready to receive data and CTS indicates your device is ready to receive data from your terminal. In practice you can hardwire RTS as your device is unable to overrun the PC.
Mark1960 is offline   Reply With Quote
Old 12th Apr 2024, 3:27 pm   #25
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 753
Default Re: RS232 question

Quote:
Originally Posted by Mark1960 View Post
For RTS/CTS handshaking the RTS indicates the terminal on your PC is ready to receive data and CTS indicates your device is ready to receive data from your terminal. In practice you can hardwire RTS as your device is unable to overrun the PC.
Mark, see post #22. RTS is an *output* from the PC side - see the photo, CTS is an *input*. These are the names of the signals on the interface board.

I can't control RTS, all I can do is read it, and it never changes.

I can set/clear CTS but it has no effect on the data sent by the PC.
Attached Thumbnails
Click image for larger version

Name:	IMG_5611.jpg
Views:	62
Size:	57.1 KB
ID:	296285  
Keith956 is offline   Reply With Quote
Old 12th Apr 2024, 3:58 pm   #26
Mark1960
Octode
 
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,317
Default Re: RS232 question

Yes RTS is an output from the PC side and indicates when the PC is able to receive data. It doesn’t change as the PC is always able to receive data.

CTS is an input to the PC side and should stop the PC side from transmitting data.

Do you have hardware handshaking enabled on the terminal emulator on the PC?
Mark1960 is offline   Reply With Quote
Old 13th Apr 2024, 2:57 am   #27
ortek_service
Octode
 
ortek_service's Avatar
 
Join Date: May 2018
Location: Northampton, Northamptonshire, UK.
Posts: 1,490
Default Re: RS232 question

Yes, there's sometimes an option the the serial device driver to set whether hardware handshaking / flow control is used by default.

However, it does seem that RTS/CTS was never originally intended for 'Flow Control', but for half-duplex Comms. Although they later rather got mis-used for Flow-Control instead of DTR / DSR - which were originally intended for this.
This explains it: https://stackoverflow.com/questions/...s-flow-control

The 9way D-Type PC 'AT' COM port does have both CTS/RTS Handshaking & DTR/DSR handshaking pairs.
And with TxD/RxD would be have 3 fully symmetrical pairs if it were not for the DCD & RI Inputs - so DTE & DCE are different with the 5+3 lines as to which has more inputs or outputs.

Although unfortunately 'FTDI' USB-to-'TTL-UART' level cables only seem to give you RTS/CTS (in addition to TxD/RxD), along with Power-Out + Gnd, as they only have a 6pin connector - So no original FTR/DSR flow-Control: https://www.ftdichip.com/Support/Doc...32R_CABLES.pdf
- So have to use RS232 9way D ones, and use level translators if wanting the extra Flow-Control etc. lines


However, Sparkfun did a modified version that swaps RTS for DTR, which was needed by Arduino's etc:
https://learn.sparkfun.com/tutorials...okup-guide/all

And the CH340 Modules, allow you to Swap CTS to RTS to have that back again (but on CTS pin, as DTR is always present).
So you can either have RTS or CTS, but not both at once
- unless you solder extra wire(s) direct to the module - where you can also get access to DSR & DCD+RI direct on pins of the CH340G IC.
ortek_service is offline   Reply With Quote
Old 13th Apr 2024, 8:28 am   #28
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 753
Default Re: RS232 question

Thanks, yes I can control the handshaking to the extent that the host allows using the serial port interface I'll be using:

https://doc.qt.io/qt-6/qserialport.html

This can offer none, RTS/CTS or XON/XOFF flow control.

Hopefully with a little bit (or maybe a lot!) of trial and error I can get all modes of flow control working.
Keith956 is offline   Reply With Quote
Old 13th Apr 2024, 11:47 am   #29
RogerEvans
Hexode
 
Join Date: Oct 2014
Location: Wiltshire, UK.
Posts: 384
Default Re: RS232 question

If you are into writing your own code the most straightforward (but hardly elegant) method is to write a sequence of data bytes (preferably as hex characters) to the PIC and then wait long enough for the PIC to program the data bytes to the device. You usually need a timer on the PIC anyway to control the duration of the programming pulse so you can make a good guess as to how long the PC side needs to wait.

I have a home made programmer for EPROM, EEPROM, FRAM and serial EEPROM all driven from the same Linux code that sends a code for the device type, then 32 bytes of data, waits for the appropriate time, checks the device is programmed correctly, sends a confirmation code to the PC and loops to completion. The coding is very amateur but once working it was very easy to add a new device type to the code.

Roger
RogerEvans is offline   Reply With Quote
Old 13th Apr 2024, 12:22 pm   #30
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 753
Default Re: RS232 question

Roger, that sounds a good idea. So the plan is for the PC to send a batch of (say) 16 bytes to the PIC, then a checksum into a small bufffer. The PIC would then recompute the checksum and if the same, program those bytes, then read them back and compare with the buffer. If an error, repeat a few times. Then send back a 'pass' or 'fail' message back to the PC indicating whether to send more data or error out.

It's going to be slower than hardware flow control but speed is not that important and we are only talking about a few Kb to send.
Keith956 is offline   Reply With Quote
Old 13th Apr 2024, 3:15 pm   #31
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,704
Default Re: RS232 question

What (on the PC) are you going to be using to send the code to the PIC with?

You'll only be able to exercise that sort of control if the sending program on the PC is a bit of software written by you in C, Python, BASIC or what have you. If you just use the 'send file' feature on a typical PC terminal program it won't normally give you the option to send chunks of 'n' characters, it will take the view that that is what handshaking is for and that you should be using that if you need it. Back to square one.

What terminal programs often will do, though, is let you insert a delay between either individual characters sent or after every line sent, or both, provided what you are sending is a text file (such as Intel Hex or Motorola 'S'). If you use that facility to really slow down the transmission rate of the file then the PIC should be able to keep ahead of the incoming data. It's not ideal but if you just want it to work and you don't mind how slow it is, that may be one way to go.

I started (but didn't yet finish) a similar project for programming a particular type of Bipolar PROM which is not well supported by any modern programmers and not many old ones either, but my starting point was an Arduino, the main reason being that, depending on the one you pick, they have quite a lot of onboard RAM - my project uses the built in Arduino serial libraries and USB serial interface to read Intel Hex code, unchecked, as fast as possible (115K) into the Arduino's onboard RAM and only afterwards do I work through it, checking for correct format etc and then sending it out byte by byte to the device to be programmed.

On my original MK14 loader which did use a PIC and entirely self written code I did the same thing but added an 8-pin 32K serial SRAM (23K256?*) to the project for the purpose of serially receiving and storing the whole hex file verbatim before working through it and outputting the code as keypresses to the MK14. You could do the same, but obviously in your case the received file would be converted to physical address lines, data lines and programming pulses.

* The 23K256 is a 3V3 device but if you prefer to work with 5V devices (who doesn't?) there are similar 5V-tolerant devices, such as the 23LCV512 (64K) which are 5V-friendly and pretty cheap.

https://uk.farnell.com/microchip/23l...dip/dp/2309513
SiriusHardware is online now   Reply With Quote
Old 13th Apr 2024, 4:53 pm   #32
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 753
Default Re: RS232 question

Quote:
Originally Posted by SiriusHardware View Post
What (on the PC) are you going to be using to send the code to the PIC with?

You'll only be able to exercise that sort of control if the sending program on the PC is a bit of software written by you in C, Python, BASIC or what have you.
Yes that's the idea, a C++ gui based bit of code on the PC / Mac that can control what it feeds to the PIC by sending it commands and data as required,
through the serial port. That's actually the easy bit for me.

Why a PIC, well only because I have a few lying around and am familiar-ish with the IDE and C compiler. I must confess I like the look of the Raspberry Pi Pico, if the PIC is not up to the job.

So for the whole thing, there's a bit of code at the PC end to read hex files and send them, bit by bit, to the programmer. Or read back from the programmer.

Then there's the PIC code that receives commands from the PC and the program data, and does the writing or reading of the EPROM.

Then lastly there's the hardware to generate the required voltages, could be a simple dc-dc converter and pin driver, or maybe something fancier to control the voltage. The programming pulse time would be handled by the PIC, which is being clocked at 20MHz.

It's still in the early stages though, and the info/ideas have been very helpful. When I get it all working I'll make the code and schematics public - it might be useful for other people.
Keith956 is offline   Reply With Quote
Old 23rd Apr 2024, 8:09 am   #33
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 753
Default Re: RS232 question

So here's the best description I've found so far of the RTS/CTS, from the FTDI support page:

How does RTS/CTS flow control work in an FTDI chip?

FTxxx RTS# pin is an output. It should be connected to the CTS# input pin of the device at the other end of the UART link.

If RTS# is logic 0 it is indicating the FTxxx device can accept more data on the RXD pin.

If RTS# is logic 1 it is indicating the FTxxx device cannot accept more data.

RTS# changes state when the chip buffer reaches its last 32 bytes of space to allow time for the external device to stop sending data to the FTxxx device.

FTxxx CTS# pin is an input. It should be connected to the RTS# output pin of the device at the other end of the UART link.

If CTS# is logic 0 it is indicating the external device can accept more data, and the FTxxx will transmit on the TXD pin.

If CTS# is logic 1 it is indicating the external device cannot accept more data. the FTxxx will stop transmitting within 0~3 characters, depending on what is in the buffer.

This potential 3 character overrun does occasionally present problems. Customers shoud be made aware the FTxxx is a USB device and not a "normal" RS232 device as seen on a PC. As such the device operates on a packet basis as opposed to a byte basis.

Word to the wise. Not only do RS232 level shifting devices (e.g. MAX232) level shift, but they also invert the signal.


I've managed to get flow control from the PC to the PIC working correctly by using the CTS pin as in the description - basically the PIC has a receive buffer that is filled by an interrupt on receiving a character from the PC. When the receive buffer gets within a few bytes of full, it sends CTS high. When the buffer empties below that level, it sends CTS low again.

The other necessity is to restrict the transmission of characters by the PC to one pair of hex digits per 50mS - actually a little longer, as the programming time is 50mS. Easily done by putting the send thread to sleep for that time.
Keith956 is offline   Reply With Quote
Old 23rd Apr 2024, 10:21 am   #34
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,704
Default Re: RS232 question

Thanks for the update - this thread, from beginning to end, could be quite a useful resource for anyone else working through the same problems.

You mentioned the Pi Pico - potentially very useful especially as it has a lot of onboard RAM (256K!) to use as a huge RS232 receive buffer, but like so many modern devices a 3V3 device, so you'd have the added complication of needing bidirectional 3V3 <-> 5V0 level converters on the data lines to the device to be programmed, and unidirectional 3V3 -> 5V0 level converters on the address and chip select, etc lines.

You can sometimes get away with driving 5V logic inputs with only 3V3 logic levels on the principle that 3V3 is high enough to look like a valid logic '1' to most 5V logic devices - I see this most often when generic 2-line alphanumeric LCD displays (which are 5V devices) are being driven by 3V3 devices in write-only mode and it works fine. A Raspberry Pi project that I made to (only) read EPROMs only level-converted the data lines from the EPROM, all the driven lines to the EPROM - Address, CS, etc, were left at 3V3 and I got away with it.
SiriusHardware is online now   Reply With Quote
Old 23rd Apr 2024, 10:58 am   #35
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 753
Default Re: RS232 question

Yes I am looking at the Pi Pico, have got as far as setting up the build chain on Mac and got the blinking lights example working. I like the fact that you can just plug it into a serial port and it appears as a USB device on your PC, so programming is just a case of dragging your compiled application into a folder. And at £3.80 they don't exactly break the bank, and as you say, have plenty of ram to read in the whole hex file in one go.

At the moment though I'm still using the PIC, but that will probably change when I'm a bit more up to speed on the Pi. The RS232 lessons will still come in handy though!
Keith956 is offline   Reply With Quote
Old 8th May 2024, 2:52 pm   #36
Keith956
Heptode
 
Keith956's Avatar
 
Join Date: Jun 2019
Location: Oxfordshire
Posts: 753
Default Re: RS232 question

I got around to getting a PCB made, a simple through hole board, with a header for connecting a USB-FTDI cable to the PC and a header for the PIC ICSP (although the PIC can be programmed externally). There is an onboard 26v generator for the programming voltage using a MC34063.

All seems to be working well with a quickly put together gui app for loading/saving hex files and reading/writing the 8755 EPROM.
Attached Thumbnails
Click image for larger version

Name:	IMG_5642.jpg
Views:	39
Size:	62.0 KB
ID:	297294   Click image for larger version

Name:	Screenshot 2024-05-08 at 14.48.44.jpg
Views:	23
Size:	118.7 KB
ID:	297300  
Keith956 is offline   Reply With Quote
Reply

Thread Tools



All times are GMT +1. The time now is 12:28 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.