On Tuesday, July 05, 2011 15:15:15 Andreas Pretzsch wrote:
Am Dienstag, den 05.07.2011, 13:44 -0400 schrieb Mike Frysinger:
unintentional side effects like "gpio value". then we could change all the others to return 0/1 based on whether they succeeded, not based on the level of the gpio pin.
Didn't quite get that. In terms of "gpio value" = "give me the current (output latch) value without setting it to input if it's an output" ?
yes. all it does is return gpio_get_value().
We can't change the return value of "gpio input", as it's out in the wild and would break existing scripts.
i dont think this is that big of a deal
I'd say clear/set/toggle are changeable, don't see any legit return-value-usage here. For 100% backward compatibility, one could leave them as they are and use 0|1 as new actions with return 0, as proposed.
So these variants: gpio clear|0 => set to output, write 0, return success gpio set|1 => set to output, write 1, return success gpio toggle => (set to output), toggle output, return success gpio input => set to input, return pin value gpio value => return current pin/latch/whatever value or gpio clear => set to output, write 0, return 0 gpio set => set to output, write 1, return 1 gpio 0 => set to output, write 0, return success gpio 1 => set to output, write 1, return success gpio toggle => (set to output), toggle output, return new_val gpio input => set to input, return pin value gpio value => return current pin/latch/whatever value
Not perfectly symmetric, but the best way out I can think of. Maybe "get" instead of "value", as it's more usual. OTOH, get (to some people) implies "set to input", so value is more explicit.
i prefer to have the command be simple and throw the extended logic onto the people writing scripts rather than trying to encode script logic into the commands themselves
Also, this leads to unexpected side effects with complex constructs,
e.g. consider this environment: setA=gpio set PF1 setB=gpio clear PF2 setAB_separate=env run setA ; env run setB setAB_concatenated=env run setA setB setBA_concatenated=env run setB setA
While executing "setAB_separate" and "setBA_concatenated" work as expected, "setAB_concatenated" will only run setA, but not setB, as setA "failed" (ret=1). [1] The same would apply to e.g. && constructs.
ive never used the shell in u-boot, but couldnt the first logic be: setA=gpio set PF1 || : setB=gpio clear PF2 || :
Not fully, you'd need "gpio set PF1 || true". Not that this makes it less ugly...
but it is doable if we want to just say now "ignore the value" without changing any code -mike