Tried both, but need to shutdown VEE
-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: 02 June 2004 12:05
To: Simon Parfitt; 'VRF'
Subject: RE: [vrf] RE: Binary read over serial port
> I need to close down VEE to reset the port then it's fine.
Can you maybe just EXECUTE CLOSE and clear it? Or RESET maybe? I know
sometimes that's not enough.
> Also never happens in runtime!!!
There's serial for ya
-SHAWN-
E-mail Confidentiality Notice and Disclaimer
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited.
Email messages are not necessarily secure. Renesas Technology Europe does not accept responsibility for any changes made to this message after it was sent. Please note that Renesas Technology Europe checks outgoing email messages for the presence of computer viruses.
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: 02 June 2004 12:05
To: Simon Parfitt; 'VRF'
Subject: RE: [vrf] RE: Binary read over serial port
> I need to close down VEE to reset the port then it's fine.
Can you maybe just EXECUTE CLOSE and clear it? Or RESET maybe? I know
sometimes that's not enough.
> Also never happens in runtime!!!
There's serial for ya
-SHAWN-
E-mail Confidentiality Notice and Disclaimer
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited.
Email messages are not necessarily secure. Renesas Technology Europe does not accept responsibility for any changes made to this message after it was sent. Please note that Renesas Technology Europe checks outgoing email messages for the presence of computer viruses.
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
I think that might have shed light on a problem I keep getting. I am doing a
binary transfur at 115200 using the DTR line to control the flow. But
sometimes it still times out halfway through a transfur. I have managed to
work out that it is the decimal value 10 that causes it!! I need to close
down VEE to reset the port then it's fine. This might not happen for days at
a time then I get a group for them. Also never happens in runtime!!!
Simon
-----Original Message-----
From: Shawn Fessenden [mailto:shawn@testech-ltd.com]
Sent: 02 June 2004 04:26
To: VRF
Subject: [vrf] RE: Binary read over serial port
> A clue as to what might be going on is that the last byte received was
> 0x0a or a linefeed. Looking at responses that did not error out
> showed no linefeeds.
I believe you have correctly identified the problem...
> Why would the binary read fail at all?
You did appease the gods, right? Remember, they want *virgins*.
With respect to your COM2 problem, I would check Advanced Instrument
Properties, Direct I/O and make sure the Read Terminator and EOL Sequence
are cleared.
But seriously, if the IO Libs is using serial.sys to implement serial ports
then it's pretty easy to explain how it could get screwed up. By the time
Win32 was settled on (some 14 months before NT was released) comm management
was so screwed up that it was one of the major PITA points of all previous
Windows. Windows 3.1 Enhanced Mode's serial.vxd started the whole trouble
and it's not going away any time soon. In fact my money is on it's never
going to go away.
As far as Windows is concerned, the uber-controller of how a serial port
works is called the DCB - the device control block. This is not the same as
a disk DCB for those who are familiar with that.
A DCB is a C structure that contains many bit fields. A bit field in a C
structure is theoretically a field that masks n-bits of a byte. How exactly
it is implemented is up to the compiler. Optimization will usually dictate
exactly how the fields are handled. Sometimes a bit field is implemented as
an entire entity of enough bits to handle the bit field and sometimes it is
packed in along with other fields into "chunk" size entities that the
processor handles most efficiently.
The point is that there's room for a lot of interpretation as to just where
exactly a field is located within the structure. And of course that can lead
to difficulties when Stupid C Tricks are used to access the structure.
There's no denying that such tricks are employed in the name of efficiency,
but when it comes to bit fields these are better left in the bag because of
the problems they can cause.
Anyway... there's one member, DWORD fBinary: 1, that would seem to
ultimately control how data is handled, but Win32 doesn't support non-binary
transfer modes so this member must always be 1. The kicker is that the
documentation NOW says "Using FALSE will not work" but years ago (back in
the 16-bit days) it USED to say "A value of FALSE can cause undefined
behavior".
The next interesting character (har!) is the member char EofChar. Now, armed
with the above information one would think that this is a useless member.
Under certain specific conditions though it does in fact terminate input.
None of these conditions are documented or supported, and should (IMO) never
be used. The documentation never exactly says what they mean by EOF - End Of
Field, End Of File, End Of Farkle?
Then there's flow control. There are no less than 12 members that specify
exactly how flow control is to be handled. XON/XOFF is the worst, with 9
separate members specifying exactly how to handle it. Some ambiguous
combinations of flow control parameters are not flagged by error 6
(incorrect parameter) and so are able to terribly confuse the issue.
There's the EvtChar which signals a soft event, there's fAbortOnError which
will abort all I/O when an error occurs until ClearCommError is called,
there's the ErrorChar that replaces characters with parity errors, and
that's not the end of it yet. There are dozens of combinations of things
that can go wrong with serial communications that can cause failure. Put
simply it's a wonder that it works at all.
FWIW I've delved far more deeply into the subject than I ever wanted to
(it's why my hair turned white and fell out) and have found that it's best
to obey the rules of thumb that our elders (those who investigated the 8250)
gave us: simple is better and if you go over 9600 baud then use hardware
flow control. Avoid XON/XOFF at all costs.
-SHAWN-
---
You are currently subscribed to vrf as: simon.parfitt@renesas.com To
subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
E-mail Confidentiality Notice and Disclaimer
This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to which they are addressed. Access to this email by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited.
Email messages are not necessarily secure. Renesas Technology Europe does not accept responsibility for any changes made to this message after it was sent. Please note that Renesas Technology Europe checks outgoing email messages for the presence of computer viruses.
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".