Nextion an LCD the makers can benefit from...

Posted on
  • I stumbled across a touch LCD on indiegogo that sorta resembles the touch screens from 4d systems:­on-a-cost-effective-high-performance-tft­-hmi

    looks pretty cool and only has a few more days left. Might be of use to people here. I think @allObjects was working on a touch screen project using an Espruino for the "brain" but the post has been buried and I can't seem to find the post....

  • ...yep, for the display and control of my DIY (Marine) GPS and for some games and touch-painting... I had a small UI system going, very easy to use, very compact. But it did not include 'real' graphices, just buttons, text, checkboxes. Of course, the game stuff had some 'graphics'. If you search for LCD controller ILI9341 LCD CONTROLLER and Touch Screen you may find the posts.

    The biggest challenge was the speed and memory... for example, I built an alogrithm for calibrating the touch screen - btw a quite spungy resistive one. The modern, snappier ones are all capacitive now... (combined with other technologies - like Samsung phone screens with stylus - wher the stylus is recognized already from qute far and eventual touch 'point' is indicated with a white little circle...

    In a UI of that small size, you need to be able to quickly backup display area for a so-called overlay.... which is not really an overlay because there esists no such thing like layers... This means 2..3 bytes per pixel and FAST to backup, paint the overlay (pain over!), restore from backup (paint-over again). Since pin numbers are limited and a lot - almost all - happens within Espruino, acutual graphical data is transmitted.... and that give the memory issue and the speed challenges (I you do not want to spend GPIO pins to go at least 8-bit, better 16 bit parallel...). For font, built in fonts work faster, but the controller supports not much for that...

    A 'display' module like that - with built in render support for all kinds of text/gauges/graphics dsiplay, additional memory, max-parallel access - is quite a nice thing. Nothing has changed: good displays require still 'large, but still very very fast moving parts... like the 'old RAMDAC' (that had to 'feed' the guns for the 'unstoppable' electro-magnetic ray deflection coils 'in' a Cathode-Ray-Tube/CRT display...

    The graphics stuff showed some of the limitaitons of the hardware / connectivity setup and in which hardware component functions were (software-aly) implement.

    Took a closer look at­on-a-cost-effective-high-performance-tft­-hmi. It will be fast for sure, design of applications become a bit more tricky - even more than X11 display server and other ultra-light-client-technologies (from the past): nextion display server has to be prebuilt (complemented/loaded with custom UI definitions/components), and application will have to send the commands over serial to make it happen, as well as receive the input over serial. Things that are not preloaded will just take for ever to happen... so displaying some imagery or alike from the internet will be sluggish - even more sluggish that with an SPI, because max speed for plain asynch serial is much lower (and more error prone) than SPI's. With the limitations clearly understood, it can become a wonderful cheap component. For industrial apps though, I'd rather take 'large' up-to-date phone or micro/mini tablet - fablet as client device which has html5 and alike support, where the whole client app can reside and 'behaves' - and only raw / concise data is exchanged with the sensor and motion controller device(s). See also the Shiny UI conversation. The flood very affordable 5..7 tablets provide options on many levels far beyond a tethered, basic TFT display with touch, that makes it easy to justify the cost not so big cost difference anymore.

    Since communication has anyway to be availble practically anytime, I feel the approach of / @mkarliner more promising: taking advantage of the existing, very powerful communication and display infrastructure and focus on predefined, custom extendable widgets, data/package formats, and a 'easy to use' IDE to get the things composed on a purposed platform with stub and and test support / regression test support.

  • It's definitely an interesting idea... Others have done similar things before, but it looks like this time they've managed to make the UIs look a lot better.

    Actually interfacing to it seems like it should be easy - but it won't involve any of Espruino's existing graphics API.

    As @allObjects says, I wonder whether sometimes it might actually be cheaper/easier to use a cheap phone/tablet as the user interface - and then you can use normal HTML/CSS/JS for the user interface.

  • As @allObjects says, I wonder whether sometimes it might actually be
    cheaper/easier to use a cheap phone/tablet as the user interface - and
    then you can use normal HTML/CSS/JS for the user interface.

    It seems like that is the better/fastest/intuitive choice.


    I started a basic version. Feel free to bugreport, extend, etc...


  • Yes, the phone is maybe cheeper, but eats more power. :)

  • @hygy - thanks for this, definitely interested in giving this a go with espruino. Nextion + Espruino on ESP8266 + voltage regulator = instant tiny cheap wifi HMI running javascript.

  • @hygy that is awesome. Maybe now I can put my nextion screens to good use :-)

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview

Nextion an LCD the makers can benefit from...

Posted by Avatar for d0773d @d0773d