I'm not sure what's going on, it might be a mismatch 'tween the buffer size
and the read speed. What I would do is:
Set the buffer size to something I know works for the device and with the
speed, sometimes slower is ok, then work backwards. Once this is working I
would read a byte at a time and stuff it into a string. This way you build
your own endless buffer within your code and this should solve any dropped
bytes through "dirty" windows. Note, once you set the speed limit, the
device sending should comply, else tell it to comply.
Once good data is received, you can try to speed-up, but try to understand
the buffer size vs read speed (kinda funky since WINDOWS controls this one,
read speed). But once you've got good buffer size and baud rate, you might
want to read all as an array. Don't be surprised that you might loose a
byte here and there through the "window." I've had trouble intermittently
with the array, just shows up every month or so.
So a byte at a time is hard to drop. You should be able to grab a byte with
a tin can and piece of string.
If you find a better way, please let me know.
rufus
-----Original Message-----
From: Martin.Alles@hno.atmel.com [mailto:Martin.Alles@hno.atmel.com]
Sent: Friday, July 30, 2004 9:11 AM
To: VRF
Subject: [vrf] Access to serial port, some more details
Hello all,
a colleague has some problems using the serial interface, please find the
description of what happens below. Has anyone a solution to this? The
time-out is not active, the error occurs directly. We actually use VEE Pro
7, however, the error also occured in Vee 6.
Best regards,
Martin
> VEE seems to have difficulties in addressing the serial interface. So
> an error message like this happens the first time when using the
> serial interface. But then it works all right for reading 16 bytes
@115000Bd.
>
> Unfortunatelly we have to capture 36 bytes. With this setting, this
> error message occures every time at once, so it isn't a timeout.
Using an error output together with execute reset is a good tip when the vee
routine fails just once. But it does not help when vee settles with an error
message every time.
Thing is, after an initial error message, it works for reading 16 bytes (so
the transceiver is active . It also works when using a C routine. But the
VEE program fails when it has to read 36 bytes instead of 16 - even when
using restart to clear the buffer.
details:
stop bit: 1
parity: none
baud rate: 115200
handshake: none
receive buffer size: 4096 and other values
timeout: 15 secs
Read Terminator: ""
EOL sequence: ""
Array seperator: ""
Live Mode: ON
Byte ordering: MSB
>
>
>
> . <<err_msg_vee.gif>>
>
---
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".
and the read speed. What I would do is:
Set the buffer size to something I know works for the device and with the
speed, sometimes slower is ok, then work backwards. Once this is working I
would read a byte at a time and stuff it into a string. This way you build
your own endless buffer within your code and this should solve any dropped
bytes through "dirty" windows. Note, once you set the speed limit, the
device sending should comply, else tell it to comply.
Once good data is received, you can try to speed-up, but try to understand
the buffer size vs read speed (kinda funky since WINDOWS controls this one,
read speed). But once you've got good buffer size and baud rate, you might
want to read all as an array. Don't be surprised that you might loose a
byte here and there through the "window." I've had trouble intermittently
with the array, just shows up every month or so.
So a byte at a time is hard to drop. You should be able to grab a byte with
a tin can and piece of string.
If you find a better way, please let me know.
rufus
-----Original Message-----
From: Martin.Alles@hno.atmel.com [mailto:Martin.Alles@hno.atmel.com]
Sent: Friday, July 30, 2004 9:11 AM
To: VRF
Subject: [vrf] Access to serial port, some more details
Hello all,
a colleague has some problems using the serial interface, please find the
description of what happens below. Has anyone a solution to this? The
time-out is not active, the error occurs directly. We actually use VEE Pro
7, however, the error also occured in Vee 6.
Best regards,
Martin
> VEE seems to have difficulties in addressing the serial interface. So
> an error message like this happens the first time when using the
> serial interface. But then it works all right for reading 16 bytes
@115000Bd.
>
> Unfortunatelly we have to capture 36 bytes. With this setting, this
> error message occures every time at once, so it isn't a timeout.
Using an error output together with execute reset is a good tip when the vee
routine fails just once. But it does not help when vee settles with an error
message every time.
Thing is, after an initial error message, it works for reading 16 bytes (so
the transceiver is active . It also works when using a C routine. But the
VEE program fails when it has to read 36 bytes instead of 16 - even when
using restart to clear the buffer.
details:
stop bit: 1
parity: none
baud rate: 115200
handshake: none
receive buffer size: 4096 and other values
timeout: 15 secs
Read Terminator: ""
EOL sequence: ""
Array seperator: ""
Live Mode: ON
Byte ordering: MSB
>
>
>
> . <<err_msg_vee.gif>>
>
---
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".
> handshake: none
This is probably a bad idea. Communicating at over 9600 over serial usually
implies using some kind of flow control. Software flow control is usually a
bad idea, so it's almost always hardware flow control.
> receive buffer size: 4096 and other values
I'm not certain this is what I think it is, but if it is then this value
isn't meant to be changed. Pick one, set it, reboot and forget it.
It might be Agilent's own buffer and have nothing to do with the driver's
buffer but if, as I think, it boils down to a call to SetCommProperties with
a different dwMaxRxQueue size then changing it is a sure way to fragment non
paged pool. Once that happens no driver will be able to reallocate any of
it's buffers (they shouldn't be doing that anyway) and the only cure is a
reboot.
In the past, whenever I've run into this error I used to uninstall IO Libs
and load a newer IO Libs. That seemed to fix it most of the time. Every once
in a while I had to mess with the driver load order to get it to work right.
You used to do that by using the Driver control panel and making other
drivers depend on the serial driver, whether they really do or not - it
ensures that serial is loaded first, then everything else.
Since Windows 2000 removed the Drivers control panel, I'm not aware of an
easy way to do that anymore. There may be something in the resource kit, or
you can write your own program to do it, or you can just modify the
registry. In any case, be sure to make a backup of the
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices subkey. Modifying
values here can potentially be disastrous.
-SHAWN-
---
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".