Periphery OOP Interface

[jptech]

As per @xxAtrain223 's suggestion, we should investigate if we should refactor periphery to use a parent abstract class.

From the original post:

It would be nice if there was a periphery abstract class to provide a unified interface.

For example:

class Device
{
public:
    std::vector<uint8_t> readBytes() = 0;
    std::string readString() = 0;
    void write(std::vector<uint8_t> data) = 0;
    void write(std::string str) = 0;
    void close() = 0;
    ...
};

class Serial : public Device
{
public:
    void write(std::string str)
    {
        this->write(std::vector<uint8_t>(str.begin(), str.end()));
    }
    ...
};

class Mmio ; public Device
{
public:
    void write(std::string str)
    {
        this->write(0, std::vector<uint8_t>(str.begin(), str.end()));
    }
    ...
};

int main(int argc, char** argv)
{
    Device serial = Serial(/* Connection settings */);
    Device mmio = Mmio(/* Connection settings*/);

    serial.write("Hello");
    mmio.write("Hello");
}

[robobenklein]

Honestly with only two classes I've seen overlapping that much, I'm not sure that the work to benefit trade off should be made here until 1.0 maybe?

We don't really use MMIO, do we? And I don't see enough overlap to gpio or i2c for this to apply to them, unless I'm just looking in the wrong direction?

[argvrutter]

Agreed, each protocol is fairly distinct from each other, I think the way it is already organized is sensible.

[argvrutter]

In retrospect, I changed my mind, this could be a nice feature for implementations that could be used with more than one comm protocol (ie navx)

[robobenklein]

Probably just want to push this to an after-comp release.