parallel port driver

M

Thread Starter

Mario de Sousa

Hi all,

I have just uploaded to the cvs a parallel port io driver, and a corresponding demo.

Basically you can map 1 bit linuxplc points onto the digital io points of the parallel port. Have a look through the example config files to get an idea of how to configure it.

The parallel port has some TTL outputs that can sink (but not source!) enough current to drive a led. It's fun to whach these leds following the lights of the vitrine.

Please note that the parport driver needs to run with root permissions to be able to access the parallel port. You can either execute the program when logged in as root, or set the program to suif root.

As root, execute:
$chown root parport; chmod u+s parport

Have fun,

Mario.

-------------------------------------------------
Mario J.R. de Sousa
[email protected]
----------------------------------------------
 
Cool!

For circuits to connect to the parallel port, see the Coffee mini-HOWTO.

(Hmm, I think I once had quite a different circuit running off a parallel port; if I come across it I'll put it somewhere - I think it had fewer parts than the Coffee mini-HOWTO one, because it used a reed relay.)

BTW, the directory should probably have been called ``parport'' rather than ``basic_parport'', but that's not important now... (Also, the duplication of the Chaser code is a poor habit; we should probably rationalize that, but not tonight.)

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!
 
M

Mario de Sousa

> Cool!
> For circuits to connect to the parallel port, see the Coffee mini-HOWTO.

If you just want to test the thing and see some lights going on and off, you can either use a voltmeter or use a few leds. Check the README file in the /demo/basic_parport directory.

By the way Jiri, would you like to write a keyboard io module? Do you know how to interface to the keyboard, i.e. read the keypressed state of
a key?

I also need some help finishing the dsp module. Chetan seems to have too much work at the moment, and says maybe only next year. If nobody is willing to help out, then it will have to wait until the next release.

Like I said previously, if you are willing to help out, I can send you some .h files for you to write standard C, operating system independent, code. The dsp module is organized in blocks, so we can break this out for several people. If somebody is willing to help out, it doesn't mean you will have to do all the work. Just one or two blocks, like a filter function, etc... You say what you want to code. This is really very simple code for someone that knows the algorithms. I really don't have time (and above all will) to go through my books and refresh my memory on all these algorithms.

Mario.
-------------------------------------------
Mario J. R. de Sousa
[email protected]
-------------------------------------------
 
M

Mario de Sousa

Sorry Jiri, I've been reading my last email and it seems I am asking you in particular for help on finishing the dsp module.

Actually I asking anybody who nows the algorithms to help out here.

>I also need some help finishing the dsp module. Chetan seems to have
>too much work at the moment, and says maybe only next year. If nobody is
>willing to help out, then it will have to wait until the next release.
>Like I said previously, if you are willing to help out, I can send you
>some .h files for you to write standard C, operating system independent,
>code. The dsp module is organized in blocks, so we can break this out
>for several people. If somebody is willing to help out, it doesn't mean
>you will have to do all the work. Just one or two blocks, like a filter
>function, etc... You say what you want to code. This is really very
>simple code for someone that knows the algorithms. I really don't have
>time (and above all will) to go through my books and refresh my memory
>on all these algorithms.

Mario.
------------------------------------------------
Mario J. R. de Sousa
[email protected]
--------------------------------------------------
 
Mario de Sousa:

>By the way Jiri, would you like to write a >keyboard io module? Do you know how to interface >to the keyboard, i.e. read the keypressed state >of a key?

No, but I have an idea where I might find out... I'll have a look.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World!
 
M

Mario de Sousa

> No, but I have an idea where I might find out... I'll have a look.
> Jiri

Hi Jiri,
I have been looking through the ncurses man pages but it seems that we can only get when a character key is pressed, which makes sense for
ncurses. What I would really like is to be able to know when _any_ key is pressed or not, including shift, ctrl, alt, num_lock, ...

I have been glancing through the kernel code, and it seems to have a generic keybaord driver, called by the pc_keyb, m68k, mac_keyb, ..., drivers. If we could have this generic driver make a call to a kernel module written by us, we could have our module keep a map in memory of the state of the keyboard keys. This info could then be read from normal user space processes through a char device. Unfortunately this scheme requires that the kernel be patched to make one single call to our kernel module. We can't just insert our kernel module. It does have the advantage of being portable to any architecture.

Another option would be to replace the keyboard interrupt handler. Unfortunatley this is not portable to any architecture, nor can I figure
out how to call the original interrupt handler to do the normal processing from our own interrupt handler.

I don't like the way I wrote the parport io driver either. It writes directly to the parallel port control registers. This is non portable, and only works for PC compatible platforms. The correct way of doing this seems to be to write a simple passthrough kernel module that uses the generic parport kernel module (the kernel has a module with this name already), which in turn calls the architecture dependent kernel module. If we were to do this, we could automatically support PCI, firewire, etc.. parallel ports. Unfortunately I haven't completely figured out how to use the generic parallel port. Once somebody could explain this, it would be a simple matter of writing a simple character device kernel module.

Sorry for rambling on. Just some thoughts.
Mario.

-----------------------------------------------
Mario J. R. de Sousa
[email protected]
-----------------------------------------------
 
Mario de Sousa:
> I have been looking through the ncurses man >pages but it seems that we can only get when a >character key is pressed, which makes sense for
> ncurses. What I would really like is to be able >to know when _any_ key is pressed or not, >including shift, ctrl, alt, num_lock, ...

The key observation (so to speak) is the program showkey which, in its default mode, actually goes:
jiri@legend> showkey
kb mode was XLATE

press any key (program terminates after 10s of last keypress)...
keycode 30 press
keycode 30 release
keycode 48 press
keycode 48 release
keycode 46 press
keycode 46 release

At that point, it was a simple matter to download the source, cut out all the other modes and hook it up to the linuxplc. Eventually, though, I'd
like to be able to use human-readable key names instead of keycodes.

Jiri
--
Jiri Baum <[email protected]>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.
 
O

Oscar Esteban

> the other modes and hook it up to the linuxplc. > Eventually, though, I'd like to be able to use >human-readable key names instead of keycodes.

I agree on getting key names instead of scan codes. But remember you press keys which, depending on your language, will be mapped to different characters.

That's the advantage of having codes (independence of mapping). But I'm not sure if we would like to be map independent. After all, if someone should press 'A' to do something it would always be 'A', instead of the second key from the left in the middle row (in my keyboard). But then, you'd have to go through Linux's keyboard mapping, which sure are not in the kernel.

Concerning of the need of being in the console, it seems obvious to me. You can not tell about the state of the keys if the computer who can tell doesn't send it to you. And I don't think most telnets (or even terminal emulators) will...
 
I think we can probably assume for demonstration purposes that the target platform is PC. I don't see how writing a simple character device will allow you to properly manipulate bits on the port. A lot of times you have to do read-modify-write operations on the port and it would be tricky with a standard linux character driver and have atomic operations of this sort. (This is somewhat of speculation ... )

Isn't the (LPT1) parallel port pretty much a PC specific thing anyway??? (Pure Speculation)

perhaps you could just have a non hardware specific function call something like:

UNSIGNED CHAR Value = ReadParPort( INT PORT)
WriteParPort(UNSIGNED CHAR Value, INT PORT)

and if someone wants to run it on machine "x" they just insert some simple one or two line code.

I guess that I think that what you have done so far, Mario, is good enough for the scope of LPLC for now.

(Has anyone heard of anyone wanting to run LPLC on any other platform besides Intel??? This seems strange to me.)

~Ken

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> > the other modes and hook it up to the linuxplc. Eventually, though, I'd
> > like to be able to use human-readable key names instead of keycodes.

Oscar Esteban:
> I agree on getting key names instead of scan codes. But remember you
> press keys which, depending on your language, will be mapped to different
> characters.

Yes, therefore you need to look up the mapping (something like the dumpkeys(1) program does) and search in that.

I think for the time being I'll just write a perl script that gets the mapping from dumpkeys, sorts it alphabetically and writes it to a "keycode
chart" file, for the human to read.

> Concerning of the need of being in the console, it seems obvious to me.

Yes, it's obvious, just unfortunate.


Jiri
--
Jiri Baum <[email protected]> You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
G

Gilles Allard

I do not understand why such a utility cannot be developed for Xwindow terminals. I have a program named "keycode" that does that. It is running on
HPUX and it post keycodes on a text window. I'm pretty sure that text can be piped back to the host (X client if you prefer).
Here is a sample output of the program:

KeyPress event state 0x0, keycode 60 (keysym 0x68, h)
KeyRelease event state 0x0, keycode 60 (keysym 0x68, h)
KeyPress event state 0x0, keycode 26 (keysym 0xffe3, Control_L)
KeyRelease event state 0x4, keycode 26 (keysym 0xffe3, Control_L)
KeyPress event state 0x0, keycode 75 (keysym 0x6b, k)
KeyRelease event state 0x0, keycode 75 (keysym 0x6b, k)
KeyPress event state 0x0, keycode 84 (keysym 0x6c, l)
KeyRelease event state 0x0, keycode 84 (keysym 0x6c, l)

The program was supplied with a well-known SCADA program. It may be proprietary or from public-domain, I don't know (so I will not post the
program). If somebody in the group has some Xwindow programming experience, he (she) may look at the two attached files (one in this message and the second to follow). One is the usage text and the second is the output of "strings keycode".
'hope this helps
Gilles
 
Gilles Allard:
> I do not understand why such a utility cannot be developed for Xwindow
> terminals.

It can - just none of us's written it yet. What I've written works for the
console.

> I have a program named "keycode" that does that. It is running on HPUX
> and it post keycodes on a text window. I'm pretty sure that text can be
> piped back to the host (X client if you prefer).

Yup - either grab the keycode source and mangle it the way I've mangled
showkey(1), or write it from scratch - it'll be a very simple program.

> The program was supplied with a well-known SCADA program. It may be
> proprietary or from public-domain, I don't know (so I will not post the
> program).

I'd expect there'd be such a program supplied with X as a utility.
But like I said, it'll be a very simple program.

Jiri
--
Jiri Baum <[email protected]>
You know you've been hacking too long when ...
... reading a book you notice the word "From" at the beginning of a line.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
T

Thomas B. O'Hanlan

I've been out of the country til recently. Please fill me in on what you are thinking about a Parallel Printer Port I/O card. Sealevel Systems, as well as others would be interested in buiding something like this. Thanks Tom -----Original Message----- From: [email protected] [mailto:[email protected]]On Behalf Of Mario de Sousa Sent: Tuesday, March 06, 2001 4:12 AM To: [email protected] Subject: LinuxPLC: Parallel port driver "Campbell, David (Ex AS17)" wrote: > > > Hugh Jack wrote: > *snip* > > But the PPLC will be free - and will run on 'obsolete' PCs - > > the parallel port will provide a nice IO card. > > Could someone take a quick look at the lp driver in the kernel? > If it still has my name on it then I will quickly through together > the stuff required to make this a reality (complete with circuit > board design if required). > It already is a reality. I did this a couple of months ago. Been playing with it since then ;-) Check out the parport module under the /io/parport directory of the cvs. _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Tom. What might really be handy for using the parallel port and 8255 type cards are level translators from TTL to 24 volt logic. I have been designing these into my testers, but small inexpensive "packaged" translators would answer a perennial problem with using PC's for control. The various relay cards, etc. do the job but are large and expensive. An 8311 for outputs and optoisolators for inputs would work fairly well and the cost could be reasonable with multiple devices per package. The 8311 provides 16 OC high current peripheral drivers in one package. I'm sure there are octal optoisolators, etc. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Campbell, David (Ex AS17)

> Curt Wuollet wrote: > The 8311 provides 16 OC high current peripheral drivers in > one package. I'm sure there are octal optoisolators, etc. http://www.findchips.com/ look for optocoupler and duck!! (a lot of matches, need something to filter them...) 90+% of optocouplers are 6/8 pin packages (eg: 1 optocoupler per package). There are a couple of quad channel devices. For example: PS2702-4NEC which is listed at USD$2.55 each (Just a touch over $.74 per device). David Campbell _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Dave and all. I'll let someone else deal with the PC parallel port, the variations have always scared me off. Since I have done most of this to build testers with DAQ cards and 8255 type digital ports, I looked around a little and they even have some OI's with back to back led diodes that would let us closely match what is in use now. (strap to + or - as common) Since I need this functionality for paying projects, I have considered doing the design and releasing the schematics and artwork to the LPLC project. We could even do kits, but that comes very close to commercialism. Sealevel could also add this to their boards for a nominal cost increment and we would have real industrial IO available assuming they could justify the certifications, blah, blah, that matter to the automation industry. To roll our own, the remaining problem to be solved is that the 8255 boards can be programmed as inputs or outputs in groups of 4 or 8. For maximum flexibility a translator board would need 20 ins and 23 outs (one output is needed to disable the outputs until initialized for safety) This would bump the cost a little. If we compromise and settle for 16 in and 16 outs this would mean that you would always have at least 8 inputs or 7 outputs and the balance the other. Switching adds cost, I was thinking of using dip switches or some such to connect a 8255 pin to the correct buffer depending on whether it's an input or output. I looked briefly at configuring as a bus, with OC outputs we could do this but, I don't think the automation crowd is ready for pins that can switch from being inputs to being outputs in software :^). There don't seem to be any 24V tristate buffers. All thoughts on how to do this most cleverly would be appreciated. We have the direction state of the IO groups as that is programmed on initialization. Could we automap? I'll start lobbying for the release of the design. If that's not possible, I may do it on my time but that is pretty limited just lately. I would like one "real" option to answer the question of "what can I do with it". Perhaps someone not directly involved in the project would make kits or at least boards available. For that matter, if my day job company were to offer kits, would that be a conflict of interest? Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
W
Curt and others, Finally! Something I may be able to help with. Point me to a pinout of what comes off those 8255 boards (ribbon? d-sub?). I'll design a schematic, board, etc., and put it in the public domain. I'll use Eagle, so it can be edited under Linux or Winkers, and used free by students. I have made an I/O board with software switchable inputs/outputs. The chip is an MC33298. You don't need any other parts, but it runs on SPI so we probably can't use it for this app. It can sink 24V at .5 amp per channel (8), and if it's an input, the logic threshold is >4 volts = on. Give me pinouts, I'll come up with a concept and post it. Regards, Willy Smith Costa Rica _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Hi all Puffins, -----Original Message----- From: Curt Wuollet <[email protected]> >I'll let someone else deal with the PC parallel port, the variations have always >scared me off. >Since I have done most of this to build testers with DAQ cards and 8255 type >digital ports, Please, take into account that Linux users in teens bracket are likely to accept PC parallel port most enthusiastically -(and they are likely to become Puffin's best advocates). It would be nice if parts would be easy to obtain everywhere and if there would be very low requirements for assembly technology (soldering etc). E.g. if one of standard breadboard systems can be used, it would double number of finished systems ... most likely... They may also lack safety-oriented habits which are second nature to most professionals and attached documentation should provide at least basic recommendations and warnings for use of PC parallel port for control of mains-driven appliances (somebody somewhere will use Puffin to switch on a kettle by 8 AM for sure!). Petr -- <[email protected]> Petr Baum P.O.Box 2364, Rowville 3178, Australia fax +61-3-97643342 _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Curt Wuollet: > To roll our own, the remaining problem to be solved is that the 8255 > boards can be programmed as inputs or outputs in groups of 4 or 8. For > maximum flexibility a translator board would need 20 ins and 23 outs (one > output is needed to disable the outputs until initialized for safety) > This would bump the cost a little. The other way is to make the isolators pluggable modules. This too bumps up the cost, but OTOH gives the option of different levels of isolation and different kinds of output (solid-state versus relay). Then again, such systems already exist (or at least did ten years ago), so we don't need to do anything to have them. Just point people at them. If it's just a board design without actual hardware, it's probably easiest to just design all the combinations, there ain't that many of them. (Or design a board where relevant bits can be populated one way or the other.) > All thoughts on how to do this most cleverly would be appreciated. We > have the direction state of the IO groups as that is programmed on > initialization. Could we automap? Theoretically yes, but in practice it would defeat the point of using 8255. > Perhaps someone not directly involved in the project would make kits or > at least boards available. As I wrote above, at least one such system is available - in-computer board (8255-based), connected via ribbon cable to a break-out board, which has pluggable modules (input, output, solid-state, relay, 240V etc). > For that matter, if my day job company were to offer kits, would that be > a conflict of interest? Probably not all that much. Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Top