Pyboard + SSD1306

General discussions and questions abound development of code with MicroPython that is not hardware specific.
Target audience: MicroPython Users.
User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Pyboard + SSD1306

Post by pythoncoder » Fri Aug 03, 2018 7:37 am

It's a software implementation. I've submitted a PR to try to clarify the docs.
Peter Hinch
Index to my micropython libraries.

doublevee
Posts: 75
Joined: Mon Jul 02, 2018 11:09 pm

Re: Pyboard + SSD1306

Post by doublevee » Fri Aug 03, 2018 5:00 pm

Thanks Peter - I'm sure some clarification in the docs will help others.

So at the end of the day, the Pyboard doesn't currently support hardware I2C?

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Pyboard + SSD1306

Post by pythoncoder » Fri Aug 03, 2018 5:52 pm

The Pyboard supports hardware I2C via the pyb and machine modules. But the "Primitive I2C operations" used in the SSD1306 driver are unavailable, presumably owing to hardware limitations. Consequently to run the SSD1306 driver on the Pyboard requires software I2C.
Peter Hinch
Index to my micropython libraries.

User avatar
boochow
Posts: 30
Joined: Sat Dec 16, 2017 9:36 am

Re: Pyboard + SSD1306

Post by boochow » Tue Aug 07, 2018 3:49 pm

Hi Peter,

I think that rewriting write_data() method using mid-level I2C API makes this driver usable with hardware I2C.
I did it with hardware I2C class of my bare metal Raspberry Pi port and it worked fine.

Code: Select all

    def write_data(self, buf):
        self.i2c.writeto(self.addr, bytearray([0x40]), False)
        self.i2c.writeto(self.addr, buf)

doublevee
Posts: 75
Joined: Mon Jul 02, 2018 11:09 pm

Re: Pyboard + SSD1306

Post by doublevee » Fri Aug 10, 2018 7:44 am

Hi boochow,

I was looking at exactly the same idea as it seemed only a small change was needed to utilise the hardware functions, especially as the Pyboard is the official product.

I was looking at prepending the framebuffer bytearray with 0x40 as I wasnt sure if calling the writeto method twice would work for the bulk data for the framebuffer but it looks like I was overthinking it.

Many thanks for your message - I will try this but I see no reason for it not to work. I will post back once I return from holiday.

User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Pyboard + SSD1306

Post by pythoncoder » Fri Aug 10, 2018 5:36 pm

In my testing this does not work. With my test data the display is reflected about both axes, resulting in an upside down mirror image. This is because the first self.i2c.writeto() is ignored by the hardware: you can comment out the first line without affecting the (wrong) outcome. The code was written as it was because the chip requires both transfers to occur without an intervening stop condition.

The correct way is to prepend the buffer with 0x40 in a way which won't break existing applications. This has been discussed on GitHub here and here.

Damien wrote this to minimise allocation - hence the use of the self.temp buffer. I haven't yet figured out a way to modify write_data to work with writeto() without allocation and I suspect it is not possible. The following (allocating) hack works on the Pyboard with both software and hardware i2c.

Code: Select all

    def write_data(self, buf):
        self.i2c.writeto(self.addr, b''.join((b'@', bytes(buf))))  # prepend with 0x40  Co=0, D/C#=1
I think a proper solution needs to wait for PR4020.
Peter Hinch
Index to my micropython libraries.

User avatar
boochow
Posts: 30
Joined: Sat Dec 16, 2017 9:36 am

Re: Pyboard + SSD1306

Post by boochow » Sat Aug 11, 2018 7:26 am

Hi Peter, thank you so much for your comment.
I'm sorry I was misunderstanding the mid-level API.
The second line of my code re-sends the slave address again, so it cannot produce the expected result.
I think a proper solution needs to wait for PR4020.
Yes, PR4020 looks good and simple enough.

Post Reply