Limifrog lessons learned

Discussion and questions about boards that can run MicroPython but don't have a dedicated forum.
Target audience: Everyone interested in running MicroPython on other hardware.
Post Reply
User avatar
marfis
Posts: 168
Joined: Fri Oct 31, 2014 10:29 am
Location: Zurich / Switzerland

Limifrog lessons learned

Post by marfis » Sun Dec 04, 2016 7:51 pm

Spent some time with my limifrog board and the OLED module. Great HW. Sadly, there isn't activity anymore on https://github.com/LimiFrog.

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

make BOARD=LIMIFROG
in the stmhal directory and flash according to https://github.com/LimiFrog/LimiFrog-SW ... mifrog.pdf
- a correct powerup sequence is necessary to enable the regulators on the board, see https://github.com/hoihu/projects/blob/ ... mi/limi.py
- to access the OLED use the driver of @tobbard https://github.com/tobbad/micropython_l ... seps525.py (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: https://github.com/hoihu/projects/blob/ ... seps525.py

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 (https://github.com/peterhinch/micropython-font-to-py). 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 https://github.com/peterhinch/micropyth ... 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:
https://github.com/hoihu/projects/blob/ ... mi/test.py

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

Re: Limifrog lessons learned

Post by pythoncoder » Mon Dec 05, 2016 7:14 am

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.
Peter Hinch

User avatar
marfis
Posts: 168
Joined: Fri Oct 31, 2014 10:29 am
Location: Zurich / Switzerland

Re: Limifrog lessons learned

Post by marfis » Mon Dec 05, 2016 8:23 pm

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.

User avatar
marfis
Posts: 168
Joined: Fri Oct 31, 2014 10:29 am
Location: Zurich / Switzerland

Re: Limifrog lessons learned

Post by marfis » Mon Dec 05, 2016 8:37 pm

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 https://github.com/hoihu/projects/blob/ ... ter.py#L70 ."screenwidth/height" could then be directly taken from the framebuffer (the "device" would be the framebuffer instance)

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

Re: Limifrog lessons learned

Post by pythoncoder » Tue Dec 06, 2016 8:23 am

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 ;)
Peter Hinch

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

Re: Limifrog lessons learned

Post by pythoncoder » Sat Dec 17, 2016 1:37 pm

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 https://github.com/peterhinch/micropython-samples.git and the example code here https://github.com/peterhinch/micropyth ... -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.
Peter Hinch

Post Reply