Re: [fpc-pascal] Access to RS232 ports with fpc
In our previous episode, Holger Bruns said: > > The only way to get rid of this problem is a direct port access. But > direct port access is only possible for the first 200 port addresses. A > "port" array is not yet implemented, and the required higher port > addresses are strictly ruled out from every use through compiled fpc > programs. I do not understand this harsh policy. And I have no idea to > rule this policy out. If there is any possibility to get access to all > ports on the system without access error messages, please let me know. > If I need to alter the compiler, is there a patch available? Or should I > use gcc rather than fpc to match my ideas? > > The real sad thing is, that one cannot produce software for Linux, based > on the restricted free pascal compiler. I am really disappointed. WHere is this limitation? I'm not aware that FPC has a limitation that GCC hasn't. More probably it is an OS limitation, or do you need to ask permission for higher portnumbers with ioperm. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
There's nothing limited within the compiler! If you have the same knowledge and expertise of Pascal and C, IMHO with gcc you will only be complicating your life. About serial port, low level routine need some practice, but you can go quickly to the point with this component for lazarus: http://sourceforge.net/projects/cportlaz/ You get threaded data reception and even packet parsing with automatic event fire on a specific packet pattern. I am using it to develop hardware monitors which are running smoothly also on old fashioned hardware, so there's no packet loss or packet corruption. R# 2009/11/2 Holger Bruns : > Martin schrieb: >> >> Holger Bruns wrote: >>> >>> Jürgen Hestermann schrieb: > > function SerRead(Handle: TSerialHandle; var Buffer; Count: LongInt): > LongInt; > begin > Result := fpRead(Handle, Buffer, Count); > end; > i don't understand the declaration for "buffer" in the function below, > because no type is declared for "buffer". I believe that the type is irrelevant, you can use whatever you want. I think that it's just used by fpRead to buffer data. You only provide the space for the buffer but you don't need to read it directly. It seems that Count has to be the size of the buffer. But I am just guessing >>> >>> My hope was to read more than guessing. As I pointed out, the "buffer" >>> seems not to be filled with incoming data from the selected serial port. >>> Hence I cannot read just this data, and serread seems to be faulty. For this >>> reason I ask for an advice. I need to look on working sample code to use >>> this function in a working manner. In my example, serread replies only, what >>> has been written with serwrite right before. Not even serflush, executed >>> right after serwrite, can solve this problem to me. >> >> var foo; >> const foo; >> >> are hidden pointer types. >> That is foo would contain a pointer, but you never see this. You never >> have to get the address of something, and you never have to dereference it. >> >> As for using this: >> >> SerRead(Handle, Buffer, 0) >> >> Buffer must be the first byte of a block of memory >> >> you can do: >> var buffer: Array of byte; >> >> SetLength(Buffer, 1000); >> SerRead(Handle, Buffer[0], 1000); >> > > Hi Martin, > > I checked this out. It works not reliable. Sometimes I get real data, > sometimes the data are corrupted. I have no idea to rule out corrupted data. > I also tried to use the synaser unit, which can be found on the internet. > The demo code "sertest" crashes instantly. > > The only way to get rid of this problem is a direct port access. But direct > port access is only possible for the first 200 port addresses. A "port" > array is not yet implemented, and the required higher port addresses are > strictly ruled out from every use through compiled fpc programs. I do not > understand this harsh policy. And I have no idea to rule this policy out. If > there is any possibility to get access to all ports on the system without > access error messages, please let me know. If I need to alter the compiler, > is there a patch available? Or should I use gcc rather than fpc to match my > ideas? > > The real sad thing is, that one cannot produce software for Linux, based on > the restricted free pascal compiler. I am really disappointed. > > Best regards, Holger > > ___ > fpc-pascal maillist - fpc-pas...@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns wrote on Mon, 02 Nov 2009: Martin schrieb: you can do: var buffer: Array of byte; SetLength(Buffer, 1000); SerRead(Handle, Buffer[0], 1000); I checked this out. It works not reliable. Sometimes I get real data, sometimes the data are corrupted. I have no idea to rule out corrupted data. You have to check the result of the serread routine. Since it returns the result of the fpread call, "man 2 read" will tell you what those results mean. In short, a) result >= 0: actual number of bytes read (the 1000 you pass is just a maximum) b) result < 0: an error occurred Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] mail-slot
All the good days. Does free pascal implementation of the mail-slot (http://en.wikipedia.org/wiki/MailSlot) ? If yes, then if it works under windows and linux? Thanks in advance and sorry if the question too stupid:) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] mail-slot
On 02/11/2009, Alexey Voytsehovich wrote: > All the good days. Does free pascal implementation of the mail-slot > (http://en.wikipedia.org/wiki/MailSlot) ? I couldn't find any reference to MailSlot in the git commit logs, so I guess it doesn't have a MailSlot implementation. You can use Pipes or SimpleIPC as alternatives though. Both of these are implemented in Free Pascal -- Regards, - Graeme - ___ fpGUI - a cross-platform Free Pascal GUI toolkit http://opensoft.homeip.net/fpgui/ ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] memory mapped file
2009/11/2 Alexey Voytsehovich : > Hello Micha, > > Saturday, October 31, 2009, 2:39:19 PM, you wrote: > >> Alexey Voytsehovich wrote: >>> All the good days. >>> You can not tell what I need to read and/or study for solving >>> cross-platform (linux/windows) implementation of the memory mapped file? > >> On unix, it would be fpmmap. >> On windows, it would be CreateFileMapping/MapViewOfFile if I'm not mistaken. > > Thank you. But it will have to write my wrapper for these functions in > my program to use something the same way. That and I thought perhaps > someone had already written such a cross-platform wrapper for memory > mapped file for linux and windows platforms. That's why I said you should look at java/boost, because they already have a cross platform (at least linux/win) implementation for memory mapped files. This will give you an idea of the interface, at least. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Jürgen Hestermann schrieb: function SerRead(Handle: TSerialHandle; var Buffer; Count: LongInt): LongInt; begin Result := fpRead(Handle, Buffer, Count); end; i don't understand the declaration for "buffer" in the function below, because no type is declared for "buffer". Untyped parameters date back to early TurboPascal. http://www.freepascal.org/docs-html/ref/refsu48.html Variable and constant parameters can be untyped. In that case the variable has no type, and hence is incompatible with all other types. However, the address operator can be used on it, or it can be can passed to a function that has also an untyped parameter. If an untyped parameter is used in an assigment, or a value must be assigned to it, a typecast must be used. This can be used when you create a variable to use as a block of memory, for a buffer. The size of the buffer has to be known to the function, so it would typically be passed in as a parameter. I'd guess the reason for adding these to the language is that the caller has to have a variable to pass, so you are less likely to pass an invalid pointer, i.e. one which has not been set to point at allocated memory. FP ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Jonas Maebe schrieb: Holger Bruns wrote on Mon, 02 Nov 2009: Martin schrieb: you can do: var buffer: Array of byte; SetLength(Buffer, 1000); SerRead(Handle, Buffer[0], 1000); I checked this out. It works not reliable. Sometimes I get real data, sometimes the data are corrupted. I have no idea to rule out corrupted data. You have to check the result of the serread routine. Since it returns the result of the fpread call, "man 2 read" will tell you what those results mean. In short, a) result >= 0: actual number of bytes read (the 1000 you pass is just a maximum) b) result < 0: an error occurred Thank you. I checked this out, but every incoming character is interpreted as zero, regardless of its real value. Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Felipe Monteiro de Carvalho schrieb: It may be useful to know that there is a serial communication example using Synaser here: http://wiki.lazarus.freepascal.org/Hardware_Access#Serial_Communication Yes, thank you. I checked this out. The procedure reccvbyte, as used in this manner: Write(IntToHex(ser.RecvByte(1000), 2), ' '); reads every incoming character as zero. Simply, is does not work. It's much easier to use then using the lower level routines yourself. I try to implement a direct port access. If this also leads to access errors, I should give it up. Embarassing. Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns wrote on Mon, 02 Nov 2009: Felipe Monteiro de Carvalho schrieb: It may be useful to know that there is a serial communication example using Synaser here: http://wiki.lazarus.freepascal.org/Hardware_Access#Serial_Communication Yes, thank you. I checked this out. The procedure reccvbyte, as used in this manner: Write(IntToHex(ser.RecvByte(1000), 2), ' '); reads every incoming character as zero. Simply, is does not work. Are you certain that your serial port is actually configured correctly? Many people have successfully used these units in the past, so it most likely seems like a configuration or usage problem. Moreover, the serread function you posted earlier is about as low level as you can get: it directly reads bytes from a handle using a system call. If that never works, then the problem is almost certainly completely unrelated to anything FPC. You may also want to post the complete test program that you are using, maybe there is an error somewhere. I try to implement a direct port access. If this also leads to access errors, I should give it up. Embarassing. Please stop complaining in virtually every reply to people trying to help you. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns schrieb: I try to implement a direct port access. If this also leads to access errors, I should give it up. Embarassing. Accessing ports is limited to ports < 03ffh, more ports cannot be released with fpioperm. This means to me, successful serial port access on higher addresses cannot yet be implemented with fpc. If this policy can be ruled out, let me know. Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns schrieb: > Holger Bruns schrieb: >> I try to implement a direct port access. If this also leads to access >> errors, I should give it up. Embarassing. > Accessing ports is limited to ports < 03ffh, more ports cannot be > released with fpioperm. This means to me, successful serial port access > on higher addresses cannot yet be implemented with fpc. If this policy > can be ruled out, let me know. This has nothing to do with fpc. Maybe you should read the ioperm man page and you might start to understand things. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns wrote on Mon, 02 Nov 2009: Accessing ports is limited to ports < 03ffh, more ports cannot be released with fpioperm. This means to me, successful serial port access on higher addresses cannot yet be implemented with fpc. If this policy can be ruled out, let me know. fpioperm directly passes whatever parameters you give it to the Linux kernel. If the kernel refuses you access to those ports, there is nothing FPC can do about that. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Florian Klaempfl schrieb: Holger Bruns schrieb: Holger Bruns schrieb: I try to implement a direct port access. If this also leads to access errors, I should give it up. Embarassing. Accessing ports is limited to ports < 03ffh, more ports cannot be released with fpioperm. This means to me, successful serial port access on higher addresses cannot yet be implemented with fpc. If this policy can be ruled out, let me know. This has nothing to do with fpc. Maybe you should read the ioperm man page and you might start to understand things. I am new to linux and wrote only small things for MS-DOS before. As far as I could read on the internet, fpc uses ioperm and iopl, and I will try to use iopl to get access to the ports I want to use. The problem is indeed the rights management, as far as I can read on several web pages, which addresses my technical problem. The rights management cannot be ruled out by an application like I intend to write. But I can deal with it, I hope so far. My posts to this list are not written against any person. My problem is not an interpersonal problem, but a technical question, and I try to find a good answer to it. Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns wrote: Holger Bruns schrieb: I try to implement a direct port access. If this also leads to access errors, I should give it up. Embarassing. Accessing ports is limited to ports < 03ffh, more ports cannot be released with fpioperm. This means to me, successful serial port access on higher addresses cannot yet be implemented with fpc. If this policy can be ruled out, let me know. so you must use a very special serial hardware which is located on io address higher than $3ff. Seems unlikely to me. In your former post, you tried to access io address 1000 (decimal) this is $3e8 (hexadecimal) and should be an ordinary COM3. May be you are mixing up decimal vs. hexadecimal notation. Regards, Bernd. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Bernd Mueller schrieb: Holger Bruns wrote: Holger Bruns schrieb: I try to implement a direct port access. If this also leads to access errors, I should give it up. Embarassing. Accessing ports is limited to ports < 03ffh, more ports cannot be released with fpioperm. This means to me, successful serial port access on higher addresses cannot yet be implemented with fpc. If this policy can be ruled out, let me know. so you must use a very special serial hardware which is located on io address higher than $3ff. Seems unlikely to me. In your former post, you tried to access io address 1000 (decimal) this is $3e8 (hexadecimal) and should be an ordinary COM3. May be you are mixing up decimal vs. hexadecimal notation. No, the "1000" means the size of a buffer, not a part address. The port address I try to use is 0xEC00, which is the base address for an UART on a PCI card. Linux sees this UART as /dev/ttyS2. Accessing the registers direcly should be easy, because 3 lines of assembler code should do this job: function readport (portaddress: word): byte; begin asm mov %dx, portaddress inb %al,%dx mov readport, %al end end; As long as the pascal syntax and the assembler syntax (instruction destination source) are both correct for fpc, this function should return the value of the selected port. This is all, what I try to do. Best regards, Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
> No, the "1000" means the size of a buffer, not a part address. The port > address I try to use is 0xEC00, which is the base address for an UART on a > PCI card. Linux sees this UART as /dev/ttyS2. Accessing the registers > direcly should be easy, because 3 lines of assembler code should do this > job: > > function readport (portaddress: word): byte; > begin > asm > mov %dx, portaddress > inb %al,%dx > mov readport, %al > end > end; > > As long as the pascal syntax and the assembler syntax (instruction > destination source) are both correct for fpc, this function should return > the value of the selected port. This is all, what I try to do. > > > Best regards, Holger > Just user synaser, http://www.synapse.ararat.cz/ . When you get the thing working, go back to the serial unit. I do SCADA with Modbus through serial port. Never had a problem. You can't write programs in linux (or windows) like in DOS. Gustavo ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Something I discovered using "Hint" directives.
Hi, FPC 2.2.4 refers. Two of the four hint directives listed on page 11 of the Reference Guide for Free Pascal, version 2.2.4 don't work as described in the manual. The "Experimental" directive causes the compiler to stop with a syntax error. The example program listed on page 11 doesn't compile because of the "Experimental" directive. The "Unimplemented" directive seems to be ignored. (This directive is mis-spelt in the manual, but this, I am quite sure, is not the cause of the compile time error). Are these known issues? The directives listed on page 11 of the manual issue warnings during compilation. Why are they refered to as "Hint" directives? Regards, Nino ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Some more units
Hi, I decided to use iopl and portread to address my idea on accessing ports on addresses above 0x3ff. Sadly, these units are not compiled yet, but the sourcecode is available. I still have no luck at all. Pointing fpc to x86.pp leads to an error message. The compiler misses an include file. Once the include file has been added to the desired directory, another file is missed instead, it reminds me to a chain reaction. How can I get the missed units compiled? Should I copy every delivered source file in one directory, or is there a more convenient way to deal with this problem? I tried to use make, but make also replies with error messages. Regards, Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Am Montag, den 02.11.2009, 15:20 +0100 schrieb Holger Bruns:
> I am new to linux and wrote only small things for MS-DOS before. As far
> as I could read on the internet, fpc uses ioperm and iopl, and I will
> try to use iopl to get access to the ports I want to use. The problem is
> indeed the rights management, as far as I can read on several web pages,
> which addresses my technical problem. The rights management cannot be
> ruled out by an application like I intend to write. But I can deal with
> it, I hope so far.
The best things you can do are to:
- Search the web for a freely available document called:
"Serial Programming Guide for POSIX Oaperating Systems"
This document shows you how to set up serial ports on Linux, the most
important part when you cann open the port but not send or receive
anything meaningful.
- Use the device the system gives you. ANything else is aking for
trouble (IMHO).
If you can access and use the hardware port in question at all, maybe
connecting a mouse or something, it will work in your fpc programs.
> My posts to this list are not written against any person. My problem is
> not an interpersonal problem, but a technical question, and I try to
> find a good answer to it.
Some more examples (shortened from real code for showing the principle):
sDefaultPort: string = '/dev/cuaa0'; { this would be /dev/ttyS2 for you }
fPort = sDefaultPort;
{ Init }
fCom := SerOpen(fPort);
if (fCom > -1) then begin
SerSetParams(fCom, 1200, 7, NoneParity, 2, []);
end else begin
writeln('Metex: failed to open port');
n := GetLastOSError;
end
{ Reading }
var
inbuf: array[0..14] of char;
begin
fillchar(inbuf, sizeof(inbuf), #0);
res := SerRead(fCom, inbuf[0], 14); { last figure would be 1000 for you,
bytes to read }
if (res < 0) then
{ signal error }
...
That way I use serial ports successfully on FreeBSD and Windows.
HTH,
Marc
--
Marc Santhoff
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] using softfloat on i386
Hi, after finding the floating point calculations implementation for fpc[1] I'm asking myself if it is possible to force fpc to use it although the CPU does actually have a FPU built in. How can this be done? [1] /usr/home/marc/fpc-2.2.2/share/src/fpc-2.2.2/rtl/inc/softfpu.pp -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] cross compiling x64_64 to i386 linux
I'm trying to cross-compile on Ubuntu 9.10 x86_64 for i386. Here's what I've done so far: I got FPC from the fixes_2_4 branch in SVN and did make/make install. I used samplecfg to generate /etc/fpc/fpc.cfg. I followed the wiki (http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux) and did the steps listed there, including creating the i386-linux-ld and i386-linux-ls scripts in /usr/bin and compiling for the i386 target, so I ended up with a ppc386. At this point I could do a simple "hello world" program which would generate a 64-bit binary if i selected x86_64 for the target in lazarus under "Compiler Options | Code" and a 32-bit binary if i selected i386 as the target. So far so good. I then tried to compile something a bit more complicated (not that much more, though: I just tried to include "cthreads") and I got an error about crti.so not being found: /usr/bin/ld: skipping incompatible /usr/lib/crti.o when searching for /usr/lib/crti.o /usr/bin/ld: cannot find /usr/lib/crti.o build.lpr(16,1) Error: Error while linking As the Wiki is extremely vague as to what to do for fpc.cfg (Sorry, but "Edit your /etc/fpc.cfg file if needed" is not very useful), I did change this line: #-Fl/lib;/usr/lib to -Fl/lib;/usr/lib;-Fl/lib32;/usr/lib32 However, to no avail. However, I did discover that /usr/lib32 doesn't even have crti.o, so a little more investigation made me realize I needed to install the "libc6-dev-i386" package, after which I did, in fact, have that file. However, I'm still unable to compile a 32-bit executable that includes "cthreads" in its uses clause. ld still complains about not being able to find crti.o, despite my having added /usr/lib32 to the -Fl line of my fpc.cfg. I do have this in my fpc.cfg: == # set binutils prefix #IFNDEF CPUI386 #IFNDEF CPUAMD64 #DEFINE NEEDCROSSBINUTILS #ENDIF #ENDIF #IFNDEF linux #DEFINE NEEDCROSSBINUTILS #ENDIF #IFDEF FPC_CROSSCOMPILING #IFDEF NEEDCROSSBINUTILS -XP$fpctarget- #ENDIF NEEDCROSSBINUTILS #ENDIF == but I don't know if that's correct or whatever, that's just what samplecfg generated. Observe: compiling for 64-bit == $ /usr/local/bin/fpc -MObjFPC -Scgi -O1 -gl -vewnhi -l -Fu. -obuild build.lpr Hint: Start of reading config file /etc/fpc.cfg Hint: End of reading config file /etc/fpc.cfg Free Pascal Compiler version 2.3.1 [2009/11/02] for x86_64 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for x86-64 Compiling build.lpr Linking build ld here i am ld.real: warning: link.res contains output sections; did you forget -T? 17 lines compiled, 0.2 sec 2 hint(s) issued == attempting to compile for 32-bit == $ /usr/local/bin/fpc -Pi386 -MObjFPC -Scgi -O1 -gl -vewnhi -l -Fu. -obuild build.lpr Hint: Start of reading config file /etc/fpc.cfg Hint: End of reading config file /etc/fpc.cfg Free Pascal Compiler version 2.3.1 [2009/11/02] for i386 Copyright (c) 1993-2009 by Florian Klaempfl Target OS: Linux for i386 Compiling build.lpr Linking build ld: warning: link.res contains output sections; did you forget -T? ld: skipping incompatible /usr/lib/crti.o when searching for /usr/lib/crti.o ld: cannot find /usr/lib/crti.o build.lpr(16,1) Error: Error while linking build.lpr(16,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you did not specify a source file to be compiled) == I sort of think that /usr/bin/i386-linux-ld isn't being called. I added an "echo here I am" sort of line to that bash script, and I never see that echo happen. I'm sure there's some magic I need to do in my fpc.cfg file, but I'm having a hard time finding specifically what it is. I'd really like to be able to compile for x86_64 and i386 in the same development environment simply by selecting a different target from the Lazarus UI and have it "just work." If anyone can offer assistance, I'd surely appreciate it. -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns : > Accessing ports is limited to ports < 03ffh, more ports cannot be > released with fpioperm. This means to me, successful serial port access > on higher addresses cannot yet be implemented with fpc. Or any other compiler, for that matter, because this is a system restriction. Plus, it's Linux-only, it's i386-only, it's pure legacy and thus should not even be used anymore. > If this policy can be ruled out, let me know. If you want to access ports directly, compile for DOS or write a device driver. Vinzent. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: cross compiling x64_64 to i386 linux
Okay, in further investigation I am now manually forcing fpc to use i386-linux-ld for linking by using the "-Pi386 -XPi386-linux-" compiler flags (-P for the target and -XP for the binutils prefix). I assume there's something wrong in my fpc.cfg or it would do this manually, but I don't know what it is. Still, at least I'm getting i386-linux-ld to be called. However, ld is still not searching /usr/lib32. I also tried manually adding -Fl/usr/lib32 to the fpc command line but that didn't help. So apparently I have to somehow tell ld to look there... -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com On Mon, Nov 2, 2009 at 12:45 PM, Seth Grover wrote: > I'm trying to cross-compile on Ubuntu 9.10 x86_64 for i386. Here's > what I've done so far: > > I got FPC from the fixes_2_4 branch in SVN and did make/make install. > > I used samplecfg to generate /etc/fpc/fpc.cfg. > > I followed the wiki > (http://wiki.lazarus.freepascal.org/Cross_compiling#To_Linux) and did > the steps listed there, including creating the i386-linux-ld and > i386-linux-ls scripts in /usr/bin and compiling for the i386 target, > so I ended up with a ppc386. > > At this point I could do a simple "hello world" program which would > generate a 64-bit binary if i selected x86_64 for the target in > lazarus under "Compiler Options | Code" and a 32-bit binary if i > selected i386 as the target. So far so good. > > I then tried to compile something a bit more complicated (not that > much more, though: I just tried to include "cthreads") and I got an > error about crti.so not being found: > > /usr/bin/ld: skipping incompatible /usr/lib/crti.o when searching for > /usr/lib/crti.o > /usr/bin/ld: cannot find /usr/lib/crti.o > build.lpr(16,1) Error: Error while linking > > As the Wiki is extremely vague as to what to do for fpc.cfg (Sorry, > but "Edit your /etc/fpc.cfg file if needed" is not very useful), I did > change this line: > > #-Fl/lib;/usr/lib > > to > > -Fl/lib;/usr/lib;-Fl/lib32;/usr/lib32 > > However, to no avail. However, I did discover that /usr/lib32 doesn't > even have crti.o, so a little more investigation made me realize I > needed to install the "libc6-dev-i386" package, after which I did, in > fact, have that file. > > However, I'm still unable to compile a 32-bit executable that includes > "cthreads" in its uses clause. ld still complains about not being able > to find crti.o, despite my having added /usr/lib32 to the -Fl line of > my fpc.cfg. > > I do have this in my fpc.cfg: > == > # set binutils prefix > > #IFNDEF CPUI386 > #IFNDEF CPUAMD64 > #DEFINE NEEDCROSSBINUTILS > #ENDIF > #ENDIF > > > #IFNDEF linux > #DEFINE NEEDCROSSBINUTILS > #ENDIF > > > #IFDEF FPC_CROSSCOMPILING > #IFDEF NEEDCROSSBINUTILS > -XP$fpctarget- > #ENDIF NEEDCROSSBINUTILS > #ENDIF > == > > but I don't know if that's correct or whatever, that's just what > samplecfg generated. > > Observe: > compiling for 64-bit > == > $ /usr/local/bin/fpc -MObjFPC -Scgi -O1 -gl -vewnhi -l -Fu. -obuild build.lpr > Hint: Start of reading config file /etc/fpc.cfg > Hint: End of reading config file /etc/fpc.cfg > Free Pascal Compiler version 2.3.1 [2009/11/02] for x86_64 > Copyright (c) 1993-2009 by Florian Klaempfl > Target OS: Linux for x86-64 > Compiling build.lpr > Linking build > ld here i am > ld.real: warning: link.res contains output sections; did you forget -T? > 17 lines compiled, 0.2 sec > 2 hint(s) issued > == > > attempting to compile for 32-bit > == > $ /usr/local/bin/fpc -Pi386 -MObjFPC -Scgi -O1 -gl -vewnhi -l -Fu. > -obuild build.lpr > Hint: Start of reading config file /etc/fpc.cfg > Hint: End of reading config file /etc/fpc.cfg > Free Pascal Compiler version 2.3.1 [2009/11/02] for i386 > Copyright (c) 1993-2009 by Florian Klaempfl > Target OS: Linux for i386 > Compiling build.lpr > Linking build > ld: warning: link.res contains output sections; did you forget -T? > ld: skipping incompatible /usr/lib/crti.o when searching for /usr/lib/crti.o > ld: cannot find /usr/lib/crti.o > build.lpr(16,1) Error: Error while linking > build.lpr(16,1) Fatal: There were 1 errors compiling module, stopping > Fatal: Compilation aborted > Error: /usr/local/bin/ppc386 returned an error exitcode (normal if you > did not specify a source file to be compiled) > == > > I sort of think that /usr/bin/i386-linux-ld isn't being called. I > added an "echo here I am" sort of line to that bash script, and I > never see that echo happen. > > I'm sure there's some magic I need to do in my fpc.cfg file, but I'm > having a hard time finding specifically what it is. I'd really like to > be able to compile for x86_64 and i386 in the same development > environment simply by selecting a different target from the Lazarus U
Re: [fpc-pascal] Re: cross compiling x64_64 to i386 linux
In our previous episode, Seth Grover said: > Okay, in further investigation I am now manually forcing fpc to use > i386-linux-ld for linking by using the "-Pi386 -XPi386-linux-" > compiler flags (-P for the target and -XP for the binutils prefix). I > assume there's something wrong in my fpc.cfg or it would do this > manually, but I don't know what it is. Still, at least I'm getting > i386-linux-ld to be called. > > However, ld is still not searching /usr/lib32. I also tried manually > adding -Fl/usr/lib32 to the fpc command line but that didn't help. > > So apparently I have to somehow tell ld to look there... You might have to tell it simply NOT to look in /usr/lib E.g. like described in paragraph 3.4.1 of the buildfaq: http://www.stack.nl/~marcov/buildfaq.pdf ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does GetLastError in WinCE work? NO answer??
Is this the wrong forum?
Can anybody help with my question? If I should send it to another forum,
please
tell me which one.
Thanks
epergola wrote:
>
> Hello
> I get strange results form GetLasError in WinCe;
> something like 1449435930, for example;
>
> I use this:
> {$include d:\lazarus\fpc\2.2.4\source\rtl\wince\wininc\coredll.inc}
> function GetLastError:DWORD; external KernelDLL name 'GetLastError';
>
> var
> err: dword;
>
> begin
> MutexHandle := CreateMutex(NIL, TRUE, 'xxx');
> err:= GetCeError;
> if err = ERROR_ALREADY_EXISTS THEN BEGIN
> SetForegroundWindow(FindWindow('xxx', ''));
> CloseHandle(MutexHandle);
> Application.BringToFront;
> END ELSE BEGIN
> .
> Am I missing something?
> Why do I get those huge values from GetLastError?
> Thanks for any help
>
--
View this message in context:
http://old.nabble.com/Does-GetLastError-in-WinCE-work--tp26124267p26157812.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] x86.pp and oldlinux.pp
Hi, I decided to copy all the necessary files for x86.pp and oldlinux.pp into one directory for compiling these two units. This compilation failed due to syntax errors. A bunch of warnings also appeared. I post only the syntax error messages: oldlinux.pp(1696,2) Error: User defined: Cannot decide which processor you have ! define cpui386 or m68k oldlinux.pp(3831,29) Error: Incompatible type for arg no. 1: Got "Constant String", expected "LongInt" oldlinux.pp(3834,32) Error: Incompatible type for arg no. 1: Got "Constant String", expected "LongInt" oldlinux.pp(5902,1) Fatal: Syntax error, "ASM" expected but "INITIALIZATION" found x86.pp(192,23) Error: Asm: 16 or 32 Bit references not supported x86.pp(207,23) Error: Asm: 16 or 32 Bit references not supported x86.pp(222,24) Error: Asm: 16 or 32 Bit references not supported Some nice warnings nevertheless: x86.pp(237,6) Warning: Register list is ignored for pure assembler routines x86.pp(247,6) Warning: Register list is ignored for pure assembler routines x86.pp(256,6) Warning: Register list is ignored for pure assembler routines And now? It seems to be hard to get this working. Debugging source code, which produces long lists of errors and warnings while compiling is a time consuming piece of work. Is there an alternative out there? Regards, Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Something I discovered using "Hint" directives.
fpcl...@silvermono.co.za wrote: Two of the four hint directives listed on page 11 of the Reference Guide for Free Pascal, version 2.2.4 don't work as described in the manual. Actually there are 5 hint directives: platform, library, unimplemented, experimental and deprecated. The "Experimental" directive causes the compiler to stop with a syntax error. The example program listed on page 11 doesn't compile because of the "Experimental" directive. The "Unimplemented" directive seems to be ignored. (This directive is mis-spelt in the manual, but this, I am quite sure, is not the cause of the compile time error). Are these known issues? Have you tried with the trunk compiler? Last time I tried all 5 worked fine. The only thing is that the library directive showed no warning but this is fixed now. Best regards, Paul Ishenin. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Marc Santhoff schrieb:
sDefaultPort: string = '/dev/cuaa0'; { this would be /dev/ttyS2 for you }
fPort = sDefaultPort;
{ Init }
fCom := SerOpen(fPort);
if (fCom > -1) then begin
SerSetParams(fCom, 1200, 7, NoneParity, 2, []);
end else begin
writeln('Metex: failed to open port');
n := GetLastOSError;
end
{ Reading }
var
inbuf: array[0..14] of char;
begin
fillchar(inbuf, sizeof(inbuf), #0);
res := SerRead(fCom, inbuf[0], 14); { last figure would be 1000 for you,
bytes to read }
if (res < 0) then
{ signal error }
...
That way I use serial ports successfully on FreeBSD and Windows.
This helps a lot. Thank you. This was the example I was looking for. My
fault was the declaration of inbuffer: array of char, and I guess, I did
not understand how to deal with hidden pointers. Now I've got this idea
from you and hope so far, I can move on.
Best regards, Holger
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] x86.pp and oldlinux.pp
Holger Bruns wrote on Tue, 03 Nov 2009: I decided to copy all the necessary files for x86.pp and oldlinux.pp into one directory for compiling these two units. This compilation failed due to syntax errors. A bunch of warnings also appeared. I post only the syntax error messages: You appear to be compiling for x86_64 (please mention your full build configuration in the future, until now I thought your were working on i386). The reason that we do not ship a compiled version of the oldlinux unit for x86_64 is that it simply does not work on 64 bit platforms. Hence all the errors you are getting when trying to compile it anyway. The reason that oldlinux is not support for 64 bit platforms is that, as the name implies, it is no longer maintained and hence only works on the platforms that were supported when it was written (being i386 and m68k). It is full of code specific to those two platforms and hence unportable by design. In fact, the last time we shipped a compiled version of the oldlinux unit for any platform was with 2.0.4 (released 3 years ago). It is simply no longer supported, and the source only included for people who might have legacy projects depending on it (or because nobody bothered yet to delete it from svn). The x86 unit was not yet adapted for x86_64 in FPC 2.2.4, hence why a) a compiled version was not included in the distribution b) you get errors when trying to compile it anyway The next release of FPC will include a version of the x86 unit for Linux/x86_64. In general, if a unit is not available in a precompiled version for your platform, the reason is that it does not work. Unless you intend to fix/rewrite that unit for your platform, trying to force the compiler to compile it anyway will not help you. Jonas This message was sent using IMP, the Internet Messaging Program. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Holger Bruns wrote: The real sad thing is, that one cannot produce software for Linux, based on the restricted free pascal compiler. I am really disappointed. That's an interesting assertion. I use serial.pp on i386 Linux, x86_64 Linux, PPC OSX & Intel OSX flawlessly. I use synaser on Win32. I suspect you might be doing something wrong, but with the complete lack of information provided about what you are doing and how you are doing it there is just no way to help you. Why not try attaching your test code that is failing so we can help you get it working? Brad -- Dolphins are so intelligent that within a few weeks they can train Americans to stand at the edge of the pool and throw them fish. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] x86.pp and oldlinux.pp
Jonas Maebe schrieb: Holger Bruns wrote on Tue, 03 Nov 2009: I decided to copy all the necessary files for x86.pp and oldlinux.pp into one directory for compiling these two units. This compilation failed due to syntax errors. A bunch of warnings also appeared. I post only the syntax error messages: You appear to be compiling for x86_64 (please mention your full build configuration in the future, until now I thought your were working on i386). The reason that we do not ship a compiled version of the oldlinux unit for x86_64 is that it simply does not work on 64 bit platforms. Hence all the errors you are getting when trying to compile it anyway. Yes, I tried to compiling missed units for x86_64. The next release of FPC will include a version of the x86 unit for Linux/x86_64. In general, if a unit is not available in a precompiled version for your platform, the reason is that it does not work. Unless you intend to fix/rewrite that unit for your platform, trying to force the compiler to compile it anyway will not help you. This means, you deliver these units for documentation purposes only, I guess. Now I am waiting für your next release, and I am really curious to look at your new code for x86 on x86_64 platforms. Best regards, Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Access to RS232 ports with fpc
Brad Campbell schrieb: Why not try attaching your test code that is failing so we can help you get it working? Done. My fault was the following declaration: var inbuffer: array of char; This is a better declaration: var inbuffer: array[0..10] of char; Now I got my code working. Hidden pointers are new to me. Therefore I felt in trouble with it. Secondly, it appears to be necessary to use the fpc compiler as "root", not simply as a user, I guess. Best regards, Holger ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
