Raspberry Pi, Python and graphical LCD 122×32 @ NJU6450

Before we do a restart and focus on creating GfxLCD module we need to know something more about other graphical displays. I have two more, one is monochrome 122×32 on NJU6450 chipset and second is OLED 0.96″ on SSD1306.
This time we gonna run NJU6450.
Why we need to know more? Because we will create a main gfx class and it’s drivers for different LCDs. And we should know biggest differences so we can be prepared for them. Like TFT is a color display but NJU is monochrome, so what to do with colors? How to do a conversion?
But before we answer those question let’s wire it and do a simple drawing.




Raspberry Pi as a Node

We have the remote nodes that work with NodeMCU board with message handler. But I found out that I forgot to implement such mechanics for RPi ๐Ÿ™‚ I’m talking about handlers and listeners. On NodeMCU we start a server that listens to broadcasts on port 5053 and passes the message to registered handlers.

This time we will create a Python server and we will write our first handler to support char LCDs. It will react to the same messages as NodeMCU’s one. This will allow us to use ProxyLCD with it and it is a first step to support TFT LCD.

Code on GitHub
Installation from PyPi:

pip3 install message_listener

And handler incorporated into CharLCD. It is also available as submodule in Doton project

Symfony ProxyLCD bundle

Finally 3rd phase of project – integration with Symfony ๐Ÿ™‚ But I’m afraid it is not the last part ๐Ÿ™‚

What is the goal of this Symfony bundle? It will hook to dump() command and send content to ProxyLCD application. It will transform any array or object to string representation.
Source on GitHub
Install via composer, package name: kosci/proxy-lcd-bundle


Proxy LCD – desktop application

In first part we saw a summary (hardware and software) of remote LCD. Such remote LCD works on NodeMCU and can be accessed via network. It was first stage of bigger project.
Now is time for second part, a desktop application. Its main task is to manage remote LCDs and provide a way to send content from computer to display.
One may add/remove node and set a stream option. What is stream option?
App works in two ways (one for now :P, second option in 3rd phase) if it receive content and it is not a proper packet it iterates over all added lcds and streams data to them. Difference between display and stream is that stream as name says is just a data stream and it send chars one after another. When it reaches end of available space on display it starts over.
In case of packet it will send formatted content to node.

Get from GitHub

Part 1 – remote LCD

CLI on Raspberry Pi

Using LCD HD44780 on Raspberry Pi – part 3: upgrades and tests

Before we add new drivers lets do some more cleaning, upgrading and add nose tests.

First we will clean driver class and remove manual 4/8 bit function usage.

Next we will add abstraction class to our driver to force required functions implementation.

Finally we will add Nose framework for tests. And add few simple tests.

This time I will attach ziped source code


Using LCD HD44780 on Raspberry Pi โ€“ part 2: drivers

lcd_20_tutorial_2If we look at our code from part one we will see that more than half functions are used to communicate between Raspi and lcd. In this tutorial we will separate low level function from user functions and create a driver class. Why ? If we connect later our LCD by i2c we will just add new driver and it will work.

All function used to communicate directly with display will be moved to separate driver class, a GPIO driver class. Such basic function are _write and _write4. But in our case it is not so simple, all around a code we have some GPIO.output(self.PINS[‘E’], 1) lines, like inย _send(self) function. We will do something about it, but lets start from small things.

Current CharLCD class will be refereed as user driver or user class, and new one as driver or low level driver.