Julian Coleman <jdc%coris.org.uk@localhost> writes:
>> > #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.
That's what I missed. On a device you are dealing with, pin N is
*always* wired to an LED because that's how it comes from the factory.
My head was in maker-land where there is an LED because someone wired
one up.
> 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()
That makes sense, then. But how do you denote that logical high turns
on he light, vs logical low?
>> 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 just remember lights before LED, and the fact that they are LED vs
incandescent is not important to how they are used. I don't know what's
next.
But given there is an led system, there is no incremental harm and it
seems ok.
>> 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"?
Or even "GPIO_ENVSYS_INDICATOR" because there might be some binary
inputs later that get hooked up to some other kind of framework.
> 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);
> ...
So I see the ACT_LOW.
GPIO_PIN_LED is an output, but presumably this means that one can no
longer use it with GPIO and only via led_. Which seems fine. Is that
what you mean?
> 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);
Do you mean MD, or MI?
> 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.
I 95% follow, but I am convinced that what you are doing is ok, so to be
clear I have no objections.
Attachment:
signature.asc
Description: PGP signature