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.
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.
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
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.
First brick for my ‘secret’ project is ready. It is a remote LCD based on NodeMCU. Such node has a char lcd (HD44780) connected to it and listens for incoming broadcast messages. After receiving message that is for this node it displays content. It is nothing new but lets quickly summarize it.
If 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.