Last time we wrote an HD44780 driver that takes GfxLCD compatible display and works with CharLCD package. This is nice because we can use big ILI9486 as a character display.
You may ask, why?
Because with ProxyLCD we can see a big output from Symfony 🙂 And because we can 🙂
Today we will focus on two bugs from a previous part and we will see if all chipsets can work with HD44780 driver.
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 🙂
Today we combine the power of HLK-PM01, PIR HC SR-501, DHT11 and a light detector.
Together they create a nice looking multipurpose Node One. I wanted to do it for some time but the last piece was missing. I didn’t have an idea how to create a box for components.
Few days ago I found a perfect case named Z27. It has all I wanted, socket, plug and enough space for NodeMCU v3.
Python code @ GitHub
LUA code @ GitHub (more…)
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.
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.