Additional Feature Collection

[noctarius]

@dmitrydvorkin, @sombriks let's move the discussion over here and start a collection of ideas :-)

• Remove dependency on libgpiod and use ioctl directly
• With the above comes the requirement to implement the gpio character device api V1 and V2
• Functionality to return all available gpio chips
• Functionality to return the pinmux configuration (bias, and stuff) and pinmux name
• Functionality to return the gpio number, e.g. on IMX6 and some others: (chipNumber - 1) * 32 + lineOffset
• Functionality to configure Edge detection (with event triggering)
• Bulk operations

[noctarius]

Tbh, I don't really care for the removal of the libgpiod dependency which (together with the c++ adapter) is about 60K bytes. It'd be nice to save them, but it means we have to deal with API changes, as it just so happens with V1 and V2 of the gpio character device APIs.

If most chips have only a single gpio chip, I don't know, ours doesn't and just for debugging purpose I try to name all of them :-)

gpiochip0  gpiochip1  gpiochip2  gpiochip3  gpiochip4  gpiochip5  gpiochip6

Anyhow, is the list above missing anything else for now?

[dmitrydvorkin]

gpio chips list are located at
/sys/class/gpio/gpiochip < N >
so Chip or whole module constructor can list them first and then return as the list of options to choose in Node configuration dialog in NodeRed. it will help user to do less typing or make stupid mistake of entering wrong chip name.

I am not good in NodeJS, so giving this idea to you, guys
if there is only one chip (in most cases), you does not have to enter anything and it is already choosen in drop-down node configuration menu. It is usability.

[dmitrydvorkin]

Functionality to return the pinmux configuration (bias, and stuff) and pinmux name

• never cared about this in real projects :)

Functionality to return the gpio number, e.g. on IMX6 and some others: (chipNumber - 1) * 32 + lineOffset

• same comment

Functionality to configure Edge detection (with event triggering)

easy:
struct gpioevent_request ereq;
ereq.lineoffset = 0;
ereq.eventflags = GPIOEVENT_REQUEST_BOTH_EDGES;

ioctl(fd, GPIO_GET_LINEEVENT_IOCTL, &ereq);

three constants GPIOEVENT_REQUEST_* are defined there
https://elixir.bootlin.com/linux/v4.8/source/include/uapi/linux/gpio.h#L112

Bulk operations

• could be useful, but event triggering gives a lot more.

[noctarius]

See, that's how priorities differ. I think event detection is nice, but we're just polling since we basically have modules either being plugged in (and booted) or not. No quick changes.

The issue with event detection is not how to make it happen in the Linux gpio api itself, but those events need to be enqueued into the actual nodejs event loop. And there's nothing like "immediate reaction" to the event since nodejs has pretty hard rules in what order certain types of events are executed.

[dmitrydvorkin]

No quick changes

• button press/release (yes, it is gpio event). May happen rather quick and you can't do simple polling to detect it correctly. Or polling period should be rather small - requires a lot of CPU for that!

GPIO events can be read like this:
struct gpioevent_data event;
read(pin->fd, &event, sizeof(event));

it may be called at any time and it will return the timestamp and event type.
it may be repeated to check if there are more then 1 event is happened - like till "EOF" reading of the file.
You will never loose the butto press/release using this interface and you can call it on "free time" of your app.

I suspect, there are something in NodeRed/NodeJS that can be used as "event queue"

[noctarius]

You misunderstood what I meant. Nodejs is single threaded and uses an event loop internally. You can register certain types of events to be executed inside the event loop. But there is a hard order of how the different types of events are executed to prevent dead locks. That means you can generate a trigger event for the button press, but you can't react too it immediately. The button may even not be pressed anymore when event is finally handled (depending on the other code running). For more information see https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/. That means we need to see and think about how the handling in nodejs should happen. Just to make sure it's built in a way to be future proof.

[dmitrydvorkin]

yes, thanks for explanation! BTW, with events gpio api we will never loose the event.
so no need very short polling inverval to catch the line switches

[khill-fbmc]

I would be happy to help with testing on a physical platform. I mentioned here that I am working on a RockChip board.

I'd like to chime in and say I would prefer an interface where I can:

const pin3 = new Pin(3); // Internally this would map to `new Line(new Chip(), n)`
pin3.requestOutputMode();
// which for me in the instance 

It was unclear to me at first how the chip number and line were retrieved, but then found this tool's use:

That was how I found out how to get:

const chip = new Chip(1);
const line = new Line(chip, 31);

When I landed on Radxa's doc's for their GPIO I didn't see at first how to get that info, when they were giving the GPIO numbers

[khill-fbmc]

By the way, it works as is, I was able to get the first example here to blink a LED :)

[sombriks]

@khill-fbmc this is a nice proposal, By using pin we would assume the first gpiochip found and map one pin to one line.

the tests will be very appreciate, i am working on how to make github actions proper run tests so we can get more confidence on the current codedabe.

[khill-fbmc]

This may not be the best way to do this, but here is how I made a little class to use gpiofind and collect all the chip and line numbers

/**
 * Map the gpio pin numbers to their (chip, line) numbers
 */
async init() {
    for (let pinNum of this._pinList) {
        let { output } = await this._gpiofind(pinNum);
        const [chipNum, lineNum] = output.replace("gpiochip", "").split(" ").map(Number);
        this._log(`🔎 Found PIN_${pinNum} on Chip ${chipNum}, Line ${lineNum}`);
        const chip = new Chip(chipNum);
        const line = new Line(chip, lineNum);
        const newPin: GpioPin = {
            pin: {
                num: pinNum,
                formatted: `PIN_${pinNum}`,
                id: `gpiochip${chipNum} ${lineNum}`,
            },
            chip: {
                num: chipNum,
                raw: chip,
            },
            line: {
                num: lineNum,
                raw: line
            },
        };
        this.pins.push(newPin);
    }
}

this._pinList was assigned in the constructor with a simple [3,5,7,.... etc]

This makes getting the Line by gpio pin number very easy :)

gpio(pinNum) {
    const pin = this.getPin(pinNum);
    return pin.line.raw;
}

getPin(pinNum: number): GpioPin {
    this._ensureInitComplete();
    const pin = this.pins.find(({ pin }) => pin.num === pinNum);
    if (!pin) throw Error(`PIN_${pinNum} is not a valid pin.`);
    return pin;
}

[khill-fbmc]

[noctarius]

I think the issue is, that GPIO numbers aren't just assigned in a linear fashion to pin numbers. Many SOCs have specific GPIO numbers assigned to specific pads and specific chips.

The most obvious example is a Raspberry Pi, where the pin numbers (on the header) have absolutely nothing to do with the GPIO numbers (see https://pi4j.com/assets/getting-started/pins/headerpins_in_header.png). But this is true for almost all ARM SOCs.

On an i.MX6, as another example, the GPIO number is calculated as 32 + 4 = 36 (meaning port 2/chip1, pin 4/line4). That said, they always assume 32 lines per chip (https://www.digi.com/resources/documentation/digidocs/90001546/reference/bsp/cc6/r_general_purpose_input_output.htm#:~:text=LinuxGPIO_num%20%3D%20(%3Cimx6_gpio_port%3E%20%2D%201)%20*%2032%20%2B%20%3Cimx6_gpio_pin%3E). I'm not sure this would hold true for every chip though.

With the two above examples, the more complicated issue though, what would PIN mean to the user? Is it the header pin? Is it the GPIO number? Is it just a linearly increasing number? If so, how many lines to assume per chip?

[khill-fbmc]

Here's the alternative example from a RaspberryPi: https://github.com/radxa/kernel/blob/d7f6b85f6fcfdf510f382174bf08368e73fb9287/arch/arm/boot/dts/bcm2837-rpi-3-b.dts#L61

I don't know that file format, but I can see GPIO23 instead of things like PIN_3 so that makes sense that on a pi you couldn't use my solution. I assume on a pi you would have to gpiofind GPIO23?

[noctarius]

Yes, for example. But it also means your split magic wouldn't just work. Unfortunately, I don't think there's any way to do it. Many boards (especially custom ones) will not have any names set up, because "why?".

I like the simplified version, but I wouldn't know how to make it work in a generic way, and adding something which works on one board, or if you pass in the name config (which doesn't make things easier and you wouldn't even have to, you can build the table from the Linux kernel lookups), I'd still only works on board with the gpio lines named.

PS: The file format is the device tree descriptor. That file describes the board and how components are interconnected. Since there isn't a BIOS or something that can discover components (like in a PC) and you normally have hardwired connections (so discovering every boot wouldn't make sense), Linux uses device trees to learn about the components. Every ARM board uses them, (I think) every RISC-V board uses them, too. Here's some info: https://docs.kernel.org/devicetree/usage-model.html

[khill-fbmc]

Thank you for such a detailed reply. It makes sense.

I had the idea to make a wrapper around your library to extend it with board specific mappings, so maybe I will think more on that.

[noctarius]

My pleasure and no worries, before I had my own startup working directly with ARM boards and Linux (DTS), I had neither knew. The only thing I knew was that the raspi has those "weird" overlays to enable hardware extensions. Now I know why. They add additional components to the device tree :-)

[khill-fbmc]

I recently came into possession of a Pico Pi H, so I am learning MicroPython alongside the Rock5 as well :)

[d-beamon]

Hi!
It would be great to support all the line configuration flags that libgpiod supports. Mainly when configuring a line as an input line.
For instance:

• gpiod_line_edge
• gpiod_line_bias
• gpiod_line_drive