Feature request and observation

[tchilton]

Hi,

Like the idea of the gpio tools to simplify GPIO pin control and I recognise that this seems to be a fairly fast moving project at the moment, but there seem to be a couple of gaps.

1. The documentation says that there is a big benefit over the /sys/class predecessor in that you can seize a pin and work on it, yet there is no way to generate a full pulse, all you can only generate an edge / level transition, before having to exit gpioset (loosing your lock on it), then run another separate gpioset command to complete the pulse. This runs the risk that you may not be able to seize the pin again. In many ways, its similar to its predecessor at this point, thus potentially leaving the pins in an undefined state. Who normally checks return codes from command lines ?

2. The --mode=time option allows you to delay the time before gpioset returns, thus giving you most of what you need to form a full pulse. Currently though this offers no benefit above a simple sleep command in a script as nothing happens once the time expires, except a script reading another command.

3. The --mode=time option provides a --sec option and a --usec option, but there is no --msec option, so this is inconsistent

A couple of very useful enhancements would therefore be :

1. Allow a single invocation of GPIOSET to generate a full pulse, the initial seize of the pin, set its initial state, delay a specific time, then set it to a second state before exiting

2. Add consistency by adding a --msec option, giving the three most useful SI units for time

An example use case that I'm looking at is driving an open drain reset pin, where I need to grab the pin, drive it low for a period, then release it back to a high state. Currently I need 3 separate commands - edge 1, delay and edge 2. Combining these to one command would be much clearer in the script.

3. A more complex option would be to allow a command line syntax that allows you to define pin transitions and delays (left to right on the command line), thus allowing you to set pins to a state, then toggle them in a defined order and with a defined time delay between each event.

i.e., set pins initial states to X, then set pin 1 high, delay 10ms, set pin 2 high, delay 5us, set pin 2 low, delay 5us, set pin 2 low

This would allow basic sequencing with timing across a number of pins and would probably meet many simple IO requirements without having to delve into microcontroller territory.

[warthog618]

You are talking about the libgpiod v1 tools. Those were obsoleted some time ago by updated tools in libgpiod v2 that address your issues, though not quite in the way you have suggested.