Hi
I am a new user of FPC can somebody guide me how to access directly hardware ports with FPC
Thanks
Ezra
________________________________________________________________________ Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading spam and email virus protection.
Mailing lists / fpc-pascal / 2007-05
accessing hardware ports in FPC
10 messages · 5 people · –
- Daniël Mantione 5
- Felipe Monteiro de Carvalho 2
- Alexey Pavluchenko 1
- Tomas Hajny 1
- Unknown author 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
Op Thu, 17 May 2007, schreef
Hi I am a new user of FPC can somebody guide me how to access directly hardware ports with FPC
http://www.freepascal.org/faq.var#accessioports
Daniël
The port array will fail on NT versions of windows. Better to use the methods described here:
http://wiki.lazarus.freepascal.org/Hardware_Access
Felipe Monteiro de Carvalho
Op Fri, 18 May 2007, schreef Felipe Monteiro de Carvalho:
The port array will fail on NT versions of windows. Better to use the methods described here: http://wiki.lazarus.freepascal.org/Hardware_Access
Can you please implement a ports unit for Windows then? The last thing we need is people to start using OS specific code.
Daniël
Daniël Mantione wroteCan you please implement a ports unit for Windows then?
This requires writing a Device Driver for NT.... and later you need to take it with your executable somehow.
The last thing we need is people to start using OS specific code.
OS specific code is not a devil. Sometimes it's necessary. Ports alone won't work on linux also, by the way. You also need to call ioperm and run your software as root. (some docs say you need to do one or the other, but I tested with real hardware, and it never worked unless I did both).
To make ports work on linux without ioperm you would need to make the ioperm call inside ports getter and setter methods, which can be significant overhead for software that need to reliably access hardware every microsecond for example.
Felipe Monteiro de Carvalho
Hello Felipe,
you wrote 5 lines
On 5/18/07, Daniël Mantione wrote:
> Can you please implement a ports unit for Windows then?
This requires writing a Device Driver for NT.... and later you need to
take it with your executable somehow.
It's already written. Visit http://www.logix4u.net. I'm not sure it will work with Vista though.
This page also may prove useful:
http://www.rdrop.com/~cary/html/device_driver.html.
Best regards,
Alexey
Op Tue, 22 May 2007, schreef Alexey Pavluchenko:
Show quoted text 15 lines
Hello Felipe,
Tuesday, May 22, 2007, 10:48:54 AM, you wrote:
> On 5/18/07, Daniël Mantione wrote:
>> Can you please implement a ports unit for Windows then?
> This requires writing a Device Driver for NT.... and later you need to
> take it with your executable somehow.
It's already written. Visit http://www.logix4u.net.
I'm not sure it will work with Vista though.
This page also may prove useful:
http://www.rdrop.com/~cary/html/device_driver.html.
Perhaps the best approach is to make such a port unit abort the program if it runs on WINNT and the device driver isn't found.
Daniël
This requires writing a Device Driver for NT.... and later you need to take it with your…
Op Tue, 22 May 2007, schreef Felipe Monteiro de Carvalho:
OS specific code is not a devil. Sometimes it's necessary. Ports alone won't work on linux also, by the way.
Even if extra calls are needed, like ioperm, the existance of a hardware serial port unit, ignoring the existance of ioperm, can be very usefull for a Linux programmer, as long as it uses the portable port[] array. An ioperm call is easily added to any program.
It is the same for WinNT, while the programmer might have to do extra tricks, existing code can be very valueable for him.
Needless to say I don't recommend people driving hardware by port access, but some people feel/have the need to. There is no need why such code should be different on WinNT than on Win95; FPC's task is to hide such differences from the user.
Daniël
Daniël Mantione wrote 17 lines
Op Tue, 22 May 2007, schreef Felipe Monteiro de Carvalho:
> OS specific code is not a devil. Sometimes it's necessary. Ports alone
> won't work on linux also, by the way.
Even if extra calls are needed, like ioperm, the existance of a hardware
serial port unit, ignoring the existance of ioperm, can be very usefull
for a Linux programmer, as long as it uses the portable port[] array.
An ioperm call is easily added to any program.
It is the same for WinNT, while the programmer might have to do extra
tricks, existing code can be very valueable for him.
Needless to say I don't recommend people driving hardware by port access,
but some people feel/have the need to. There is no need why such code
should be different on WinNT than on Win95; FPC's task is to hide such
differences from the user.
I don't know Linux, but: If ioperm needs to be called just once (without specifying a particular port number), this call could be added to unit initialization. If it needs to be called for particular port number or port range, we could add a function doing this to interface of unit ports (and document it as appropriate, of course), because it's better to provide common approach than to require users to fiddle with IFDEFs and platform specific API for this (such a function probably exists for most platforms and platforms not requiring such a thing may simply ignore it).
Potentially, we could even add a boolean array to implementation part of unit ports maintaining the permission status for all the ports. Calling the "IOPerm" function would mark access to that port as permitted. Call to getter/setter would check the status first and call IOPerm if needed, otherwise skip the IOPerm call (that would allow both fast access and "no hassle" approach for our users).
Tomas
Op Tue, 22 May 2007, schreef Tomas Hajny:
Show quoted text 8 lines
I don't know Linux, but: If ioperm needs to be called just once (without
specifying a particular port number), this call could be added to unit
initialization. If it needs to be called for particular port number or
port range, we could add a function doing this to interface of unit ports
(and document it as appropriate, of course), because it's better to
provide common approach than to require users to fiddle with IFDEFs and
platform specific API for this (such a function probably exists for most
platforms and platforms not requiring such a thing may simply ignore it).
It would be a good idea to make even this platform independend, but only if you can provide similar semantics on all platforms. However, at least in the case of Linux, it such not entirely clear what this initialization should do.
There are two calls:
* ioperm, allows you to ports $0..$3ff, for each port individually.
* iopl, which moves the program into cpu ring 2. It can then access ports $0..$ffff and execute the cli/sti instructions.
A program can inherite port access, if the parent process has io port access, so has the child. So, perhaps the intention of the user could even be that no io permission is asked.
Show quoted text 6 lines
Potentially, we could even add a boolean array to implementation part of
unit ports maintaining the permission status for all the ports. Calling
the "IOPerm" function would mark access to that port as permitted. Call to
getter/setter would check the status first and call IOPerm if needed,
otherwise skip the IOPerm call (that would allow both fast access and "no
hassle" approach for our users).
This could be an elegant way to abstract the ioperm style functionality into a platform independend interface.
Daniël