Page 1 of 1

Limifrog lessons learned

Posted: Sun Dec 04, 2016 7:51 pm
by marfis
Spent some time with my limifrog board and the OLED module. Great HW. Sadly, there isn't activity anymore on

It took me a while to figure out things, so here are a few lessons learned. May serve to get you started.

- to build and deploy, run

Code: Select all

in the stmhal directory and flash according to ... mifrog.pdf
- a correct powerup sequence is necessary to enable the regulators on the board, see ... mi/
- to access the OLED use the driver of @tobbard ... (you'll need to spezify XSIZE, YSIZE in pixel)

The driver above is not compliant with the framebuffer module, so I changed it a bit. Since the framebuffer logic is now part of the master branch I was able to shorten the code (at the expense of some helper utilites like circle). This can be found here: ...

And good news: the frambuffer support has just recently been enabled to support RGB565 support (thanks @deshipu) and further optimized to fast-fill regions (that's from damien). So you'll get a nice speed increase.

If you are at that point, checkout peter hinch's font creator utility ( I used that to create a reasonable large font (23px) - the font provided by the micropython repo is way too small for a 160x128pixel display.

At the moment Peters Writer class implementation uses the 1bit framebuffer mapping hard-coded to speedup things. It will not work with the 16bit framebuffer. I issued this here ... y/issues/1 . He provided me with sample code to use the framebuffer's pixel method. With this modifications it is then possible to show some nice, large texts :)

Note that I also had to change some small things of the writer's implementation. This definetly needs cleanup and may serve just as example.

Some test code to see how everything fits can be found here: ... mi/

Re: Limifrog lessons learned

Posted: Mon Dec 05, 2016 7:14 am
by pythoncoder
Interesting. I'll review the Writer class in the light of the recent changes to the framebuffer module and your changes. I think my use of byte writes was probably an optimisation too far - using the pixel method is more portable. I assume you've found the performance to be OK?

Has the framebuf scroll method been fixed? When I last looked vertical scrolling by more than 8 pixels was broken.

Re: Limifrog lessons learned

Posted: Mon Dec 05, 2016 8:23 pm
by marfis
pythoncoder wrote:Has the framebuf scroll method been fixed? When I last looked vertical scrolling by more than 8 pixels was broken.
To me it works. I don't know how it was before though.

The way it works now is that the new content that is scrolled in has the same content as the content that was before there. It's "smeared" if you specify like 10pixels but I guess that sounds reasonable.

Performance wise it is more than enough for me. A simple test program that filled and cleared the display 100 times finished in 2.5sec (means a fill_rect of the whole screen takes about 12msec.). That's with an SPI bus clocked at 30MHz.

Re: Limifrog lessons learned

Posted: Mon Dec 05, 2016 8:37 pm
by marfis
One thing that I was thinking about... Should the framebuf class have the width and height values expose for other modules?

A text renderer like you have implemented could then take all the information from the framebuffer itself.

To me it would make sense since framebuf manages the whole display content and width / height seems like a natural thing to expose.

It would eliminate the ugly hack here ... ."screenwidth/height" could then be directly taken from the framebuffer (the "device" would be the framebuffer instance)

Re: Limifrog lessons learned

Posted: Tue Dec 06, 2016 8:23 am
by pythoncoder
That sounds logical.

I'll revisit this stuff soon. At the moment I'm getting to grips with uasyncio on the Pyboard which now supports millisecond level timing making it properly useful for us hardware types ;)

Re: Limifrog lessons learned

Posted: Sat Dec 17, 2016 1:37 pm
by pythoncoder
The framebuf scroll method does work now, but (by design) it leaves unchanged the region of the screen exposed by the scrolling. In my view it should be possible to have the method blank that space and I've raised issue #2692 to discuss this.

I've updated the SSD1306 section here and the example code here ... -to-py.git. The simplified Writer class now uses the framebuf pixel() method rather than using byte addressing. This sacrifices some performance in favour of compatibility with (hopefully) any device using the framebuf, regardless of mapping.

Regarding alternative code emitters, the Writer class is primarily a demonstration, and is designed to run on any MicroPython platform. Performance could be improved with native or viper at the expense of cross-platform capability. On small displays such as those supported by the SSD1306 device performance is adequate. On large displays with built-in frame buffers optimisation becomes more important, but in such cases Writer would need substantial revision to match the hardware.