[fpc-pascal] The fpOpen call on a serial port blocks on a Mac. Why? [SOLVED]

[Bruce Tulloch]

Thanks Henry, I've found the problem, more than one actually.

For the record if anyone else runs into this is that the red-herring
here was another bug in synaser.pas (007.005.002) where an incorrect
ioctl call is made (in Darwin), fixed on line 1939 with:

- SerialCheck(fpioctl(FHandle, TCIOflush, TCIOFLUSH));
+ SerialCheck(fpioctl(FHandle, TCIOflush, Pointer(PtrInt(TCIOFLUSH))));

This bug resulted in the purge that's called after the port is opened to
fail resulting in my client code being erroneously told the open failed.
Inspection of errno revealed the real problem (EINVAL).

Thanks for the tips and just to confirm the open call I now use (on line
946) which works in Darwin (subject to the ioctl fix above) is:

 FHandle := THandle(fpOpen(FDevice, O_RDWR or O_SYNC or O_NONBLOCK));

which opens successfully and allows the other termio flags to then be
set appropriately. My earlier comments about ENOTTY were erroneous.

Bruce.

On 08/11/11 18:54, Henry Vermaak wrote:
> On 11/08/11 05:00, Bruce Tulloch wrote:
>> I am using the latest synaser (007.005.002) from the synapse library
>> which works just fine with (USB) serial ports on Linux and Windows but
>> Mac OSX 10.6 it is proving problematic.
>>
>> The call which opens the port (synaser.pas:946) is:
>>
>>    FHandle := THandle(fpOpen(FDevice, O_RDWR or O_SYNC));
>>
>> where in my case, FDevice is /dev/tty.usbserial.DCUIYCH4.
>>
>> This fpOpen call blocks indefinitely (i.e. it never returns).
>>
>> The device is present, working and requires no flow control:
>>
>> My-Mac:~ admin$ stty -f /dev/tty.usbserial-DCUIYCH4 -a
>> speed 9600 baud; 0 rows; 0 columns;
>> lflags: -icanon -isig -iexten -echo -echoe -echok -echoke -echonl
>>     -echoctl -echoprt -altwerase -noflsh -tostop -flusho -pendin
>>     -nokerninfo -extproc
>> iflags: -istrip -icrnl -inlcr -igncr -ixon -ixoff -ixany -imaxbel -iutf8
>>     -ignbrk -brkint -inpck -ignpar -parmrk
>> oflags: -opost -onlcr -oxtabs -onocr -onlret
>> cflags: cread cs8 -parenb -parodd hupcl -clocal -cstopb -crtscts
>>          -dsrflow -dtrflow -mdmbuf
>> cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol =<undef>;
>>     eol2 =<undef>; erase = ^?; intr = ^C; kill = ^U; lnext = ^V;
>>     min = 1; quit = ^\; reprint = ^R; start = ^Q; status = ^T;
>>     stop = ^S; susp = ^Z; time = 0; werase = ^W;
>>
> 
> Have you tried setting clocal under oflags?  If "open" thinks it's a
> modem, then it can block until it sees carrier detection.  I notice that
> my serial ports have clocal set.
> 
>> and the screen command opens and communicates via this port just fine so
>> I don't believe there is anything wrong with the device, the driver or
>> the state of any port flags when fpOpen is attempted.
>>
>> Can anyone tell me what I might be doing wrong here?
>>
>> Note that adding the O_NONBLOCK flag allows the fpOpen to succeed but
>> all subsequent attempts to talk to the port return ENOTTY which is of
>> course wrong as it is a real (USB) serial (TTY) device.
> 
> This should have helped for the modem issue.  Did you remove the O_SYNC?
>  Maybe setting clocal after opening will help?
> 
> Henry
> _______________________________________________
> fpc-pascal maillist  -  fpc-pascal at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-pascal