drivers: add generic interface types

[aykevl]

Here is a starting point for interfaces that drivers should implement, to make it easier to write generic code. The goal is to get all drivers to implement generic interfaces (like driver.Accelerometer), for example:

• Accelerometer (mma8653/mpu6050)
• Gyroscope (mpu6050)
• Magnetometer (mag3110)
• Thermometer (mag3110/mpu6050)
• Display (see #6)

But for that to work, the current drivers need some updates to have a better interface.

[deadprogram]

I think this is interesting idea, but I'm not sure we know enough to define all of this yet. Perhaps it would be better to have "de-facto" interfaces by trying to define compatible functions, but not yet enforce them.

At some point in the future, we have enough devices of a certain category to extrapolate some common interfaces.

Or we just do it now with the devices we have, and adapt them as needed.

Anyone else have an opinion on this?

[aykevl]

I think you're right, we should wait with defining strict interface requirements and instead just try to keep drivers compatible where reasonable. And add strict interfaces only when necessary. Certainly no interface should be added when there is no driver for it yet, and perhaps only when there are at least 2 implementations. However, I think adding a "LED strip" interface could be done now already.

@maruel and @conejoninja may also have ideas.

[maruel]

Specifically for LEDs and small displays, I created https://periph.io/x/periph/conn/display The rationale is:

• It's close to standard image package but Draw() returns an error, which is important.
• Users can use a device specific Write(), if any
• Color conversion is done if necessary, it's trivial to send an animated GIF
• It's possible to re-arrange the pixels of a display.

The last point is interesting but sadly I haven't had the time to implement yet; the idea is that you may have a LED strip that is in practice arranged as a zigzag or as a linear scan, in this case you want to expose a logical 2D display so that the client doesn't have to mess with which pixel is where. The interface makes it relatively easy to create such adaptor.

I've also started playing with an environment package, the first item being Weather struct that contains the combo of what a BME280 can measure, albeit air quality should be added. My thinking is that GPS, Orientation would fit in this package.

[aykevl]

Specifically for LEDs and small displays, I created https://periph.io/x/periph/conn/display

Ah, I missed that one, thanks! I only saw the ssd1306 driver.

the idea is that you may have a LED strip that is in practice arranged as a zigzag or as a linear scan, in this case you want to expose a logical 2D display so that the client doesn't have to mess with which pixel is where.

I think this is best done separately from the driver itself. For example, you could write a LinearView for a linear scan based on top of the driver:

type LinearView struct {
    driver drivers.LEDArray
    width  int
    height int
}

Such a wrapper can then use any LED strip driver, without code duplication. The same goes for color correction, for example. Many systems won't need color correction so having it built in the driver may cause unnecessary overhead.

In general, I am very cautious with anything that looks like premature abstraction. Especially when you try to build software that must fit on a microcontroller, any layer of abstraction may cause additional overhead which you'd like to avoid.

I think this matter is really a question of what tinygo-drivers is. In my view, it is all about providing a generic interface to hardware with the least amount of abstraction as is practical. Other libraries can then use those driver interfaces and write more powerful stuff on top of it. For example, a gyroscope and accelerometer are not very useful on their own, you really need some library to fuse the sensors. Such a fusion algorithm should in my view not be part of the driver, and probably not be part of tinygo-drivers either.

[maruel]

I think this is best done separately from the driver itself. For example, you could write a LinearView for a linear scan based on top of the driver:

That's exactly my point.

Such a wrapper can then use any LED strip driver, without code duplication. The same goes for color correction, for example. Many systems won't need color correction so having it built in the driver may cause unnecessary overhead.

The reason I did color correction in apa102 driver on periph is because it has 13 bit effective range per pixel, so it was more efficient to do it here.

[aykevl]

That's exactly my point.

Ah, I see. I was misreading your comment.

The reason I did color correction in apa102 driver on periph is because it has 13 bit effective range per pixel, so it was more efficient to do it here.

Yes, that's a good reason to integrate color correction.