0

I believe I could not fully understand the benefits of writing device drivers in embedded systems for some specific devices, such as GPIO, when there are alternative ways of doing the same job.

  1. You can access the GPIOs via sysfs and device tree.

    • Write a new device tree overlay and enable it
    • Go to the /sys/class/gpio
    • Export required pin and start using it (via simple shell calls or inside the c/c++ app)
  2. Write your own driver.

    • Code the real functionalities.
    • Expose the driver to a node (like /dev/tty) in userspace.
    • Write another c/c++ code to access the driver (also it can be accessed via simple shell calls)
    • If you need any new functionalities, first change the driver then your code. (Why?)
  3. Use directly /dev/mem;

    • Include mman.h and use /dev/mem object to set or get the GPIO status.

So,

  • 1 -> is going to be deprecated and slow. (Ok, absolutely beneficial for fast prototyping)
  • 2 -> How is that faster than 1? 1st one is also another GPIO driver, isn't it?
  • 3 -> Isn't it best and fastest way?

I asked several questions above but here is my biggest question; why shouldn't I go straight with the 3rd solution?

1 Answer 1

1

The advantage of option 2 is that you can validate the request in a single place. Say for a dishwasher you can ensure the door sensor says the door is closed before you turn on the water. Sure you can tell people to check the door status bit before they set the water on bit, but will they all do so?

A potential disadvantage of options 1 and 3 is permissions. It depends on how sophisticated the embedded device is, but you might want to have different userids doing different things, for example a home router might have a different uid running an http server doing the web UI and a different daemon operating the front panel LEDs. Whilst it is possible for gpio drivers to have fine grained access control, most have an all or nothing approach. With option 2 you can decide which users can access which facilities at a fine level.

The downside of option 2 is it is more complicated, and usually requires code in the kernel.

7
  • Thanks @icarus, it was short and brief explanation. But what if I'm the only designer, user and maintainer of the device and the requirements are defined strictly and won't change in the future, do you still think it is beneficial to write a kernel driver instead of directly using mmap? Jan 23, 2019 at 7:26
  • Under those circumstances I would go with option 1, and only if it proved too slow would I think about option 3 and 2. I would not expect there to a massive difference in speed between options 1 and 3, both are running in user space, Option 2 should be expected to be the fastest.
    – icarus
    Jan 23, 2019 at 7:55
  • thank you. I marked your answer as accepted. As a further discussion, is there any other options that I'm missing? And any reading references why 3 would be slower than 2 despite I'm dealing with the memory directly? Jan 23, 2019 at 9:04
  • The reason I would expect 3 to be slower than 2 is that with 3 potentially the code to do step 3 is not even in memory as it has been swapped out, and in any case needs to wait until the process has been scheduled, If one of your gpio lines is an input saying the fire alarm is on", then you can program it to also generate an interrupt, which with option 2 you can react to pretty much instantly, With option 3 you will probably need to wait until you poll the bit, which might be minutes away if your user space program is busy doing bitcoin mining. ...
    – icarus
    Jan 23, 2019 at 14:00
  • ... There are operating systems other than linux which put device drivers in user space. GNU Hurd is one of the most well known. With them the difference between your options 2 and 3 becomes very blurred. In the end any system is just changing outputs in response to a change in inputs, it is up to you how you are going to do it.
    – icarus
    Jan 23, 2019 at 14:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .