Keyboard driver

J

Thread Starter

Jiri Baum

Hello,
There is now a keyboard driver - mmi/kbd/linuxkbd

It has good points and bad points. The good point is basically that it works like it should (actual key status, not just key-toggled). The bad point is that it's non-portable. You have to be actually at the console to run it.

I've modified the basic demo to use it, falling back to the old kbd if necessary.

If you need to quit out of the linuxkbd driver, press Esc. In the demo, that will fall back, otherwise it'll just exit.

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.
 
M

Mario de Sousa

Jiri Baum wrote:
> Hello,
> there is now a keyboard driver-mmi/kbd/linuxkbd

Good show, Jiri!!
>It has good points and bad points. The good >point is basically that it works like it should
>(actual key status, not just key-toggled). The >bad point is that it's non-portable. You have to >be actually at the console to > run it.

Yes, this is a pity.

Mario.
--------------------------------------------
Mario J. R. de Sousa
[email protected]
--------------------------------------------
 
What is the deal with a keyboard driver??

Why would someone need to communicate to the LPLC through a keyboard?
Shouldn't all keyboard traffic be abstracted by the HMI software? I can see problems where someone is trying to send a keystroke to the HMI and then the LPLC driver accepts it and causes something really weird to happen that is unexpected (depending on the logic code, of course).

If you want to use a keyboard in LPLC it is clear to me that you would open up a console window (or start a new shell when at the command line) which is running in the native linux kernel land. then your "shell" would just redirect stdin and stdout to and from LPLC using shared memory. This way nobody is screwing with linux drivers or kernel patches and it is clear to the user "what" they are communicating with (i.e. LPLC or linux/HMI).

Does this make sense or am I misunderstanding you guys??

~Ken
 
M

Mario de Sousa

"Ken Emmons, Jr." wrote:
>What is the deal with a keyboard driver??
>Why would someone need to communicate to the >LPLC through a keyboard? Shouldn't all keyboard >traffic be abstracted by the HMI software? (...)

I see this kbd driver as an intermediate stage until we really get a GUI interface. Together with the vitrine it will let people play around with the PLC without any hardware.

But could you please clarify what you understand the HMI software to be?
What are you enviosining?

To me, everything that allows human interaction is HMI...

>If you want to use a keyboard in LPLC it is >clear to me that you would open up a console >window (or start a new shell when at the command >line) which is running in the native linux >kernel land. then your "shell" would just >redirect stdin and stdout to and from LPLC using >shared memory.

Is it possible to verify what state the shift, alt, ctrl, keys are in by reading stdin? Is it possible to know when any key is released by reading stdin? Please, I'm not trying to be arcastic. I'm pretty sure it is not possible, but I've been wrong before, so I may be wrong again.

I guess you want to know why we need these capabilities? As I said above, I see this as a substitue for real-world switches, sensors, etc..., to allow for testing, so I guess it would be nice to support it?

>This way nobody is screwing with linux drivers or
>kernel patches and it is clear to the >user "what" they are communicating with (i.e. >LPLC or linux/HMI).

You are quite right here. No need to screw around with kernel patches if the info is available from somewhere else. I just didn't know it was available two days ago. One thing I like about this is that I'm constantly learning.

By the way Ken, I seem to remember that you were once involved in porting gcc? If so, may I assume you know how to configure autoconf and automake? I would very much like this project to use shared object libraries, but its a bit confusing configuring these applications from scratch for someone that has never done this. Do you think you could help out here?

cheers,
Mario.
-----------------------------------------
Mario J. R. de Sousa
[email protected]
-----------------------------------------
 
OK, for an intermediate test situation or for simulation, I can see where a keyboard driver would be handy. As a standard feature ... I still have my reservations.

I see what you mean, Mario, about the keyboard button presses. Stdin and out just gives you a buffer and you can't detect when they turn off, etc .... gotcha. Since you want the keyboard to act as input switches, you need to know it's current position, etc. I didn't fully realize what you were doing with it.

What if someone were to come up with a quick and dirty HMI screen running in X windows that allows you to push some buttons that modify some input tags in the LPLC ?? You could also have some outputs shown as some kind of light or something. I've done this with Steeplechase/Citect HMI when I have to demo something for someone and as long as they understand that the LPLC is doing the logic and the GUI is just handling button presses they are OK with it. If you want a more real world demonstration you will need to interface to something like the parallel port as you guys have discussed previously.

To me, an HMI is a piece of software that runs on the computer that has hooks to the tag table in the LPLC. (lets limit this scope to just the PC that runs the LPLC, network HMIs, etc don't count for this discussion). The HMI can be written in whatever language, it's not a big concern to me. I assume that the HMI would run in linux process land, thereby utilizing X windows interface, etc. All Keyboard and mouse input should go to the HMI software as far as I am concerned in order to segregate the operator interface from the control logic. The interface to the operating system (linux) should just be shared memory, and this also solves the portability issue. I believe that we should use the native features of linux where it makes sense (GUI, keyboard, mouse, network, etc.etc.) and keep the LPLC stuff separate, simple, and well defined (which I think is happening so far. )

Hmmmm..... about GCC .... I don't know where you got the idea I had worked on a port. This is not true. (I am an electrical engineer with a desire to be a better C programmer ...) I currently use GCC with linux, but I haven't gotten into any serious make file magic yet.

~Ken
 
Ken Emmons, Jr.:
> What is the deal with a keyboard driver??
> Why would someone need to communicate to the LPLC through a keyboard?

When no other real hardware is attached...
Basically, this means the demo and (very limited) debugging.

Unfortunately, most keyboards can only handle maybe 3-4 keypresses together (depending on which key combination you press), so it's not as general as we might like. But it's a lot better than nothing, and it's a lot quicker to set up than whipping out the old soldering iron and making up a hundred-input board.

>If you want to use a keyboard in LPLC it is >clear to me that you would open up a console >window (or start a new shell when at the command >line) which is running in the native linux >kernel land. then your "shell" would just >redirect stdin and stdout to and from LPLC using >shared memory. This way nobody is screwing with >linux drivers or kernel patches and it is clear >to the user "what" they are communicating with
>(i.e. LPLC or linux/HMI).

The keyboard driver is a normal userland application, but it does need to put the keyboard into medium-raw mode so it gets key releases. Hence the requirement to be on the console.

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.
 
Ken Emmons, Jr.:
> What if someone were to come up with a quick and dirty HMI screen running
> in X windows that allows you to push some buttons that modify some input
> tags in the LPLC ??

Thank you for volunteering?

Sorry to sound facetious like this, but, well, it's true. It would be good to have this, and even better if it isn't quick-and-dirty.

> If you want a more real world demonstration you will need to interface to
> something like the parallel port as you guys have discussed previously.

Not just discussed - Mario implemented it.

> To me, an HMI is a piece of software that runs on the computer that has
> hooks to the tag table in the LPLC. (lets limit this scope to just the PC
> that runs the LPLC, network HMIs, etc don't count for this discussion).

Yup, that's what the keyboard module is - it grabs control of the keyboard and maps it to the LPLC tag table. It's input-only, but it could be extended to map a few tags to the keyboard LEDs.

> The interface to the operating system (linux) should just be shared
> memory, and this also solves the portability issue.

Well, no, the portability issue is the keyboard itself - I believe the interface I used is marked linux-i386 specific, internal, alpha. Which I understood to mean there'll be surprises down the track. We'll see.

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.
 
I wouldn't mind doing an HMI application, but I fear that my programming is limited to ANSI C, multi process programming (NT multithread and Linux multi process stuff).

One of my colleagues is learning Java and I could work with him on some kind of HMI (He is ready for a real life application ... ) I think that JAVA might be a bit too generic for this project, and it might be difficult to interface to the LPLC system. What is your feeling, Jiri, on a Java implementation?? If this is not really viable, what about using C++ with the QT libraries ???

~Ken
 
Ken Emmons, Jr.:
> What is your feeling, Jiri, on a Java implementation??

I've no idea about Java, much less how to interface it to C code.

>If this is not really viable, what about using C++ with the QT libraries ???

That's more what I was thinking, C or C++ with some toolkit library. Whether Qt or OpenGL is an interesting question, easily solved if there's a volunteer with a working knowledge of one or the other, otherwise it's a design choice.

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.
 
M

Mario de Sousa

> Hmmmm..... about GCC .... I don't know where you got the idea I had worked on a port. This is not true. (I am an electrical engineer with a desire to be a better C programmer ...) I currently use GCC with linux, but I haven't gotten into any serious make file magic yet.
> ~Ken

Sorry Ken,
I think I got you confused with Dan, from Control.com.

Dan, if you are reading this, do you think you could give us a little help here?

Thanks,
Mario.
------------------------------------------------
Mario J. R. de Sousa
[email protected]
------------------------------------------------
 
D

Dan L. Pierson

Well, I've been scanning the messages, but not paying close attention. What would you like help on? Warning, what GCC experience I have is rather rusty -- thoroughly pre-egcs...
 
M

Mario de Sousa

Thanks for your offer.

Basically I would like the project to use autoconf and automake, but they are a bit complicated to configure from scratch for a first time user. I thought maybe you might have some experience configuring these utilities?

The main objective is to start using shared object (.so) files portably.

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

Dan L. Pierson

Hmm, they're after my time, but I have done some stuff like this before. I'll look into it, but can't promise when I'll be done.
 
I have some experience with autoconf, although not automake. I could get a basic configure.in put together.

Zach
 
Top