M-A

Hi! For the waveform generation code, I've started planning on a formal API (see https://periph.io/x/periph/conn/gpio/gpiostream) but haven't upstreamed the implementation yet. As for the implementation, it seems these devices are...

I'm starting to think; independent of the DMA work, it'd be good to have a CPU based "bitbang version" of the GPIO streaming. One device for write, one for read....

I meant adding a streamer and reader to https://periph.io/x/periph/experimental/devices/bitbang that would accept a [`*gpiostream.Program`](https://periph.io/x/periph/conn/gpio/gpiostream#Program) for write and a [`*gpiostream.BitStream`](https://godoc.org/periph.io/x/periph/conn/gpio/gpiostream#BitStream) for read. Unsure about the names to use for these but...

Sorry I didn't have time to play with this locally and won't likely have time until this weekend. :/

There's an interesting issue with this, in the case of CPU memory mapped pins, as the CPU driver may have overridden the pins.

Do you have one available? If so, you could extract `/proc/devicetree/model` and you could start something from there. The first step is to implement `Present() bool`

Renamed the issue since as long sysfs works, basic functionality should be there.

Here's a simple example for the CHIP: https://github.com/google/periph/blob/master/host/chip/chip.go#L125

`/proc/device-tree/compatible` is equivalent to `/sys/firmware/devicetree/base/compatible`, It'd device-tree, not devicetree, sorry I typo'ed above. It happens that not all pins can be used, for example on the Raspberry Pi there's a...

For the [bcm283x](https://periph.io/x/periph/host/bcm283x) driver, I decided against exposing these (GPIO47 to 53) so apps do not play with them by accident.