G'day all,

Can any Mac people tell me why

FHandle := fpOpen(Port, O_RDWR or O_NOCTTY);
(Where FHandle is a longint and port is '/dev/tty.usbserial-A400379A')

.. just locks up waiting ? (I've tried it on two Mac PPC machines now, both cross-compiled from my linux x86 install, and compiled natively on the MacOS box)

macppc:~/Pascal/Proploader user$ whoami
user
macppc:~/Pascal/Proploader user$ ls -la /dev/tty.usbserial-A400379A crw-rw-rw- 1 root wheel 9, 2 Sep 23 14:45 /dev/tty.usbserial-A400379A

I can put O_NONBLOCK in there and it will open, but then I have all sorts of problems talking to it. I really want it to block.

This works on Linux x86 and PPC, but this is the first time I've strayed into MacOS land.

Free Pascal Compiler version 2.2.3

Compiler Date : 2008/06/14
Compiler CPU Target: powerpc

Supported targets:
Linux for PowerPC
Mac OS for PowerPC
Darwin for PowerPC
NetBSD for PowerPC (under development)
MorphOS
AmigaOS for PowerPC

Supported CPU instruction sets:
604
750
7400
970

Supported FPU instruction sets:
SOFT
STANDARD

Supported Optimizations:
REGVAR
LOOPUNROLL
TAILREC

Obviously I'm doing something dumb, I just don't know how to debug it. No strace on MacOS.

Regards,
Brad

No, I can't tell you why this happens. Does the same happen if you do it in a C program?

Obviously I'm doing something dumb, I just don't know how to debug it. No strace on MacOS.

There's druss on Mac OS X 10.5.x and higher, and ktrace/kdump on Mac OS X 10.4.x and lower. The rosetta stone for Unix is your friend: http://bhami.com/rosetta.html

Jonas

Ok, I think I've found an obvious bug in rtl/unix/serial.pp.

tios.c_cflag is used to obtain the baudrate constant, but it's not then cleared before or'ing the other constants into it. Strangely enough this works on linux x86, but breaks badly in MacOS PPC.

This patch makes it work for me on Linux X86 and OSX PPC. I'm not sure about the side effect of existing users to adding the O_NONBLOCK in there, but this _must_ be in place for the port to open in MacOS if there is no carrier detect.

Personally I'm wrapping this in a class and using select() on the FD to tell if I can read/write.. I wonder if there would be any value in me adding blocking/nonblocking/timed read/write procedures to this unit?

Index: rtl/unix/serial.pp
=================================================================== --- rtl/unix/serial.pp (revision 11816)
+++ rtl/unix/serial.pp (working copy)
@@ -70,7 +70,7 @@

  function SerOpen(const DeviceName: String): TSerialHandle;
  begin
-  Result := fpopen(DeviceName, O_RDWR or O_NOCTTY);
+  Result := fpopen(DeviceName, O_RDWR or O_NOCTTY or O_NONBLOCK);
  end;
  procedure SerClose(Handle: TSerialHandle);
@@ -127,7 +127,7 @@
    tios.c_ispeed := tios.c_cflag;
    tios.c_ospeed := tios.c_ispeed;
-  tios.c_cflag := tios.c_cflag or CREAD or CLOCAL;
+  tios.c_cflag := CREAD or CLOCAL;

    case ByteSize of
      5: tios.c_cflag := tios.c_cflag or CS5;

Index: rtl/darwin/Makefile.fpc
=================================================================== --- rtl/darwin/Makefile.fpc (revision 11816)
+++ rtl/darwin/Makefile.fpc (working copy)
@@ -16,7 +16,7 @@
errors terminfo termio video crt mouse keyboard console \ variants dateutils convutils stdconvs \
sysconst cthreads strutils rtlconsts cwstring bsd fmtbcd \
- clocale
+ clocale serial
implicitunits=exeinfo

rsts=math varutils typinfo classes variants dateutils sysconst rtlconsts

Brad Campbell wrote

tios.c_cflag is used to obtain the baudrate constant, but it's not then cleared before or'ing the other constants into it. Strangely enough this works on linux x86, but breaks badly in MacOS PPC.

Uninitialised data often causes bugs like this.

This patch makes it work for me on Linux X86 and OSX PPC. I'm not sure about the side effect of existing users to adding the O_NONBLOCK in there, but this _must_ be in place for the port to open in MacOS if there is no carrier detect.

Are you certain that this doesn't simply depend on some particular configuration of the serial port? I'm not a serial programming expert, but I assume that this behaviour can be changed with the stty program or with some ioctl

Jonas

Nope.. ignore me, there is something more sinister going on. The code is correct..