We have a remote LCD Node that works on NodeMCU board. It has a 40×4 char LCD attached to it and displays text received via a network message. We also can use Raspberry Pi as a remote LCD. But all those LCDs are small. We need something bigger and we have it! This something is an ILI9325 graphical display. There is a huge difference between char and graphic but we can simulate char interface. Our GfxLCD library has an ability to display a text and with a little bit of tinkering, it should work :D.
This could bring nice results, imagine a dump from Symfony with multiline formatting thanks to the ProxyLCD project. Nice 🙂
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.
In last post we started moving from single purpose node to multiple purpose node by introducing handlers and listener. We also created our first handler for temperature sensor.
This time we will take next two steps. First create a handler for lcd module and remove server that it was using.
Next we will start using server_listener as message dispatcher to handlers. We will of course write it first 🙂
Last part was strange, we wrote a direct driver that has no real usage. We done it only because we kept compatibility. This time we will do something more useful, WiFi content driver. We will try and do in such way that only content is send. This is more friendly for network and sanity 😛
What does it mean? It means that we will add another driver to CharLCD. This will allow us to use remote LCD with Raspberry Pi and later with any application in Python. It should be possible to use it with LCD Manager package and this is something very interesting 🙂
As a remote LCD we will use HD44780 (40×4) hooked to NodeMCU via i2c (but we know that we can plug any LCD via gpio or i2c 😛 ) and it will listen to broadcast messages.
Rpi (with CharLCD and driver) will broadcast UDP messages into network.
Time to take another step with NodeMCU and HD44780. This time we will separate driver logic from lcd logic. Why? Because it is much more flexible for our lcd (direct and bffered) to have general write, set_xy and move wiring specific logic to driver. This way we can just swap gpio with i2c without any problems.
This imply that we will also write i2c driver 🙂
Another matter is hooking screens with size 40×4. In fact they are two smaller lcds, 40×2, with shared all signals except E1 and E2. How it works? You set required signals and select top screen with E1 or bottom with E2.
Lets get to work.
Code is available in boilerplate (more…)
Our module displays strings as soon as function write is called. It is mostly enough but sometimes it is better to prepare what we want to display and then display it. Such action uses buffer and that why I’m calling this buffered mode.
We made something like this in CharLCD so we can convert idea to NodeMCU. Due to LUA characteristic both modes are combined into one module.
We played a little with lcd and we know that it works 🙂 It is a good idea to create a class that can be used in any project. Such class must allow setting width, height and pins if they are different from default one. It’s behaviour is based on lcd direct from CharLCD python class.
That means it is gonna display chars directly without buffer.