SPort routines witth Windows 11

[Keith_Stewart]

Does anyone have any  suggestions/experience re using SPort routines in Windows 11?

I have SPort routines within software written under Windows 7 that work fine on W7 m/cs.  I am now using the same routines with W11 and cannot see/determine returned data from SPort_Read_Line(Port,RetBuff) nor SPort_Read_Data(Port,RetBuff) - both stall.

Using SPort_Write_Line(Port,'1',1) and SPort_Write_Data(Port,'1',1) both return 0 (successful) as do SPort_Peek_Line(Port,iPresent,iCount) and SPort_Peek_Data(Port,iPresent,iCount) where the return is 0 (successful) but iPresent = 0 (no data).

I have written a small FreeBASIC program (on the same W11 m/c) that captures serial port data (same Port, same m/c, W11) and can successfully read the FB captured data from a call to the FB exe from within an IVF program, however, it is a two-step process - I would prefer the one-step process I had in W7.

Any ideas re W11 please?

I am using IVF XE - v19.1.1.216 on a HP 64-bit Workstation and compiling to a 32-bit exe.

[Barbara_P_Intel]

I think it can be inferred from this article that IVF XE - v19.1.1.216 is not supported on Windows 11.

Can you update to the latest compiler that is available in the oneAPI HPC Toolkit? It's free, no license required either. You can pay for Priority Support or use this Forum to ask questions.

Here's a link to more information.

[Steve_Lionel]

I'm dubious that the compiler version is relevant. The SPORT (serial port) library has likely not been looked at in a decade or more, and I note that it is not included in the oneAPI compiler install. Was it even in version 19?

[Keith_Stewart]

Thank you for your replies.  I find Steve's reply very useful (as always) re SPort not being available in oneAPI... I have a vague recollection of hearing that when oneAPI was first released, which is possibly why I am still with IVF XE 19.

Yes, SPort does still work in v19 - I wrote my routines using SPort 9 years ago using IVF 14, and am still using them in IVF 19, and they still work on m/cs running Windows 7.  The routines are to read from laboratory balances (weighing) that have RS-232 connections.

The issue I have now is that my W7 m/c died and I am now trying to read vernier callipers using these routines on a W11 m/c.  My users are now looking at replacement m/cs and they now come with W10/W11, so they are going to lose the straight-forward RS-232 read ability unless I can find a way to directly read RS-232 from my IVF 19 programs on W11 m/cs... if not I may need to go with the two-step IVF->FB->RS-232 path I have created that works, albeit somewhat clumsily.

Any ideas would be very welcome.

Steve - have you used IVF19 (or oneAPI) to read USB ports (as a possible alternative)?

[Barbara_P_Intel]

I checked with our intrepid Fortran compiler team and the SPort routines are available in libifport.lib for the current compiler release. And, yes, @Steve_Lionel, the routines have not been touched in a bit.

I learned enough about Windows .lib files to confirm the presence of these in the current release:

00D 00000000 SECT5 notype ()  External   | SPORT_CONNECT
026 00000000 SECTA notype ()  External   | SPORT_CONNECT_EX
02B 00000000 SECTB notype ()  External   | SPORT_RELEASE
035 00000000 SECTD notype ()  External   | SPORT_GET_HANDLE
03A 00000000 SECTE notype ()  External   | SPORT_GET_STATE
03F 00000000 SECTF notype ()  External   | SPORT_GET_STATE_EX
044 00000000 SECT10 notype ()  External   | SPORT_SET_STATE
049 00000000 SECT11 notype ()  External   | SPORT_SET_STATE_EX
04E 00000000 SECT12 notype ()  External   | SPORT_SHOW_STATE
058 00000000 SECT14 notype ()  External   | SPORT_GET_TIMEOUTS
05D 00000000 SECT15 notype ()  External   | SPORT_SET_TIMEOUTS
062 00000000 SECT16 notype ()  External   | SPORT_SPECIAL_FUNC
06A 00000000 SECT18 notype ()  External   | SPORT_WRITE_DATA
06F 00000000 SECT19 notype ()  External   | SPORT_WRITE_LINE
074 00000000 SECT1A notype ()  External   | SPORT_READ_DATA
07E 00000000 SECT1C notype ()  External   | SPORT_READ_LINE
083 00000000 SECT1D notype ()  External   | SPORT_PEEK_DATA
088 00000000 SECT1E notype ()  External   | SPORT_PEEK_LINE
08D 00000000 SECT1F notype ()  External   | SPORT_PURGE
092 00000000 SECT20 notype ()  External   | SPORT_CANCEL_IO

[Keith_Stewart]

Thank you Barbara.  I use about half of these calls in my various routines... do you know if they have been tested in oneAPI, or just included?

I think I will try oneAPI on my W11 laptop to start with, and see how I go.

[andrew_4619]

I would doubt that any 'real' testing would be made on that, lets face it how long since any PC have a serial port? You need to add specific hardware to test it. I used this interface years ago but have no recent experience. You could make some utilities routines using windows functions in kernel32,  using CreateFile to open the com port and GetCommState/SetCommState the get and set the port parameters. You can then read/write to the 'file'.

[Keith_Stewart]

Thank you for your input and suggestions Andrew - I will have a closer look at your suggestions, which are bit like what I have used in FreeBASIC (that works), but is not Windows GUI (which I have yet to try).

Yes, most PCs sold these days do not include a serial port on the back-plane, however, most newer HP m/cs (excluding laptops, so far) do include internal serial port capability along with a punch-out on the back-plane for one or two DB-9 ports.  Two recently-purchased HP PCs I have include such facilities, and can be ordered with DB-9 ports installed, or can be added later.  Manufacturers seem to have realised the benefits in areas where RS-232 is better than USB (laboratory and process automation being two).

What's old is new again, maybe.

[Steve_Lionel]

My recollection is that testing of these routines was not part of Intel's test system, understandable as they required specialized hardware to test. The SPORT library was created by DEC developer Terry Grieb, some 20+ years ago, and saw very little use. My advice would be to use the Windows API library for this purpose.

[Keith_Stewart]

Thanks Steve, yes, the use of RS-232 is somewhat specialised, which is where my need is (laboratory automation).  I have successfully used the SPort calls for line/data capture from lab equipment (balances, callipers, oscilloscopes) on W7 m/cs, but now in the age of W11 I may need to go back to API calls or use FreeBASIC to capture the data, or revert to W7 on new W10/11 m/cs. (it's a bit like why I suspect bank ATMs stayed with XP for so long - they worked (until the hackers realised it was only XP).)

I am probably inclined to at least try oneAPI for the SPort calls, and failing that go to API or FB.

Thank you for your input... appreciated.

[JohnNichols]

I hate to be the bearer of bad tidings, but some of the important ST.COM accelerometers mimic serial ports and you will need this lib if you want to use Fortran or port to C#.  I know I spend a nice 3 months getting one to work.  The problem is the timing on the devices is highly variable. 

In case you are wondering, there will be at least 3 or 4 ST.COM accelerometers within 10 feet of your body, unless you are completely anti-electronic, say if you are < 1 or > 100

[Keith_Stewart]

Thank you John, something I have not heard of nor know of to now consider.

Oh for the simpler times!

[JohnNichols]

The great advances in the world are being made by children and their "support IT person" using the RPi.

using serial ports is like shooting yourself in the head, day after day after day and in the night someone puts your brain back together, but you remember the pain. 

Fortran should be on the RPi

I still believe that MS got rid of Fortran because they could not control the development and they wanted to == hence C# which is Fortran built by some people with a few weird ideas. 

PS  A C# program from today may not run on next week's update, at least Fortran is not in that boat.