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

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.

Yes, I tried to compiling missed units for x86_64.

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

In our previous episode, Holger Bruns said:

- Stop dragging out sources, this unnecessarily complicates the picture. All units are installed precompiled, if it doesn't install, check your installation.
- Don't use oldlinux, it is deprecated and removed for a reason.

- unit x86 is compiled nightly, so should generally compile, if it doesn't compile, there should be a special situation, and please state your compiler version and target.

Holger Bruns wrote on Tue, 03 Nov 2009:

No, it means that the x86 unit is only supported on i386 in FPC 2.2.4 (we do install a compiled version of that unit when installing the i386 compiler).

And regarding your later remark about FPC only being usable as root: it's the Linux kernel that only allows direct port access by root. Please stop blaming every single one of your problems on the compiler or the RTL.

Jonas

---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Under the bottom line, the result is just the same. You need to become a superuser on a linux system, if you want to compile source code for accessing ports directly, regardless of the compiler or any other tool. This is not blaming your software as faulty, it's just a remark on a linux restriction. Secondly, having problems with a programming language is not a sign for a bad compiler. One can misunderstand some expressions, can produce errors, needs to learn more about programming. I do not blame your work, I appreciate it instead, and I am using fpc. I am pretty sure, the longer I work with it, the more I shall become familiar with it. Todays pascal is far more advanced than turbo pascal from Borland or UCSD pascal on the old Apple II, and now I have to learn pascal just as a programming language, which I would see the first time in my life.

Holger

Holger Bruns wrote

Under the bottom line, the result is just the same. You need to become a superuser on a linux system, if you want to compile source code for accessing ports directly, regardless of the compiler or any other tool.

All modern OS's have this restriction. Even on Windows, after ME (NT, XP and beyond) you cannot directly access ports anymore, like in the good old days with TP (and even those programs won't run on modern Windows machines). To do so under Linux, you need to write a device driver that then exposes an interface to the userland application. This is usually done in C. There are several books available about writing device drivers under Linux. If your device is simple, like a UART, you can probably easily adapt one of the examples to your use. However, it sounds like your device is already supported (as /dev/ttyS2), so you shouldn't need to do this, unless you are doing non-standard things with the UART (maybe using the control signals for I/O that needs more precise timing than you can get through the ioctl mechanism, or something similar). Yes, it is much harder than in the old days of DOS or Win98, but it is the proper way to do things.

Jeff.

2009/11/3 Holger Bruns :

If you need to be root to run or compile your program, then you don't understand the underlying operative system. Please, take a look at how devices works in linux, or take a look at this
http://www.linuxjournal.com/article/2114 . Linux is not DOS, you can't just write to ports.

Accessing serial ports in linux could be as simple as to write/read to/from /dev/ttySx . You don't need io ports. For a multiplatform solution, use synapsis/synaser.

Gustavo

ps: Excuse my english. Helping you is very hard: you don't listen.

Sometimes it is useful to get more information about device drivers. Searching the internet for that information is pretty difficult, because there is no detailed description available, as far as I see. The first hit on google points to a website for "device detectives". If I intend to use device drivers, I need to know how to access the ports of a device, which means in my case to a serial port based on the 16550D Universal Asynchronous Receiver/Transmiter with FIFOs. I need to read and write every register of that UART as explained in the National Semiconductor databook, register by register, address by address. No information on that topic seems to be available, but a whole bunch of useless idle talk and advertisement.

Hence I cannot use /dev/ttySx for accessing serial devices.

The only way to use serial ports successfully to me, is to use the unit serial on fpc, if I choose fpc to deal with serial ports. Another problem results from misleading comments on the implemented procedures and functions. As explained, seropen would return a zero, if a device cannot be found. For real, seropen returns a zero, if this device is found, and -1, if not.

Under the bottom line, it is embarrassing time consuming for a newbie like me, to work successfully with serial ports on linux.

ps: Excuse my english. Helping you is very hard: you don't listen.

On a mailing list, I can only read and write. ;-)

Best regards, Holger

Holger,

Here is a very simple serial example using FPC and SynaSer: http://www.turbocontrol.com/simpleserial.htm

Hope that is of some help.

Paul

www.dpReplication.com
www.TurboControl.com

Holger,

Here is a very simple serial example using FPC and SynaSer: http://www.turbocontrol.com/simpleserial.htm

Hope that is of some help.

Paul

www.dpReplication.com
www.TurboControl.com

Thank you. I have already solved the problem to access serial ports, but I am rather clueless while dealing with device drivers like /dev/ttyS0 on linux. My question is, what do I grab while reading from a device driver file like /dev/ttyS0? How can I deal with it?

Best regards, Holger

I'll follow your link.

I don't understand a programming language as a tool to override an operating system. This is not my goal. I ask for some clues to deal with ports and UART devices already connected to a computer.

And insulting comments like "Under the bottom line, it is embarrassing time consuming for a newbie like me, to work successfully with serial ports on linux." directed to the FPC list won't change that either.

I don't understand this quote as insulting. A newbie on programming languages must learn how to write working code. This is always time consuming even on computers with less restrictions. Thanks to Marc Santhoff, I have got working sample code to use the serial unit successfully. But I need to mention, the comments on procedures in this unit are not error free. Despite to these comments the procedure "seropen" returns -1, if a serial port cannot be found, and not zero.

My small selfwritten functions on serial ports are working now.

Holger

Von: Holger Bruns :

If I intend to use device drivers, I need to know how to access the ports of a device, which means in my case to a serial port based on the 16550D Universal Asynchronous Receiver/Transmiter with FIFOs.

No.

I need to read and write every register of that UART as explained in the National Semiconductor databook, register by register, address by address.

No.

No information on that topic seems to be available, but a whole bunch of useless idle talk and advertisement.

As others already told you: You do not listen.

Hence I cannot use /dev/ttySx for accessing serial devices.

You can. "cat /dev/zero > /dev/ttySx" already writes a bunch of zeros to the device.

The only way to use serial ports successfully to me, is to use the unit serial on fpc, if I choose fpc to deal with serial ports.

fpc does *not* deal with serial ports neither. It deals with the operating system's interface for teletype style devices, often called serial devices. And that is what *you* should do, too. Do not bother with port addresses or transmit registers. That's the job of the respective device driver.

Under the bottom line, it is embarrassing time consuming for a newbie like me, to work successfully with serial ports on linux.

It is embarassing for a lot of people that you hang onto your misconception about serial devices. You still talk port addresses and register whilst you should just use the operating system's (file style) interface. And there were more than one single person trying to tell you.

On a mailing list, I can only read and write. ;-)

I doubt it. You sure sound write-only...

Vinzent.

Von: Holger Bruns :

I am rather clueless while dealing with device drivers like /dev/ttyS0 on linux. My question is, what do I grab while reading from a device driver file like /dev/ttyS0?

You don't read from a "device driver". You read from a "device". What you read is usually called "data".

IOW: It works just like any other file, disk, socket, ...

How can I deal with it?

Just the same: Read, write, check for errors.

Vinzent.

I doubt it. You sure sound write-only...

I am aware, that I raise problably anger while asking on mailing lists for information, because every question can be interpreted as an insult. I do not post for interpersonal relationships, but for answers to technical questions.

I am also aware, that I get bunches of useless ads while searching the internet with google or yahoo.

My code is working now, thanks again to Marc Santhoff. Please stop writing flames because of your personal emotions. I cannot deal with it. I cannot either follow your assertion, that I do not need to know how to write data in registers of an UART or any other peripheral device attached to a computer, because I could write zeros to a device file instead of it. I cannot follow your assertion, the fpc has nothing to do with serial devices. There is a unit serial out there, and I use it successfuily. If you feel bothered because I want to write data into registers of peripheral devices on my personal computer at home, I cannot find an answer to it. I need to accept your personal point of view as it is. There is nothing more, which I can do for you.

Holger