Hi KR, I think this is a good idea to have a more standard way to control Programmable I/O on NuttX, so your driver is welcome.
Do you think RPxxxx chips could be a good candidate to use it? Although not exactly the same idea of PIO, I think ESP32_RMT also could benefit from it. What should be the user/project name after git.kerogit.eu? I tried slash pio_devel, but it returns 403. BR, Alan On Wed, Dec 31, 2025 at 6:46 AM <[email protected]> wrote: > Hello, > > I would like to solicit feedback for a draft of generic Programmable I/O > driver. This driver is supposed to be a bus driver, allowing other > device drivers to control various circuits that require more complex I/O > - for example LCDs etc. > > I already have a working implementation of this outside of NuttX for AVR > 8-bit microcontroller where it can achieve 25kHz change frequency with > 20MHz main clock (there is no overhead of an RTOS though, I expect this > implementation's result to be a bit worse.) > > The aim is to: > > - allow the user (device driver) to submit a sequence of I/O operations > on GPIO pins/ports > > - perform these operations asynchronously from an interrupt handler of a > timer/counter device (to achieve relatively high precision and hopefully > the lowest overhead possible.) > > - have this driver split to higher and lower half so it can be used by > multiple architectures > > - also provide a character device option to control the I/O directly > from the application (at least for testing) > > The feedback I would like to solicit regards to these items: > > - Is there something like that already present in NuttX the I missed? As > far as I found, there seems to only be some code supporting PIO on chips > that support it in hardware (for example RP23xx) > > - A basic one - is this acceptable to be merged? (Is it worth it to have > such a feature?) > > - API - it currently only supports simple operations (I/O port direction > change, output value change, input value read), only triggered by the > MCU side. There is no support for triggering any actions based on > external events. Should it be extended in advance or somehow made > extensible? (The thought here is that at some point, someone may want to > change this into a generic API able to control both software-based PIO > like this implementation and hardware-based one like in the RP23xx - I > would like to find a balance between not overcomplicating things now and > not hindering future development, if it comes to it.) > > > I prepared a patch composed of few files as a skeleton of the > implementation. There is a Documentation file that describes how is this > supposed to work in more detail. Other files are fairly rudimentary - > they're mostly there to show directory structure I intend to create. > > This patch is available in a git repository nuttx.git at git.kerogit.eu > accessible through HTTP/S. (Trying to prevent bot traffic by not posting > the URL in machine-readable form.) The relevant branch is called > pio_devel. > > The patch does not contain any skeleton for the character device driver > - that would simply call the chain-related functions on one side and > provide read/write for values and ioctls for the rest on the other. > > > Any feedback or suggestions is appreciated. >
