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.
Due to memory problem I looked once again at the code and.. I found that I’m not using classes properly.
Why? Because every function and attribute were static. I didn’t use self or anything similar.
I scratched my head, looked into google and rewritten temperature sensor.
It can create class instances with self values and static functions. (more…)
PANIC: unprotected error in call to Lua API (not enough memory)
I just wanted to hook two LCDs and it was overkill. This woke me up. NodeMCU / ESP8266 is not a multi-purpose node. It is good at doing its simple jobs and not doing all at once.
With this I’m gonna slightly change next steps. After next project I think I’m gonna consider moving to C. I really like fast development with LUA and I think it is good choice for small things but C is the King.
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 🙂
We have a nice NodeMCU server for LCDs. But there is one catch. We can control one LCD or all connected LCDs. But imagine that we have two LCDs and we want to display different content on each.
In message we can set node name but not device connected to it. So there is case with 1+ screens or broader with many devices connected to one Node.
Another problem: we start LCD server and we want lets say start a server with temperature sensor. We cannot. Lcd would take port and that is all. To do something with this we will introduce event handlers and listers. Big and useful change.
Each module would have an event handler, a function that gets message and do something with it. Returns true when it can handle this event and false when not.
I mention temperature sensor, currently we have none so first lets create one. (more…)
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…)