🚀 go-pugleaf

"Enquiring Mind" <Enquiring.Mind@nospam.btopenworld.com> wrote in message 
news:486a2e4c$1@newsgroups.borland.com...
> Hi,
>
> Can anyone help with a few elementary questions about serial port IO in 
> Windows?
>
> When a serial port file is created for concurrent reading and writing 
> using CreateFile with dwDesiredAccess:= GENERIC_READ or GENERIC_WRITE, can 
> one assume that the file may be used as if it supports two totally 
> independent, concurrent data streams, an input stream, and an output 
> stream, without any interaction between them? Thus does the serial port 
> driver, or the OS, effectively internally operate a critical section that 
> allows only one byte from either the outbound or the inbound streams 
> through the port at a time, and transfer inbound or outbound bytes to 
> associated data queues?

Serial ports are full-duplex. You can write and read simultaneously. 
Internally the hardware has two distinct channels for sending and receiving 
the bytes.

> If 2 computers A and B are connected via an RS-232 cable, do serial port 
> communication programs on each have to be started manually in order for 
> data communication to take place, or is it possible, using serial port API 
> functions, to get the client program on computer A to get the OS on 
> computer B to launch the server program on computer B?

No, you must start the programs on the both PCs manually before you can send 
or receive data.

> Is it possible to obtain a list of hardware I/O ports from the operating 
> system?

It must be but I dont know how.

> To allow an application that performs asynchronous I/O to a serial port in 
> two separate threads (one for reading, the other for writing) to be tested 
> on a single computer without the need to set up a serial connection to 
> another computer or device, is there any way that the file mapped to the 
> serial port can be set up so that the output stream feeds back into the 
> input stream?

Use a loopback adaptor which connects RX line to the TX line. You can easily 
do it yourself. Get a 9 pin DSUB connector and short circuit Pins 2-3 then 
plug it into the serial port.

However what you want to do is not possible using only ONE port. Serial 
ports can't be shared among different threads. You must test it using a PC 
with two serial ports. Connect one port to the other using a null-modem 
cable.

Enquiring Mind wrote:

> Is it possible to obtain a list of hardware I/O ports from the 
> operating system?

Not specifically hardware:


  for I := 1 to 9 do
    if ComPortExists(I) then
      cmbPort.Items.Add('COM' + IntToStr(I));



function ComPortExists(APort: integer): Boolean;
var
  udtComConfig: TCommConfig;
  lUDTSize: DWord;
  PName: PChar;
  S: string;
const
  COMportMask = 'COM%u';
begin
  S := SysUtils.Format(COMportMask, [APort]);
  lUDTSize := SizeOf(CommConfig);
  PName := PChar(S);
  Result := GetDefaultCommConfig(PName, udtComConfig, lUDTSize);
end;


-- 
- Mike

"Farshad" <farshad@ATfmsoftDOT.net> wrote in message 
news:486a4990@newsgroups.borland.com...

Many thanks for your help. Hardware issues are an unknown territory for me!
>
>
> Serial ports are full-duplex. You can write and read simultaneously. 
> Internally the hardware has two distinct channels for sending and 
> receiving the bytes.
>
Thanks for that. So I take it that the two data streams are transmitted 
bitwise along separate wires.

>
> No, you must start the programs on the both PCs manually before you can 
> send or receive data.
>

Is it OK to just call CreateFile to open the port, then start pumping data 
over the connection using ReadFile or WriteFile, or is it necessary to first 
make some low level serial port settings using the DCB record or otherwise?
 >
> Use a loopback adaptor which connects RX line to the TX line. You can 
> easily do it yourself. Get a 9 pin DSUB connector and short circuit Pins 
> 2-3 then plug it into the serial port.
>
Thanks for the useful tip. Sounds like the simplest approach to me, unless 
the development computer has two serial ports that can be connected with a 
null-modem cable. Mine hasn't!

> However what you want to do is not possible using only ONE port. Serial 
> ports can't be shared among different threads. You must test it using a PC 
> with two serial ports. Connect one port to the other using a null-modem 
> cable.
>
Presumably a single port can be shared between separate threads provided 
that calls to API functions that use the port file handle are enclosed in a 
Critical Section. Thus the function ReadFile, WriteFile, 
GetOverlappedResult, etc. could be called within a critical section along 
the following lines:

    FSerialPort.CriticalSection.Acquire;
      ReadDoneFlag:= Windows.ReadFile(FSerialPort.FileHandle, FData, 
SizeOf(FData),
                        FBytesTransferredCount, FOverlappedPtr);
    FSerialPort.CriticalSection.Release;

Are there any problems with this approach?

Regards,

EM

"Mike Warren" <miwa-not-this-bit@or-this-csas.net.au> wrote in message 
news:xn0fs70kyw9u6000@newsgroups.borland.com...

>
> function ComPortExists(APort: integer): Boolean;
> var
>  udtComConfig: TCommConfig;
>  lUDTSize: DWord;
>  PName: PChar;
>  S: string;
> const
>  COMportMask = 'COM%u';
> begin
>  S := SysUtils.Format(COMportMask, [APort]);
>  lUDTSize := SizeOf(CommConfig);
>  PName := PChar(S);
>  Result := GetDefaultCommConfig(PName, udtComConfig, lUDTSize);
> end;
>
Thanks very much for the useful guidance! Your approach should find all 
ports named 'COM' + IntToStr(COMPortNumber). How would one obtain a complete 
list of all I/O ports in the system, like modem ports, parallel ports, etc? 
For parallel ports I presume one could use the same approach, substituting 
'LPT' for 'COM', or perhaps use the EnumPorts API function. Unlike serial 
and parallel ports, modems don't seem to have a standard naming convention, 
so how could they be found?

Regards,

EM

"Enquiring Mind" <Enquiring.Mind@nospam.btopenworld.com> wrote in message 
news:486a2e4c$1@newsgroups.borland.com...

> Is it possible to obtain a list of hardware I/O ports from the operating 
> system?

Not glamorous, but for years, many programs have listed ports by trying to 
open a range of ports.  Trouble is, COM1 thru COM255 is going to take a lot 
of time.   Its OK for say COM1 thru COM16.

    // fill port list
    FCount := 0;
    for i := 0 to MAXPORT-1 do begin

        // generate port name
        PortName := 'COM' + IntToStr(i+1) + ':';

        // try to open port
        hSerial := CreateFile(
            pChar(PortName),
            GENERIC_READ or GENERIC_WRITE,
            0, (* comm devices must be opened w/exclusive-access *)
            NIL, (* no security attrs *)
            OPEN_EXISTING, (* comm devices must use OPEN_EXISTING *)
            FILE_ATTRIBUTE_NORMAL, (* Ansynchronous or Synchronous I/O *)
            0 (* hTemplate must be NULL for comm devices *)
        );

        if ( hSerial = INVALID_HANDLE_VALUE) then begin
            // port exists and is in use
            if GetLastError = E_PORTINUSE then begin
                Info[FCount].Busy := True;
                Info[FCount].Name := PortName;
                Inc( FCount );
            end
        end

        // port exists and is available
        else begin
            // port no longer needed
            CloseHandle( hSerial );
            Info[FCount].Busy := False;
            Info[FCount].Name := PortName;
            Inc( FCount );
        end;

    end;

Roger Lascelles

"Roger Lascelles" <relATaantDOTcomDOTau> wrote in message 
news:486b7f6a@newsgroups.borland.com...
>
> Not glamorous, but for years, many programs have listed ports by trying to 
> open a range of ports.  Trouble is, COM1 thru COM255 is going to take a 
> lot of time.   Its OK for say COM1 thru COM16.
>
Thanks for the interesting code. As a matter of interest, why use a "for" 
loop rather than a "while" or "repeat" loop to test for ports in succession? 
Surely once an attempt to open  port  'N' fails, there is no need to 
continue testing ports N+1..MAXPORT, so one can exit the loop. Or it 
possible that the Windows port numbering might contain gaps in the numbers?

Another question: why, to determine whether or not a port exists, attempt to 
open the port using CreateFile, rather than just call GetDefaultCommConfig 
as suggested by Mike Warren? I would imagine that CreateFile is considerably 
slower than GetDefaultCommConfig.

What I find strange about the Windows API in this respect is why it doesn't 
support access to port information by index as well as by name, or by means 
of the GetFirst, GetNext sequential approach that the API uses to enumerate 
files and processes. Presumably the OS must internally store the port 
objects in an array or list. By port object I mean a record containing full 
details of the port like the name, handle, status, etc. Now while serial 
ports and parallel ports have standardised names that would apply on any 
computer, ports like modems appear to have hardware-specific names that vary 
from computer to computer. For the latter, at least, access by index or by a 
GetFirst..GetNext enumeration approach would seem to be essential.

Regards,

EM

"Roger Lascelles" <relATaantDOTcomDOTau> wrote in message 
news:486b7f6a@newsgroups.borland.com...

>        if ( hSerial = INVALID_HANDLE_VALUE) then begin
>            // port exists and is in use
>            if GetLastError = E_PORTINUSE then begin
>                Info[FCount].Busy := True;
>                Info[FCount].Name := PortName;
>                Inc( FCount );
>            end
>        end
>
I tried your code, but couldn't compile the line "if GetLastError = 
E_PORTINUSE then begin
". Where is the E_PORTINUSE constant declared? I couldn't find it in my (D7 
version) of the SDK or Delphi help files.

Many thanks,

EM

"Enquiring Mind" <Enquiring.Mind@nospam.btopenworld.com> wrote in message 
news:486cea37$1@newsgroups.borland.com...

> I tried your code, but couldn't compile the line "if GetLastError = 
> E_PORTINUSE then begin
> ". Where is the E_PORTINUSE constant declared? I couldn't find it in my 
> (D7 version) of the SDK or Delphi help files.
>

const
    E_NOSUCHPORT = 2;
    E_PORTINUSE = 5;

Sorry, I invented those names - Windows has other names for these error 
constants.


Roger Lascelles 

"Enquiring Mind" <Enquiring.Mind@nospam.btopenworld.com> wrote in message 
news:486cd060$1@newsgroups.borland.com...


> I have no idea how USB port I/O is handled in Windows programming, so 
> would be interested to know!  Is it the end device connected directly or 
> indirectly to a USB port on the computer the entity that may treated as a 
> serial or parallel port? Can one open the USB-connected device using 
> CreateFile, and send and receive data using WriteFile and ReadFile?  From 
> your comments, you seem to be saying that when a serial device is 
> connected directly or indirectly to the computer via the USB port, Windows 
> dynamically allocates a new COM number to it, but this is not 
> automatically released when the device is disconnected.

Since many laptops do not have a serial connector, the small "USB to serial 
adapter" dongle is common.  When you plug in the adapter or "converter", a 
new  COM port appears in your system, just like any other.  CreateFile etc 
all work on this port.  The adapter comes with a driver which does all the 
hard stuff for you.

Just be warned - many converters are rubbish - I only buy converters 
containing the FTDI brand chips, because the chips and supplied drivers work 
so well.  All converters always give you a serial port with slightly 
different timing, because USB involves packets, whereas the old RS232 
hardware is more immediate.  However, increasing your timeouts a little does 
fix the problem, and I generally don't care which kind of port I am using.

To make a USB device cheaply, you can buy the FTDI chips separately and put 
them inside your device.  The beauty of this is that FTDI will keep 
maintaining and re-certifying the Windows device drivers at no charge over 
the years so your device remains usable.  There are other manufacturers with 
similar chip + driver solutions.

With FTDI converters at least, the converter ID and the USB socket used are 
stored on your system (somewhere) and you always get the same COM number for 
that combination of device and USB socket even when your PC restarts.  So if 
you move the converter around the 6 sockets on your laptop, you will get 6 
different COM ports.  Now, if you have 2 converters and 6 sockets, you will 
get 12 different ports - and those 12 port numbers are reserved.  I don't 
know if the allocation is freed up when you uninstall the converter driver. 
In system settingson my PC, I can alter the COM number of my adapters.  So 
you can see need to locate a particular device by trying all ports, because 
this is too confusing for customers.


> As a matter of interest, what types of hardware product still use the 
> serial port, given its almost legacy status?

Engineering and scientific equipment has not completely abandoned the serial 
connector.  It is built in to many embedded microprocessors.  The 
development cost for a USB device is higher, especially if you need to write 
and have certified a driver. So for a small run of cost-sensitive devices, 
the serial port makes sense.  Plus there is a large amount of legacy 
equipment out there.  In my work developing electronic products, 
calibrators, production testers etc, the serial port is the right choice for 
in-house.  For our customers, USB is normal for new designs, but older 
designs with COM ports are still selling.


> I did a quick Google search and found that there is a "COM Port database" 
> described in the MSDN site under "Windows Driver Kit". The "database" 
> appears to be just an array of COM port records. There are enumeration 
> functions available. I presume that the WDK is another API library. Does 
> anyone know anything about it?

thanks, I'll have a look.

Roger Lascelles 

"Roger Lascelles" <relATaantDOTcomDOTau> wrote

> To make a USB device cheaply, you can buy the FTDI chips
 separately and put them inside your device.  The beauty of ...

Roger, Thanks for the info
http://www.ftdichip.com/FTProducts.htm
Rgds, JohnH

"Roger Lascelles" <relATaantDOTcomDOTau> wrote in message 
news:486d679c@newsgroups.borland.com...
>
> Since many laptops do not have a serial connector, the small "USB to 
> serial adapter" dongle is common.  When you plug in the adapter or 
> "converter", a new  COM port appears in your system, just like any other. 
> CreateFile etc all work on this port.  The adapter comes with a driver 
> which does all the hard stuff for you.
>
Thanks for the useful guidance. So I take it that a USB to RS-232 adapter 
must always incorporate a chip  to convert the data stream from one format 
to another?

Since a USB socket could have multiple devices connected to it, the OS must 
presumably maintain a dynamic list of devices currently connected to a USB 
socket. Will these be retrieved by the code you posted?

> With FTDI converters at least, the converter ID and the USB socket used 
> are stored on your system (somewhere) and you always get the same COM 
> number for that combination of device and USB socket even when your PC 
> restarts.  So if you move the converter around the 6 sockets on your 
> laptop, you will get 6 different COM ports.  Now, if you have 2 converters 
> and 6 sockets, you will get 12 different ports - and those 12 port numbers 
> are reserved.  I don't know if the allocation is freed up when you 
> uninstall the converter driver. In system settingson my PC, I can alter 
> the COM number of my adapters.  So you can see need to locate a particular 
> device by trying all ports, because this is too confusing for customers.
>
Useful to know - thanks!
>  So for a small run of cost-sensitive devices, the serial port makes 
> sense.
Would a RS-232 connection be normally used for a simple data acquisition 
system?

I have run your posted code on both my desktop and on my laptop computers. 
On the laptop it throws up more COM ports than show up in the Control 
Panel>System>Hardware>Device manager property sheet. I would like to 
identify what hardware the additional ports correspond to. The list in the 
property sheet provides more extensive descriptions of the COM ports. Is 
there any way that the description of a COM port can be retrieved using API 
functions?

EM 

"Enquiring Mind" <Enquiring.Mind@nospam.btopenworld.com> wrote in message 
news:486e4793@newsgroups.borland.com...

> Thanks for the useful guidance. So I take it that a USB to RS-232 adapter 
> must always incorporate a chip  to convert the data stream from one format 
> to another?

Correct.  USB and RS232 are so different as to preclude a common API.  The 
converter chip has a real USB interface and a real RS232 interface.  It gets 
USB packets, buffers them, then dribbles the data out the RS232 side.  It 
receives RS232 data, buffers it, then when the buffer is full, or after a 
timeout packs the data into a USB packet and sends it to the PC.  The USB 
packets contain data in a format defined by the chip manufacturer.

Some embedded microprocessor chips do contain a USB interface - at the PC 
end you must buy or write a certified driver, or you may be able to use 
standard HID driver which is part of Windows.  Since Vista demands certified 
drivers, it is the driver that can be the stumbling block for small project 
runs. Who is going to maintain that driver for years to come?

> Since a USB socket could have multiple devices connected to it, the OS 
> must presumably maintain a dynamic list of devices currently connected to 
> a USB socket. Will these be retrieved by the code you posted?

The COM port abstraction provided by Windows is excellent.  You simply open 
a COM port in the usual way.  If you device is unplugged, its port 
disappears.


>>  So for a small run of cost-sensitive devices, the serial port makes 
>> sense.
> Would a RS-232 connection be normally used for a simple data acquisition 
> system?

Commercial data loggers for PC use often have a USB connector these days, 
but RS232 stuff is offered too.  If you are building something for yourself 
or commercial in-house or for hobbyists, RS232 is delightfully simple.  The 
RS232 hardware is fairly robust and tolerates shorts and even voltages in 
the wrong place.    I put RS232 into all the handy gadgets I use around the 
factory and testbench.  RS232 is alive and well in engineering and hobby 
electronics.

A mistake while developing for USB can destroy the USB port on your 
motherboard, so care is needed. An RS232 converter dongle is cheap insurance 
for you motherboard - even if you do blow the converter, your motherboard is 
probably OK.  I do check a new device before connecting, and have never 
killed an RS232 port.

USB provides a convenient power supply along with the data, which can be 
nice.

You can make an opto-isolated USB device by building in the FTDI converter 
chip.  The chip is powered from the USB cable and two opto isolators 
transfer the TX and RX data to your microprocessor.  Your microprocessor etc 
is powered from a "brick" or small transformer.  Now there is no electical 
path between your device and PC - thus removing ground loops, PC hash, 
protecting the PC from external voltages.

I buy my RS232 converters from http://dontronics.com - excellent product and 
service.


> I have run your posted code on both my desktop and on my laptop computers. 
> On the laptop it throws up more COM ports than show up in the Control 
> Panel>System>Hardware>Device manager property sheet. I would like to 
> identify what hardware the additional ports correspond to. The list in the 
> property sheet provides more extensive descriptions of the COM ports. Is 
> there any way that the description of a COM port can be retrieved using 
> API functions?

Someone else may know.  I have been content just to list the ports.  Device 
Manager does have a "View Hidden Devices" option, at least in Vista - I 
don't have an XP machine handy right now.

Roger Lascelles 

"Roger Lascelles" <relATaantDOTcomDOTau> wrote in message 
news:486eca41@newsgroups.borland.com...


> Commercial data loggers for PC use often have a USB connector these days, 
> but RS232 stuff is offered too.  If you are building something for 
> yourself or commercial in-house or for hobbyists, RS232 is delightfully 
> simple.  The RS232 hardware is fairly robust and tolerates shorts and even 
> voltages in the wrong place.    I put RS232 into all the handy gadgets I 
> use around the factory and testbench.  RS232 is alive and well in 
> engineering and hobby electronics.
>
I'd like to try my hand at building a very simple (and low cost) system that 
logs and processes data captured from one or more sensors, for demonstration 
purposes. I presume the basic components are one or more sensor devices, an 
analogue-digital converter and/or a datalogger, and a computer with an 
RS-232 connection to the datalogger or ADC. I can handle the serial port I/O 
programming, but am not sure about the hardware side of things. Can you 
offer any suggestions about the hardware set-up?

> A mistake while developing for USB can destroy the USB port on your 
> motherboard, so care is needed. An RS232 converter dongle is cheap 
> insurance for you motherboard - even if you do blow the converter, your 
> motherboard is probably OK.  I do check a new device before connecting, 
> and have never killed an RS232 port.
>
> USB provides a convenient power supply along with the data, which can be 
> nice.
>
> You can make an opto-isolated USB device by building in the FTDI converter 
> chip.  The chip is powered from the USB cable and two opto isolators 
> transfer the TX and RX data to your microprocessor.  Your microprocessor 
> etc is powered from a "brick" or small transformer.  Now there is no 
> electical path between your device and PC - thus removing ground loops, PC 
> hash, protecting the PC from external voltages.
>
> I buy my RS232 converters from http://dontronics.com - excellent product 
> and service.
>
>
Very useful information - thanks!

"Enquiring Mind" <Enquiring.Mind@nospam.btopenworld.com> wrote
> I'd like to try my hand at building a very simple (and low cost) system that 
> logs and processes data captured from one or more sensors, ...

EM,  Here is a site and google that should bring lots of interesting 
USB data acquisition projects.
http://www.google.com/search?hl=en&q=http%3A%2F%2Fwww.circellar.com%2F+USB
Years ago, I used to subscribe to the "Circuit Cellar" magazine 
and may have to start again. Rgds, JohnH

"John Herbster" <herb-sci1_AT_sbcglobal.net> wrote in message 
news:48722080$1@newsgroups.borland.com...


EM,  Here is a site and google that should bring lots of interesting
USB data acquisition projects.
http://www.google.com/search?hl=en&q=http%3A%2F%2Fwww.circellar.com%2F+USB
Years ago, I used to subscribe to the "Circuit Cellar" magazine
and may have to start again. Rgds, JohnH

Many thanks for the useful reference!

Rgds,

EM

"Enquiring Mind" <Enquiring.Mind@nospam.btopenworld.com> wrote in message 
news:48721964@newsgroups.borland.com...
>
> I'd like to try my hand at building a very simple (and low cost) system 
> that logs and processes data captured from one or more sensors, for 
> demonstration purposes. I presume the basic components are one or more 
> sensor devices, an analogue-digital converter and/or a datalogger, and a 
> computer with an RS-232 connection to the datalogger or ADC. I can handle 
> the serial port I/O programming, but am not sure about the hardware side 
> of things. Can you offer any suggestions about the hardware set-up?

A data logger is a microprocessor plus Analog to Digital Converter (ADC) 
connecting to a number of sensors or voltages.  These days, the ADC is often 
built into the microprocessor chip, along with the RS232 circuit.  You add a 
simple RS232 line transceiver chip and a power supply and the sensors.

Googling for "build data logger" or "data logger schematic" etc will get you 
plenty of hits like this one:
http://www.anotherurl.com/therm/logger.htm

IUnless you have electronics experience, I recommend buying a ready-built 
low end data logger.  Otherwise you have to develop electronics skills - and 
even if you buy a kit with instructions, you may still need to diagnose a 
fault if it does not work.  The hardware can turn out to be a massive 
diversion or a disappointment unless you have a knowledgeable friend who 
will help you out.

There are inexpensive loggers sold to schools which might suit.

Many affordable multimeters have an RS232 connector these days.  You set the 
meter to Volts or Temperature etc and it regularly transmits a reading.  You 
don't usually control the meter from the PC, but at least you get a single 
channel reading.  The meters use a simple data format - I have seen examples 
on the Web for various meters.

Roger Lascelles