Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
serial port: I/O error
1,240 views
Skip to first unread message
Ralf Fassel
Mar 28, 2012, 9:35:00 AM3/28/12
to
What could be the cause of an I/O error on an serial port?
I know this is somewhat generic, but...
tclkit 8.5.8 on Windows 7, 32 bit, com-port can be openend ok,
configured non-blocking with the correct baudrate etc, fileevent
readable triggers, but the actual read errs out with
"error reading "filexxxxxx": I/O error".
Hyperterminal connected to the same serial port can read data ok...
R'
I know this is somewhat generic, but...
tclkit 8.5.8 on Windows 7, 32 bit, com-port can be openend ok,
configured non-blocking with the correct baudrate etc, fileevent
readable triggers, but the actual read errs out with
"error reading "filexxxxxx": I/O error".
Hyperterminal connected to the same serial port can read data ok...
R'
Harald Oehlmann
Mar 28, 2012, 9:38:51 AM3/28/12
to
fconfigure %h -lasterror
It will tell you:
- frame, parity -> wrong baud rate, parity or stop bits
- break -> sender sent a break
and continue to read after reading the error...
Hope this helps
-Harald
T.Dieckmann
Mar 28, 2012, 5:39:24 PM3/28/12
to
Hello Ralf,
I had the same problem with TCL8.5 . I got always "framing error" as
response for fconfigure -lasterror. TCL8.4 showed the same problem but
not as often as TCL8.5 did.
Neither changing the buffersize of the tcl channel nor changing the fifo
setting of the serial device was successful.
I ask also here to get any hint, but no real solution was found.
The analysis with "portmon" (no error at all with this application)
indicated the TCL error occured always if a large data chunck went in.
Other serial terminals like hyperterm or terraterm indicated no errors,
may be they are more robust under the hood.
Finally I was forced to handle it on application level even if I missed
some data.
As a TCL fan it was really hard to acknowledge that it isn't (anymore)
the right tool for serial line handling. In older releases we monitored
several serial lines at the same time without any problems from TCL.
Could the performance penalty we have to pay for new features the reason
for that?
Br,
Torsten
I had the same problem with TCL8.5 . I got always "framing error" as
response for fconfigure -lasterror. TCL8.4 showed the same problem but
not as often as TCL8.5 did.
Neither changing the buffersize of the tcl channel nor changing the fifo
setting of the serial device was successful.
I ask also here to get any hint, but no real solution was found.
The analysis with "portmon" (no error at all with this application)
indicated the TCL error occured always if a large data chunck went in.
Other serial terminals like hyperterm or terraterm indicated no errors,
may be they are more robust under the hood.
Finally I was forced to handle it on application level even if I missed
some data.
As a TCL fan it was really hard to acknowledge that it isn't (anymore)
the right tool for serial line handling. In older releases we monitored
several serial lines at the same time without any problems from TCL.
Could the performance penalty we have to pay for new features the reason
for that?
Br,
Torsten
Harald Oehlmann
Mar 29, 2012, 2:49:37 AM3/29/12
to
On 28 Mrz., 23:39, "T.Dieckmann" <news...@arcor.de> wrote:
> Hello Ralf,
>
> I had the same problem with TCL8.5 . I got always "framing error" as
> response for fconfigure -lasterror. TCL8.4 showed the same problem but
> not as often as TCL8.5 did.
> Neither changing the buffersize of the tcl channel nor changing the fifo
> setting of the serial device was successful.
> I ask also here to get any hint, but no real solution was found.
> The analysis with "portmon" (no error at all with this application)
> indicated the TCL error occured always if a large data chunck went in.
> Other serial terminals like hyperterm or terraterm indicated no errors,
> may be they are more robust under the hood.
> Finally I was forced to handle it on application level even if I missed
> some data.
Hi Thorsten,
> Hello Ralf,
>
> I had the same problem with TCL8.5 . I got always "framing error" as
> response for fconfigure -lasterror. TCL8.4 showed the same problem but
> not as often as TCL8.5 did.
> Neither changing the buffersize of the tcl channel nor changing the fifo
> setting of the serial device was successful.
> I ask also here to get any hint, but no real solution was found.
> The analysis with "portmon" (no error at all with this application)
> indicated the TCL error occured always if a large data chunck went in.
> Other serial terminals like hyperterm or terraterm indicated no errors,
> may be they are more robust under the hood.
> Finally I was forced to handle it on application level even if I missed
> some data.
my experience:
- we are in bar code business - not so high data rates:
- set -buffersize 32768 is ok in general
- when it is a citrix/wts forwarded port, use: -buffersize 0
- when it is a virtual com over Thosiba Bluetooth stack: don't set -
buffersize and don't write more than 1kb at once.
- compatibility with Serial-to USB-Adaptors got much better with 8.5
than 8.4. This means, that many usb-adaptors have buggy drivers and
tcl deals better with it.
For us, 8.5 is more usable.
-Harald
Ralf Fassel
Mar 29, 2012, 4:46:05 AM3/29/12
to
* "T.Dieckmann" <new...@arcor.de>
with built-in RS232 (no USB-serial converter but the real thing)
| I ask also here to get any hint, but no real solution was found. The
| analysis with "portmon" (no error at all with this application)
| indicated the TCL error occured always if a large data chunck went
| in.
Define 'large'... In my situation it is at 9600 baud, with data of max
60-70 chars per chunk, chunks coming in in seconds intervals.
| Other serial terminals like hyperterm or terraterm indicated no
| errors, may be they are more robust under the hood.
Did they show *all* data? Might be that they silently dropped the
errors...
| As a TCL fan it was really hard to acknowledge that it isn't (anymore)
| the right tool for serial line handling. In older releases we
| monitored several serial lines at the same time without any problems
| from TCL.
Did the new TCL releases show the problems on the very same hardware?
| Could the performance penalty we have to pay for new features the
| reason for that?
Uh... I'd like to doubt this. At the data rates in question current
processors should be able to handle the load while in suspend-to-disk
mode (just kidding). The application in my case is doing nothing but
waiting for the serial line...
R'
| I had the same problem with TCL8.5 . I got always "framing error" as
| response for fconfigure -lasterror. TCL8.4 showed the same problem but
| not as often as TCL8.5 did. Neither changing the buffersize of the
| tcl channel nor changing the fifo setting of the serial device was
| successful.
Which OS was this on? I have the problem on a single Windows-7 laptop
| response for fconfigure -lasterror. TCL8.4 showed the same problem but
| not as often as TCL8.5 did. Neither changing the buffersize of the
| tcl channel nor changing the fifo setting of the serial device was
| successful.
with built-in RS232 (no USB-serial converter but the real thing)
| I ask also here to get any hint, but no real solution was found. The
| analysis with "portmon" (no error at all with this application)
| indicated the TCL error occured always if a large data chunck went
| in.
60-70 chars per chunk, chunks coming in in seconds intervals.
| Other serial terminals like hyperterm or terraterm indicated no
| errors, may be they are more robust under the hood.
errors...
| As a TCL fan it was really hard to acknowledge that it isn't (anymore)
| the right tool for serial line handling. In older releases we
| monitored several serial lines at the same time without any problems
| from TCL.
| Could the performance penalty we have to pay for new features the
| reason for that?
processors should be able to handle the load while in suspend-to-disk
mode (just kidding). The application in my case is doing nothing but
waiting for the serial line...
R'
Rolf Schroedter
Mar 29, 2012, 7:28:21 AM3/29/12
to
On 28.03.2012 23:39, T.Dieckmann wrote:
> Hello Ralf,
>
> I had the same problem with TCL8.5 . I got always "framing error" as
> response for fconfigure -lasterror. TCL8.4 showed the same problem but
> not as often as TCL8.5 did.
Framing errors are *hardware errors* on the serial line at UART level.
> Hello Ralf,
>
> I had the same problem with TCL8.5 . I got always "framing error" as
> response for fconfigure -lasterror. TCL8.4 showed the same problem but
> not as often as TCL8.5 did.
In most cases they have to do with invalid baud-rate or stop-bit
settings (invalid could also mean that there is a clock drift between
the two communication sides, e.g. a physical baus of 9550 vs. 9650).
Framing errors have nothing to do with TCL or OS performance.
The only thing could be, that different OS, different serial port
hardware drivers or different application software might report this
error or might ignore it.
> Neither changing the buffersize of the tcl channel nor changing the fifo
> setting of the serial device was successful.
> I ask also here to get any hint, but no real solution was found.
> The analysis with "portmon" (no error at all with this application)
> indicated the TCL error occured always if a large data chunck went in.
> Other serial terminals like hyperterm or terraterm indicated no errors,
> may be they are more robust under the hood.
> Finally I was forced to handle it on application level even if I missed
> some data.
>
> As a TCL fan it was really hard to acknowledge that it isn't (anymore)
> the right tool for serial line handling. In older releases we monitored
> several serial lines at the same time without any problems from TCL.
> Could the performance penalty we have to pay for new features the reason
> for that?
>
I'm using serial ports with Tcl 8.5 under Windows XP and Windows 7
(x86/x64) nearly each day ...
Did you try to communicate with Moni (written in Tcl)
http://rolf-schroedter.de/moni/
Regards,
Rolf.
Rolf Schroedter
Mar 29, 2012, 7:44:50 AM3/29/12
to
The "I/O error" is only the Tcl expression for the Posix(?) error code
EIO. This could happen for various reasons.
Could you please catch the [read] operation and check more error details
with [fconfigure $chan -lasterror] ?
Do you use binary or ASCII communication (e.g. ^Z could be EOF on Windows) ?
Does your communication uses some handshake ? E.g. EIO can happen when
the partner drops the DCD line...
Rolf.
EIO. This could happen for various reasons.
Could you please catch the [read] operation and check more error details
with [fconfigure $chan -lasterror] ?
Do you use binary or ASCII communication (e.g. ^Z could be EOF on Windows) ?
Does your communication uses some handshake ? E.g. EIO can happen when
the partner drops the DCD line...
Rolf.
Ralf Fassel
Mar 29, 2012, 8:02:52 AM3/29/12
to
* Rolf Schroedter <rolf.sc...@dlr.de>
I've added it but haven't got a response yet (the hardware in question
is remote, I don't have direct access to it, but must ask someone to do
it for me).
| Do you use binary or ASCII communication (e.g. ^Z could be EOF on
| Windows) ?
Binary, non blocking.
-mode $baudrate -translation binary -blocking 0
where baudrate is 9600,E,7,1 (unusual, I know, but it works on a second system).
| Does your communication uses some handshake ? E.g. EIO can happen when
| the partner drops the DCD line...
Unclear, could be that hardware handshake is involved.
I guess I will add a handshake selector too...
R'
| Could you please catch the [read] operation and check more error
| details with [fconfigure $chan -lasterror] ?
Of course I detected this option only after posting :-)
| details with [fconfigure $chan -lasterror] ?
I've added it but haven't got a response yet (the hardware in question
is remote, I don't have direct access to it, but must ask someone to do
it for me).
| Do you use binary or ASCII communication (e.g. ^Z could be EOF on
| Windows) ?
-mode $baudrate -translation binary -blocking 0
where baudrate is 9600,E,7,1 (unusual, I know, but it works on a second system).
| Does your communication uses some handshake ? E.g. EIO can happen when
| the partner drops the DCD line...
I guess I will add a handshake selector too...
R'
T.Dieckmann
Mar 29, 2012, 4:16:37 PM3/29/12
to
Am 29.03.2012 10:46, schrieb Ralf Fassel:
> * "T.Dieckmann"<new...@arcor.de>
> | I had the same problem with TCL8.5 . I got always "framing error" as
> | response for fconfigure -lasterror. TCL8.4 showed the same problem but
> | not as often as TCL8.5 did. Neither changing the buffersize of the
> | tcl channel nor changing the fifo setting of the serial device was
> | successful.
>
> Which OS was this on? I have the problem on a single Windows-7 laptop
> with built-in RS232 (no USB-serial converter but the real thing)
All tests were done on the same machine with WinXP Sp3 with build-in
> * "T.Dieckmann"<new...@arcor.de>
> | I had the same problem with TCL8.5 . I got always "framing error" as
> | response for fconfigure -lasterror. TCL8.4 showed the same problem but
> | not as often as TCL8.5 did. Neither changing the buffersize of the
> | tcl channel nor changing the fifo setting of the serial device was
> | successful.
>
> Which OS was this on? I have the problem on a single Windows-7 laptop
> with built-in RS232 (no USB-serial converter but the real thing)
RS232 16550 UART as well as with an additional RS232 card with 16C850
UART and 128 byte buffer.
Never saw that problem in the past with 8.4 on Linux, but had no chance
to check it with 8.5 under Linux as we moved to Windows.
>
> | I ask also here to get any hint, but no real solution was found. The
> | analysis with "portmon" (no error at all with this application)
> | indicated the TCL error occured always if a large data chunck went
> | in.
>
> Define 'large'... In my situation it is at 9600 baud, with data of max
> 60-70 chars per chunk, chunks coming in in seconds intervals.
- can't remember of the chunk size, but it was much higher than yours
(data source: highest logging/trace level of an embedded device with RT OS)
- we never got an UART buffer overflow error
>
> | Other serial terminals like hyperterm or terraterm indicated no
> | errors, may be they are more robust under the hood.
>
> Did they show *all* data? Might be that they silently dropped the
> errors...
>
I cannot exclude it, but it was at least not obvious.
> | Other serial terminals like hyperterm or terraterm indicated no
> | errors, may be they are more robust under the hood.
>
> Did they show *all* data? Might be that they silently dropped the
> errors...
>
> | As a TCL fan it was really hard to acknowledge that it isn't (anymore)
> | the right tool for serial line handling. In older releases we
> | monitored several serial lines at the same time without any problems
> | from TCL.
>
> Did the new TCL releases show the problems on the very same hardware?
only one version at a time. Moreover we performed the test on 3 PC of
the same type.
>
> | Could the performance penalty we have to pay for new features the
> | reason for that?
>
> Uh... I'd like to doubt this. At the data rates in question current
> processors should be able to handle the load while in suspend-to-disk
> mode (just kidding). The application in my case is doing nothing but
> waiting for the serial line...
be more OS related than TCL version related.
Br,
Torsten
0 new messages