The Wall Display

ESP8266 Wall DisplayI’ve just spent time working on my hallway wall display, the amount of which would be considered commercial suicide. Good job it isn’t commercial.

Of course I’ve not just been working on the pretty colours – I’ve revamped the control codes for the ESP8266-driven controller twice, discovered and fixed an OTA flaw in the code, re-hashed the Node-Red driving code, found and fixed countless other bits and pieces… and in the process taken pause for thought as to why I ever used the Dark Skies Node… you know – in other words – pretty much revamped everything just to improve a simple display.

Oh and I spotted an issue in Node-Red and upgraded to the latest version 0.17.4 which is wonderful.

PLEASE NOTE: If you wish to use the display module depicted above - make sure it is based on the s6d02a1 chip. Boards have the marking "1.8 TFT MODULE" on the bottom. The ones with a single connector (as against one on each side) generally do NOT use this chip and hence are not compatible).

Anyway, I figured some of you might find this interesting so here’s what I’ve been doing the last few days (apart from a trip to the coast and consuming too much alcohol on the odd evening).

Let’s get the important stuff out of the way – the hole in the box doesn’t do anything. Throwback to a previous project and it is waiting to be covered by one of those £1 Chinese back-lit touch-panels I mentioned a blog or two back.

So the box is just an Ebay job, I think it was £3 – sadly I can’t find them right now, lovely job with rounded corners and top/bottom vents. The display is one I call the QD-tech display, based on the 6sd02a1 controller and very cheap. 120x160 pixel LCD – see Ebay or AliExpress.

Glued to the back of this display is a Wemos D1 Mini from AliExpress, dirt cheap ESP-12 based board and they communicate via SPI – simplified to the minimum. I’ve connected resets together, CE to ground and so the only actual connections to the display are 5v and 3v3 (backlight) from the Wemos D1) and ground of course, for signals: clock, data, D/C. That’s it.

I use my well-developed kitchen-sink ESP8266 code for this and had to make some improvements on the way. As I was updating the board over and over and over, learning about the display chip, I noted memory issues occasionally when doing over the air updates – fixed that. I noted that I had no way to tell if the ESP8266 (and hence the display) had reset at any time (to know to do the init code) – fixed that (my ESP8266 code now sends a status message when rebooting). I got sick of the clumsy way I had to update the display, sending line, box, text commands so I amalgamated them all into string commands – and that was such a good idea I went back and made the code for other displays follow the same format.  You can see how all of this might’ve taken up a lot of time.

Node-Red

Above you see the Node-Red code, running on a Raspberry Pi using my usual setup – there are in fact 2 displays – one on my desk and one in the hallway. I check for the ESP12s coming out of reset and send start-up code via MQTT to the displays separately. Overkill, could have just done the one.  That includes setting up the display itself, clearing the screen and putting in that nice white framework of lines and rectangles.  Meanwhile I have timed functions updating the time (once a second) and everything else once a minute.  The weather forecast (see icons in a previous post) comes from Dark Sky and I was having difficulty getting what I wanted out of the Node for that service, when it occurred to me that was just as easy to do an HTTP request – as the HTTP node is able to capture information and convert it to a JSON object. How handy is that.

DarkSky

Above you see the setup to get the forecast… where it says 123 you would need your own (free) key and those are my longitude and latitude values straight from Google Maps. The function on the end – simply does this.. global.set("weather",msg.payload);

So now the global object “weather” contains everything I could ever need. See the info on their site – amazing amount of information. As a trivial example of how simple it is to get info from this – having stored the lot in an object called “weather” -  to get the percentage chance of rain for the day I need nothing more than..

var precip=global.get("weather").daily.data[0].precipProbability;

As I did not want to get barred for calling up information requests too rapidly, I separated off the weather request and now update that every 15 minutes.

You may notice a reference to England – this display is running in Spain but I have a Node-Red setup with sensors back in the UK so the two Node-Red installations exchange temperature/humidity and other info – so I figured I may as well show temperature and humidity from back in the UK.

I’ll not go into the entire code sent off to the display, as mentioned above I’ve very much simplified that now and it is all detailed in the manual I put together for home control.

And that’s it for now – as you can see on the display, it’s quite warm right now and so a bunch of us are off swimming for the day. No doubt I’ll come back full of new ideas.

See video with display and touch-switch

Meanwhile I’ve been checking out the Khadas Vim board and the latest RF Bridge 433 from Itead – but more on this and more later.

Facebooktwittergoogle_pluspinterestlinkedin

130 thoughts on “The Wall Display

  1. What was the bug in Node Red 0.17.4 Pete? I've got an issue at present. I've been playing with that large weather object/flow from your bitbucket. It caused no problems with 0.16.x but I get out of memory errors during start-up and Node Red 0.17.4 refuses to start.

    I isolated the issue by disabling my Dark Sky flow (by using a text editor to edit flows_raspberrypi.json). Was this by any chance the same fault?
    Keith.

    1. Hi Keith - the bug was in 0.17.0 - the little blue lights that indicate you've changed something - if you just MOVED something they stayed on - fixed at 0.17.4

      I'm not getting any errors.. but hang on - the way I've done dark skies - it doesn't do anything at start up - so it could not stop Node-Red working - I just pull in the object at some arbitrary time after startup....

      Not getting any problems up to now.

    2. I had a big failure last week on my previous raspberry, so I installed all from scratch wite THESCRIPT 🙂
      The node red is the 0.17.4 and I had the same problem with memory errors and continuos restart exactly due to the dark sky flow.
      Removing the weather monster (i copied from here) with the text editor everything started running without problem.
      I still have it a darksky call but not the "monster"

  2. I just came across this today. Cost a bit more but looks interesting though.
    https://www.amazon.co.uk/ESP32-WROVER-KIT-board-for-Espressif-ESP32/dp/B071ZLSB2D/ref=sr_1_2?ie=UTF8&qid=1501078881&sr=8-2&keywords=espressif

    SD card might be useful.

    Cheaper directly from Olimex.

    ESP32-WROVER module with 4MB RAM and ESP32 silicone rev.1
    3.2" LCD display
    MicroSD card connector
    Micro USB connector
    Built-in JTAG and UART interface
    RGB LED
    Two buttons
    JTAG connector
    IO 48 pin 0.1" step connector
    5V power supply jack
    ON/OFF switch

    1. Not sure that's a stunning buy - ESP8266 + the 240x320 Ili board I've already done could easily do that for 25% of the price...display would be a little smaller though... according to the spec - that's 8,000 x 4,000 x 1,500 cm - that's a BIG display - and only 18 grms! 🙂

      I think I might want a lot more than no documentation - not everyone uses Arduino - I use the Espressif SDK for example... the price is ok but pushing it - FriendlyArm s430 display _ M3 i.e. Touch 320*480 plus M3 comes to not a lot more and you have full Linux computer, stunningly nice touch display, I2c, SPI etc etc...for not a lot more... three left, will you be able to get any more... what is the screen res etc...

  3. Pete,
    I'm really impressed with your work on this display. I bought a couple and they've just arrived from China. I wonder if you'd mind giving me a teensy bit of help please?

    I'm not sure about the connections from the display to the ESP8266. Here's what I know and what I'm missing;-

    Display_________ESP8266
    1. RST__________Reset
    2. CS - to ground_ NC
    3. D/C__________??
    4. DIN__________??
    5. CLK__________??
    6. VCC__________5V
    7. BL___________ 3.3V
    8. GND_________ GND

    Many thanks
    Keith

    1. From the top of the s6d01a1.c file in my code (and this is only the way I have chosen to do this..

      // In this SPI Driver:
      // WEMOS D6 ESP8266 GPIO12 is MISO (din) - not used here
      // WEMOS D7 ESP8266 GPIO13 is MOSI (dout)
      // WEMOS D5 ESP8266 GPIO14 is clock
      // WEMOS D8 ESP8266 GPIO15 is CS/SS = not used here - assume that CS tied low, reset is tied to Processor reset
      // WEMOS D0 ESP8266 GPIO16 as the D/C line.
      // 5v power and ground and also 3v3 to the backlight - NOT 5v to backlight

      What you are referring to as DIN would be connected to WEMOS D7 ESP8266 GPIO13

      1. I have bought a few of these displays and are now connecting them up to an ESP8266. I am still confused what the connections are. I have the board you linked to on Aliexpress and there are 2 connectors, 1 16p 1 8p. I have figured it out like this looking to your reply.
        Is this right to let it work on HC2017?

        1. In the mean time I found this Youtube video https://www.youtube.com/watch?v=2xsL6JSwlS0&t=330s which explains connection clear enough. I used only the 8p connector. BL = 3.3V and RST = REST on the ESP.
          I start throwing some commands to the HC FW 2.2.02 and find out it does not understand it.
          command: {qd_string:$S;$P10,10;$C255,255,255;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"}
          response:
          Did not understand $P10,10
          Did not understand $C255,255,255
          Did not understand Hello\n$T\n$D$B0,0,255
          Did not understand $I80,80,30,30

          Not yet an idea what I am doing wrong!

            1. After that I changed the command to this via serial input :{qd_string:"$P10,10;$C255,,;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"} and the result was a reset like in the picture! Something terribly wrong. Could this be wrong connections?

            1. I mistakingly took out the $S at the start and that caused the reset. Now I have something on the screen which does not look like Hello. All colored stripes horizontally, does make sense to any one I think I have these connections on paper:

              Tomorrow more after a careful check of all lines according to connection table.

                1. I will have a look in the source code. Difficult to find, I have not had a look for it for a long time ago! Have a link to it pls?

              1. I have an issue with GPIO13. when I boot the ESP then the output says GPIO13 is a LED indicator. After connecting to internet with the debug command it says : Available for general use: Yes. My led indicator stopped blinking and that drawed my attention. Actually I blew out GPIO13 and there seems to be more damage(Cannot flash it). I will have to take another ESP8266. The input DIN should normally have high impedance and I measured about 1M. All of the inputs have! ESP8266 RIP!
                When I give this command my GPIO13 goes off and not blinking anymore! You may consider taking another output for DIN of TFT display?

                1. The whole thing works at 3v3 Leo- there is no way your display did GPIO13 a mischief. Once you start messing with the display, GPIO is otherwise disabled... I'm going a little video for the two of you having problems - it's not a good video - it's a quick video - and in the middle of it you'll see me taking all sorts of liberties with cabling to test a second display - including getting the signal wires wrong the second time - still works - I've never destroyed an ESP8266 in this way - I HAVE destroyed one by putting the power the wrong way - but that's another story. More shortly - the video is uploading.

                  1. Seen your video. I did destroy it somehow, but now convinced it is not the connection. There must have some mishap juggling with wires. Only supply on an output could do this! Ok GPIO13 stops blinking after running $S. I am listening and writing to RX/TX. Should I go through MQTT?
                    I have seen the same display as Keith showed in a comment here(all lines). Voltages are very fine 4.97/3.32V on the pins of the display. It is the right board with 8pin connection.rom.bin the latest. There is some parameter that we are missing! I don't like the switching of GPIO13, maybe that is the source of the problems. MQTT same stripes.

  4. Hi Pete,
    OK - done that. Sorry to be a pain but I have another problem...

    As I understand it, I send a command to the ESP8266 by serial or MQTT like this...

    {qd_string:"$S$P10,10;$C255,255,255;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"}

    Regretfully, the serial terminal reports "Did not understand qd_string". This happens when I send the command by serial or by MQTT.

    I get the same error with:-
    {ssd1351:"$S$P10,10;$C255,255,255;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"}
    {ssd1306:"$S$P10,10;$C255,255,255;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"}

    I am using version 1.9.33 from roms.webutu.com

    Any ideas please?

    1. I have to make assumptions here - that you either compiled the code or got the latest from roms.scargill.net in the last few weeks - as earlier versions of the software certainly would not understand that stuff.

      But - I see you ARE using an old version.. current version is 2.2.02 August 2017 and though the link you've suggested will take you there, better to use roms.scargill.net

  5. Hi Pete,

    Sorry but I'm still having trouble with the QD-Tech display. I've spent hours on it and have got nowhere.

    Here's my setup: a Node MCU board with ESP8266 with 4Mb. It's mounted on the Node MCU base board to give loads of connections and the option to power it from 12V. It was flashed with ESP8266Flasher.exe using the rboot.bin (09-08-2017) and rom.bin (06-08-2017) as per your 'Blowing the Home Control 2017 Code'. This loaded V2.2.01. I did an OTAupdate and got version 2.2.02. The 128x160 SPI display (bought from your link on AliExpress) is connected by the usual DuPont connecting wires. The ESP8266 is powered by the USB connection and I'm using your terminal program (as well as MQTT) to send commands to the display via the ESP8266.

    See next two posts...

  6. Upon power-up or reset, the terminal program shows the usual boot information (it connects to wifi and logs onto Mosquitto just fine) and the the display fills with white pixels. OK so far... I send it your sample string by serial cable: {qd_string:"$S$P10,10;$C255,255,255;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"}, the display goes into Regency Stripe Mode (Like Leo van de Hoek- see photo) and then it seems to freeze. I've tried sending loads of different commands all starting with the $S and the same thing happens. Only pushing the reset button seems to do anything (returning the all-white screen).

      1. Not exactly, but just a bunch of stripes! Maybe this is another command, mine was the example command in the blog.

  7. Final post...

    In my exhaustive testing, I've sent loads of strings to it in an effort to get anything displayed. Strangely, if I send {ili_set:1}, the display does show something recognisable - see attached photo (and yes, it's backwards). Because of this, I think the SPI bus is working - just not the qd_string commands.

    One thing that I've noticed (not sure if it's relevant) is that with SPI active in your software (or if you send {enable13:1}), GPIO13 still continues to flash the LED. Hackitt & Bodgitt suggest that when using GPIO13, you have to forego the status LED - "Note that the instant you use this (the parallel LCD on page 19) – any flashing light on GPIO13 will stop – can’t have it both ways".

    If I've done something stupid, I apologise, but I really would like to get this display working!

    1. Yes, you should NOT be running the terminal software at all on that board, make sure it is turned off - reboot and try again. Make sure it does not try to initialise the terminal software.... It will be interfering with the qdtech code. That is meant for a fast terminal on the larger 320x240 boards.

      I've done a little video to help both of you - but it is taking an age to upload to Youtube. I'll be back, as Arnold used to say.

      1. Seen it. That 's what I suspected to see. So what is the difference between NodeMCU and bare ESP8266 on breakout board? For today I surrender. I will try to continue tomorrow and have a look with my little scope and look at pin GPIO13. goodnight!

        1. The first first thing I do in the code (/user/s6d02a1.c) is to disable the flashing light - clearly it cannot be used to send data and provide a data signal to the display at the same time - this happens in the display initialisation $S and stays off until next reboot.

          If GPIO13 is flashing when you first turn the board on - then it is ok.

          1. Many thanks for the YouTube video Pete. That was good of you to take the time to do that.

            I've been doing some digging - It looks like the Wemos.cc Lolin NodeMCU V3 board that I have uses GPIO2 for the LED - NOT GPIO13. That could answer the questions as to why it keeps flashing.

            I think that I'll order a WEMOS D1 Mini - like you have and try again. Clearly, there are some compatibility issues with the boards that I have.

          2. Oh, sorry I was ASSUMING you put your own light on GPIO13 - there is no standard for this. I use GPIO2 as an input - and generally GPIO2 should be pulled high so I hope they've referenced the LED to + and not ground.

            I'm using the WEMOS D1 sometimes and IOTBEAR other times - at the end of the day any ESP12 based board with the right pullups should do. They are all much of a muchness.

              1. none should need it - the board should already have them on. None of the boards I use needs extra resistors (except for I2c of course) - but I can't control which boards other people buy or where they get them from....

                1. You've turned the terminal mode on - and that's for a different display board!!! It survives power cycling - you need to turn that off. See page 26 of manual - the ili_set command.

                  1. You are talking about the chip as initialised in /user/s6d02a1.c.

                    The chip I have is a ST7735S, clearly stated on the packing . There is a difference from your video as it shows Inteform under a CE sign on the back where yours does not have any text at that place.

                    1. In that case the chip is a different one and hence not supported as such - might be the one I mentioned in the video. I think when I tried that one I got some lines across the screen. Worth trying to compare the ST7735S and s6d02a1 instruction sets - if anyone knows how they compare it may (or may not) be a simple matter to get compatibility. Right now I have guests staying so any in-depth comparison for me is a non-starter. Anyone out there know the difference?

                    2. I've just found my conductive plastic bag that the display came in. Mine too is an ST7735S.

                      Bugger - nowhere on the AliExpress webpage does it tell you the chip type. :-{{

                      Fancy doing an ST7335S driver Pete? 🙂
                      No? Alright - fair doos.

                      At least I now know the reason why - thats something.

  8. Re: SR7735S... in principle I don't have a problem - I had assumed my KMR-1.8 board had the same chip but apparently not... but it would be nice if I didn't have to reinvent the wheel and someone else looking in could tell me the difference between that and the s6d02a1 instructions - ie. what bit(s) need changing. My KMR does NOT have the s6d02a1 but OR the SR7735 but has the supposedly compatible ILI9263 display..

    Indeed a comparison between the three might yield a driver that would power any of them with a new parameter...

    https://forum.arduino.cc/index.php?topic=406501.0

  9. I started looking at that library.. but this as an example didn't fill me with inspiration..

    ST7735_GMCTRP1,16 , // 13: Magical unicorn dust, 16 args, no delay:
    0x09, 0x16, 0x09, 0x20, // (seriously though, not sure what
    0x21, 0x1B, 0x13, 0x19, // these config values represent)

  10. Keith, Leo

    Right I have that KMR board... I have it hooked up so that C/D goes to the AO line, data goes to the SD line and the clock goes to the SCL line. CS to ground, reset to ESP8266 reset.

    Something wrong - but not entirely

    {qd_string:"$S$P10,10;$C255,255,255;Hello\n$C255,,$T\n$C0,255,$D$B0,0,255;$I80,80,30,30"}

    The example above does time and date and a rectangle on the other boards...

    When i run this after resetting the ESP8266, for a BRIEF INSTANT I can see the text and the rectangle - then the screen goes blank.

    This means that pretty much all of the code is compatible except for something minor.. but finding out what that is, could be another matter.5

    Occasionally I can send that command twice - but mostly I have to hit reset on the ESP before sending the command...

    Let's look around and see if there are any comments out there on the web as to what difference in setup or coding could be causing this. I tried missing out part of the commands - ie... leaving just this

    {qd_string:"$S$P10,10;$C255,255,255;Hello"}

    Same thing - hello pops up very briefly - which means the positioning and dot access is the same - but then the screen goes white again. When I use that reduced command, I think I can see the original square for an instant - suggesting the init is not properly wiping the buffer.

  11. I've given the ILI9163 and ST7735 displays a go (i and s respectively instead of S) - and neither work on my display. Remember you MUST reset before testing this stuff as to save pins I use the ESP8266 reset. Give it a go on update 2.203 - I've gone back and tested the original displays which this article supports and that's fine - but with the other drivers and the KMR board there is some kind of fade-out as if the screen is not being refreshed - I have had legible text up there and even the square - but only for a fraction of a second - which does suggest that the pixel driver works just fine..

    1. Well, progress!

      {qd_string:"$s$P10,10;$C255,255,255;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"}

      gives this (see photo) on my ST7735 display (sorry it is sideways). Not quite there yet but at least something recognisable and consistant. It works every time.

      For those who want to know what the difference is - use $s instead of $S.

      Thanks Pete!

      1. Because lower case s is the new GREEN init I put in. Now I have had that show a perfect picture - for about half a second - there is something we're missing here.

        So - what you get there -you say it is consistent - ie every time after a reset - does it STAY there? What if you then send something else (obvously without the $s init) after that? Do you just want to clarify exactly which wires you've taken to where? I just cannot get consistancy - mind you - MY display is not the same as yours at the bottom.. the ones I have (ALL of them) that look like yours work PERFECTLY - the one that says KMR doesn't - of course there's no guarantee it is the same chip as yours.. Where the RED is coming for that rectangle is anyone's guess.

        1. Yes, it is consistant - every time after a reset. I put it there and it stays there. I haven't left it for hours but long enough to know it does not disappear after a some amount of milliseconds.

          If I send separate commands like this...

          {qd_string:"$s"}
          {qd_string:"$C255,0,0;Hello this is a test\n"}
          {qd_string:"$C0,255,0;Another test\n"}
          {qd_string:"$B0,0,255;A further test"}

          It changes the white boot screen to a black background and as the commands are fired into the display, they appear as I send them.

          My wiring is exactly as you have stated above, but for the record:-
          Display__________ESP8266
          1. RST___________RST
          2. CS-to ground__ No connection to ESP
          3. D/C___________D0
          4. DIN___________D7
          5. CLK___________D5
          6. VCC___________5V
          7. BL____________3.3V
          8. GND__________GND

          The RED rectangle should be BLUE but it comes from the end part of your example string...

          {qd_string:"$S$P10,10;$C255,255,255;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"}

          So, for my display, it seems to init OK and reliably. It seems to respond to commands correctly (I'll test the rest of the commands later). The colours RED and BLUE seem to be swapped. Finally, the graphics are not displayed properly (looks like shadowing - timing out maybe?)

          Let me know if you'd like me to try something else Pete.

  12. If you want to dig into the relevant page and have a look I'm quite happy to make changes but I've no idea why this isn't working (of course I've no proof what chip is inside the KMR board I have).

  13. Yesterday I was trying with an example on an Arduino D1 (ESP8266), but I could not figure out the connections. So after your change I flashed my ESP8266 again and upgraded to 2.2.03. I connected my PC scope and see signals coming when I send this example command( {qd_string:"$S;$P10,10;$C255,255,255;Hello\n$T\n$D$B0,0,255;$I80,80,30,30"} ). I don't like the signal levels. This is what I catched https://leovanderhoeknl.tinytake.com/sf/MTkxNjQ0NV82MTA4Njk3 .
    The rise time if the logic signals at 3.3V is more than 1microsec. A lot of pulses don't rise over the 1 level. I run ESP on 160MHz, tried 80MHz no difference. I only produce color stripes.
    Can you make anything from this?

      1. I have made an SPI connection! On the other connector there seems to be SDA/SCK(I2c?).
        The terminal mode "worked" sort of(mirrored text).
        Your HC2017 is also capable of i2c for these displays? I do not understand anything now anymore. I downloaded the manual and there is nothing there anymore for qd display! Rewriting???

  14. I got my display showing some sensible output.
    I used the TF_eSPI library and a Arduino compatible D1 WiFi(Uno with a ESP8266-12E.
    Problems still are there like RED and Blue exchanged and first 3 rows have random color dots(160 side) as well as the same for the first few pixels on the 128 side. When I setup the SPI freq. for 80MHz it lets me believe it is working perfectly, but I suspect there is a freq. limit in the library. Possibly errors in the lib?
    On the hardware side I had to exchange CSD/C.
    My connections are:
    display D1 WiFi
    RST RESET
    CS D3
    D/C D8
    DIN D7
    CLK D5

    1. I think you have the wrong library. I remember reading something about a library for a similar chip working but the colours were wrong....

      Still, further than I got - I got the right colours, the right pixels - but the display faded out after half a second to white. So near yet so far.

      1. There is text which is perfectly allright. So at least some hope we will get it as it should be. I will dig a bit deeper! Trying some other commands.

      2. Right colors now! There are a few probable settings you have to try and find out which is the right one(for me it is GREENTAB2)The tab color is on the protective screen sticked to the display, mine is green.
        I now only use an example program that comes with the lib, not your HC firmware!

        1. Hmm, that is pretty much it - but when I do that - my display comes up instantly - then fades to white after under a second. Clearly I need to play with this some more. Maybe at the weekend, time permitting.

          1. Seems you are giving reset commands. I have done reset commands by hand by taken away the wire, which is 0V. Then the reset command is given after a few seconds. I have put in a pulldown resistor and then reset is instantaneously! Under normal operation reset is high.

            1. The reset line in my case is attached to the ESP8266 reset.... the CS line is attached to ground (as there are no other SPI devices I didn't see the point of using CS - and this works a treat for all other boards).

              Hmm

            2. Well, I THOUGHT the reset clue was partly correct. I connected reset to 5v... and got a stable text... (red and blue the wrong way around)..

              But then I tried again and the same thing happened.... image up - then faded to white.

              1. One difference: I have the CS line connected to D3 of D1 WiFi, I read something about it somewhere during my searching on Internet!
                Btw: You can change colors by changing the init variable like ST7735_GREENTAB2 in User_Setup.h. The author of the lib suggest also that you can get rid off the random colors at the edge, none of ST7735_xxxx worked also not com-speed SPI.
                I did an experiment and found out that I could finally reset the display so it did not display anything after it. I did some rough resetting lots of times. Changing displays did not solved it. Only erasing the prom totally reinstated the right memory value somewhere after loading the program again. So in your case there is a PROGMEM value set to the wrong value, I suppose.

    1. OK I ordered 2 of them.
      I however have the feeling with the other display driver we will get it working also.
      I will continue to do some digging in the code and I think I have found something in the TFT_eSPI lib which is not right. I do understand that the random colored pixels on the edges are addressed in the lib, but I suspect the setup file(s) is(are) not complete to use that correction!

      1. As this is a 132x162 dot display and we use only 128x160 there will be random colored pixels if the display is not cleared as a whole(132x162). So only the clear function at startup contains an error by not doing all pixels but only the "visible" ones. all functions work perfectly with the examples of the library except for the edge rows.

    2. Gents,
      I'm sorry but I've been away for a few days and have only just caught up with this section of Pete's blog.

      Regardless of drivers and the like, I think the main problem here is total lack of technical information about this product on the AliExpress website. I bought my displays from the link provided at the top of this article. I expected to receive a display with an s6d01a1 controller chip. Clearly what arrived at my door (and Leo's) is different from what Pete received.

      There's nothing on the pcb to indicate what the controller chip is. Fortunately I kept my packaging. This clearly says that the driver chip is a ST7735. I think that AliExpress has changed the product driver chip without telling anyone. Their cop-out is this phrase in the description... "We will send the latest version of product, the upgraded function. It may has different shape or color. If you can't agree, pls don't buy."

      About the KMR board... This one:- https://goo.gl/nujZoP. It seems that the default chip is the ST7335, although (as the info on the web page suggests) it could be supplied with the ST7335, the ILI9163 or the s6d02a1.

      The only one I found that advertises the s6d02a1 is https://goo.gl/wKwHrZ It 'says' it has an s6d02a1 chip. The only problem being that this board is much more expensive!

    1. So one bright idea up the swanny... I tested the Adafruit ST7735 TFT code using the Arduino library. Not a sausage - which suggests that the chip on MY KMR board is NOT that one - which no doubt accounts for why I can't initialise it properly!

        1. That would be a shame - there's quite a bit of interest in this subject.

          Trying to prove ST7735 code on a board of dubious parentage is bound to be frustrating. I'm sure if you had an ST7735 board, it would only require a few tweaks.

          Is there anything I can do to help? Shall I send you one of my display boards? Spain or UK - I don't mind.

          1. If you are 100% sure.. ok - FIRST of all - get it working on the Arduino library...

            https://github.com/norm8332/ST7735_ESP8266

            If you can get it working reliably on this - I should be able to - and then I can tell what I'm doing wrong....

            Is that something you can do? If that works, send me the board, I'll get it working on that same library - which proves there are no hardware issues - and from there, it should be easy.

            Mine does NOT even start up on that library...

            1. May be you have to shift aside for a short while and do something more rewarding! I am at the same level at the moment. At least I understand why these pixels on the side are appearing. This is because the resolution we use is 128x160 and registers are set wrongly during initialisation to clear the background to black.Better would be to use this display with 132x162 pixels and change the driver to that resolution! Further on there is absolutely nothing wrong with the display, it is fast with lib TFT_eSPI. I have run that example with the benchmark. I think the author of the lib has taken some shortcuts and almost only translated the Adafruit lib to this version. It is terribly complex on the lowest level when you read the datasheet. We could ask Bodmer to explain how to avoid these extra pixels on the sides and tell us how to edit User_Setup.h to avoid them, now we are left in the dark with his comments in the code that we should try just another TAB when it is not working! There is also no mentioning of reading the ID bytes of the display(see datasheet) to use this and change the behaviour. Another fhought: what is Sitronix doing in this field? What is their market? Don't they have drivers/API?

            2. I don't see the problem to use TFT_eSPI lib! This is a derivative of the Adafruit_ST7735 lib and works with my ST7735S.

              1. Lea if you wish to use that you are free to do so. My code is not Arduino based and is in C, not C#. It is not always easy to convert. I generally avoid Arduino libraries as they are often bloated and my code does a LOT more than just a few displays. If you spot any differences in the init tables do let me know.

                1. There is a bit of a com misunderstanding. The Adafruit library is cpp, same as TFT_eSPI! The init routine sets the displays according to datasheet, an array of commands and data for the different kind of ST7735(TABs). The graphics functions like text, lines will not be that much different from the other display driver s6d02a1.In fact the ST7735 looks like a clone of that(datasheets show exactly the same commands)! Also the TFT_eSPI lib can be used for s6d02a1. So if you can get the Samsung chip to work than the Sitronix one should be OK too. The Aliexpress sellers don't make a difference and SUGGEST compatibility.
                  I will try to compare the init settings of the 2 displays, different format so will take some time.
                  Why don't you try to run your s6d02a1 on the TFT_eSPI,clock example?

            3. There is a mistake in the setup of ST7735. You defined the width not correctly.
              #define ST7735_TFTWIDTH_128 128
              // for mini
              #define ST7735_TFTWIDTH_80 80 <<<<<<<<<<<<<<<
              // for 1.44" display
              #define ST7735_TFTHEIGHT_128 128
              // for 1.8" and mini display
              #define ST7735_TFTHEIGHT_160 160

              This ends up with a width setting of 80.

              I tried this in my TF_eSPI driver and the display stays blank, nothing happens. Comment out the width for mini!

              1. So logically this should be correct -
                // experiment from adafruit - header info for st7735
                // for 1.44 and mini
                #define ST7735_TFTWIDTH_128 128
                // for mini
                //#define ST7735_TFTWIDTH_80 80
                // for 1.44" display
                //#define ST7735_TFTHEIGHT_128 128
                // for 1.8" and mini display
                #define ST7735_TFTHEIGHT_160 160

                So version 2.2.04 is up there - you can probably {otaupdate} it - anyone with a known good ST7735 want to give it a go?

                In my case, the first time I ran it - I got completely random data then white within a fraction of a second. I reset the ESP (and hence the display) - this time a perfect display for a fraction of a second (again) then back to white.

  15. I have been looking into your source and only find the ili9340_init. Nothing about s6d02a1. Did you remove it because of the problems? I suspect you only need to exchange the init and further on use the ili_commands. I could make a textfile with all settings for ST7735 in the form as you have done them.

  16. So the question is I guess, has anyone managed to get a working example AT ALL in ESP8266 code, of the 7735 code or at least sometihng working with a board marked KMR 1.8 SPI. I can't really test this further until I have something working to compare with. A clarifier for those looking in - the 6sd02a1 code here works a TREAT with the chip it was intended to work with - but it seems that not ALL the boards that should be using this chip ARE. Most of my boards are marked on the bottom "1.8 TFT SPI" and work perfectly - but I have a board (god knows what chip it actually has in it) marked KMR 1.8 SPI - which does not work but is only stones' throw away- able to put text, lines and boxes up - sometimes, exactly as they should be - for a fraction of a second before going white. So near yet so far.

    1. Well, I'm working on it but it's a steep learning curve as I've done next to bugger all with Arduino. If I get anywhere, I'll let you know Pete. In the meantime, maybe let this subject go quiet until we have some more info.

      Thanks for your work on this one.
      Keith.

  17. I have a working copy on 2.2.04 Hooray!!!!!!! I was using $S all the time as it must be $s for ST7735.
    Red and Blue reversed. This is one of the settings in Rcmd2. Greentab2

    1. Leo - it is in the setup for 's' in 6sd02a1.c

      case 's' : s6d02a1Startup(Rcmd1); //doesn't work on my board
      s6d02a1Init(Rcmd2green);
      s6d02a1Init(Rcmd3);

      The character code MUST be compatible or I would not see my strings and boxes appear momentarily...

      1. So your board does not seem to be with ST7734(version R or S will not make so much difference).
        As it works now we could add the reversing of the colors in different setups like $sg,$sg2,$sr for GREENTAB,GREENTAB2 and REDTAB respectively. Blacktab seems to around also, but I red someone saying he has seen a lot but never a ST7735B.

  18. Well, there you go Keith - could be your lucky day, Leo says the mods I made work - which means I have YET ANOTHER chip if Leo is using my unmodified code version 2.2.04 released today with the same wiring - so either I have a duffer (unlikely) or I'm using yet another chip. Test yours - if you're using 2.2.03 you can just {otaupdate} to update your code.

    1. Yes I used the wiring as stated in the source. It is the first time I am working with GIThub like things making a clone in VScode. I am very happy to be of any help!

        1. Did you follow my suggestion $sg,$sg2,$sr. I still have wrong colors BGR.
          Tomorrow more. Other things to attend to.

          1. No - I've had no time to try out new menu options - I'm putting too much effort into this one now as it is.... I simply tried the register fix you suggested. I take it it made no difference?

    2. Many thanks Pete but, for me, there's no improvement. For the record, If I send this to my display (through your terminal and with V2.2.05 loaded in the ESP):-

      {qd_string:"$s"}
      {qd_string:"$F4$C255,0,0;Hello\n"}
      {qd_string:"$F5$C0,255,0;Goodbye!\n"}
      {qd_string:"$F0$B0,0,255;Bonjour"}

      This is what I see...

      The words horse, flogging and dead spring to mind 🙂

      1. I have 2 displays. One gives me about the same errors as on this picture. The other seems quite right, but there many bit faults in the character,data does not seem to com faultless. Positioning seems alright. Init with$s sometimes is a bit shifted a pixel. Something wrong with the SPI com!

  19. It is sad, but I have found out the SPI communication is not reliable in this configuration. I have regular spurious pixels set or cleared in characters. Also my second display shows more errors, like heavily distorted characters, misplaced lines on the rectangle and random bg color on the side pixel row. The TFT_eSPI interface does not show these faults. I suppose until you have time to investigate that we can forget about this display in HC2017. I have ordered a few with Samsung chip(will take a few weeks to arrive). If you like I can send you a ST7735 display to see they work with TFT_eSPI. You cannot even get your piece to work with TFT_eSPI lib?

    1. I am assuming you're talking about the chip you use, not the 6sd02a1. We need to be careful not to confuse anyone reading in - the software works for that board perfectly as far as my tests can tell and I have several on test. Attempts to get this to work with other boards - especially those I don't have, were always going to be an issue. If they work that's a bonus.

      I've no wish to use the Arduino software other than simply to compare if I have a problem with my own. I have no idea what you mean when you say "get your peice to work with the TFT_eSPI lib. My software is not designed to work with Arduino libraries - it is stand-alone.

      1. Yes my board with ST7735. it is not going to work on HC2017 without a lot of effort. I assumed you have also one which does not work on your Firmware. To test if any HW fault then test it on that lib. I ordered me a few with s6d02a1. The with ST7735 I will find some other use.

  20. I think at this point I may resign my KMR display to using as a door-stop. I still have several of the 66d02a1 displays which operate perfectly - the challenge now is to get a supply that is guaranteed to actually be the same board. Now I have the dirt cheap touch switches I have lots of use for these. Incidentally Keith the mere fact that you get that far with the display pretty much proves that mine has a different chip altogether. In your case, it may be that the actual driving code (as against init) should be slightly different. I'm going to put this to rest now - too many variations.

    1. I agree! Whilst I would have loved to have this little display working in my house, the effort does seem to outweigh the benefits.

      Anyway, thanks for sticking with until now Pete - Much appreciated.

Leave a Reply

Your email address will not be published. Required fields are marked *