Hi,
in theory - yes, the software-based bottom half could be replaced by a
one that simply converts data received by the top half to whatever the
hardware expects.
However, I think that in the proposed form, the driver would be way too
limited to be useful. Judging from what I quickly read from sources for
RP23xx/RP2400, there seem to be some instructions for the PIO hardware
that my implementation does not have. It can change I/O direction, I/O
values, read values and jump between instructions (which my
implementation calls steps) - nothing more.
Thinking of it, instead of having the instruction (step) that can do all
the things, the better approach would be to build the top half as a VM -
driver/userspace would provide instructions to it and the bottom half
would do any conversion for either hardware or software-based I/O. That
would map more closely to what current implementations do and still
allow for creating software-based lower half.
As for RMT on ESP32, I am not familiar with that so I don't know.
Other than that, it's slash and nuttx.git (same as if pulling from
github except you remove the apache part from apache/nuttx.git),
pio_devel is a branch name in that repository (which is itself a clone
from github)
On 2025-12-31 13:18, Alan C. Assis wrote:
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.