Add driver for HT16K33 (8x8 matrix display).

[jose1711]

No description provided.

[peterhinch]

I am surprised you can do anything useful with nano-gui on such a minimal display. Do you have a photo to convince me?

[peterhinch]

On further thought I think this is a useful driver but not in the context of nanogui. The display is too small to display any GUI elements.

I think you should publish it somewhere else. I like the driver concept: framebuf methods will be usable on a tiny matrix. I would improve the driver to support larger matrices up to the 16x8 limit of the chip, publish it and draw attention to it in the forum.

However I can't take this on as part of nanogui. Sorry.

[jose1711]

I admit this is more a PoC than anything else but thing may improve with larger matrix displays - the largest I found backed by HT16K33 was 16x8 (https://pmdway.com/collections/monochrome-led-matrix/products/ht16k33-16x8-red-led-matrix-module) and if the bi-color mode lands in micropython.

FWIW here's a dial with the current time (09:30):

Not really accurate but you get at least some idea about the time.

My main motivation however was a usage of custom fonts - micropython does not offer a way to load custom fonts so far while nanogui coupled with font_to_py.py is a ready-to-deploy solution.

I see the reason why you're not willing to see such a small display support in the main branch. What would be really nice though is a generic framebuffer object which nanogui could draw on and then the user would blit (or any part of it) to a real display. Would you accept PR for this?

[peterhinch]

You don't need nanogui just to display fonts. You just need the Writer class for monochrome displays (CWriter for color). See this demo.

As for your suggestion it sounds interesting. I'll think about it and get back to you.

[peterhinch]

a generic framebuffer object which nanogui could draw on and then the user would blit (or any part of it) to a real display.

I've thought about this and I'm afraid I can't see the application. Why not just subclass FrameBuffer and write a show method which does the copying to the display? A buffer larger than the physical display could be accommodated. In this case, either approach would need a means of determining which part of the buffer was drawn.

The docs outline the subclass approach, which I'm sure you've seen to write your driver.

The benefit of this approach is that a show method is synchronised to the rest of the GUI. Unless that synchrony is maintained it is likely that there would be brief artifacts when displayed objects updated.

Ultimately I can't see what a generic driver would achieve over a simple custom one.