Hi, Thanks for the comments!
> > #define GPIO_PIN_LED 0x01 > > #define GPIO_PIN_SENSOR 0x02 > > > > Does this seem reasonable, or is there a better way to do this? > I don't really understand how this is different from in/out. > Presumably this is coming from some request from userspace originally, > where someone, perhaps in a config file, has told the system how a pin > is hooked up. The definitions of pins are coming from hardware-specific properties. In the driver, I'd like to be able to handle requests based on what is connected to the pin. For example, for LED's, attach them to the LED framework using led_attach(), and for sensors add them to envsys. I wasn't planning to use this for userland, but it might be useful for a config file (as you mention). > LED seems overly specific. Presumably you care that the output does > something like "makes a light". But I don't understand why your API > cares about light vs noise. And I don't see an active high/low in your > proposal. So I don't understand how this is different from just > "controllable binary output" As above, I want to be able to route the pin to the correct internal subsystem in the GPIO driver. > I am also not following SENSOR. DO you just mean "reads if the logic > level at the pin is high or low". > > I don't think you mean using i2c bitbang for a temp sensor. Yes, just reading the logic level to display whether the "thing" connected is on or off. A better name would be appreciated. Maybe "INDICATOR", which would match the envsys name "ENVSYS_INDICATOR"? > Perhaps you could step back and explain the bigger picture and what's > awkward currently. I don't doubt you that more is needed, but I am not > able to understand enough to discuss. Hopefully, the above is enough, but maybe a code snippet would help (this snippet is only for LED's, but similar applies for other types). In the hardware-specific driver, I add the pins to proplib: add_gpio_pin(pins, "disk_fault", GPIO_PIN_LED, 0, GPIO_PIN_ACT_LOW, -1); ... add_gpio_pin(pins, "power", GPIO_PIN_INPUT, 5, GPIO_PIN_ACT_LOW, -1); add_gpio_pin(pins, "key_normal", GPIO_PIN_SENSOR, 6, GPIO_PIN_ACT_LOW, -1); where add_gpio_pin() has: prop_dictionary_set_cstring(pin, "name", name); prop_dictionary_set_uint32(pin, "type", type); prop_dictionary_set_uint32(pin, "pin", num); prop_dictionary_set_bool(pin, "active_high", act); Then, in the MD driver I have: pin = prop_array_get(pins, i); prop_dictionary_get_uint32(pin, "type", &type); switch (type) { case GPIO_PIN_LED: ... led_attach(n, l, pcf8574_get, pcf8574_set); and because of the way that this chip works, I also need to know in advance which pins are input and which are output, to avoid inadvertently changing the input pins to output when writing to the chip. For that, generic GPIO_PIN_IS_INPUT and GPIO_PIN_IS_OUTPUT definitions might be useful too. Regards, Julian