Обираємо дисплей для розумних пристроїв під керуванням ESP8266 з прошивкою NodeMCU / Lua

Які дисплеї можливо застосувати у конфігурації ESP8266 з прошивкою NodeMCU? – Для відповіді на це запитання, у даній публікації розглянемо наявні можливості та обмеження програмно-апаратної платформи NodeMCU.

Інтерфейси ESP8266
Вбудовані контролери дисплеїв
Графічні бібліотеки адаптовані і інтегровані у NodeMCU
Технології дисплеїв
Локалізація
Бюджет пінів GPIO
Замість висновків

Інтерфейси ESP8266

Мікроконтролер ESP8266 може запропонувати два поширених інтерфейси:

  • Програмну реалізацію послідовної шини I2C;
  • Апаратну реалізацію послідовного інтерфейсу SPI.

Примітка: дисплей з паралельним інтерфейсом підключення не розглядаємо, адже він потребує, у більшості випадків, додаткового розширювача портів вводу-виводу, хоча підтримку подібних дисплеїв в NodeMCU, теж реалізовано у вигляді Lua-модуля LyquidCrystal (LiquidCrystal Module).

Поміж згаданих двох основних варіантів потрібно обирати – апаратний SPI чи програмний I2C. Кожен варіант має свої переваги та недоліки.

Послідовна шина I2C в прошивці NodeMCU за замовчуванням може працювати лише в режимі Standard(Slow, 100kHz), а якщо ви самостійно складаєте і компілюєте прошивку, також є можливість працювати з швидкостями Fast(400kHz) та FastPlus(1MHz) з оновленим драйвером I2C. Надшвидкий режим HIGH-speed mode (3.5MHz clock) – не підтримується.

Послідовний інтерфейс SPI тактується частотою процесора через поділювач частоти у налаштуваннях ініціалізації. За замовчуванням швидкість процесора ESP8266 80 МГц, а поділювач на SPI дорівнює 8. Таким чином частота швидкодії інтерфейсу SPI знаходиться на рівні 10 МГц за замовчуванням. І це значно краща швидкість (порівняно з I2C) для роботи з дисплеями високої розподільної здатності і глибини кольору на піксель.

Графічна бібліотека UCG, що є в прошивці у вигляді C-модуля, дозволяє задавати глибину кольора восьми бітами на кожен канал R, G, B. А тому маємо можливу глибину кольорів 8 * 3 = 24 біт (2^24 = 16 777 216 варіантів), хоча це також залежить від конкретного дисплея і вбудованого спеціалізованого контролера. Наприклад, контролер SSD1351, як і більшість LCD-контролерів,  дозволяє передавати до 18 біт для кодування кольору на піксель (2^18 = 262 144 варіантів).

Таким чином, якщо ми маємо картинку 128 х 128 пікселів з глибиною кольору 24 біт, тобто розмір картинки, у даному прикладі, буде складати 393 216 біт, або 49.15 КБайт, то ми повинні мати спроможність її обробляти і передавати на дисплей через обраний інтерфейс з потрібною частотою оновлення кадрів, яку, в свою чергу, має бути здатен підтримувати вбудований у дисплей контролер. В SSD1351 частота чіпа приблизно дорівнює 2.8 МГц, що за замовчуванням забезпечує дисплею з картинкою 128х128х18, частоту у 74.4 Гц оновлення кадрів. 

Примітка: Для порівняння, частота оновлення кадрів у іншого OLED контролера – SSD1327, монохромного 1.5” 128 х 128 з 16-біт відтінками сірого, знаходиться на рівні 113.4 Гц, при тому, що його чіп працює на частоті лише 595 КГц. Відсутність необхідності встановлювати 384 драйвери (128 * 3) для кожного з кольорів, як у SSD1351, дає SSD1327 відчутне підвищення продуктивності всієї обчислювальної системи модуля дисплея.

Звісно, картинку не потрібно надсилати у контролер з частотою у 113.4 разів на секунду, адже є буфер кадру – RAM всередині чіпа дисплея. Тому картинку не оновлюють повним кадром, а будують поступово, елемент за елементом. 

Але якщо б ми задалися подібною метою – оновлювати повним кадром, то нам потрібно було б забезпечити швидкість на інтерфейсі SPI на рівні 44,9 Мбіт / с, що теоретично цілком можливо, враховуючи частоту тактування SPI у 10 МГц і відповідну можливу граничну швидкість у 10 Мбіт/с, що може забезпечити оновлення 25 кадрів на секунду. Frame rate у 25 кадрів на секунду цілком достатньо, щоб спробувати виводити відео на такий дисплей, але звісно, Lua для цієї задачі буде слабкою ланкою, та і мета у нас набагато простіше – інтерфейс користувача. 

А от на інтерфейсі I2C, у нас би нічого подібного не вийшло від слова взагалі.

Примітка: Ба більше, якщо почитати документацію на дуже популярний мультимедійний інтерфейс HDMI, відразу стає зрозуміло, що цей інтерфейс настільки складний і вибагливий по обчислювальним ресурсам, що навіть мови не може йти, щоб спробувати його застосовувати на 32 бітному контролері типу ESP8266 / NodeMCU. Для того, щоб полоскотати уяву, – швидкість передачі даних HDMI 1.0 – 4.9 Гбіт/с, HDMI 2.1 – теоретично до 42.66 Гбіт/с.

Вбудовані контролери дисплеїв

Більшість дисплеїв має вбудований спеціалізований мікроконтролер. Вбудований у дисплей контролер відповідає не лише за побудову зображення, а і за перелік наявних інтерфейсів комунікації, що підтримується.

Серед підтримуваних інтерфейсів можуть бути:

  • паралельний інтерфейс;
  • послідовний інтерфейс:
    • I2C;
    • 3-провідний SPI;
    • 4-провідний SPI.

та ще багато інших.

Також на ринку є універсальні дисплеї без явно детермінованого виробником  вбудованого контролера. Зазвичай такі дисплеї підтримують достуступний широкому загалу інтерфейс, наприклад SPI. Але такі дисплеї потрібно програмувати на низькому рівні, що вимагає від головного контролера потужних обчислювальних ресурсів – оперативної пам’яті насамперед, а від розробника – кодування команд контролера на низькому рівні.

З точки зору підключення до головного контролера, потрібно обирати дисплей з таким вбудованим контролером, який без складнощів і зручно підключається і підтримується як на апаратному рівні, так і на рівні програмних графічних драйверів та мови програмування.

Графічні бібліотеки адаптовані і інтегровані у NodeMCU

Для прошивки NodeMCU і контролера ESP8266 розроблено дві основні графічні бібліотеки U8G2 та UCG, які в свою чергу підтримують перелік конкретних вбудованих дисплейних чіпів, а також підтримують інтерфейс SPI та/чи шину I2C.

З переліком вбудованих чіпів, що підтримуються, можливо ознайомитися тут: u8g2 Module і ucg Module

Програмна платформа NodeMCU підтримує дві поширені бібліотеки тому, що у них є відмінності у призначенні:

  • U8G2 – бібліотека для монохроматичних дисплеїв;
  • UCG – бібліотека для TFT/LCD кольорових дисплеїв.

Кожна з цих бібліотек, в межах впровадження під NodeMCU, має свої особливості, не дивлячись на їх зовнішню схожість.

Наприклад, бібліотека U8G2 підтримує як дисплеї з інтерфейсом I2C, так і з інтерфейсом SPI. В той же час, бібліотека UCG, підтримує лише дисплеї з інтерфейсом SPI. Так пішлося не через рішення розробників бібліотеки, а тому що кольорових дисплеїв з повільною шиною I2C просто не виробляють.

Або наприклад, бібліотека UCG підтримує можливість задати колір графічним елементам, а бібліотека U8G2, як ми вже знаємо – ні.

Зверніть увагу: Яскравість дисплея. Як вже зазначалося, дисплеї LCD / TFT за своєю технологією вимагають керування яскравістю підсвітки. Потрібно пам’ятати і враховувати, що бібліотека UCG не вміє керувати цим процесом. Фактично це окреме електричне коло, яке дозволяє керувати підсвіткою за допомогою окремого GPIO (дискретно, або через PWM) і для цього потрібно писати відповідний код. Без підсвітки на LCD/TFT дисплеї нічого не видно, наче він вимкнений.

У той же час, бібліотека U8G2 вміє керувати яскравістю OLED дисплеїв через окремий метод, який доступний розробнику з рівня Lua, як і всі інші методи бібліотеки.

Технології дисплеїв

Ми не будемо робити складний розбір різноманітних технологій, а лише звернемо увагу на ключові і вирішальні (для нас) відмінності найпоширеніших з них: OLED, LCD, TFT, IPS, E-INK у прив’язці до платформи NodeMCU.

Технологія LCD (TFT, IPS в тому числі) сама по собі будучи не вимогливою по енерговитратам, все ж потребує забезпечення підсвітки (так звание backlight). А це в свою чергу вимагає застосування додаткового GPIO ESP8266 і керування вбудованим у дисплей світлодіодом(и) підсвітки за допомогою ШІМ (PWM).

OLED дисплеї не вимагають додаткової підсвітки, але мають відносно низьку, порівняно з TFT/IPS дисплеями, розподільну здатність та густину розташування пікселів на дюйм. OLED дисплеї зазвичай мають одночасно два інтерфейси на вибір: I2C чи SPI. Дисплеїв технології OLED з розмірами більше ніж 128×128 пікселів буде складно знайти.

Дисплеї ж технології LCD/TFT/IPS, маючи порівняно високу роздільну здатність (на рівні 200, 300, 400 пікселів мінімум), не дозволяють застосовувати менш швидкісний I2C інтерфейс і відтак, оснащуються інтерфейсом SPI, що вимагає від 4 до 8 GPIO для підключення до головного контролера, замість всього двох GPIO, як у випадку з підключенням через послідовну шину I2C.

Підсвітка в LCD/TFT/IPS, що забезпечується окремо встановленими по периметру дисплея світлодіодами, просто фізично не може бути рівномірною, що дуже сильно кидається в очі. 

Дисплеї LCD/TFT/IPS, маючи потужніші вбудовані контролери, зазвичай можуть забезпечити вищі – кращі характеристики по частоті оновлення кадрів, що може бути визначальним для певних проектів. Втім, OLED дисплеї дають набагато кращу яскравість і насиченість кольорів.

У випадку з програмною шиною I2C, яку реалізовано у ESP8266 (не плутати з прошивкою NodeMCU / Lua для ESP32, де реалізовано обидві шини – і програмну, і апаратну), вивід даних на дисплеї з розмірами 128 на 128 пікселі і більше, відбувається на межі швидкодії програмної реалізації інтерфейсу, що може призводити до нестабільної роботи головного контролера і навіть зависання (спрацювання watchdog). В той же час, дисплеї будь-якої розподільної здатності (ми тестували до 320 х 240), що підключено через апаратний SPI – працюють на ESP8266 з прошивкою NodeMCU, швидко і стабільно.

Дисплеї з технологією E-INK і подібні, ми тут не розглядаємо здебільшого через те, що NodeMCU не може запропонувати готової бібліотечної підтримки для них. Також ці дисплеї мають занадто високу вартість, не дозволяють ними нормально користуватися у темряві, мають дуже низьку швидкість оновлення кадру.

Писати ж власний код на низькому рівні щоб спробувати підключити такий дисплей, нам здається марною тратою часу.

Локалізація

Невідомим для нас чином, у розробників прошивки NodeMCU (чи відповідних бібліотек безпосередньо) вийшло так, що бібліотека UCG не підтримує українізовані чи русифіковані шрифти, але підтримує кольорові дисплеї. В той же час, бібліотека U8G2 підтримує будь-які необхідні шрифти (їх сотні), українські в тому числі, але не підтримує кольорові дисплеї.

Необхідно враховувати ці суттєві з нашої точки зору особливості і обмеження.

Бюджет пінів GPIO

У мініатюрних контролерах типу ESP8266 про бюджет наявних GPIO потрібно пам’ятати і турбуватися завжди. 

1) Якщо ви обрали дисплей, що підключається до головного контролера через інтерфейс SPI:

  • OLED потребує 4 сигнальні GPIO на SPI (MOSI,CLK, DC, CS):
    • MOSI <-> D7;
    • CLK <-> D5;
    • DC <-> D4;
    • CS <-> D8;

вільними лишаються D0, D1, D2, D3, D6. D0 зазвичай теж застосовують під сигнал RST (ресет дисплея), D1 & D2 – наприклад, під шину I2C, D3 – під кнопку чи переривання. D6 також можливо використати, наприклад, як світлодіодний індикатор стану.

  • LCD/TFT потребує 4 сигнальні GPIO на SPI (MOSI, CLK, DC, CS) + GPIO підсвітки:
    • MOSI <-> D7;
    • CLK <-> D5;
    • DC <-> D4;
    • CS <-> D8;
    • BL <-> D6;

вільними лишаються D0, D1, D2, D3. На один менше ніж у випадку з OLED. D0 аналогічно – можливо застосувати під RST.

2) Якщо ви обрали дисплей, що підключається до головного контролера через послідовну шину I2C:

  • OLED потребує два сигнальні GPIO (SDA, SCL):
    • SDA <-> D2
    • SCL <-> D1

Вільними лишаються D0, D3, D4, D5, D6, D7, D8.

  • LCD/TFT не підключається через I2C, бо є лише SPI.
Споживання

Споживання дисплея залежить від заповненості площини дисплея інформацією і встановленої яскравості. Кольорові дисплеї споживають значно більше монохроматичних. Електроніка (вбудований спеціалізований контролер) дисплеїв різних технологій з екраном без інформації, споживає приблизно однаково.

Розміри дисплеїв

Для мініатюрних пристроїв, найпоширенішим варіантом вважається OLED монохромний дисплей з діагоналлю 0.96 дюйма з вбудованим чіпом SSD1306. 

Але як це зазвичай це буває, дизайн корпусу пристрою може потребувати значно більших розмірів дисплея. В такому випадку на вибір розробника може бути такий ряд розмірів: 1.3”, 1.4”, 1.5”, 1.8”, 2”, 3.2” і так далі.

Замість висновків

Ми розглянули наявні можливості і обмеження програмно-апаратної платформи NodeMCU.

Вибір найкращого варіанта дисплея – це завжди компроміс:

  • розмірів,
  • споживання,
  • роздільної здатності,
  • яскравості,
  • кількості графіки та тексту на один кадр,
  • підтримки україномовних шрифтів.

Бажаємо успіхів!

Корисні посилання:

Datasheet SSD1306

1.5inch RGB OLED Module

Datasheet ST7735S

SSD1327-datasheet.pdf