reading memory for lpt port

reading memory for lpt port

Post by soth » Mon, 01 Jun 1998 04:00:00



I was talking to someone recently who wanted to read a memory address,
namely what would be 0x0408 in dos real mode.  this is the location for lpt
1, apparently, with other lpt ports following.
I guess it seems obvious that you can't just set a pointer to 0x408, as it
would not point to the location in question.
a search of dejanews turned up some info in the parallel-processing howto,
that said you would have to mmap() the page.

Is that the best way?  does linux have facilities to read that page of
memory already, perhaps through /proc?
thanks
sothis

 
 
 

reading memory for lpt port

Post by Peter Samuels » Wed, 03 Jun 1998 04:00:00



Quote:> I was talking to someone recently who wanted to read a memory
> address, namely what would be 0x0408 in dos real mode.  this is the
> location for lpt 1, apparently, with other lpt ports following.

Why do you want to do this?  (Not an insult, just a question.)  It _is_
possible to write a user-space device driver in Linux but only (IIRC)
if you don't need to use interrupts.  Probably you would be better off
with a kernel module (or a hybrid, where the userland program loads a
module which does whatever is needed to communicate with this device,
then maybe unloads the module if it's a one-time thing).

Quote:> I guess it seems obvious that you can't just set a pointer to 0x408,
> as it would not point to the location in question.  a search of
> dejanews turned up some info in the parallel-processing howto, that
> said you would have to mmap() the page.

Right -- each process has its own address space.  If you really want
the physical addresses, you will have to mmap them.

--
Peter Samuelson
<sampo.creighton.edu ! psamuels>

 
 
 

reading memory for lpt port

Post by soth » Wed, 03 Jun 1998 04:00:00


On 2 Jun 1998 00:51:10 -0500, Peter Samuelson enlightened with:


>> I was talking to someone recently who wanted to read a memory
>> address, namely what would be 0x0408 in dos real mode.  this is the
>> location for lpt 1, apparently, with other lpt ports following.

>Why do you want to do this?  (Not an insult, just a question.)  It _is_
>possible to write a user-space device driver in Linux but only (IIRC)
>if you don't need to use interrupts.  Probably you would be better off
>with a kernel module (or a hybrid, where the userland program loads a
>module which does whatever is needed to communicate with this device,
>then maybe unloads the module if it's a one-time thing).

I will relay this to my friend.  He formulated this question while working
on a project to communicate with an external device(household device, i
believe) via the parallel port.  I think he's looking at other methods, but
it was bugging him that he couldn't find an intuitive answer to the question
that I posted.
Thank you Peter.
sothis
 
 
 

reading memory for lpt port

Post by Andreas Mo » Thu, 04 Jun 1998 04:00:00



> I was talking to someone recently who wanted to read a memory address,
> namely what would be 0x0408 in dos real mode.  this is the location for lpt
> 1, apparently, with other lpt ports following.
> I guess it seems obvious that you can't just set a pointer to 0x408, as it
> would not point to the location in question.
> a search of dejanews turned up some info in the parallel-processing howto,
> that said you would have to mmap() the page.
> Is that the best way?  does linux have facilities to read that page of
> memory already, perhaps through /proc?
> thanks
> sothis

You dont want to get the address of the lpt port by reading this BIOS
configuration memory address, do you !?
This is... well, I just cant express it.

Please try to use the normal Linux device handling scheme when accessing the LPT
ports.
If this wont work with your project, start writing a device driver that
does some ioctl() magic or something like that.

I am not too experienced with that either, I just wanted to tell you that
what you are trying to achieve is certainly not The Best Thing (tm).

Maybe somebody else could explain writing a device driver for parallel port
a little bit further...

Good luck !

--
Andreas Mohr

 
 
 

reading memory for lpt port

Post by Andre Facha » Thu, 04 Jun 1998 04:00:00



> Why do you want to do this?  (Not an insult, just a question.)  It _is_
> possible to write a user-space device driver in Linux but only (IIRC)
> if you don't need to use interrupts.  Probably you would be better off

How do you do a user-space device driver (besides running a root process
doing an ioperm() and using inb() and outb())?

I am in the process of building an IEEE488 interface for the parallel port
and want to avoid writing a kernel module...

Thanks
Andre

--
Email address may be invalid. Use "fachat AT physik DOT tu-chemnitz DOT de"
------Fight SPAM - join CAUCE http://www.cauce.org------Thanks, spammers...
Andre Fachat, Institute of physics, Technische Universit?t Chemnitz, FRG
                http://www.tu-chemnitz.de/~fachat

 
 
 

reading memory for lpt port

Post by Przemek Klosowsk » Thu, 04 Jun 1998 04:00:00



> I was talking to someone recently who wanted to read a memory address,
> namely what would be 0x0408 in dos real mode.  this is the location for lpt
> 1, apparently, with other lpt ports following.
> I guess it seems obvious that you can't just set a pointer to 0x408, as it
> would not point to the location in question.

I think your friend may be hoping to obtain the LPT1 base address from
BIOS.  In Linux, the LPT devices are discovered by the kernel; more
importantly, they are handled by the kernel lp driver. Also, Linux
doesn't use BIOS. If all you need is to read and write data, you would
use the kernel. If you want to use funky stuff (bitbang on LP control
lines, etc), normally assume the printer port at its standard address,
and open /dev/port, seek()ing to the right port.
--

                        NIST Center for Neutron Research (bldg. 235), E111
                        National Institute of Standards and Technology
                        Gaithersburg, MD 20899,      USA
                        .. and for spam extractors, FCC Commisioners' email is:

 
 
 

reading memory for lpt port

Post by Peter Samuels » Sat, 06 Jun 1998 04:00:00



Quote:> How do you do a user-space device driver (besides running a root
> process doing an ioperm() and using inb() and outb())?

That's pretty much what I meant.  There isn't really a concept of
"user-space device driver" as opposed to other sorts of user-space
processes, except that they use ioperm()s etc.

Quote:> I am in the process of building an IEEE488 interface for the parallel
> port and want to avoid writing a kernel module...

There are a lot of problems with controlling a device from userland.
You can't service IRQ's, for one.  You can't operate with any sort of
reliable realtime, for another -- you never know when you're gonna get
swapped out for exactly the wrong few milliseconds, unless you cli() or
something, which is also a Bad Thing.

That said, there's a good case to be made for hybrids -- where the
lowest-level device handling is done in a kernel module and all the
post-processing or whatever sits in user space.  (This is the model
planned for GGI.)  For one thing, it's harder to crash the system from
user space so it's best to keep kernel code too simple for bugs.  For
another, modules can't use libc to do their dirty work, only a rather
stripped-down version in the kernel sources.

--
Peter Samuelson
<sampo.creighton.edu ! psamuels>