Collaborate!

[scowcron]

@therealprof @jamwaffles

At leas the three of us have some code lying around trying to accomplish different things with this little display. This repository was offered up as a forum for putting together an SSD1306 driver we can all work with at rust-embedded/wg#39.

I think we should lay down what our various goals are and decide the best path forward here.

[scowcron]

It seems like the biggest bit of what I've worked on that seems to be useful here is the command interface. One route we may want to take, and I think it's a good idea, is to pull that bit out into an ssd1306-cmd crate so that if someone doesn't like the abstraction we end up adding, they don't have to start from scratch.

It could include I2C and SPI implementations of an ssd1306-cmd::{Write, Read} traits (read isn't useful for i2c, but it is for spi) on the embedded-hal, or just the enum and conversions to bytes to be sent.

[therealprof]

I'd say let's keep it all in one piece, I'm not a big fan of splitting up things that really belong together into too many pieces...

From where I'm standing I can see the following layers:

• Generic communication layer (I2C and SPI, maybe parallel too at some point) (@jamwaffles)
• Commands (@scowcron)
• Setup
• Output (Buffered drawing primitives @scowcron, Framebuffer Iterator @jamwaffles, Direct character output @therealprof)

In the end I would expect that an application can set up the communication channel, consume it into a SSD1306 communication layer, do some application specific setup (i.e. set up orientation, size, charge pump), and consume it into an output channel and use the display.

[jamwaffles]

Oh hello!

I agree. I don't think we need to split the command interface out right now, although exposing a configuration interface to the user to perform common commands would be useful. Things like "set rotation to Xº" as opposed to "send some hex down the wire". If it could be reused by the Builder interface that would be a bonus.

I'm going to open issues for the ideas, features and fixes I have in my head. I'd welcome you all to do the same to get a more granular picture of what people want.

How do we want to handle contributions? I think we should stick to PRs for now for visibility on changes, but I'm certainly not opposed to adding contributors to this project.

[jamwaffles]

@scowcron

It seems like the biggest bit of what I've worked on that seems to be useful here is the command interface.

It is, and thank you for doing the legwork getting it working. I hope you don't mind me ripping off your code...

[scowcron]

I hope you don't mind me ripping off your code...

That's why I published it :)

[therealprof]

So I was just looking into how to get the Builder interface to work with different drawing interfaces and I'm not quite sure how to build that into the builder interface. Ideally each drawing interface should have their own type so the interfaces are truly separate but once the connect_xxx() has been called the boat has pretty much sailed.

[therealprof]

So thinking a bit more about this. I think we can introduce display modes by separating the current buffer initialisation from the interface initialisation. Then we could use different types for the different modes and into_...() functions to turn the initialised display interface into a specific output interface.

I'd have called @jamwaffles egfx, mine char and @scowcron pixbuf.

Comments?

[jamwaffles]

Moved to #25