there must be a reason why minicom uses O_NDELAY (=O_NONBLOCK) in case
O_NDELAY ist defined. Now i remember that i had the same problem several
years ago with cat file /dev/ttyUSB0, i think it was Fedora Core 3 or 4.
I assume this does not only happen with a pl2303.
#if defined(O_NDELAY)
Armin Diehl wrote:
I need some hint regarding opening a serial (ttyUSB) port using the unit
serial. Minicom works fine under my user id. When i call
SerOpen('/dev/ttyUSB0'), fpopen blocks forever. When i first start
minicom on that port, SerOpen and all other functions of serial.pp works
Armin Diehl wrote:
I need some hint regarding opening a serial (ttyUSB) port using the
unit serial. Minicom works fine under my user id. When i call
SerOpen('/dev/ttyUSB0'), fpopen blocks forever. When i first start
minicom on that port, SerOpen and all other functions of serial.pp
works
Hi Peter,
that is the same as in the standard serial.pp:
Result := fpopen(DeviceName, O_RDWR or O_NOCTTY);
and this fpopen will block as long as minicom is not started on that
device.
On 08/18/2011 11:10 AM, peter green wrote:
Armin Diehl wrote:
I need some hint regarding opening a serial
On 18/08/11 10:34, Armin Diehl wrote:
Hi Peter,
that is the same as in the standard serial.pp:
Result := fpopen(DeviceName, O_RDWR or O_NOCTTY);
and this fpopen will block as long as minicom is not started on that
device.
Try to add O_NONBLOCK to the flags with fpopen. Then set CLOCAL like
Just tried it on a 32 bit system (Linux t41.armin.d
2.6.35.13-92.fc14.i686 #1 SMP Sat May 21 17:39:42 UTC 2011 i686 i686
i386 GNU/Linux) as root
uses baseunix;
var handle : longint;
begin
writeln('Start: fpopen');
handle := fpopen('/dev/ttyUSB0',O_RDWR or O_NOCTTY);
writeln ('Result:
In our previous episode, Armin Diehl said:
that is the same as in the standard serial.pp:
Result := fpopen(DeviceName, O_RDWR or O_NOCTTY);
and this fpopen will block as long as minicom is not started on that
device.
Yes. And seems that minicom turns of xon/xoff. You could try to verify
Yes, found that a few minutes ago (strace is nice), micom does:
open(/dev/ttyUSB0, O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
fcntl(3, F_GETFL) = 0x8802 (flags
O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_LARGEFILE) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or
In our previous episode, Armin Diehl said:
should that be changed in the standard serial.pp ?
I'm not sure, since this leaves nonblocking behaviour on by default,
moreover serial is pan unix, and non linuxes might react differently.
Btw do you see minicom do a sequence of opening in nonblock,
On 18/08/11 11:21, Marco van de Voort wrote:
In our previous episode, Armin Diehl said:
should that be changed in the standard serial.pp ?
I'm not sure, since this leaves nonblocking behaviour on by default,
moreover serial is pan unix, and non linuxes might react differently.
No it
Hi Marco,
minicom calls open with O_NONBLOCK and resets O_NONBLOCK directly after
the open call:
open(/dev/ttyUSB0, O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
fcntl(3, F_GETFL) = 0x8802 (flags
O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_LARGEFILE) = 0
doing the
On 18/08/11 12:00, Armin Diehl wrote:
Hi Marco,
minicom calls open with O_NONBLOCK and resets O_NONBLOCK directly after
the open call:
open(/dev/ttyUSB0, O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
fcntl(3, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE)
fcntl(3, F_SETFL, O_RDWR|O_LARGEFILE) = 0
yes, that is better
function SerOpen(const DeviceName: String): TSerialHandle;
var
flags : cint;
begin
Result := fpopen(DeviceName, O_RDWR or O_NOCTTY or O_NONBLOCK);
if result -1 then
begin
flags := fpfcntl(Result,F_GetFl);
fpfcntl(Result,F_SETFL,flags and (not O_NONBLOCK));
Armin Diehl wrote:
yes, that is better
function SerOpen(const DeviceName: String): TSerialHandle;
var
flags : cint;
begin
Result := fpopen(DeviceName, O_RDWR or O_NOCTTY or O_NONBLOCK);
if result -1 then
begin
flags := fpfcntl(Result,F_GetFl);
fpfcntl(Result,F_SETFL,flags and
On 18/08/11 14:11, Mark Morgan Lloyd wrote:
But why have I not seen this problem on Debian despite having used this
unit extensively? And why have I not seen it when testing the modified
unit on Solaris with the SerOpen() function being unchanged?
Some serial ports seem to have clocal unset,
In our previous episode, Henry Vermaak said:
On 18/08/11 14:11, Mark Morgan Lloyd wrote:
But why have I not seen this problem on Debian despite having used this
unit extensively? And why have I not seen it when testing the modified
unit on Solaris with the SerOpen() function being
Some serial ports seem to have clocal unset, for some reason, which
causes it to block on open (waiting for the modem status
lines). Like
you, I've never seen it with any of my serial ports, either.
Might have to do with the defaulting to autobaud of some
usbserial chips.
Ludo Brands wrote:
Some serial ports seem to have clocal unset, for some reason, which
causes it to block on open (waiting for the modem status
lines). Like
you, I've never seen it with any of my serial ports, either.
Might have to do with the defaulting to autobaud of some
usbserial chips.
18 matches
Mail list logo