new: Support for RC switches (initial version available)

[rck]

Hi guys,

For a small project I ported an Arduino/Raspi library to control 433/315MHz devices (https://github.com/sui77/rc-switch) to golang/periph.io.

This is the initial version: https://github.com/rck/rcswitch

What I would like to know is if this is something you guys would actually be interested in merging eventually? And if so, it would be great if someone could do some mentoring/review to get it into a reasonable shape. I think it is mainly okay and works for me, but there are some points I don't know how to resolve, like the "Exact naming" requirement. Like the upstream C++ project, this supports a whole range of chipsets, so how should the thing be actually named? And I'm sure there are other things that would have to be added like an "Example function", but I would do that after I know that there is some basic interest at all.

Regards, rck

[maruel]

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 essentially uni-directional, so I would recommend one Sender and one Receiver object. I also recommend against functions like SetPin() which make the internal state mutable.

For the name, I'm fine with making an exception when it makes sense.

[maruel]

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 think for it to work it needs @tve code, https://gophers.slack.com/archives/C4GBL0WPL/p1493362656635775 other than that, it'd be a pretty simple loop!

That means dedicating one core for the operation. It's fine on RPi3, but not on single core systems like CHIP or beaglebone. ¯_(ツ)_/¯

Once that's implemented, the rc switch driver could focus on the higher level communication parameters, which is what is relevant here IMHO.

[rck]

Hi,

the first answer perfectly makes sense. Sender/Receiver is a good idea, SetPin() and a likes should be kicked, and for the waveform I had the feeling that not every driver should reinvent the wheel here... So yes, in that direction I would know what to work on.

I also think the second part makes sense, but I'm not so sure about the conclusion. Should I just wait and you point me to the parts when they are upstream and I then rewrite the rc switch parts?

[maruel]

I meant adding a streamer and reader to https://periph.io/x/periph/experimental/devices/bitbang that would accept a *gpiostream.Program for write and a *gpiostream.BitStream for read.

Unsure about the names to use for these but roughly:

type GPIOReader struct {
  P gpio.PinIn
}

func (g *GPIOReader) Read(b *gpiostream.BitStream) error {
  ... magic happens
}

type GPIOWriter struct {
  P gpio.PinOut
}

func (g *GPIOWriter) Read(b *gpiostream.Program) error {
  ... magic happens
}

For this to work, we need the Realtime() function but also cpu.Nanospin() to be more efficient. I have a CPU specific prototype for both allwinner and bcm283x but they are not committed yet.

I think in the end it would result in a pretty robust solution, albeit wasting a CPU core. :)

What is needed here is someone to own and does this to completion.

[maruel]

Ported to https://github.com/periph/devices/issues/62.