Re: [fpc-devel] LoadLibrary and FPU control word
Because of no response I registered it as bug
http://bugs.freepascal.org/view.php?id=20011
Can you please look at least at this:
Which compiler defines are OK ? i386 or cpui386
My test shows, that i386 is NOT defined (cpui386 IS defined), but
then I do not understand how can it work in dynlibs.pas ???
BTW:
When I look at function SafeLoadLibrary in dynlibs.pas there is used :
{$ifdef i386}
w:=get8087cw;
When I look at function SafeLoadLibrary in SysUtils.inc there is used :
{$if defined(cpui386) or defined(cpux86_64)}
fpucw:=Get8087CW;
Which conditional is correct ? (i386 or cpui386)
Looking at
http://www.freepascal.org/docs-html/prog/progap7.html#x316-331000G ...
I see no i386 ?
And what FPUX87 ? Can not be used this ?
Thanks
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] serial under linux, SerOpen blocks
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
fine.
ttyUSB0 is:
crw-rw 1 root dialout 188, 0 Aug 18 09:37 /dev/ttyUSB0
changing it to
crw-rw-rw- 1 root dialout 188, 0 Aug 18 09:38 ttyUSB0
makes no difference. (my user id has the supplemental group dialout
added) SerOpen will always block if minicom is not started on the same
port, the same applies if i try it wit root.
stty with minicom started:
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;
time = 5;
-parenb -parodd cs8 hupcl -cstopb cread clocal crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon
ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
stty without mnicom started:
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;
time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
diff
time = 0; -clocal -crtscts -ixon -ixof
Fedora 14, 64 Bit
2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux
Thx
Armin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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
fine.
ttyUSB0 is:
crw-rw 1 root dialout 188, 0 Aug 18 09:37 /dev/ttyUSB0
changing it to
crw-rw-rw- 1 root dialout 188, 0 Aug 18 09:38 ttyUSB0
makes no difference. (my user id has the supplemental group dialout
added) SerOpen will always block if minicom is not started on the same
port, the same applies if i try it wit root.
stty with minicom started:
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;
time = 5;
-parenb -parodd cs8 hupcl -cstopb cread clocal crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon
ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
stty without mnicom started:
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;
time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop
-echoprt -echoctl -echoke
diff
time = 0; -clocal -crtscts -ixon -ixof
Fedora 14, 64 Bit
2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux
Assuming that you mean the standard serial.pp, that's not something I've
seen here /but/ I'm using a 32-bit kernel. I think that the first thing
I'd explore is whether you need the incoming control lines (cts, dsr,
cd) to be asserted before the function completes, but quite frankly if
I'm reading your
When i first start minicom on that port, SerOpen and all other
functions of serial.pp works fine.
correctly then it sounds like a kernel or driver issue.
Anybody: I've modified serial.pp to support Win-32 and fix a couple of
issues. Bug http://62.166.198.202/view.php?id=18946
--
Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk
[Opinions above are the author's, not those of his employers or colleagues]
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LoadLibrary and FPU control word
Fixed in r18255. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On Thu, Aug 18, 2011 at 1:57 AM, Graeme Geldenhuys graemeg.li...@gmail.comwrote: On 15 August 2011 10:48, Michael Schnell wrote: I never tried this, but I feel that IDEs (integrating code editor, GUI designer, make process, and debugger) have been invented for a purpose. I agree with all except the gui designer part. Layout Managers are by far the better choice compared to something like Delphi or Lazarus or MSEgui and even fpGUI's UI Designer gives. Java hit the nail on the head. Why define a UI with co-ordinates, then sit with problems like overlapping components, components that don't scale, locked to a specific DPI etc. For my projects in Delphi I did this with a control that was inspired by table layouts of HTML (I called it TControlAligner, it is a TGraphicControl descendant without own drawing, its bounds are used as a container). It has Controls property (TCollection descendant) and direction (vertical/horizontal). Every collection item has a reference to a control on the form (that can be simple control or another TControlAligner) and different properties. The main property of the item that affects the position is Cells which is either weight (equivalent of % of html tables) or pixels, and when all requirements is set and this TControlAligner is placed (or its bounds changed) it does the best it can do with all the requirements of the collections items (as with html tables where cells can require % of the width or exact pixels). Adding new aligners and using it for items of another aligner can build very complex layouts not using direct coordinates at all. Seems like the port of this component works in Lazarus. If the concept is worth considering I can provide the source for further review by the developers. Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 fine.
I don't use serial.pp but here is how I open a serial port for basic
communication (no flow control, modem control or stuff like that) under
linux. I remember this taking some experimentation to get right.
procedure tlserial.open;
var
fd : longint;
config : termios;
baudrateos : longint;
begin
fd := fpopen(device,O_RDWR or O_NOCTTY);
if isatty(fd)=0 then begin
writeln('not a tty');
halt(1);
end;
fillchar(config,sizeof(config),#0);
config.c_cflag := CLOCAL or CREAD;
cfmakeraw(config);
case baudrate of
50: baudrateos := B50;
75: baudrateos := B75;
110:baudrateos := B110;
134:baudrateos := B134;
150:baudrateos := B150;
200:baudrateos := B200;
300:baudrateos := B300;
600:baudrateos := B600;
1200: baudrateos := B1200;
1800: baudrateos := B1800;
2400: baudrateos := B2400;
4800: baudrateos := B4800;
9600: baudrateos := B9600;
19200: baudrateos := B19200;
38400: baudrateos := B38400;
57600: baudrateos := B57600;
115200: baudrateos := B115200;
230400: baudrateos := B230400;
else raise exception.create('unrecognised baudrate');
end;
cfsetispeed(config,baudrateos);
cfsetospeed(config,baudrateos);
config.c_cc[VMIN] := 1;
config.c_cc[VTIME] := 0;
if tcsetattr(fd,TCSAFLUSH,config) 0 then begin
writeln('could not set termios attributes');
halt(3);
end;
dup(fd);
closehandles := true;
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LoadLibrary and FPU control word
Thank you! Off-topic: It seems, that in my case (in ibase60.inc is used: uses Dynlibs, sysutils,ctypes; ) function SafeLoadLibrary defined in SysUtils hides SafeLoadLibrary used in DynLibs, this is reason, why SafeLoadLibrary worked as expected. So is i386 obsolete ? If yes there are other palaces, where it is used: rtl/linux/system.pp rtl/wince/wininc/defines.inc rtl/wince/wininc/struct.inc rtl/solaris/i386/sighndh.inc rtl/solaris/x86_64/sighndh.inc -Laco. Fixed in r18255. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 (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 fine.
I don't use serial.pp but here is how I open a serial port for basic
communication (no flow control, modem control or stuff like that)
under linux. I remember this taking some experimentation to get right.
procedure tlserial.open;
var
fd : longint;
config : termios;
baudrateos : longint;
begin
fd := fpopen(device,O_RDWR or O_NOCTTY);
if isatty(fd)=0 then begin
writeln('not a tty');
halt(1);
end;
fillchar(config,sizeof(config),#0);
config.c_cflag := CLOCAL or CREAD;
cfmakeraw(config);
case baudrate of
50: baudrateos := B50;
75: baudrateos := B75;
110:baudrateos := B110;
134:baudrateos := B134;
150:baudrateos := B150;
200:baudrateos := B200;
300:baudrateos := B300;
600:baudrateos := B600;
1200: baudrateos := B1200;
1800: baudrateos := B1800;
2400: baudrateos := B2400;
4800: baudrateos := B4800;
9600: baudrateos := B9600;
19200: baudrateos := B19200;
38400: baudrateos := B38400;
57600: baudrateos := B57600;
115200: baudrateos := B115200;
230400: baudrateos := B230400;else raise
exception.create('unrecognised baudrate');
end;
cfsetispeed(config,baudrateos);
cfsetospeed(config,baudrateos);
config.c_cc[VMIN] := 1;
config.c_cc[VTIME] := 0;
if tcsetattr(fd,TCSAFLUSH,config) 0 then begin
writeln('could not set termios attributes');
halt(3);
end;
dup(fd);
closehandles := true;
end;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 Peter suggested. Then disable O_NONBLOCK again with fcntl if you want blocking I/O back. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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: ',Handle);
if handle 0 then fpclose(handle);
end.
and exactly the same problem. fpopen blocks if minicom is not started on
the same port. I think i have to figure out how minicom (or stty) opens
the port.
btw, ttyUSB0 is a Prolific pl2303:
Aug 18 11:47:18 t41 kernel: [ 599.994081] usb 3-2: new full speed USB
device using uhci_hcd and address 2
Aug 18 11:47:18 t41 kernel: [ 600.140165] usb 3-2: New USB device
found, idVendor=067b, idProduct=2303
Aug 18 11:47:18 t41 kernel: [ 600.140180] usb 3-2: New USB device
strings: Mfr=1, Product=2, SerialNumber=0
Aug 18 11:47:18 t41 kernel: [ 600.140191] usb 3-2: Product: USB-Serial
Controller
Aug 18 11:47:18 t41 kernel: [ 600.140200] usb 3-2: Manufacturer:
Prolific Technology Inc.
Aug 18 11:47:18 t41 mtp-probe: checking bus 3, device 2:
/sys/devices/pci:00/:00:1d.1/usb3/3-2
Aug 18 11:47:18 t41 mtp-probe: bus: 3, device: 2 was not an MTP device
Aug 18 11:47:18 t41 kernel: [ 600.329041] usbcore: registered new
interface driver usbserial
Aug 18 11:47:18 t41 kernel: [ 600.329070] USB Serial support registered
for generic
Aug 18 11:47:18 t41 kernel: [ 600.329948] usbcore: registered new
interface driver usbserial_generic
Aug 18 11:47:18 t41 kernel: [ 600.329953] usbserial: USB Serial Driver core
Aug 18 11:47:18 t41 kernel: [ 600.345812] USB Serial support registered
for pl2303
Aug 18 11:47:18 t41 kernel: [ 600.346655] pl2303 3-2:1.0: pl2303
converter detected
Aug 18 11:47:18 t41 kernel: [ 600.358507] usb 3-2: pl2303 converter now
attached to ttyUSB0
Aug 18 11:47:18 t41 kernel: [ 600.359439] usbcore: registered new
interface driver pl2303
Aug 18 11:47:18 t41 kernel: [ 600.359445] pl2303: Prolific PL2303 USB
to serial adaptor driver
On 08/18/2011 10:22 AM, Mark Morgan Lloyd wrote:
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 fine.
ttyUSB0 is:
crw-rw 1 root dialout 188, 0 Aug 18 09:37 /dev/ttyUSB0
changing it to
crw-rw-rw- 1 root dialout 188, 0 Aug 18 09:38 ttyUSB0
makes no difference. (my user id has the supplemental group dialout
added) SerOpen will always block if minicom is not started on the
same port, the same applies if i try it wit root.
stty with minicom started:
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;
time = 5;
-parenb -parodd cs8 hupcl -cstopb cread clocal crtscts
ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
ixon ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase
-tostop -echoprt -echoctl -echoke
stty without mnicom started:
speed 19200 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^A; eol = undef;
eol2 = undef; swtch = undef; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1;
time = 0;
-parenb -parodd cs8 hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl
-ixon -ixoff -iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0
bs0 vt0 ff0
-isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase
-tostop -echoprt -echoctl -echoke
diff
time = 0; -clocal -crtscts -ixon -ixof
Fedora 14, 64 Bit
2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 x86_64
x86_64 x86_64 GNU/Linux
Assuming that you mean the standard serial.pp, that's not something
I've seen here /but/ I'm using a 32-bit kernel. I think that the first
thing I'd explore is whether you need the incoming control lines (cts,
dsr, cd) to be asserted before the function completes, but quite
frankly if I'm reading your
When i first start minicom on that port, SerOpen and all other
functions of serial.pp works fine.
correctly then it sounds like a kernel or driver issue.
Anybody: I've modified serial.pp to support Win-32 and fix a couple of
issues. Bug http://62.166.198.202/view.php?id=18946
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 that by disabling it with stty. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B19200
-opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
ioctl(3, TIOCMSET, [TIOCM_DTR|TIOCM_RTS]) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B19200
-opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B19200
-opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_START or SNDRV_TIMER_IOCTL_TREAD or TCSETS, {B19200
-opost -isig -icanon -echo ...}) = 0
ioctl(3, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS,
{B19200 -opost -isig -icanon -echo ...}) = 0
ioctl(3, TCFLSH, 0x2) = 0
should that be changed in the standard serial.pp ?
On 08/18/2011 11:51 AM, Henry Vermaak wrote:
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
Peter suggested. Then disable O_NONBLOCK again with fcntl if you want
blocking I/O back.
Henry
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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, setting params and reopening without nonblock ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 doesn't, the fcntl call disables it again. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 same in serial.pp should not change the blocking behaviour of serial.pp. function SerOpen(const DeviceName: String): TSerialHandle; begin Result := fpopen(DeviceName, O_RDWR or O_NOCTTY or O_NONBLOCK); // AD: O_NONBLOCK was missing if result -1 then fpfcntl(Result,F_SETFL,O_RDWR or O_NOCTTY); //AD: non blocking off again end; On 08/18/2011 12:21 PM, 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. Btw do you see minicom do a sequence of opening in nonblock, setting params and reopening without nonblock ? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 doing the same in serial.pp should not change the blocking behaviour of serial.pp. function SerOpen(const DeviceName: String): TSerialHandle; begin Result := fpopen(DeviceName, O_RDWR or O_NOCTTY or O_NONBLOCK); // AD: O_NONBLOCK was missing if result -1 then fpfcntl(Result,F_SETFL,O_RDWR or O_NOCTTY); //AD: non blocking off again Better use F_GETFL first, then flags = ~O_NONBLOCK, like minicom does. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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)); end; end; results in open(/dev/ttyUSB0, O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 10 fcntl(10, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE) fcntl(10, F_SETFL, O_RDWR|O_LARGEFILE) = 0 i think this should be changed in serial.pp On 08/18/2011 01:18 PM, Henry Vermaak wrote: 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 doing the same in serial.pp should not change the blocking behaviour of serial.pp. function SerOpen(const DeviceName: String): TSerialHandle; begin Result := fpopen(DeviceName, O_RDWR or O_NOCTTY or O_NONBLOCK); // AD: O_NONBLOCK was missing if result -1 then fpfcntl(Result,F_SETFL,O_RDWR or O_NOCTTY); //AD: non blocking off again Better use F_GETFL first, then flags = ~O_NONBLOCK, like minicom does. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 (not O_NONBLOCK)); end; end; results in open(/dev/ttyUSB0, O_RDWR|O_NOCTTY|O_NONBLOCK|O_LARGEFILE) = 10 fcntl(10, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE) fcntl(10, F_SETFL, O_RDWR|O_LARGEFILE) = 0 i think this should be changed in serial.pp 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? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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, 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. Henry ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] serial under linux, SerOpen blocks
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 unchanged? 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. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
RE : [fpc-devel] serial under linux, SerOpen blocks
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. ___ Apparently a bug in a recent usb serial kernel module pl2303: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/661321 Ludo ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: RE : [fpc-devel] serial under linux, SerOpen blocks
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. ___ Apparently a bug in a recent usb serial kernel module pl2303: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/661321 Well spotted :-) I was going to speculate that it might be something to do with the Prolific driver- I think that the device I use most is FTDI. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On Thursday, 18 August 2011, Max Vlasov wrote: Adding new aligners and using it for items of another aligner can build very complex layouts not using direct coordinates at all. Seems like the port of this component works in Lazarus. If the concept is worth considering I can provide the source for further review by the developers. MiGLayout went a step further. It is powerful enough to never need nested layout managers. Yet it's still possible to code complex forms with it. I once found a website where somebody took a popular app (I think firefox), and recreated all the forms using MiGLayout, just to show that it is possible and very simple to do, just with MiGLayout and no nesting. :-) Graeme. -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://fpgui.sourceforge.net ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi XE2 uses FPC for iOS target
On Thu, Aug 18, 2011 at 9:56 PM, Graeme Geldenhuys graemeg.li...@gmail.comwrote: On Thursday, 18 August 2011, Max Vlasov wrote: Adding new aligners and using it for items of another aligner can build very complex layouts not using direct coordinates at all. Seems like the port of this component works in Lazarus. If the concept is worth considering I can provide the source for further review by the developers. MiGLayout went a step further. It is powerful enough to never need nested layout managers. Yet it's still possible to code complex forms with it. I once found a website where somebody took a popular app (I think firefox), and recreated all the forms using MiGLayout, just to show that it is possible and very simple to do, just with MiGLayout and no nesting. :-) I glanced at the quick guide. Actually MiGLayout looks promising, but personally I'd use it if it's implemented with intuitiveness and visual sense in mind. Without doubt they should work and show rendered layout in design-time and all these dock west, gaps etc should be available as a context menu items or maybe some tool buttons. Otherwise if one have to learn the string constraint language, he can fall into the same trap as with regular expressions, I mean if you don't use them on a regular (ironic coincidence) basic, you learn them every time from the start :) Max ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Arm Thumb2 - Stellaris status
Did an analysis of the Stellaris current product lineup, there are over 180
current Stellaris products on TI's selection guide. Boiling through the FLASH
and RAM availability, there are 31 unique configuratios of FLASH / SRAM between
those 180 devices. So, the case() statements in t_embed.pas will have 31 more
entries to completely support the entire line of Stellaris processors (and a
few
more with products slated for future release).
Currently, everything is in a handful of giant arrays. Just wondering if it
would be better to switch to a record structure for the controller entries -
rather than individual arrays. (Add in a variety of STM parts and the other
manufacturers, and there could easily be over 100 memory configurations in the
table.)
Looking at RTL support. Currently for each ARM variant, they have a contoller
unit (the controllerunitstr entry). Inside the current controller units,
registers are defined. These registers definitions automatically become part
of the variable space of an application. Is the intent for ALL controller
registers be provided inside the RTL ? I would think this would be better
provided by outside files. (i.e. uses LM3S8962 - brings in a file
containing
all the 8962 register definitions.)
Having an outside file (it would be akin to a C header file - interface only
specifications for the registers, and that would be it) would be much clearer
than hiding the details inside a hidden file. If the user wants to chase
down
exactly where the definition is coming from, using a non-RTL file saves the
user
from having to dig through the compiler source to determine where it was coming
from. (Although for a newb, it may be preferable to have them automatigically
available.)
My suggestion would be that the register definitions come in an UNIT file that
only defines registers. The controller unit in the compiler source would only
provide the bare minimum necessary to bring the system up and call PASCALMAIN.
However, if it is deemed better to have the entire register set defined inside
the RTL - that would be fine too.
John
From: Florian Klämpfl flor...@freepascal.org
To: FPC developers' list fpc-devel@lists.freepascal.org
Sent: Tue, August 9, 2011 7:59:06 PM
Subject: Re: [fpc-devel] Arm Thumb2 - Stellaris status
Am 09.08.2011 17:04, schrieb Jeppe Græsdal Johansen:
On 09-08-2011 15:53, Geoffrey Barton wrote:
On 9 Aug 2011, at 14:14, John Clymer wrote:
I was thinking more of a generic controller class, including a
memory.def (or whatever one wants to name it) file. That would be
easiest as it would only effect the t_embed.pas file (and cpuinfo.pas
file to add the generic type.)
Haven't looked into possibly a compiler option (and may easily be
more trouble than a command line option):
{$ARM_FLASH_START }
{$ARM_FLASH_LENGTH }
{$ARM_SRAM_START }
{$ARM_SRAM_LENGTH }
But, I still think a static memory definition file would require the
least amount of code changes. And would only effect only the ARM
related files.
The compiler option works well when you have conditional options for
different target builds using ifdefs, which I do I lot. It makes it
very easy to see if it is in the source file as it can be locked to
other options and you only need to select it in one place.
A separate linker file starts to make FPC handle like any other
compiler :( instead of the joy to use it is :)
I agree. Keeping the configurations in code is easier to manage,
Yes. I think as well that everything should stick in the compiler. FPC
is open source, so no need for a convolution of compiler support and
external files. Full support of all devices will lead to a huge number
of interwinded include files in the rtl anyways.
compared to the spiderweb of magically named files of other embedded
compilers
I think that maybe creating an abstract class hierachy of chip families,
instead of the current solution of a single large case statement, would
be a better solution in the long run
Well, it can be done also by some sets like
controllers_stellaris128flash64ram. I don't think that a big full
fledged class hierary is needed. Even the case statement might be
sufficient.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
