Displays with driver subclassed from framebuf

Discuss development of drivers for external hardware and components, such as LCD screens, sensors, motor drivers, etc.
Target audience: Users and developers of drivers.
User avatar
pythoncoder
Posts: 3543
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Displays with driver subclassed from framebuf

Post by pythoncoder » Mon Aug 26, 2019 4:56 am

Inheritance from built-in types is not generally supported: Damien made the effort to support it in the specific case of Framebuf. I think the reasons were for efficiency and simplicity. Using composition rather than inheritance implies an additional lookup at the Python level. Some applications of graphics methods require the maximum performance possible. The Zen of MicroPython (as I understand it) is to prioritise performance over Python coding style.

The simplicity argument is perhaps less pressing, but if you subclass a driver from Framebuf you automagically have a set of useful graphics primitives as fast methods. The requirement specifications for libraries become very simple. For example for monochrome displays the requirements to support my nano-gui are:

"For a driver to support nanogui it must be subclassed from framebuf and provide height and width bound variables defining the display size in pixels".

Admittedly specifying a standard means of composition wouldn't add much. And, if you didn't fancy my GUI, there's nothing to stop you writing a driver using that approach.
Peter Hinch

Post Reply