1

So I have a python script that emulates an ESC_KEY on pin 17 (Raspberry Pi).

#!/usr/bin/env python
#Imports for Pins,input
import RPi.GPIO as GPIO
import uinput
from time import sleep

#Setup
key_events=( uinput.KEY_ESC, )
device=uinput.Device(key_events)
GPIO.setmode(GPIO.BCM)
GPIO.setup(17, GPIO.IN, pull_up_down=GPIO.PUD_UP)

#MAIN
while True:
   GPIO.wait_for_edge(17,GPIO.FALLING)
   device.emit(uinput.KEY_ESC,1)
   sleep(2)
   device.emit(uinput.KEY_ESC,0)

Is there an "easy" way to set this up as a kernel module, or does anyone have some good documentation to create this kernel module? Do I need to rewrite it using C?

It seems as this is eating alot of resources when running in python, I'm hoping it would be less a strain on the system when run as module.

closed as off-topic by slm, cuonglm, rahmu, Patrick, Caleb Jun 24 '14 at 15:55

  • This question does not appear to be about Unix or Linux within the scope defined in the help center.
If this question can be reworded to fit the rules in the help center, please edit the question.

  • For starters this is software development and thus belongs on StackOverflow. But why do you want to make this into a kernel module? Isn't it enough to daemonize your script and let it run in background? What does "alot of resources" mean? CPU or RAM? Both? Have you tried pypy, Cython or similar? – 0xC0000022L Jun 24 '14 at 9:29
  • I tried nothing and am all out of ideas... Just asking, you know maybe get some good documentation. I could do userland. Anyways thanks for the feedback – Stapper Jun 24 '14 at 10:09
1

Is there an "easy" way to set this up as a kernel module

Probably not. Also, that might be kind of contra good design principles, because what you have seems like more of a userspace app; there's a kernel driver lurking in the background of it anyway.1

It seems as this is eating alot of resources when running in python

Considering it sleeps most of the time, that's not a good sign; maybe you should be more specific. The stuff I've done with the rpi pins is all I2C based in C or C++ using the kernel interface, and something simple like this wouldn't be more than 1 MB RSS or use any noticeable CPU time.

Do I need to rewrite it using C?

Re-writing it in userspace C might solve your problem, if the problem is resources (WRT kernelspace code, yes, that is C and asm only). However, python should not be all that bad -- there's obviously no performance issue here. Again, you should describe the problem in more detail.

The RPi.GPIO module is written in C, you might want to take a look at that. However, IMO if you don't know the language already and don't have an interest in it otherwise, it is not worth learning just for this.

You could also try using the (language agnostic) existing kernel interface in python directly, instead of RPi.GPIO; it's simply a matter of reading from and writing to file nodes in /sys/class/gpio. You'll find more stuff about that online if you search and at the raspberry pi exchange. The DMA hack mentioned in the footnote may have an advantage over this if you are trying to do things at a very high frequency, but that's not the case here (and I'm dubious as to how useful it really would be in this sense, because it is still a pure userland entity and subject to kernel latency).


1 Actually that's not true in this case -- RPi.GPIO uses a direct memory address hack like this one; I think the C level wiringPi modules also work this way. That's stuff that would make a good kernel module, except the kernel already has a gpio module with a userland interface. I imagine the justification for the DMA hack is that it seems more efficient (and more interesting to write).

  • even so, a kernel module has to make that DMA possible. Why not Cython or pypy? The former allows one to compile the end product and is known to have speeds comparable to C code, and pypy is even seamless, just another interpreter that is anyway worth installing on an RPi. – 0xC0000022L Jun 24 '14 at 11:24
  • @0xC0000022L "even so, a kernel module has to make that DMA possible" -> not in a very direct sense, although it involves the kernel and the kernel is modular (so technically, yes). It's done through /dev/mem. I think the OP should do some more fine grained profiling before making any decisions, but profiling python is not my area. – goldilocks Jun 24 '14 at 11:26
  • admittedly I am not familiar with all the nitty gritty on the RPi and mine is inaccessible in another country, but from all I know about how the kernel and the memory space works, device memory has to be mapped into the memory space before it can be used. And under normal circumstances a kernel module/driver is responsible for that. But of course you are right, once it's there it's not so direct anymore. IIRC some bcm2835 module is responsible for the GPIO part, but I could be wrong, it's been a while. – 0xC0000022L Jun 24 '14 at 11:30
  • @0xC0000022L Yeah, it's mmap'd. Since the /dev/mem interface must be a bit of an abstraction it's hard to see how this could be much of an improvement on /sys/class/gpio but then I haven't used either (I2C is its own thing), so there may be details I don't appreciate. – goldilocks Jun 24 '14 at 11:38

Not the answer you're looking for? Browse other questions tagged or ask your own question.