Serial unit missing

[kaimex]

Hi,
I just tried to compile the example program "TestSerialPortCom" taken from the page
https://wiki.lazarus.freepascal.org/Hardware_Access#FPC_built_in_Serial_unit
The accompanying text says
"Another serial unit is part of FreePascal since version 2.2.2: just put 'Serial' in the Uses list. However there does not seem to be any documentation other than the Serial.pp source file and some discussions.
An example using FPC 2.6.2 on WIN7. "
I am (still) using FPC V 2.6.0 under Windows 7 Home Premium 64 Bit.
The Compiler responds with "Can't find unit serial used by TestSerialPortCom".
The search function of Explorer++ does not find serial.pp on the disk.
Why is it not included contrary to the above statement "since version 2.2.2" ?
Is it only included when installed on 32 Bit versions of Windows ?
How can I get the serial unit ?

Regards Kai

[lucamar]

In 2.6.0 it seems to be a Unix-only unit:

Code: Bash  [Select][+][-]

1. lucamar@Diana:~/temp/fpcbuild-2.6.0$ find ./ -iname "serial.*"
2. ./fpcsrc/packages/amunits/src/coreunits/serial.pas
3. ./fpcsrc/packages/libndsfpc/src/nds/arm7/serial.inc
4. ./fpcsrc/rtl/unix/serial.pp
5. ./fpcdocs/olinuxex/serial.pp

Probably also in previous releases, though I don't have any at hand to check it.

Is there any reason why you can't update to a more modern version? 2.6.0 is almost ten years old by now. Lots of water have passed under the bridge

[PascalDragon]

Looks like the wiki article you linked is not entirely correct. While the Serial unit for *nix systems exists since essentially forever (at least since conversion to SVN, thus before 2.2.2), the Serial unit for Windows was added only rather recently (namely 3.0.0, so not 2.6.2 either). You could try to take the unit from trunk (click Download at the top). I think it should work with 2.6.0 as well as there weren't any fancy changes.

[MarkMLl]

It went in at about 2.7.1, I think it sat in Mantis for quite a while after I submitted it. I forget the precise sequence of what went on 10+ years ago, but it's reasonable to expect that since it was in the development 2.7.1 it was backported into the (fixes release) 2.6.2, particularly if I was hassling people about it on the mailing list :-)

https://bugs.freepascal.org/view.php?id=18946

There have been no recent changes, but I don't think it's been tested against recent Windows. If OP does look at it, he should note the comments in the definition part about the change of flush/drain/sync behaviour, which is why I initially got involved.

I've considered some minor changes since then, but at present am not well set up for testing on Solaris which should also be good for the BSDs.

MarkMLl

[PascalDragon]

It went in at about 2.7.1, I think it sat in Mantis for quite a while after I submitted it. I forget the precise sequence of what went on 10+ years ago, but it's reasonable to expect that since it was in the development 2.7.1 it was backported into the (fixes release) 2.6.2, particularly if I was hassling people about it on the mailing list :-)

It wasn't backported. The fixes tree for the 2.6.x series does not contain it.

[MarkMLl]

Sorry, you're right: I was grepping over my source directories in haste.

MarkMLl

[kaimex]

Hi guys,
thank you for your immediate help,
especially to PascalDragon for the hint to the trunk download of serial.pp .
I have taken the latest version. It compiles with V 2.6.0, but so far does not "wait for answer", as it announces.
But so far I have not configured anything. Hopefully that can be fixed...
I installed V 2.6.0 actually on Oct. 18, 2012. Back then (and with still older versions before) I have been using undocumented FPC-code to capture exceptions or rather avoid crashes of my programs. The positions of the code I utilized changed from version to version, so I got lazy with updating...
May be, I don't need that anymore and could update to the most recent version.
Thanks again
Kai
P.S.: What I would very much wellcome, would be a unit to access an "old-time" 8-Bit-Parallel Port (Data, Control & Status) for interfacing to DIY-equipment under Win32 and Win64.

[avra]

P.S.: What I would very much wellcome, would be a unit to access an "old-time" 8-Bit-Parallel Port (Data, Control & Status) for interfacing to DIY-equipment under Win32 and Win64.

You should redirect your Delphi component search at Torry's first. Here is everything for direct port access: https://torry.net/pages.php?id=227.

[jamie]

get a LabJack

[VTwin]

Does Ararat Synapse meet your needs:

https://sourceforge.net/projects/synalist/

I use basic serial port functions in laz_synapse.pkg.

There is also:

https://forum.lazarus.freepascal.org/index.php/topic,20481.0.html

[kaimex]

@avra: Thank you for making me aware of Torry's page on direct port access. However, I don't see any solution that is supposed to work under 64-Bit Windows. I have tried several tools in the past. Some work under 32-Bit windows. Some have annoying side effects (e.g. after userport.exe has started its port-access driver, all old 16-Bit programs running under ntvdm won't work). I could not find a solution that works under Windows 7 Home Premium 64 Bit. Even tools that others have reported to do it, did not in my environment.
@jamie: I don't want to spend money on LabJack, I want to be able to use my own old equipment, that was formerly hooked to and controlled via the Printer-Port.
64-Bit Windows appears to me like Ransom-Ware: My PC has a dedicated PCI-Parallel-Port card inserted that the system won't use, but Microsoft does not allow me to use it without extra cost for special certified drivers.
@VTwin: Thanks for pointing to Synapse. I have had a very brief look at it. Presently FPC's "built-in" serial unit does what I wanted.
Thanks
Kai

[avra]

I don't see any solution that is supposed to work under 64-Bit Windows.

All these can be found from that page and all work under 64bit:
https://www.entechtaiwan.com/dev/port/index.shtm
https://www.entechtaiwan.com/dev/hw32/index.shtm
http://www.zealsoftstudio.com/ntport/
https://www.winsoft.sk/ioport.htm

You could also take a look at these:
https://github.com/changguangyu/DelphiMSR
http://pascal.hansotten.com/delphi/driverlynx-dlportio-and-windows-7-and-8-and-64-bit/
https://www.highrez.co.uk/Downloads/InpOut32/
https://wiki.freepascal.org/Hardware_Access#Parallel_Communication

after userport.exe has started its port-access driver, all old 16-Bit programs running under ntvdm won't work

So you expect that ntvdm and direct port driver both work while trying to race for direct access to the same physical port? Highly unlikely without them cooperating and using single gateway for port access, which doesn't seam to happen. Did you try to run your old 16-bit programs under dosbox or virtualbox instead?

I could not find a solution that works under Windows 7 Home Premium 64 Bit. Even tools that others have reported to do it, did not in my environment.

Then move to Windows 32 bit or Linux if that is so important. Alternatively, you could use some Arduino (or similar) for direct access and talk to it from your x64 pc os via serial/usb, bluetooth or ethernet. Some FTDI chips have fast GPIO which can be also used. Take a look at bit banging example here: https://ftdichip.com/software-examples/code-examples/delphi-examples/

[MarkMLl]

I have taken the latest version. It compiles with V 2.6.0, but so far does not "wait for answer", as it announces.

What doesn't wait for answer? Is this the wiki example or something in serial.pp?

MarkMLl

[kaimex]

Hi avra,
thank you for your additional advice.
As far as I can remember, I already tried
directio/giveio.sys/totalio.sys, gwiopm.sys, inout32.dll and inpoutx64.dll, userport.exe/userport.sys, WinIo v3.0, port.dll .
At least WinIo and inpoutx64.dll are reported to work under 64 Bit Windows, but they don't work on my Windows 7 Home Premium 64 Bit PC.

I'll check the other tools that you listed, whether one of those does the job.

I did not try to access I/O-ports concurrently via userport and programs running under ntvdm. I just observed that all old 16 Bit Programs (e.g. those compiled with Turbo Pascal 6 & 7 under Windows XP and TP6 & TP7 themselves are blocked when userport.sys has been started. They do not respond to keyboard or mouse with the exception of the close-window-button, just "hang" in the entry display.

I am using Windows 32-Bit (XP on 3 PCs and Win 7 on a netbook), Linux Mint 20 on a laptop and Windows 7 64 Bit on a quadcore desktop PC. I have no (serious) problems to access the Parallel port with userport.sys under Windows XP with programs written with FPC. I just want to access the parallel just as well on my "work-horse", the quadcore 64-Bit PC.
The initial question for the serial unit arose from my arrempt to communicate with a µP-board via V24, possibly as a work-around for the denied access to the parallel port.
I am using one of those ubiquitous PCI Parallel-Port boards from Sunix. They supply certified drivers for use as Printer Port (LPTxx). But these drivers do not allow transparent control or read-out of the data/control/status-port bit values. It is in principle all there, but you don't get it.
Printing is done on this PC via USB. The sytem does not use the parallel port if I do not define it as a another printer port. So there is no danger of collision with other processes on the PC. It is no security leak as I am the only user. So no reason at all to deny access. Sunix might as well supply a certified driver to access the ports in a way as was possible during DOS-times.
Regards
Kai

Addendum to MarkMLI:
The example program ends with "Waiting for an answer" (waits for a CR from the other end of the V24 connection). It did not wait after my first attempt to run that program because nothing was configured nor connected. In the meantime I have connected a µP-board, "harmonized" the V24-parameters on both sides and now it works fine. Thank you.

[MarkMLl]

OP: sorry, I'm stressed by a growing to-do list right now so this will be curt.

For various reasons I have spent a long time hamstrung by older operating systems, and in some cases by old code which demanded direct hardware access. So "I feel your pain" but here's how things are:

Unless you have a very old version of Windows there is no real reason why you should not be able to upgrade to a newer version of FPC. If you're running something pre-2000 you might have problems on account of limited support for non-Western character sets, but that's the main cutoff.

Almost all recent operating systems, i.e. anything with multitasking and memory management, limit access to hardware. A substantial reason for that is security: the more loopholes in the system, the greater the risk that somebody will do something unexpected to your detriment: and they might only need a webpage or an MS Word document to do so. So you really do have to start looking for alternatives to direct hardware access.

MarkMLl