- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi, I received the following complaint regarding the CVF SPORT routines. Since I haven't used them recently, should they be functional in CVF 6.6 and are they in current versions of IVF?
----------------------------
Gary,
{Happy Christmas!]
I have tried using these SPORT routines with both XP and NT computers, and for me almost all do not work either at all or completely. Some work partially.
> List of Serial Port Routines
> The SPORT routines are:
> SPORT_CANCEL_IO
> SPORT_CONNECT
> SPORT_GET_HANDLE
> SPORT_GET_TIMEOUTS
> SPORT_GET_STATE
> SPORT_PEEK_DATA
> SPORT_PEEK_LINE
> SPORT_PURGE
> SPORT_READ_DATA
> SPORT_READ_LINE
> SPORT_RELEASE
> SPORT_SET_STATE
> SPORT_SET_TIMEOUTS
> SPORT_SHOW_STATE
> SPORT_SPECIAL_FUNC
> SPORT_WRITE_DATA
> SPORT_WRITE_LINE
There follows my message to Compaq. It was not replied to.
These are the problems so far. I got no output from the port either.
If can help me in this are I would appreciate it!
Problem area:
"SPORT" serial port routines have serious errors with less-common parameters and situations. See Compaq manual Page E22-23. Probably ceased working with NT/XP.
Some cause serious program errors if used.
Please read this paragraph carefully: we have done this before.
If we are given the SPORT source code which are written in F90, to correct them, and redefine whatever Microsoft API routines they are calling INCORRECTLY, we could recompile SPORT.lib equivalent as part of a working CVF library set and send you the corrected versions source for your own re-testing to further user migration. WE DID THIS BEFORE for Compaq, to correct the SCREENIO routines and Keyboard handler, sent to Steve Lionel now helping Intel with the migration.
After extensive testing we find the SPORT serial access routines to be flawed - actually unworkable except in very simple and rudimentary cases. We can provide all test proof.
MOST IMPORTANT:-
1) SPORT_GET_TIMEOUTS does not return any correct RX timeout value, nor report the RX multiplier value. And timeout NEVER occurs - the two read calls never return; the PEEK return does.
Both should timeout at some stage whether milliseconds, second minutes or hours, but DO NOT.
2) SPORT_SET_TIMEOUTS does not allow setting of RX or RX multiplier values; (Rx is there, but does nothing). There are four parameters and this function offers only three of them and only actually does something with TX constant and TX multiplier values. But it is the RX parameter that is vital to any application timeout operations. The program CONTROLS its WRITES but has NO PRIOR KNOWLEDGE OF ANY READ OPPORTUNITY (data coming in).
Details:-
SPORT_GET_STATE returns ONLY zero for the PARITY parameter, and does not return the correct values as shown by SPORT_SHOW_STATE. (SPORT_SET_STATE seems to work partially but should allow TO=OFF and TO=ON options as well as CTS and DSR signalling, or Xon/Xoff signalling handled by the command-line MODE operator which still works externally and partially internally to a program). Windows NT and XP do not allow use of MODE internally to change some parameters other than speed and frame description and only allow full MODE externally as a DOS emulator command.
SPORT_SET_STATE does not offer setting the parity enable and SHOW returns a "parity-unabled" state whic h may be incorrect.
SPORT_SHOW_STATE does not return the Rx constant of Rx multiplier as actually is present.
SPORT_READ_DATA and SPORT_READ_LINE do not terminate as defined by Microsoft when no character is received; nor if a data read or a line read is not terminated within the timeout period (OR AT ALL). Microsoft specifies the return code will ALWAYS be zero but the returned count different from the requested, or zero, if a timeout occurs. This does not occur at all with the two read functions WHICH DO NOT TERMINATE AT ALL is no data is present.
Steve Lionel (working for Intel now), worked with or knew about these routines with Compaq in your support function with Compaq and HP. Can we get a copy to correct the use of the API calls, as we did with SCREENIO and keyboard/mouse calls (upper row wrong/inverted with control key set, or with control-shift or alt anything combinations)?
We can't migrate to IVF if what we have doesn't work right now (only on XP situations).
All our commercial software has worked since early versions in 1972; the XP has brought a problem in now not being able to control the serial port - which is ALWAYS a dedicated port at any one time and never shared.
Terence Wright
tbwright@cantv.net
CEO, TAU Systems
Director, Sistemas TAU A.C.
At 01:46 AM 18/11/2005, you wrote:
>
>
> -----Original Message-----
> From: fortran-owner@lahey.com [ mailto:fortran-owner@lahey.com] On Behalf
> Of Laurie Aldridge
> Sent: Thursday, November 17, 2005 4:30 AM
> To: fortran@lahey.com
> Subject: RE: [LF] XP serial port control
>
> Dear Terence and the others
>
> My five bobs worth
>
> I am interested in monitoring real time experiments and am slowly
> building up equipment and software to carry out the job. Like Terrance I
> do not think that XP is fit for this purpose and am experimenting using
> LINUX as the operating system. However I will have to run legacy Fortran
> code to interpret the data. - Some of the experiment is carried on for
> days. I may also have to use a windows machine and with my luck it will
> have XP on it.
>
> In the old days I used GWbasic to do all of the input output from ports
> and we seemed to have a much better control program than we have now. Is
> it possible that we should be using a simpler language (perhaps python
> or java) to handle the tricky stuff (Sorry I was being sarcastic for
> GWBASIC could control ports well and was not nearly as complicated as
> Python.) This pseudo simple solution may not work (I have only collected
> the serial programs for python and have not tested them yet). However if
> it does work we could run the fortran exe's from python and use files to
> communicate between the serial ports and the legacy code.
>
> It seems to me that we are being urged by Microsoft to use .net
> applications for things like serial communications. While .net does have
> the virtue of making the old IMB OS system user-friendly it appears to
> me as a black hole made simply to swallow time. Am I being unfair in
> believing this .net is a super kludge?
>
> Am I the only idiot still using RS232 or are there others out there who
> have done this. I acknowledge that every time I had to marry equipment
> to PC in the past I usually cobbled a system together using hyperterm on
> WIN 98 or modified a C program using Borlands or ginal C compiler or the
> GWBASIC mentioned before. I would be interested in comments on this
> comment - Thanks
>
>
> Laurie Aldridge
> 24 Balmer Cres
> Woonona 2517 NSW
> Australia
>
----------------------------
Gary,
{Happy Christmas!]
I have tried using these SPORT routines with both XP and NT computers, and for me almost all do not work either at all or completely. Some work partially.
> List of Serial Port Routines
> The SPORT routines are:
> SPORT_CANCEL_IO
> SPORT_CONNECT
> SPORT_GET_HANDLE
> SPORT_GET_TIMEOUTS
> SPORT_GET_STATE
> SPORT_PEEK_DATA
> SPORT_PEEK_LINE
> SPORT_PURGE
> SPORT_READ_DATA
> SPORT_READ_LINE
> SPORT_RELEASE
> SPORT_SET_STATE
> SPORT_SET_TIMEOUTS
> SPORT_SHOW_STATE
> SPORT_SPECIAL_FUNC
> SPORT_WRITE_DATA
> SPORT_WRITE_LINE
There follows my message to Compaq. It was not replied to.
These are the problems so far. I got no output from the port either.
If can help me in this are I would appreciate it!
Problem area:
"SPORT" serial port routines have serious errors with less-common parameters and situations. See Compaq manual Page E22-23. Probably ceased working with NT/XP.
Some cause serious program errors if used.
Please read this paragraph carefully: we have done this before.
If we are given the SPORT source code which are written in F90, to correct them, and redefine whatever Microsoft API routines they are calling INCORRECTLY, we could recompile SPORT.lib equivalent as part of a working CVF library set and send you the corrected versions source for your own re-testing to further user migration. WE DID THIS BEFORE for Compaq, to correct the SCREENIO routines and Keyboard handler, sent to Steve Lionel now helping Intel with the migration.
After extensive testing we find the SPORT serial access routines to be flawed - actually unworkable except in very simple and rudimentary cases. We can provide all test proof.
MOST IMPORTANT:-
1) SPORT_GET_TIMEOUTS does not return any correct RX timeout value, nor report the RX multiplier value. And timeout NEVER occurs - the two read calls never return; the PEEK return does.
Both should timeout at some stage whether milliseconds, second minutes or hours, but DO NOT.
2) SPORT_SET_TIMEOUTS does not allow setting of RX or RX multiplier values; (Rx is there, but does nothing). There are four parameters and this function offers only three of them and only actually does something with TX constant and TX multiplier values. But it is the RX parameter that is vital to any application timeout operations. The program CONTROLS its WRITES but has NO PRIOR KNOWLEDGE OF ANY READ OPPORTUNITY (data coming in).
Details:-
SPORT_GET_STATE returns ONLY zero for the PARITY parameter, and does not return the correct values as shown by SPORT_SHOW_STATE. (SPORT_SET_STATE seems to work partially but should allow TO=OFF and TO=ON options as well as CTS and DSR signalling, or Xon/Xoff signalling handled by the command-line MODE operator which still works externally and partially internally to a program). Windows NT and XP do not allow use of MODE internally to change some parameters other than speed and frame description and only allow full MODE externally as a DOS emulator command.
SPORT_SET_STATE does not offer setting the parity enable and SHOW returns a "parity-unabled" state whic h may be incorrect.
SPORT_SHOW_STATE does not return the Rx constant of Rx multiplier as actually is present.
SPORT_READ_DATA and SPORT_READ_LINE do not terminate as defined by Microsoft when no character is received; nor if a data read or a line read is not terminated within the timeout period (OR AT ALL). Microsoft specifies the return code will ALWAYS be zero but the returned count different from the requested, or zero, if a timeout occurs. This does not occur at all with the two read functions WHICH DO NOT TERMINATE AT ALL is no data is present.
Steve Lionel (working for Intel now), worked with or knew about these routines with Compaq in your support function with Compaq and HP. Can we get a copy to correct the use of the API calls, as we did with SCREENIO and keyboard/mouse calls (upper row wrong/inverted with control key set, or with control-shift or alt anything combinations)?
We can't migrate to IVF if what we have doesn't work right now (only on XP situations).
All our commercial software has worked since early versions in 1972; the XP has brought a problem in now not being able to control the serial port - which is ALWAYS a dedicated port at any one time and never shared.
Terence Wright
tbwright@cantv.net
CEO, TAU Systems
Director, Sistemas TAU A.C.
At 01:46 AM 18/11/2005, you wrote:
>
>
> -----Original Message-----
> From: fortran-owner@lahey.com [ mailto:fortran-owner@lahey.com] On Behalf
> Of Laurie Aldridge
> Sent: Thursday, November 17, 2005 4:30 AM
> To: fortran@lahey.com
> Subject: RE: [LF] XP serial port control
>
> Dear Terence and the others
>
> My five bobs worth
>
> I am interested in monitoring real time experiments and am slowly
> building up equipment and software to carry out the job. Like Terrance I
> do not think that XP is fit for this purpose and am experimenting using
> LINUX as the operating system. However I will have to run legacy Fortran
> code to interpret the data. - Some of the experiment is carried on for
> days. I may also have to use a windows machine and with my luck it will
> have XP on it.
>
> In the old days I used GWbasic to do all of the input output from ports
> and we seemed to have a much better control program than we have now. Is
> it possible that we should be using a simpler language (perhaps python
> or java) to handle the tricky stuff (Sorry I was being sarcastic for
> GWBASIC could control ports well and was not nearly as complicated as
> Python.) This pseudo simple solution may not work (I have only collected
> the serial programs for python and have not tested them yet). However if
> it does work we could run the fortran exe's from python and use files to
> communicate between the serial ports and the legacy code.
>
> It seems to me that we are being urged by Microsoft to use .net
> applications for things like serial communications. While .net does have
> the virtue of making the old IMB OS system user-friendly it appears to
> me as a black hole made simply to swallow time. Am I being unfair in
> believing this .net is a super kludge?
>
> Am I the only idiot still using RS232 or are there others out there who
> have done this. I acknowledge that every time I had to marry equipment
> to PC in the past I usually cobbled a system together using hyperterm on
> WIN 98 or modified a C program using Borlands or ginal C compiler or the
> GWBASIC mentioned before. I would be interested in comments on this
> comment - Thanks
>
>
> Laurie Aldridge
> 24 Balmer Cres
> Woonona 2517 NSW
> Australia
>
Link Copied
17 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The SPORT routines have been tested on NT and XP. They are documented and supported by Intel Visual Fortran. The SPORT routines are NOT written in Fortran - they are in C - and the source code is not available. However, they are mainly wrappers around Win32 API calls and it's easy to just call the Win32 API directly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The SPORT routines are nonfunctional on CVF or any other platform. They are written in C, as a collection of Win32 API calls. I have inspected the C source code, and found the problem is that they got the threading model completely wrong.
I have posted to this forum (several times) a set of sample routines showing how to use the Win32 API calls directly from Fortran to do serial i/o. I will be glad to providemy samplecode to those with interest.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hmmm, well I guess I'll have to regard these two responses as discordant...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks to Gary Scott for getting my old message through!.
Our only communication with Intel is here - we can't even register for support, though we COULD register the software licenses!
I hope Paul Curtis can let us look at HIS Routines!
We wrote a set of simple Fortran console programs to exercise the SPORT routines. We SET parameters for (say) port 1, then asked for the settings to be displayed. They were different! Some parameters could not be changed, some were not reported, so there are BASIC errors there.
Especially PARITY was always returned a zero so either is wasn't being SET or wrongly reported (SHOW). If Parity ODD was NOT set then all our communication with an ODD-parity serial device obviously would NOT work in either direction.
But other tests explored TIMEOUT - which NEVER occured, no matter what values for this we set (?) PEEK DID return, but never could we see data enter, and an oscilloscope never showed data leaving the ports. The erros we noted are above.
One point not documented is that Windows allows setting the serial ports for a specific usage and protocol (eg cpu-cpu, null modem, etc). Nowhere do we find what limitation Microsoft sets on this, or the ability to override settings.
We also tried using the MODE command. This would work in a command line and change anything to anything, including protocol and switching timeout on or off, NOT covered by the SPORT routines, but if called within a Fortran program, it would not change the externally-set values but would report them - in line with Microsoft prohibiting NT and XP programs to change resource parameters. This is OK for a parallel printer port (or other use) but pretty stupid for a serial port, which is never shared unless running with the same parameters, and never simultaneously.
I haven't seen any positibve reply from Steve about this (with whom we had an excellent relationship in the CFV/DFV days, solving many compiler startup problems 2001/2002.
Terence Wright
tbwright@cantv.net
TAU Systems
Our only communication with Intel is here - we can't even register for support, though we COULD register the software licenses!
I hope Paul Curtis can let us look at HIS Routines!
We wrote a set of simple Fortran console programs to exercise the SPORT routines. We SET parameters for (say) port 1, then asked for the settings to be displayed. They were different! Some parameters could not be changed, some were not reported, so there are BASIC errors there.
Especially PARITY was always returned a zero so either is wasn't being SET or wrongly reported (SHOW). If Parity ODD was NOT set then all our communication with an ODD-parity serial device obviously would NOT work in either direction.
But other tests explored TIMEOUT - which NEVER occured, no matter what values for this we set (?) PEEK DID return, but never could we see data enter, and an oscilloscope never showed data leaving the ports. The erros we noted are above.
One point not documented is that Windows allows setting the serial ports for a specific usage and protocol (eg cpu-cpu, null modem, etc). Nowhere do we find what limitation Microsoft sets on this, or the ability to override settings.
We also tried using the MODE command. This would work in a command line and change anything to anything, including protocol and switching timeout on or off, NOT covered by the SPORT routines, but if called within a Fortran program, it would not change the externally-set values but would report them - in line with Microsoft prohibiting NT and XP programs to change resource parameters. This is OK for a parallel printer port (or other use) but pretty stupid for a serial port, which is never shared unless running with the same parameters, and never simultaneously.
I haven't seen any positibve reply from Steve about this (with whom we had an excellent relationship in the CFV/DFV days, solving many compiler startup problems 2001/2002.
Terence Wright
tbwright@cantv.net
TAU Systems
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Terence,
What do you want me to say? As far as I know, we have had zero bug reports on the SPORT routines in the past couple of years. Once we get you access to Intel Premier Support, we'll be glad to look into whatever problem you're having.
The SPORT routines are certainly not the only way to access serial ports, as mentioned above.
What do you want me to say? As far as I know, we have had zero bug reports on the SPORT routines in the past couple of years. Once we get you access to Intel Premier Support, we'll be glad to look into whatever problem you're having.
The SPORT routines are certainly not the only way to access serial ports, as mentioned above.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve, We have two valid licenses for Intel 9.0. THESE ARE REGISTERED. We have only been sent ONE license file back. But we am STILL trying to find how to register these products for Premium support.
I have supplied Intel staff (Charles Broward, Ravikanth Talakoti) with our license ID numbers, screen copies of trying to register and explained we cannot register for the Support correctly because every attempt returns an "UNAUTHORISED" message - also sent to Intel staff - and still not resolved in four days now.
Cannot this be done from there? I gave the ID numbers to both? There is something not working with the Web pages.
Charles changed my password from there (which was alreadt working), and I entered the Forum today with a different ID and still got in, so I seem to be two persons now.
About my SPORT routines problem (and it isn't just me); we will put together a complete demonstration F90 program to show what happens on executing each function; especially what we put in (SPORT_SET_STATE) and what we get back from SPORT_GET_STATE and SPORT_SHOW_STATE. Also continuing with code which reads a line or string from the "opened" port which will hang without return, when in fact it should time out and return to the program.
This is enough to show something is wrong.
A valid test to avoid fingure-pointing at external equipment is to loop back TX output to RX input; then a write line followed by a read line should bring back what is written immediately back into the program.
We cannot see any data leaving the ports.
Now,if it is true he functions "WORK", there are still some possibililities:-
a) They work only for even or no parity (we find parity always reported as NOPARITY).
b) They work only for default frames (8-1-OFF) and any baud rate.We use ODD parity and 7 bits (7-2-ODD) 9600-38400 baud.
c) They work only if MODE or CONTROL panel is used to PRESET the.ports to the desired state, because SPORT does not really do it correctly. What process do you recommend?
How is it we can change some parameters to any valid values but CANNOT change some other parameters (e.g. Parity, RX timeout multiplier, RX timeout constant)?
And how does the programmer define he wants:
a) timeouts ON or OFF?
b) RTS/CTS control
c) DSR/TSR control
d) XON/XOFF handshaking control?
These are just some of the strange (apparent) omissions.
We will settle for anything that works. We just want to open a port, send ACK, read text-cr-lf, reply NAK if parity or other error reported and repeat the read, or else ACK and gete more data. That's it!
Now, I have found four DLL files in Windows, at WINNTsystem32. They contain all the Fortran special functions:-
These DLLs are in c:WINNTsystem32
Note the DF and the FOR parts of the names: are these CVF/DVF installed dlls from older Compaq Fortran?
DFORMD.DLL
DFORMDD.DLL
DFORRT.DLL
DFORRTD.DLL
As an example, using DFORMD.DLL, this contains the obvious useful entries (INCLUDING ALL THE SPORT NAMES):-
BEEPQQ
BSEARCHQQ
CHANGEDIRQQ
CHANGEDRIVEQQ
CLEARSTATUSFPQQ
COMMITQQ
DELDIRQQ
DELFILESQQ
FINDFILEQQ
FOCUSQQ
FULLPATHQQ
GETARG
GETCHARQQ
GETCONFIGQQ
GETDAT
GETDRIVEDIRQQ
GETDRIVESIZEEXQQ
GETDRIVESIZEQQ
GETDRIVESQQ
GETENVQQ
GETEXCEPTIONPTRSQQ
GETFILEINFOQQ
GETHANDLEQQ
GETHWNDQQ
GETLASTERRORQQ
GETSTRQQ
GETTIM
GETUNITQQ
GETWSI ZEQQ
INQ
FOCUSQQ
LCWRQQ
MAKEDIRQQ
NARGS
PACKTIMEQQ
PEEKCHARQQ
RANDOM
RENAMEFILEQQ
RUNQQ
SCWRQQ
SEED
SETDAT
SETENVQQ
SETERRORMODEQQ
SETFILEACCESSQQ
SETFILETIMEQQ
SETTIM
SETWSIZEQQ
SLEEPQQ
SORTQQ
SPLITPATHQQ
SPORT_CANCEL_IO
SPORT_CONNECT
SPORT_GET_HANDLE
SPORT_GET_STATE
SPORT_GET_TIMEOUTS
SPORT_PEEK_DATA
SPORT_PEEK_LINE
SPORT_PURGE
SPORT_READ_DATA
SPORT_READ_LINE
SPORT_RELEASE
SPORT_SET_STATE
SPORT_SET_TIMEOUTS
SPORT_SHOW_STATE
SPORT_SPECIAL_FUNC
SPORT_WRITE_DATA
SPORT_WRITE_LINE
SSWRQQ
SYSTEMQQ
TRACEBACKQQ
UNPACKTIMEQQ
What do you make of this?
Is it possible everything we need is already in MS?
Could we write Fortran programs that call a DLL from c:WINNTsystem32 ?
Terence Wright
Sistemas TAU/TAU Systems
I have supplied Intel staff (Charles Broward, Ravikanth Talakoti) with our license ID numbers, screen copies of trying to register and explained we cannot register for the Support correctly because every attempt returns an "UNAUTHORISED" message - also sent to Intel staff - and still not resolved in four days now.
Cannot this be done from there? I gave the ID numbers to both? There is something not working with the Web pages.
Charles changed my password from there (which was alreadt working), and I entered the Forum today with a different ID and still got in, so I seem to be two persons now.
About my SPORT routines problem (and it isn't just me); we will put together a complete demonstration F90 program to show what happens on executing each function; especially what we put in (SPORT_SET_STATE) and what we get back from SPORT_GET_STATE and SPORT_SHOW_STATE. Also continuing with code which reads a line or string from the "opened" port which will hang without return, when in fact it should time out and return to the program.
This is enough to show something is wrong.
A valid test to avoid fingure-pointing at external equipment is to loop back TX output to RX input; then a write line followed by a read line should bring back what is written immediately back into the program.
We cannot see any data leaving the ports.
Now,if it is true he functions "WORK", there are still some possibililities:-
a) They work only for even or no parity (we find parity always reported as NOPARITY).
b) They work only for default frames (8-1-OFF) and any baud rate.We use ODD parity and 7 bits (7-2-ODD) 9600-38400 baud.
c) They work only if MODE or CONTROL panel is used to PRESET the.ports to the desired state, because SPORT does not really do it correctly. What process do you recommend?
How is it we can change some parameters to any valid values but CANNOT change some other parameters (e.g. Parity, RX timeout multiplier, RX timeout constant)?
And how does the programmer define he wants:
a) timeouts ON or OFF?
b) RTS/CTS control
c) DSR/TSR control
d) XON/XOFF handshaking control?
These are just some of the strange (apparent) omissions.
We will settle for anything that works. We just want to open a port, send ACK, read text-cr-lf, reply NAK if parity or other error reported and repeat the read, or else ACK and gete more data. That's it!
Now, I have found four DLL files in Windows, at WINNTsystem32. They contain all the Fortran special functions:-
These DLLs are in c:WINNTsystem32
Note the DF and the FOR parts of the names: are these CVF/DVF installed dlls from older Compaq Fortran?
DFORMD.DLL
DFORMDD.DLL
DFORRT.DLL
DFORRTD.DLL
As an example, using DFORMD.DLL, this contains the obvious useful entries (INCLUDING ALL THE SPORT NAMES):-
BEEPQQ
BSEARCHQQ
CHANGEDIRQQ
CHANGEDRIVEQQ
CLEARSTATUSFPQQ
COMMITQQ
DELDIRQQ
DELFILESQQ
FINDFILEQQ
FOCUSQQ
FULLPATHQQ
GETARG
GETCHARQQ
GETCONFIGQQ
GETDAT
GETDRIVEDIRQQ
GETDRIVESIZEEXQQ
GETDRIVESIZEQQ
GETDRIVESQQ
GETENVQQ
GETEXCEPTIONPTRSQQ
GETFILEINFOQQ
GETHANDLEQQ
GETHWNDQQ
GETLASTERRORQQ
GETSTRQQ
GETTIM
GETUNITQQ
GETWSI ZEQQ
INQ
FOCUSQQ
LCWRQQ
MAKEDIRQQ
NARGS
PACKTIMEQQ
PEEKCHARQQ
RANDOM
RENAMEFILEQQ
RUNQQ
SCWRQQ
SEED
SETDAT
SETENVQQ
SETERRORMODEQQ
SETFILEACCESSQQ
SETFILETIMEQQ
SETTIM
SETWSIZEQQ
SLEEPQQ
SORTQQ
SPLITPATHQQ
SPORT_CANCEL_IO
SPORT_CONNECT
SPORT_GET_HANDLE
SPORT_GET_STATE
SPORT_GET_TIMEOUTS
SPORT_PEEK_DATA
SPORT_PEEK_LINE
SPORT_PURGE
SPORT_READ_DATA
SPORT_READ_LINE
SPORT_RELEASE
SPORT_SET_STATE
SPORT_SET_TIMEOUTS
SPORT_SHOW_STATE
SPORT_SPECIAL_FUNC
SPORT_WRITE_DATA
SPORT_WRITE_LINE
SSWRQQ
SYSTEMQQ
TRACEBACKQQ
UNPACKTIMEQQ
What do you make of this?
Is it possible everything we need is already in MS?
Could we write Fortran programs that call a DLL from c:WINNTsystem32 ?
Terence Wright
Sistemas TAU/TAU Systems
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Have just seen the reply to "Issue34835".
A comment. We used assembler routines called from the Fortran programs before, which managed the serial ports directly. The advent of NT and XP systems actually prevents the user from changing the characteristics of the serial and parallel ports, so what worked from MSDOS up to Windows 98 won't work with NT and XP. So we went to CVF and DVF and easily converted at the expense or very large compilations indeed (about 15 times the sizes for the same F77 code).
Other things that went wrong in NT and XP executions were screen handling and upper-key-oard row characters in multiple shift modes and Function key codes other than unshifted. (XP writes only half the last screen line in console mode, till it gets more data). We found how to correct these items. We wrote our own corrected and much-extended version of SCREENIO which work wonderfully in full colour, still up to current XP. But we are stuck on getting a simple "write port, read port" to work. I wonder if our problem is that REALLY, the parity is set wrongly, due to the bug you found in the SPORT_SET_STATE function? If you can find more information I would be obliged. We could then ask our equipment makers/providers to switch from (standard) ODD parity to EVEN parity. But I still see CONTROL_SHOW_STATE reporting parity is DISABLED. If this is true we risk bad data.
Terence Wright
A comment. We used assembler routines called from the Fortran programs before, which managed the serial ports directly. The advent of NT and XP systems actually prevents the user from changing the characteristics of the serial and parallel ports, so what worked from MSDOS up to Windows 98 won't work with NT and XP. So we went to CVF and DVF and easily converted at the expense or very large compilations indeed (about 15 times the sizes for the same F77 code).
Other things that went wrong in NT and XP executions were screen handling and upper-key-oard row characters in multiple shift modes and Function key codes other than unshifted. (XP writes only half the last screen line in console mode, till it gets more data). We found how to correct these items. We wrote our own corrected and much-extended version of SCREENIO which work wonderfully in full colour, still up to current XP. But we are stuck on getting a simple "write port, read port" to work. I wonder if our problem is that REALLY, the parity is set wrongly, due to the bug you found in the SPORT_SET_STATE function? If you can find more information I would be obliged. We could then ask our equipment makers/providers to switch from (standard) ODD parity to EVEN parity. But I still see CONTROL_SHOW_STATE reporting parity is DISABLED. If this is true we risk bad data.
Terence Wright
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Further to reply in Premium Support issue Q345835.
The example file Q345835.F90 was in fact Q345835.exe and on executing did nothing but try to start the printer and "printed" many blank sheets.
I would appreciate a skeleton F90 program:-
SPORT_CONNECT
SPORT_SET_STATE !for data=7 stops=2, parity=odd, baud=9600
SPORT_GET_STATE ! to check what comes back
SPORT_SET_TIMEOUTS ! 2 second wait is enough
SPORT_GET_TIMEOUTS ! to check what comes back
SPORT_SHOW_STATE ! check total settings for agreement
SPORT_WRITE_DATA !#11 ACK, one character trigger input
SPORT_READ_LINE ! with case text of good/bad
Then we can compile and run on NT and XP machines and give detailed analyses of the results back to you.
Terence Wright
The example file Q345835.F90 was in fact Q345835.exe and on executing did nothing but try to start the printer and "printed" many blank sheets.
I would appreciate a skeleton F90 program:-
SPORT_CONNECT
SPORT_SET_STATE !for data=7 stops=2, parity=odd, baud=9600
SPORT_GET_STATE ! to check what comes back
SPORT_SET_TIMEOUTS ! 2 second wait is enough
SPORT_GET_TIMEOUTS ! to check what comes back
SPORT_SHOW_STATE ! check total settings for agreement
SPORT_WRITE_DATA !#11 ACK, one character trigger input
SPORT_READ_LINE ! with case text of good/bad
Then we can compile and run on NT and XP machines and give detailed analyses of the results back to you.
Terence Wright
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Terence,
Please use the Intel Premier Support web site to respond to issues. Use the "Update Issue" link or button to do that. This forum is not a substitute for Premier Support.
I have no idea why you saw an EXE that tried to print something.
There's nothing we can do to help regarding the fact that Windows no longer allows DOS-style direct port access nor supports ANSI.SYS.
Please use the Intel Premier Support web site to respond to issues. Use the "Update Issue" link or button to do that. This forum is not a substitute for Premier Support.
I have no idea why you saw an EXE that tried to print something.
There's nothing we can do to help regarding the fact that Windows no longer allows DOS-style direct port access nor supports ANSI.SYS.
Message Edited by Steve_Lionel on 01-06-2006 08:08 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
To clarify, You sent me a 2609 byte file (or made it available) related to this problem topic.
It was an executable in name and content. But the file name in your note terminated in .F90. So I think the wrong file was appended. So we got no information from the action. If I shouldn't mention it here, I'm sorry, but we couldn't access those other routes after ID's and passwords were changed unitl the new ones were sent.
Second. I have no idea what DOS and ANSI.SYS are being mentioned by you in this thread. We have never, ever used ANSI.SYS. We are using pure Fortran F90 code and SPORT routines and cannot get a port to work with certain real devices or on port loopback. These routines allow setting some parameters of the serial ports. They DO NOT cover setting the handshaking DTR/DSR, RTS/CTS nor Xon/Xoff protocols, nor allow setting DSR or CTS signals to a particular fixed state (Aren't these VITAL?). Nor do they allow turning input timeout on or off. So all these must be previously set by a MODE command before programm execution.
This CAN only be PARTIALLY executed by a SYSTEM call, so it has to be an external command-line command to set the port to the handshake characteristics required by any external device, because they are NOT in the SPORT_SET_STATE function.
We also suspect MS never tested the API at ODD parity with 2 stop bits and 7 data bits. We found we could get the CPU to hang if the port was initialized with some "valid" combinations of parameters. We suspected and you confirmed, that there is a bug in the underlying API which will not report PARITY correctly as so SPORT reports it incorrectly; the problem is, we don't know what parity the WRITE and READ functions are really using, because the ACK and NACK characters are also affected by the real port parity setting, affecting the port chip registers and the actual bit framing of these control codes..
So far we have got as far as finding a code 29 returned on writing the port with SPORT_WRITE_LINE; we suspect it is a handshake conflict at the hardware-software driver interface. NOTE: parity is also reported by SPORT_SHOW_STATE at level 11 as UNABLED which would be a disaster if true.
Terence Wright
It was an executable in name and content. But the file name in your note terminated in .F90. So I think the wrong file was appended. So we got no information from the action. If I shouldn't mention it here, I'm sorry, but we couldn't access those other routes after ID's and passwords were changed unitl the new ones were sent.
Second. I have no idea what DOS and ANSI.SYS are being mentioned by you in this thread. We have never, ever used ANSI.SYS. We are using pure Fortran F90 code and SPORT routines and cannot get a port to work with certain real devices or on port loopback. These routines allow setting some parameters of the serial ports. They DO NOT cover setting the handshaking DTR/DSR, RTS/CTS nor Xon/Xoff protocols, nor allow setting DSR or CTS signals to a particular fixed state (Aren't these VITAL?). Nor do they allow turning input timeout on or off. So all these must be previously set by a MODE command before programm execution.
This CAN only be PARTIALLY executed by a SYSTEM call, so it has to be an external command-line command to set the port to the handshake characteristics required by any external device, because they are NOT in the SPORT_SET_STATE function.
We also suspect MS never tested the API at ODD parity with 2 stop bits and 7 data bits. We found we could get the CPU to hang if the port was initialized with some "valid" combinations of parameters. We suspected and you confirmed, that there is a bug in the underlying API which will not report PARITY correctly as so SPORT reports it incorrectly; the problem is, we don't know what parity the WRITE and READ functions are really using, because the ACK and NACK characters are also affected by the real port parity setting, affecting the port chip registers and the actual bit framing of these control codes..
So far we have got as far as finding a code 29 returned on writing the port with SPORT_WRITE_LINE; we suspect it is a handshake conflict at the hardware-software driver interface. NOTE: parity is also reported by SPORT_SHOW_STATE at level 11 as UNABLED which would be a disaster if true.
Terence Wright
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Further news. We found Windows assumes no handshaking and no parity (actually 1200-7-OFF-1). As expected, compute switch-on reverts to these values. We have progressed to changing the paramters and getting timeout to switch on (just by actually setting any value), and can write the port. So far no reading occurs. We suspect we need to use the numbered special functions of SPORT_SPECIAL_FUNC to set the port to the correct device characteristics. Where are these to be found? Search on topic and word on the on-line files gave no item found. We are still trusting that parity is what we set it at, so we have two simultaneous potencial problems.
Terence Wright
Terence Wright
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
More: can loopback or talk between computers with no parity set and no handshaking. Cannot get results if parity set.
Note the norm is :
start_bit - data_frame(5-8) data_parity- stop_bit(s).
Is the problem that MS is only happy with 8-bit stripped frames?
Seems the API or the driver does not operate correctly in parity situations, looking like it doesn't do it at all (doesn't tell the UART chip to use parity). Now down to fiddling with a lot of bits in the DCB (T-DCB structure). So still cannot get trustable data from highspeed devices if no parity checks can be used, even if we go to CRC checksums, (this is NOT the normal way to do things). Is anybody looking into this Intel<-->Microsoft?
Terence Wright
Note the norm is :
start_bit - data_frame(5-8) data_parity- stop_bit(s).
Is the problem that MS is only happy with 8-bit stripped frames?
Seems the API or the driver does not operate correctly in parity situations, looking like it doesn't do it at all (doesn't tell the UART chip to use parity). Now down to fiddling with a lot of bits in the DCB (T-DCB structure). So still cannot get trustable data from highspeed devices if no parity checks can be used, even if we go to CRC checksums, (this is NOT the normal way to do things). Is anybody looking into this Intel<-->Microsoft?
Terence Wright
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This would be a Microsoft issue - nothing to do with our product.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I now confirm the detected problem with the SPORT routines is that SPORT_SET_STATE does not set the fPARITY bit in the DCB at position 1 when the requested parity is not OFF.
This is born out by variable parityenable being reported OFF even though parity was set.
The routines seem to work with NO handshaking and NO parity set; we haven't tested any but one velocity (9600 baud) but suspect speed is not part of the problem.
It MAY turn out that timeout is not set ON either, but we were using PEEK to know when to queue a READ_LINE and so not jam the computer in a wait loop (and we protect that with a SLEEPQQ call).
This is thereofre a bug in the Wrapper around the use of the underlying API routines and therefore it IS AN INTEL RESPONSIBILITY. If parity is specified as ODD or EVEN or SPACE or MARK, then the fparity bit should be set by this routine as part of its job.
The whole idea of the routines is to remove the user from using API's and bit-fiddling at the hardware interface.
Terence Wright.
This is born out by variable parityenable being reported OFF even though parity was set.
The routines seem to work with NO handshaking and NO parity set; we haven't tested any but one velocity (9600 baud) but suspect speed is not part of the problem.
It MAY turn out that timeout is not set ON either, but we were using PEEK to know when to queue a READ_LINE and so not jam the computer in a wait loop (and we protect that with a SLEEPQQ call).
This is thereofre a bug in the Wrapper around the use of the underlying API routines and therefore it IS AN INTEL RESPONSIBILITY. If parity is specified as ODD or EVEN or SPACE or MARK, then the fparity bit should be set by this routine as part of its job.
The whole idea of the routines is to remove the user from using API's and bit-fiddling at the hardware interface.
Terence Wright.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Terence,
You are mistaken. The SPORT_SET_STATE does indeed set the fparity bit. The problem is that the CommGetState Win32 API routine which retrieves the DCB (Device Control Block) always sets fparity to 0, therefore any attempt to see what the state of a port is will show this bit as 0. I did some web searching and found that many others, using a variety of languages, found the same problem. Nobody has an explanation of it and, to the best that anyone can tell, it doesn't matter. Windows handles the parity properly. It is not clear if the fparity bit is even looked at by Windows.
There is a bug in that SPORT_GET_STATE (and therefore SPORT_SHOW_STATE) tests fparity on return from CommGetState and. if fparity is zero in the DCB, tells the caller that parity is off in all cases. We will fix that bug. The program I sent you demonstrates that the actual parity value can be returned by looking at the DCB directly.
We cannot be responsible for the behavior of Windows itself.
You are mistaken. The SPORT_SET_STATE does indeed set the fparity bit. The problem is that the CommGetState Win32 API routine which retrieves the DCB (Device Control Block) always sets fparity to 0, therefore any attempt to see what the state of a port is will show this bit as 0. I did some web searching and found that many others, using a variety of languages, found the same problem. Nobody has an explanation of it and, to the best that anyone can tell, it doesn't matter. Windows handles the parity properly. It is not clear if the fparity bit is even looked at by Windows.
There is a bug in that SPORT_GET_STATE (and therefore SPORT_SHOW_STATE) tests fparity on return from CommGetState and. if fparity is zero in the DCB, tells the caller that parity is off in all cases. We will fix that bug. The program I sent you demonstrates that the actual parity value can be returned by looking at the DCB directly.
We cannot be responsible for the behavior of Windows itself.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Fair enough Steve.
Thank you for your patience.
We still can talk between computers with no parity and no handshaking. We still haven't progressed to talking to and reading from hardware devices with settable frame parameters, but with fixed hardware signalling requirements, that have always worked on MSDOS, Windows 95, 98 and (newly found) 2000 systems, but still not XP systems with handshaking and (possibly) parity considerations.
.
It may turn out that we need to be able to modify the remaining DCB settings to switch the handshaking from whatever default that Windows or the computer has set up. This point may be the downfall of all the others who have reported problems. If ever Intel gets to hear the full story, it would be worth writing up a mini-instruction manual for port management (lots of lab machine use). One guru says these routines have a problem if more that one port is running at the same time, but that is no part of our problem.
Terence Wright
TAU Systems
Thank you for your patience.
We still can talk between computers with no parity and no handshaking. We still haven't progressed to talking to and reading from hardware devices with settable frame parameters, but with fixed hardware signalling requirements, that have always worked on MSDOS, Windows 95, 98 and (newly found) 2000 systems, but still not XP systems with handshaking and (possibly) parity considerations.
.
It may turn out that we need to be able to modify the remaining DCB settings to switch the handshaking from whatever default that Windows or the computer has set up. This point may be the downfall of all the others who have reported problems. If ever Intel gets to hear the full story, it would be worth writing up a mini-instruction manual for port management (lots of lab machine use). One guru says these routines have a problem if more that one port is running at the same time, but that is no part of our problem.
Terence Wright
TAU Systems
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I can tell you that the SPORT routins always have a pending read on the port in order to be able to perform some of the other functions. If this poses a problem for you, I will again recommend the Win32 API direct calls. It isn't really that hard and you have full control over what is going on.
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page