I'm looking to connecting some devices to the GPIO pins on the Raspberry Pi Zero, (namely a VGA connector). So I was wondering what are the steps to tell the Kernel to say these pins aren't GPIO, but they are of device type X.

Is this just a udev thing to reclassify? I know that no matter what, I'd have to write my own driver to convert whatever kernel data is to the output device and if I wanted to do input, then it'd be vice versa.

Any thoughts or suggestions would be appreciated.

  • I'd look into device tree and see if there's a way to use an overlay such that if appropriate circuitry were actually attached to the GPIOs, the kernel would think that was a VGA interface.
    – goldilocks
    Commented Apr 1, 2016 at 14:05
  • 1
    In general what you are asking for is not possible, doubly so for VGA. What have you read to suggest this is feasible?
    – joan
    Commented Apr 1, 2016 at 15:24
  • @joan you're looking at it the wrong way. With a 1Ghz clock, it should be more than able to do VGA.
    – SailorCire
    Commented Apr 1, 2016 at 20:35
  • 1
    What have you read to support that conclusion?
    – joan
    Commented Apr 1, 2016 at 22:31
  • To be 100% honest, I'm not looking to do VGA. I'm wanting to use a TFT screen as a display divice; however, I want a generic enough answer so others can benefit.
    – SailorCire
    Commented Apr 1, 2016 at 22:59

2 Answers 2


I am not sure whether this can be done easily. I think that one important point has to be considered: while the GPIO pins are more or less direct connections to the CPU, actual hardware interfaces have their own components that alter signals that are present on the connector. So you do not only have to emulate your device but also parts of the receiving hardware.

As an example: Let's say you would like to emulate a USB device that you connect directly to the GPIO pins. Real USB devices are not connected directly to the CPU. There is hardware like transceivers and USB controllers and similar either on the mainboard or inside the micocontroller that actually receives the signals. And the result of this "preprocessing" step is then sent to the CPU and to the kernel. In your emulation scenario you would also have to emulate this receiving hardware.

For many applications this can be quite difficult and very low level. And for many it can easily become impossible to do it with an arduino or raspberry pi or similar because of very high frequencies and/or signal speeds. Actual hardware implementations use dedicated chips like ASICs, DSPs or FPGAs to achieve this.

  • If I wanted to plug in a USB device through GPIO, then couldn't I use a FTDI then to translate it in serial I\O? The problem I have isn't how much extra circuitry I need, but how to use the GPIO pins. Also, if there is direct communication to the CPU, then wouldn't all activity cause an interrupt?
    – SailorCire
    Commented Apr 1, 2016 at 13:59
  • But when you use an FTDI to connect a USB device (via I2C or SPI), you are not telling the kernel that the GPIO pins are a new device. It is still a serial port like before. In your question you asked about turning GPIO pins to a new hardware interface (seen from the kernel). And the GPIO pins cause interrupts and depending on your configuration they are handled by drivers (for example when you configure them to be SPI or I2C).
    – Mononess
    Commented Apr 1, 2016 at 14:06
  • The GPIOs can and do cause interrupts when used normally. Interrupts can be ignored, the fact that they represent "a direct connection to the CPU" doesn't mean they have any control over the CPU that the CPU doesn't configure itself (together with the OS).
    – goldilocks
    Commented Apr 1, 2016 at 14:08
  • @goldilocks so if it causes an interrupt, doesn't the PIC have to service it and then in kernel space it'd say just ignore this? Or have I been spending too much time building an 8086 box?
    – SailorCire
    Commented Apr 1, 2016 at 20:44
  • I dunno. I just know in general processors implement interrupt vectors, but it's the OS that mostly decides what to do with them. Of course it can ignore stuff if it wants or needs to. Try setting all your pins to inputs and then connecting them to 3.3V. Guess what happens to the system? Nothing. It just keeps doing whatever it was doing. (Probably you shouldn't really do this, lol, but you can do it with at least a few of them.)
    – goldilocks
    Commented Apr 1, 2016 at 20:57

It's definately not just udev - it's a fex/bin/dtbs overlays magic. For VGA you better use an external media converter from GPIO/HDMI, hdmi-based ones are in a whoresale worldwide. VGA will be difficult or even impossible because of lacking of DAC's : it's an analog interface...

  • GPIO really doesn't work as DAC? That is very strange! I would have thought it could go both ways.
    – SailorCire
    Commented Apr 1, 2016 at 20:43
  • @SailorCire if you're using it like DAC - it will be too heavy-resource-load. use a dedicated DAC - it will be a way faster Commented Apr 1, 2016 at 20:51
  • I can always slap a ATmel or PIC device...however, there are ways to convert gpio to HDMI and the kernel will treat it as such? Just need to edit X.org?
    – SailorCire
    Commented Apr 1, 2016 at 23:06
  • it will be a way easier task Commented Apr 1, 2016 at 23:11
  • VGA is just an example. I want to connect a TFT display ment for an arduino. However, I'm looking for a generic solution so someone who wants to turn the GPIO into a USB port can follow the same procedure.
    – SailorCire
    Commented Apr 1, 2016 at 23:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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