📜 ⬆️ ⬇️

About connecting and working with Winstar text OLED-displays

Inline (or text) displays are designed to give text information in the form of lines. They are of several types (first of all, LCD or self-luminous OLED), and usually there are numbers 1202, 1602, 1204 or similar indicating the number of lines (in examples 2 or 4) and characters in each line (12 and 16) . There are also single-line displays of this type, but in the following presentation we focus on the more used two-line displays.

The defining part of such displays is compatible with the HD44780 controller (Hitachi). The most popular (at least in our country) displays of this type are produced by Winstar. Moreover, LCD versions (the name starts with the letters WH, for example, WH1602) are one-on-one compatible with the HD44780 command system, and OLED types (the name starts with WEH, for example, WEH001602) have an advanced controller WS0010. Unfortunately, or fortunately - now we will understand.

In contrast to the graphical displays based on the ks0108 controller that we have previously analyzed, the character generator is embedded in lowercase displays. In this case, for us the main difference between the WS0010 and the standard HD44780 is the presence of several (four) code tables for displaying multilingual text. The HD44780 has only one such table, which is why firms in each region have to sell a separate type of display. WS0010-based OLED displays do not require regional breakdowns, which is much more convenient. But not for the user: the ENGLISH_JAPANESE table is enabled by default in WEH-displays, and to enable Russian characters, you need to switch it to ENGLISH_RUSSIAN.

Read more about the table ENGLISH_RUSSIAN
No standard encoding is valid there: in the font table (see the documentation on the links below) there are generally only Cyrillic characters, different in their style from Latin characters. The very idea of ​​saving on Cyrillic glyphs identical to those in Latin style is not new - once there was the encoding DKOI-8, which even with a big delay was even introduced into the standard (see GOST 19768-93 ). But it was invented in the framework of the EU-program, and, accordingly, is based on EBCDIC Aybiema coding, therefore it does not coincide with any modern ones, in which the ASCII table is always taken as the basis (the first 127 characters). That is why in text displays, similar to those considered, their own proprietary encodings are invented, their compatibility with ASCII in the part of the English alphabet is strictly observed.

The standard (attached to the Arduino IDE) LiquidCrystal library, naturally, knows nothing about the four tables, and therefore requires leveling, at least in this respect. But not only: it would be possible, in the end, to get along with the English language. However, at WS0010 the initialization procedure differs markedly, and if it is not corrected, the display will show that every time it starts.
')
Other features
At the same time, we note that Winstar OLED displays have hardware capabilities that are not reflected in the official documentation (or reflected, but not too clearly). A lot of interesting things can be done by soldering the jumpers on the displays. For example, you can read about how to work with WEH displays via the SPI interface (more precisely, “SPI type”) here , and how to enable support for brightness adjustment (via pin 3) - here . But do not rush headlong to the possibility of connecting via a serial interface: the number of connections decreases slightly compared to the four-wire connection, and you need to look for a ready-made library on this topic. If you really really need to reduce the number of wires, a great option is to connect via I2C with an intermediate controller (see, for example, at the end of this article ).

For some reason, Winstar displays a big deficit in terms of coherent documentation (as you can see, this is generally a characteristic feature of Chinese products). It is necessary to indicate where you can download more or less complete documentation without any special errors: here is the LCD display (WH1602) with the HD44780 controller, here the OLED-type displays (WEH1602), here separately the WS0010 controller (we will refer to it later) . And here, if anyone is interested, there is a detailed description of the HD44780 controller in Russian.

Leveling the library LiquidCrystal


The standard LiquidCrystal library, which is traditionally included in the delivery of the Arduino IDE of all versions, is quite suitable for managing lowercase displays on the HD44780 and its analogs. To display the Russian text, there is its version LiquidCrystalRus , which works surprisingly well in all modern versions of the Arduino IDE (which means that the author has correctly approached the UTF-8-character conversion). But to adapt to the OLED displays on the WS0010 controller, editing will still be required. We will continue to mock precisely this library, and therefore we will rename it to LiquidCrystalRus_OLED, so as not to be confused with the usual one. To simplify the task, we will not rename the function, because the initialization will be the same as for the original LiquidCrystalRus.

The changes are as follows:

1. Since the Russian-English table in WS0010 (see page 9 of the datasheet on WS0010 in the link above) is number 2, to switch to it, you need two low bits FT1 and FT0 in the FUNCTION SET command to be set to 10 (0x02) . (By the way, these bits are not used in LCD displays with a single code table). To do this, find the place in the LiquidCrystalRus_OLED.cpp file (line 96 of the file) where the value of the _displayfunction variable is set . In both lines of its initialization (lines 97 and 99) add the appendix " | = 0x02 ".

2. Next, you need to correct the initialization delay after power on. For HD44780, it should be no more than 40 ms (see the documentation for the links above). The library uses the delayMicroseconds (50000) function for this (line 120 of the LiquidCrystalRus_OLED.cpp file). For the WS0010 controller, you need to have a delay of ten times more - at least 500 ms (see the last page of the datasheet at the link above). The requirement is so carefully hidden (files with English documentation on Winstar displays “lost the font” in just this part) that, it seems, very few people have thought about it yet. Therefore, we replace this line with 32 repeating delays of 16 ms each:

for (int i = 0; i <=31; i++) delayMicroseconds(16000); 

3. In addition to this (see also this last page of the datasheet), after this delay, with a four-wire connection , an empty command (0x00) must be submitted five times in a row . Since the Arduino is significantly faster than the display controller, commands should be given with an intermediate delay. They need to be inserted a little further in the text of the begin function, where it’s about 4-bit inclusion (line 147 of the LiquidCrystalRus_OLED.cpp file).

4. But this is not the end. The original ENGLISH_RUSSIAN table has a degree icon (code 0xEF). The variant is extremely unsuccessfully executed graphically (too large), because instead of it I prefer to use a thick top point (code 0xDF) - it is much more like a degree in the usual outline. It could be entered as a code (better octal “\ 337”), but the trouble is in trying to simplify the function of replacing Russian letter codes with codes in the character generator table, the author of the library, based on the UTF-8 encoding (see the previous article ) introduced the condition of replacing any code greater than 0x80 (function LiquidCrystalRus :: write ). Since our 0xDF is clearly greater than 0x80, when you specify the symbol "\ 337" in the code line, an empty space will be displayed instead, because it does not match any Russian letter.

Unfortunately, the standard createChar () function, when I tried to create my own degree icon with it, introduced the display into a complete stupor, from which it could only be output by reloading the program. What you need to understand further and I will be grateful if someone will tell me what's the matter. So, the character generator does not rule in our capabilities, but we can exclude the 0xDF symbol we need from the condition. To do this, replace the existing condition (see the text of the write function) with the following:

 if ((value>=0x80)&&(value!=0xdf)) 

5. Finally, the crossed out zero on this display is not as striking as on the graphic LCD screens. However, in the same write function, I have introduced the replacement of the zero code (0x30) with the code of the letter “O” (0x4f). Those interested can return the crossed out zero by simply deleting or commenting out the replacement line (line 308 of the modified LiquidCrystalRus_OLED.cpp file).
The revised library can be downloaded from the link at the end of the article.

Connection


Now it seems that everything has been corrected, you can connect. Connecting the display WEH001602BG (16 characters, screen length 100 mm) to the Arduino is shown in the following figure:

image

The Arduino pins to which the RS, E, DB4-DB7 display pins are connected must be indicated when the display is initialized:

 // RS, E, DB4, DB5, DB6, DB7 LiquidCrystalRus OLED1(3, 5, 7, 8, 9, 10); 

If desired, you can connect two or even more displays in any interface variant (eight- or four-wire). Data and RS lines can be shared. In this case, the choice between the displays is made via the output E, which is connected to different Arduino outputs for different displays (the connection lines of the second display are shown in gray in the diagram, the output E of the second display is connected to pin 6 of the Arduino). Of course, in the program it is necessary to create two copies of the library (for example, OLED1 and OLED2), in which all outputs are the same, except for E. In this case, the displays can be of different configurations and sizes (8x2, 16x2, 12x2, 12x4, etc. .). This also applies to the case of conventional LCD displays on the HD44780.

And why is there a power relay? The main disadvantage of the WS0010 is the lack of hardware "resets". In HD44780, the built-in rezet may be justified - the author does not have enough experience with LCD screens to say for sure. But Winstar, trying to follow the standard in its design, clearly did not cope with this task. Rebooting the controller without turning off the power causes any murkiness on the display, and you can get rid of it only by juggling the power of the whole circuit and initializing the display from scratch.

In addition, the display may confuse strings when turning off / on the power. The people assure that a full-fledged 8-bit inclusion (instead of 4-bit) helps, but for me it worked even worse. They also persistently say that in the hypothetical “new batches” this is all already fixed, but it is hard to believe (what kind of “new” batches are we talking about when Winstar has been releasing OLED displays since 2008 , and I have had displays for 13 and 14 years release?).

The relay is set to artificially restart the display when the Arduino restarts without turning off the power. It reliably eliminates debris on the screen. The display (or displays) are powered up separately via this relay, which is turned on from the free output of the Arduino (in this case, pin 4) at the beginning of the setup procedure, when the controller is already running stable. And before turning on the relay, it is not bad to give an additional delay of 1000 ms (see the sketch below). The indicated EDR202A05 relay is reed, the winding current is 10 mA, therefore it is quietly controlled from the Arduino pin.

As for the confusion between the lines when turned on, then, in addition to the above changes in the initialization procedure, the power of the entire circuit from this effect is relieved from this effect by a sufficiently powerful (at least 1-2 A) external source with a stable voltage under load of at least 7.5 volt. This dependence on nutrition is obviously a source of discrepancies in many publications, where many authors claim that everything works fine for them. At the same time, the display (or displays) can be connected through the Arduino internal stabilizer (5V output), or through a separate stabilizer, but the main thing is that the input voltage of the stabilizer is sufficiently stable regardless of the consumption surges at the moment of switching on.

Check


To check, I put on a Proba_Rus_Liquid_Crystal_OLED demo sketch imitating the display of a calendar clock with an external temperature sensor:

Display example WEH1602
 #include <LiquidCrystalRus_OLED.h> // initialize the library with the numbers of the interface pins // RS, E, DB4, DB5, DB6, DB7 LiquidCrystalRus OLED1(3, 5, 7, 8, 9, 10); #define RelayPin 4 // 4 -   void setup() { delay (1000); pinMode(RelayPin, OUTPUT); digitalWrite(RelayPin, HIGH); //   delay (500); OLED1.begin(16,2); //16  2  OLED1.clear(); OLED1.setCursor(0,0); // ,   OLED1.print("-22,3\337C"); //10   OLED1.setCursor(11,0); // , 11  OLED1.print("10:22"); // OLED1.setCursor(0,1); //    OLED1.print("16.01.17 "); // 16   OLED1.setCursor(13,0); // , 13  ":" OLED1.blink(); //  delay(1000); } void loop() { /*                13,0    blink */ } 


All the characteristic changes in the library mentioned above are applied here. The program also shows how to flash the colon in the value of hours: minutes using the blink () function. Note that the new output in the same position destroys the blinking of the familiarity, and when you update it, you have to resume it again by first setting the invisible cursor to the same position 13 in the zero line. With a real clock update, it may be easier to update only the numbers in positions 11–12 and 14–15, leaving the blinking colon intact.

The results of the example are shown in the photo:

image

It should be noted that the photo does not convey the shade of the glow of the green OLED display (in this case). In fact, it is a deep green color, with a wavelength shorter than the usual 568 nm for LED displays (seven-segment or matrix). Why are the latter on the background of OLED seem "faded", and their combined use is difficult.

WS0010 has a graphic mode, and Winstar graphic OLED-displays (such as WEG010016) also have this controller installed. Someone noticed that they even have the same matrix. In my opinion, trying to use the graphical mode on a text line display is quite meaningless: the line display has hardware-installed dark gaps between characters and lines that make the picture extremely unaesthetic (see numerous examples of such attempts).

One last note: the durability of Winstar OLED displays. The datasheet indicates the time is 100,000 hours, that is, 11 years. And yet, one of the displays of the 13th year of release (yellow glow) to date (winter of the 16th) has drastically lost my brightness. It's funny that the rest of the same (green) and later (yellow and green 14 years old) parties do not show any signs of dying. Therefore, I don’t dare to say anything with certainty, but just in case I advise you not to solder the displays into the board, but install them on the connectors so that in case of anything they can be replaced without problems.

Download the archive with the approved library and an example from here .

UPD: there was a solution to the problem of a sustainable launch without power manipulation:
https://geektimes.ru/post/287234/

Source: https://habr.com/ru/post/400833/


All Articles