GPIO in the kernel: future directions
GPIO in the kernel: future directions
Posted Jan 24, 2013 18:12 UTC (Thu) by jimparis (guest, #38647)In reply to: GPIO in the kernel: future directions by linusw
Parent article: GPIO in the kernel: future directions
There are lots of cases where you want things to happen simultaneously, but they're not time critical. For example, let's say you drive an RGB LED on a cell phone with three GPIOs. If it's currently yellow (R+G) and you want to change it to blue (B), you want to turn off two GPIOs and set one GPIO as a single operation. It's okay if the entire action is delayed by 250ms, but it's not okay to change one bit, then have a delay, then change the other two bits, because then you'll have a visibly long period with an unexpected third color.
Posted Jan 24, 2013 19:50 UTC (Thu)
by dlang (guest, #313)
[Link]
There is also the chance that changing multiple bits at once is much easier than changing one bit at a time.
If you were to use a parallel printer port as a GPIO (it has 8 outputs and 3 inputs IIRC), it's much easier to change all 8 bits at once than to change one bit at a time.
The only thing I find questionable with the concept is that it allows grouping GPIO lines that do not have any underlying connection, but that doesn't make things any worse than they are now (other than possibly fooling the programmer into thinking they are better than they are now), and the improvements in the code of things using GPIO lines can be significant.
one place this would make a huge amount of sense from a software point of view is if you are connected to a small LCD display through a parallel interface (very common for 16 character x 2 line displays for example).
with this interface, you can do
nibble = *c & 0x0F;
it would be much more work if you had to set each line independently.
GPIO in the kernel: future directions
output(nibble);
toggle(clock);
nibble = *c++ <<4 & 0x0F;
output(nibble);
toggle(clock);