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
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:
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
Fixed in r18255.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
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
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
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
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.
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
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
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
25 matches
Mail list logo
